7 common mistakes people make with DMARC
Interest in DMARC is growing exponentially, but most of the organizations that deploy DMARC don’t actually achieve its full anti-spoofing benefits. Here’s how to overcome the most common DMARC deployment challenges.
In our conversations with thousands of prospects and customers, we’ve found that while the interest in DMARC is high, it’s also very easy to run into problems configuring it. This is reflected in the fact that, while nearly one million domains have now deployed DMARC, only about 16 percent of them have reached the point at which their DMARC records actually protect them from spoofing (known as DMARC enforcement).
If you have published a DMARC record but haven’t reached DMARC enforcement yet, don’t worry. It’s not your fault: This project can be very challenging even for the world’s biggest email security experts.
Here are seven common mistakes that domain owners make with setting up DMARC records and configuring underlying email authentication standards.
Want to know more and get actionable solutions for each of these problems? Download our free whitepaper: 7 Mistakes to Avoid on the Path to DMARC Enforcement.
Mistaking monitoring for protection
We’ve run across accounts where folks believe their domain is protected, but the DMARC record is left at p=none — for years. The policy p=none puts the domain into monitoring mode so that DMARC-compliant receiving gateways send reports back to the domain owner about messages that passed and failed authentication. But mail gateways only send data — they continue to deliver all email normally, even if it fails to authenticate. Monitoring is both useful and a required first step in the DMARC journey, but it does nothing to protect against spoofing.
Believing in the myth of “partial enforcement”
By default, a DMARC policy applies to 100% of all mail unless a percentage is specified with a pct= tag. Unfortunately, if you are at p=quarantine and set a percentage less than 100, that means that some spoofed messages will still be delivered. There is no such thing as “partial” DMARC enforcement. While there are ways to use percentages usefully, don’t fall into the trap of thinking you’re fully protected if your pct= tag specifies anything less than 100%.
Forgetting about subdomains
The default setting for subdomains is to obey the main policy (e.g. p=reject). Sometimes in the process of getting to DMARC enforcement, domain owners focus on getting their main domain to enforcement, while postponing the work needed to bring subdomains into enforcement by setting a subdomain policy of “sp=none.” Unfortunately, this means that those subdomains can still be spoofed. Phishing emails sent from firstname.lastname@example.org won’t get through, but email@example.com will. To be at enforcement, subdomains need to be protected, just like the main organizational domain.
Out of order records
We’ve seen many records that are not using correct DMARC syntax. An example: a DMARC record that places the policy, such as p=reject behind another statement instead of directly following the v=DMARC1 statement. Putting these tags in the wrong order can cause problems, making DMARC authentication fail or causing mail gateways to skip the DMARC check altogether.
Omitting a reporting address
One of the most important aspects of DMARC is that it provides domain owners with feedback about email authentication status, including passes as well as failures, via aggregate data reports. But if you omit a reporting address (via a rua= tag), you will not get this data — and you’ll learn nothing about authentication failures and possible domain impersonation (spoofing) attacks. The reporting address makes it possible for the DMARC record to specify how to report these failures.
Misconfigured SPF records
The SPF record is a text record published in DNS that contains a list of IP addresses of permitted senders, rules pointing to other types of DNS records, and directives that reference SPF records of other domains. While there are many ways to misconfigure an SPF record, one of the most common mistakes is building a record that requires the receiving domain to do more than 10 domain lookups for each message it receives. If a domain’s SPF record requires too many lookups, some or all email sent from that domain may not authenticate successfully.
To get around this limitation in the standard, some domain owners “flatten” their SPF record by pulling all the IP addresses of approved sending services forward into the primary SPF record. A flattened SPF record lists a bunch of IP addresses explicitly, rather than including equivalent DNS lookups. But that introduces a new problem: The need to continually maintain the flattened list of IP addresses, in case an email-sending service you’re using adds or removes IP addresses.
Mismanaged DKIM Keys
DomainKeys Identified Mail (DKIM) uses public/private key cryptography to sign email messages, which validates that the email came from the domain that the DKIM key is associated with — and that the email has not been modified in transit.
DKIM keys are long strings of seemingly random data and are easy to get wrong in DNS. Even a simple copy/paste issue can cause errors, leading legitimate email messages to fail DKIM.
Additionally, experts recommend rotating DKIM keys at least every six months to prevent attackers from stealing or compromising the keys. Many organizations have no method for managing and rotating keys; some even use the same DKIM key for each email service they use. If that one key gets compromised, every service is vulnerable to attack.
Mistakes 6 and 7 are the most critical ones to fix, because without properly configured SPF AND DKIM, DMARC enforcement will never happen.
DMARC requires that the message pass either SPF or DKIM authentication, and it also requires alignment (a match) between the visible From: address in the email message, with either the Return-Path found in the SPF record or the domain in the DKIM signature. So you’ve got to get these fundamental email authentication protocols right before you can protect your domain with DMARC at enforcement.
To learn more about how to address these common mistakes, see some examples, and get actionable advice on how to fix the errors, read our free whitepaper: 7 Mistakes to Avoid on the Path to DMARC Enforcement.