DMARC Deployment Mistakes

Interest in DMARC is growing exponentially, but most organizations implementing DMARC aren’t taking advantage of its anti-spoofing benefits. Here’s how to overcome the most common DMARC deployment issues.

Being Stuck on “Policy None”

During DMARC deployment for our clients, we’ve come across accounts where people think their domain is protected. But the DMARC record has been left at p=none for years. 

The p=none policy, along with rua and ruf tags, puts the domain into monitoring mode so receiving mail servers/gateways can send back aggregate reports and authentication-failed messages back to the domain owner.

With this policy, mail servers/gateways only send back reports—they don’t prevent fraudulent, spam, or phishing emails from being delivered.  Instead, all emails go straight to the recipient’s inbox, even if they  aren’t validated. Monitoring is a useful and necessary first step towards DMARC implementation, but it doesn’t protect your domain or prevent scammers, spammers, and bad actors from exploiting your company’s name.

By default, your DMARC policy applies to 100% of all received mail unless a percentage is specified using the pct tag. Unfortunately, if the DMARC record uses p=quarantine and the percentage is set to less than 100, email recipients can still receive fake messages in your company’s name. 

There’s no such thing as “partial” DMARC compliance. Your domain isn’t entirely safe if your pct tag indicates anything less than 100%.

Going Full “Reject” at Once

While it’s easy to set your DMARC policy to “Reject” just by changing the record syntax in your DNS, it’s not something we recommend. Achieving full DMARC compliance is a methodical process that includes:

• Reviewing all your sources.
• Making them compliant one by one. 
• Going through the motions of the “None” and “Quarantine” policies. 

Skipping these steps is a common DMARC deployment mistake and will lead to errors in source alignment, where legit emails can be rejected.

Foregoing Authentication for Subdomains

The default setting for subdomains is to inherit the main domain’s policy (for example, p=reject). Sometimes, in the process of enforcing DMARC, domain owners only focus on protecting their primary domain. 

Many people discount the importance of safeguarding subdomains. They fail to implement an effective protocol by opting to use the sp=none subdomain policy. 

In reality, this means that all subdomains (existing and non-existing) can still be spoofed. To enforce DMARC effectively, subdomains must be protected—just like the main organizational domain.

Using the Wrong DMARC Syntax

Using the correct DMARC syntax is crucial. For example, a DMARC record that has a policy, like p=reject put after another tag (and not immediately after v=DMARC1 tag), can cause errors. Placing the tags in the wrong order can lead to problems like failing DMARC authentication or causing mail gateways to skip DMARC checks altogether.

To avoid such issues, generate a DMARC record according to all specifications you need.

One of the most important aspects of DMARC is that it provides domain owners with feedback on the status of email authentication, including omissions and failures, through summary reports of the data. 

But if you don’t put the reporting email address in the rua tag, you won’t receive this data. Moreover, you won’t be informed of any authentication failures and possible attacks like domain spoofing. The email address(es) mentioned in rua tag tells receiving mail servers where they need to submit reports with aggregated DMARC data.

Exceeding the ‘10 DNS Lookups’ for SPF

An SPF record is a text record published in DNS that contains a list of IP addresses of authorized senders and directives pointing to specific DNS entries of the same domain or referring to SPF records of external domains. While there are many ways to misconfigure an SPF record, one of the most common DMARC deployment mistakes is creating a record that instructs the receiving domain to perform more than 10 so-called “DNS lookups” for every message received. 

A DNS lookup basically resolves the a, mx, include and redirect directives to IP addresses. If the sending domain’s SPF record requires too many DNS lookups, it may create a heavy load on the receiving mail server. Thus, some or even all received emails might fail SPF authentication.

To work around this limitation, some domain owners flatten their SPF record by extracting and putting all the IP addresses of approved dispatch services into the main SPF record. 

The flattened SPF record explicitly specifies a list of authorized IP addresses. But this introduces a new problem: The need to maintain the integrity of the IP address list at all times. The email sending service you use may also add or remove sending IP addresses on their side, causing the SPF PermError “too many lookups.” 

Fortunately, you can use our EasySPF tool to repair and optimize your SPF records, add, remove, and update your authorized sending sources, and resolve the “too many lookups” error.

Neglecting DKIM Configuration

DomainKeys Authenticated Mail (DKIM) uses public/private key cryptography to sign email messages. This confirms that the email came from the domain to which the DKIM key is associated and that the email was not altered in transit.

DKIM records are long strings of seemingly random data that can be easily mistaken in the DNS. Even a simple copy-paste problem can lead to errors resulting in failed DKIM authentication. Deploy DKIM only when you’re sure you’ve generated the correct record syntax.

In addition, experts recommend rotating DKIM keys at least once every six months to prevent keys from being stolen or cracked. Many organizations don’t have methods for managing and rotating keys. Some even have the same DKIM key for every email service they use. If that one key is compromised, each service is vulnerable to attack.

Without properly configured SPF and DKIM, DMARC enforcement will never happen.

More DMARC Deployment Mistakes

1. One of the most glaring DMARC deployment mistakes is specifying default or implicit tags in the record. For example, you can skip setting the percentage tag to 100 (pct=100) because when the DMARC record is fully compliant, the percentage is implied to be 100.
2. Another DMARC deployment mistake that can lead to security issues is using another domain for receiving your reports without external domain verification.
3. Ignoring parked domains is yet another slip-up made by decision-makers. If you’re not thorough with DMARC deployment, security and domain misuse issues are likely.
4. Lastly, it’s easy to start neglecting your DMARC reports when you’ve reached compliance. However, continuous monitoring and periodic brush-ups are extremely important for any security concern.

Conclusion

DMARC requires an email to pass either SPF or DKIM authentication checks. Domain alignment (a match) must occur between the visible From: address of the message and:

1. The address in Return-Path: field of the message header; and 
2. The domain in DKIM-Signature: field of a message header. 

You must set up these basic email authentication protocols correctly before you can enforce domain protection with DMARC.

To learn more about how to troubleshoot these common issues and get helpful tips on how to fix errors, read our article: How to Implement DMARC with EasyDMARC.