Domain-based Message Authentication Reporting & Conformance, or DMARC, protects an organization’s trusted domains from email spoofing. Due to the exponential growth of email fraud, and the fact that domain spoofing attacks account for a significant percentage of these attacks, it’s no wonder that many businesses are looking to introduce DMARC authentication to ensure that emails sent on their behalf are legitimate.

In fact, the Department of Homeland Security recently required that all civilian government agencies complete the DMARC implementation within a short timeframe, and urged private companies to do the same.

Many companies have not yet adopted DMARC because it is difficult to enforce and there is a high risk of DMARC problems, such as blocking legitimate email. To better help companies and agencies protect their trusted domains, we have identified five common mistakes made when deploying DMARC authentication.

Mistake #1: Don’t account for all legitimate mail streams, including third-party senders

Many senders, including third parties, send emails on behalf of other organizations. It can be difficult to recognize all of the legitimate senders, particularly when various departments within a company use third party email senders, such as marketing, sales, and human resources. 

However, if all legitimate senders are not detected and allowed to send an email on behalf of the company, essential communications may be blocked, causing business disruption. Stakeholders from all related agencies should be consulted and active.

Mistake #2: Let a subdomain inherit the top-level domain’s policy

DMARC implementation is usually focused on the top-level domain (ex: acme.com), and organizations can neglect the importance of configuring unique policies for each of their subdomains (ex: mail.acme.com). The DMARC policy that is applied to the top-level domain is immediately applied to subdomains. If all subdomains are separately accounted for, this can result in accidental blocking of legitimate email.

Mistake #3: Don’t have a system or tool in place to parse the data from DMARC records

The receiving email service providers’ DMARC aggregate reports provide important details about your email ecosystem, but they are not easy to understand. If you can arrange data in a way that adds meaning, it’s just data. Furthermore, keeping up with the sheer volume of reports sent and collating all of the data in a timely way can be difficult.

Mistake #4: Don’t understand SPF and DKIM alignment

DMARC alignment prevents spoofing of the “header from” address by:

1. Matching the “header from” domain name with the “MFROM” domain name used during an SPF check, and
2. Matching the “header from” domain name with the “d=domain name” in the DKIM signature.

Proper alignment guarantees that the transmitting identity is authenticated in relation to the domain that it appears to be. Third-party email senders, once again, present additional obstacles. Third-party vendors, for example, typically have their own “MFROM” domain. As a result, they pass SPF but not SPF alignment. DKIM is in the same boat. DKIM can be passed by third-party vendors, but not DKIM alignment.

Mistake #5: Use improper DMARC syntax or content

Although there are instructions for generating DMARC records, they can be confusing at times. Improper formatting and/or content, as well as incorrect policy values, are also popular. To prevent DMARC issues, keep the following in mind:

• Don’t forget to use “_dmarc.”
• If you have multiple reporting addresses – separate with a comma, don’t include a space after the comma, and ensure the second address starts with MailTo:
• Use correct policy values (example: use “none” instead of “monitor”)
• Check for typos
• Missing characters or extra characters

Mistake #6: Believing in the myth of “partial enforcement”

Unless a percentage is defined with the pct= tag, a DMARC policy applies to 100% of all mail by default. Unfortunately, if you use p=quarantine and set a percentage lower than 100, some spoofed messages will still get through. There is no such thing as DMARC compliance that is “partial.” 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%.

Mistake #7: Immediately going to a full ‘Reject’ policy

We often see businesses implement DMARC and then instantly switch to a complete “Reject” policy. Going to a complete “Reject” policy right away is a common blunder because it will almost certainly result in the loss of valid email. We suggest deploying DMARC policies in phases. Begin by tracking your traffic and searching for anomalies in your files, such as unsigned messages or whether you’re being spied on. 

Adjust your strategy to dmarc quarantine in small steps until you’re satisfied with the outcome. Once again, keep an eye on the results, this time in both your spam capture and your DMARC files. Adjust your policy to ‘Reject’ until you are certain that all of your messages have been signed. Be sure to keep an eye on all reviews to ensure that the results are satisfactory.

Mistake #8: Forgetting about subdomains

Subdomains are set to follow the key regulation (e.g. p=reject) by default. Domain owners often concentrate on bringing their main domain to DMARC compliance while deferring the work required to bring subdomains into enforcement by setting a subdomain policy of “sp=none.” Unfortunately, this means that spoofing of certain subdomains is still possible. Phishing emails sent from whatever@example.com won’t get through, but xyzz@mail.example.com will. To be at enforcement, subdomains need to be protected, just like the main organizational domain.

Mistake #9: Omitting a reporting address

One of the most critical features of DMARC is that it provides domain owners with aggregate data reports on email authentication status, including passes and failures. You won’t get this data if you don’t provide a reporting address (via a rua= tag), and you won’t know about authentication failures or potential domain impersonation (spoofing) attacks. The reporting address makes it possible for the DMARC record to specify how to report these failures.

Mistake #10: Misconfigured SPF records

The SPF record is a DNS txt record that includes a list of approved senders’ IP addresses, rules referring to other forms of DNS records, and instructions referencing SPF records from other territories. Although there are several ways to set up an SPF record incorrectly, one of the most common errors is creating a record that allows the receiving domain to perform more than 10 domain lookups for each message it receives. If a domain’s SPF record requires too many lookups, some or all emails sent from that domain may not authenticate successfully.

Some domain owners “flatten” their SPF record by pulling all the IP addresses of authorized sending services forward into the primary SPF record to get around this restriction in the standard. Instead of including identical DNS lookups, a flattened SPF record lists a bunch of IP addresses directly. However, this presents a new issue: the need to keep the flattened list of IP addresses updated in case the email-sending service you’re using adds or eliminates IP addresses.

Conclusion

DMARC authentication is a useful method for preventing email theft in organizations. The method of implementing a DMARC implementation plan is a journey, but the benefits of preventing phishing and email spoofing attacks are numerous.

ProDMARC is a DMARC email protection solution that gives companies the visibility, resources, and services they need to easily and confidently incorporate DMARC.