DMARC deployment mistakes while implementing DMARC
Interest in DMARC is growing exponentially, but most organizations, implementing DMARC, are not really achieving all of its anti-spoofing benefits. Here’s how to overcome the most common DMARC deployment issues.
Here are common mistakes domain owners make when setting up DMARC records and basic email authentication standards.
Top DMARC deployment mistakes
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 that DMARC aware of receiving mail servers/gateways send back aggregate reports and authentication-failed messages back to the domain owner.
But those mail servers/gateways only send back reports – they continue to deliver all email as usual, even if it doesn’t authenticate. Monitoring is a useful and necessary first step towards DMARC implementation, but it does not protect against counterfeiting.
By default, the DMARC policy applies to 100% of all received mail unless a percentage is specified using the pct tag. Unfortunately, if the DMARC record has p=quarantine and the percentage is set to less than 100. It means that you will still receive fake messages. There is no such thing as “partial” DMARC compliance. Do not assume that your domain is safe if your pct tag indicates anything less than 100%.
The default setting for subdomains is to inherit the main policy (for example, p=reject). Sometimes, in the process of gaining access to DMARC, domain owners focus on enforcing the protection of their primary domain. Thus postponing the work required to bring subdomains into action, by setting sp=none subdomain policy. Actually, this means that all subdomains (existing and non-existing) can still be spoofed. To enforce the rules, subdomains must be protected, just like the main organizational domain.
DMARC deployment problems
Many people do not use the correct DMARC syntax. Example: a DMARC record that has a policy, e.g. p=reject, put after another tag, not immediately after v=DMARC1 tag. Placing the tags in the wrong order can lead to problems, failing DMARC authentication, or causing mail gateways to skip DMARC checks altogether. Get more information about DMARC tags, follow the link.
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 do not put the reporting email address in rua tag, you will not get this data. And you will not know anything about authentication failures and possible attacks using domain spoofing. The email address(es) mentioned in rua tag tells receiving mail servers where they need to submit reports with aggregated DMARC data.
SPF and DMARC deployment
SPF record is a text record published in DNS that contains a list of IP addresses of allowed 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 mistakes is creating a record that makes the receiving domain perform more than 10 so-called “DNS lookups” for every message received.
DNS lookup basically resolves the a, mx, include and redirect directives to IP addresses. So if the sending domain’s SPF record requires too many DNS lookups, that may create a heavy load on the receiving mail server. Thus some or even all received emails might fail the authentication check.
To work around this limitation of SPF specification, 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 IP addresses. But this introduces a new problem: the need to maintain the integrity of IP addresses list at all times. And if the email sending service you use, adds or removes sending IP addresses on their side.
DKIM and DMARC
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.
DKIMs are long strings of seemingly random data that can be easily mistaken in DNS. Even a simple copy / paste problem can lead to errors resulting in DKIM crashing of legitimate emails.
In addition, experts recommend rotating DKIM keys at least once every six months to prevent keys from being stolen or cracked. Many organizations do not have methods for managing and rotating keys. Some even use the same DKIM for every email service they use. If that one key is compromised, each service is vulnerable to attack.
So without properly configured SPF and DKIM, DMARC enforcement will never happen.
DMARC requires the message to pass either SPF or DKIM authentication check. And domain alignment (match) between the visible From: address of email message and 1) address in Return-Path: field of the message header and 2) domain in DKIM-Signature: field of a message header.
You must set these basic email authentication protocols right before you can enforce your domain protection with DMARC.
To learn more about how to troubleshoot these common errors and get helpful tips on how to fix errors, read our article: how to implement DMARC with EasyDMARC