Use this ONE WEIRD TRICK when implementing a DMARC record

The one thing, the absolute most important thing to keep in mind when setting up a DMARC p=reject policy is: You have to know all of the sources of all legitimate, desired mail that uses your domain name, before you proceed. If you don't, here's what happens: You turn on p=reject, and suddenly offer letters to new employee candidates start bouncing. Why? Because you didn't know that your human resources department uses a third-party service provider to handle applications and offers. It sends its own email, from its own server, and it's either that the mail is not being authenticated with DKIM, or that it's sending IP addresses are not included in your SPF record.

I've seen it happen more than once.

What other things are important considerations when planning to move forward with a p=reject DMARC policy? Share in comments and I'll wrap them into a future post.

1 comment:

  1. Even if you're *reasonably* sure that you have done all the diligence above and do not expect a lot of rejects, make sure your RUF and RUA addresses are able to handle large amounts of traffic. You never know whether a receiver out there has a screwy implementation, or some phisher will launch an attack. Consider hosting these addresses with a third party - try not to ddos your own corporate email.

    ReplyDelete

Comments policy: Al is always right. Kidding, mostly. Be polite, and you're welcome to join in, even if it's a differing viewpoint.