Top 5 DMARC Deployment Mistakes

With phishing exploits at an all-time high, there’s growing awareness of how DMARC can help protect domains and make email more trustworthy. It’s no secret that enacting DMARC can be a complex and intimidating process. DMARC project teams often enter uncharted territory and make mistakes as they deploy the DNS-based protocol. Our support and deployment teams have assembled some common mistakes to be aware of to help make your DMARC project smoother and more successful.

Top 5 DMARC Mistakes

1. DMARC record not found
Publishing a DMARC record with a policy set to p=none to observe domain activity and not disrupt email is the first step of deployment. By not having a published DMARC record, you not only remain unaware of how your domain is being used outside of your own monitored infrastructure, but you are not taking advantage of the domain protection DMARC offers. To publish a DMARC record you can get started here.

2. Policy enforcement on active domain without monitoring
Having a DMARC record with policy enforcement yet no reporting to monitor the domain (e.g. v=DMARC1; p=reject) doesn’t give you the visibility you need to maintain your domain protection. Monitoring is key to understanding who and what is sending email on your behalf.

3. Specifying implicit tags
For example, pct=100 is the same as not putting that tag/value pair in. The same goes for rf=afrf, aspf=r, adkim=r. Adding these tags and values makes the record look more complicated and takes up more space because the TXT record becomes longer.

4. Sending reports to a different domain
Sending reports to a destination which includes a different domain in the RUA and RUF tags without creating an external domain verification record can lead to a security risk. Google, in particular, does not check for this requirement, so you still get reports. But other DMARC reporters follow the specification requirement of not sending reports to destinations whereby the domain in the RUA and RUF tags are different unless the domain in those tags explicitly publishes the external domain verification record in DNS. This record tells the world that it is okay to send DMARC reports about other domains to them. This is a necessary security limitation to prevent DDoS attacks, and it is likely that Google will check for this requirement in the future.

5. DMARC syntax invalid
Here are some points to keep in mind when creating DNS records:

• Don’t forget to place a semicolon between tag/value pairs.
• Use p=none and not p=monitor. p=monitor was an early, pre-publication DMARC policy that was supplanted by p=none, the monitoring policy.
• Specify the mailto: in front of the submission reporting address.
• Make sure the DNS TXT record has the hostname of _dmarc
• Place the p= tag after v=DMARC1 — it is required at that position.
• Remove quotes around a TXT record in DNS, though some DNS providers do accept quotes.

dmarcian strives to make email safer by expanding the knowledge and awareness of DMARC. If you haven’t begun your DMARC project, you can register for a no-strings attached, free trial here.

Want to continue the conversation? Head over to the dmarcian Forum.