When organizations implement Domain-based Message Authentication, Reporting and Conformance (DMARC), they expect to tighten email security and protect against spoofing and other spam email attacks. Unfortunately, many organizations experience errors and don’t complete the DMARC setup to enforce a DMARC policy, leading to far less secure email systems than they think they have.
This article provides details to help an organization establish a robust DMARC policy with detailed information on:
- Troubleshooting DMARC
- Common Reasons Why DMARC Fails
- Bottom Line: DMARC Enforcement Reduces Phishing
Troubleshooting DMARC
Troubleshooting and deploying a correctly formatted Domain-based Message Authentication, Reporting and Conformance (DMARC) policy will require precision and time. Fortunately, there are many resources available from the DMARC.org website, email vendors, and even full-service DMARC vendors to help IT teams with the process.
General Troubleshooting Process
When attempting to fix a DMARC policy after initial setup, organizations will run into various issues. Basic DMARC requirements help to define the best practices for troubleshooting, which include:
- Verify and Check SPF, DKIM, and DMARC policies in detail
- Deploy DMARC in monitoring mode (p=none)
- Check DMARC report for several weeks to identify legitimate email sources suffering rejection
- Resolve rejection issues by updating the appropriate policy (SPF, DKIM, DMARC, or email vendor settings)
- Once legitimate email issues have been resolved
- Gradually enforce DMARC to ‘p=quarantine’ or ‘p=reject’
- Check for new rejection issues
- Repeat steps until all sending domains are verified, enforced, and fully protected
- Periodically check reports for IP address changes or new domain conflicts to be resolved or spoofing sites to report or block
Vendor-Specific DMARC Troubleshooting Guides
Most DMARC settings do not rely upon the specific email vendor, but some details may be vendor specific — especially with regard to DNS deployment, DMARC activation, and troubleshooting. Fortunately, most email vendors also provide guides or tutorials.
Microsoft 365 and Gmail provide tutorials and specialized instructions for properly configuring DMARC policies for their email customers. Similarly, smaller vendors such as Twillio’s SendGrid will publish their own troubleshooting guides, so IT teams will need to check with their email and DNS providers for specific information.
Specialized DMARC Vendors
Harried IT teams without resources may not have time to study the requirements or troubleshoot the processes. For these organizations, specialized DMARC vendors can be an effective solution to save time and money.
Seth Blank, CTO of Valimail and co-chair of the DMARC Working Group, suggested, “To evaluate a platform’s ability to help you reach enforcement, assess its user experience, automation and customization.” Organizations should also verify that these potential vendors can service the full spectrum of policies (SPF, DKIM, DMARC) and can explain how they might address common issues such as SPF lookup limits.
Common Reasons Why DMARC Deployment Fails
DMARC deployment can fail for a host of reasons. Initially, an organization may make mistakes with their DMARC record that causes DMARC checks to fail. Once the DMARC record is corrected, the organization may find many emails suffering DMARC rejection which requires another round of troubleshooting.
Beyond the technical issues, DMARC can also fail due to insufficient resources dedicated to supporting DMARC or even by not escalating the DMARC settings. An IT team must work with other stakeholders in the organization to stress the importance of DMARC and overcome these obstacles.
Common DMARC Mistakes
Text files are small and simple; however, simplicity also means that small mistakes can create big problems. The DMARC working group publishes a list of common problems with DMARC records that includes detailed issues, and we will cover the major categories here.
Invalid DNS Records
Incorrectly published DMARC, DKIM, and SPF records with extra text or incorrect text will invalidate the records. These issues can stem from several different types of errors, including:
Wildcard records include wildcard characters or the addition of extra text that might invalidate the record such as:
- SPF records using the IP address: ip4: 201.5.YY.ZZZ (instead of numbers)
- Incomplete DKIM public encryption keys
- Random text or comments inserted into the record such as “Please contact your registrations service provider…” or or “***” or “This domain’s zone has been disabled”
- Domain or vendor owner inserting names into the text file
Not following directions can be similar to wildcard records because it includes extra text; however, in this case it typically will be instructions for content that have remained in the file such as “descriptive text” in the following sample: “_dmarc.fromage.XXXXXXXX.fr descriptive text v=DMARC1; p=reject;…”
Common formatting errors avoid wildcard and extra text issues but create problems in other ways such as:
- Order of elements: “v=DMARC1” must come first and be listed in all capital letters so both “p=none; v=DMARC1; rua=mailto:…” and “v=dmarc1;P=Reject;…” will cause errors
- Forgetting variable tags or proper syntax such as writing
- “DMARC1” instead of “v=DMARC1”
- “rua=email@…” instead of “rua=mailto:email@…”
- Forgetting semicolon (;) separators or using the wrong separator between variables such as with “v=DMARC1 p=none…” or “v=DMARC1:p=none…” instead of “v=DMARC1;p=none…”
- Permitted, but potentially problematic formatting such as
- Using capital letters other than for DMARC1 such as “V=DMARC1;P=NONE…” instead of “v=DMARC1;p=none…”
- Unneeded spaces such as with the extra space before “mailto” in “rua= mailto:email@…” instead of “rua=mailto:email@…”
Typos and extra characters will often sneak into a DNS record because of copy-paste errors or even specific DNS requirements. For example, some DNS servers require semicolon characters to be escaped using a backslash (\) character and the file may be found with too many (\\) backslashes or forward slash (/) characters used by accident.
Bad record content is listed separately by dmarc.org, but it has a lot in common with typos and formatting errors. For example, instead of using one of the three permitted values for the “p” tag (none, quarantine, reject), the record may use incorrect (“blocked” or “monitor”) or mispelled (“quarintine”) values.
Overlooked Subdomains
When creating SPF files, an organization will be limited to 10 DNS query lookups. Often this means larger organizations will have multiple SPF files and will segregate out specific subdomains for separate SPF records.
However, when the organization creates their DMARC record, the organization may focus exclusively on the top level domain (EX: SampleOrganization.com) and may overlook their subdomains (EX: ITNotifications.SampleOrganization.com or SalesEmails.SampleOrganization.com).
Unless explicitly handled separately, the DMARC policy deployed on the top-level domain automatically trickles down to subdomains. Overlooking subdomains that require separate handling may unintentionally block legitimate emails originating from servers on those subdomains.
Overlooked DMARC Updates
All DNS records, including DMARC, require updates as organizations evolve. For example, an organization will switch the IP addresses for email servers as they upgrade or transition to the cloud. Each IP address change requires an update to the filed policy.
Similarly, companies send email campaigns from a variety of third-party vendors for marketing (HubSpot, Mailchimp, etc.), sales (Salesforce, etc.), surveys (SurveyMonkey, etc.), accounting (Quickbooks, etc.), and help desks (Zendesk, etc.). As they adopt new vendors or these vendors change their email infrastructure, again, DMARC, SPF, and DKIM will require updates to keep up with the changes and avoid blocking legitimate emails.
DMARC Rejections
When implementing DMARC, organizations start with ‘p=none’ to avoid rejecting improperly configured but legitimate emails. The three most common ways legitimate emails will be rejected include:
- Failure to set up DKIM Signatures for email vendors — this leads to a mismatch between the sender (Gmail, Microsoft 365, etc.) and the DMARC domain
- Failure to whitelist third-party senders with DNS providers — these providers sign emails with their domain by default, which causes a mismatch
- Forwarding entities altering body and headers — resenders, gateways, and malware scanning solutions will intercept the email and then forward it on. The forwarding replaces the sender IP address, which causes a DMARC mismatch
The first two issues can be managed by correctly establishing DKIM signatures for email vendors and correctly whitelisting third-party senders with DNS providers. Unfortunately, there isn’t much that can be done with the third issue unless the organization can contact or control the forwarding email servers.
In addition to the three most common issues, an organization can also run into issues with SPF and DKIM alignment. DMARC alignment seeks to prevent spoofing of the “header from” address by matching:
- The “header from” domain name and the “MFROM” domain name used during an SPF check
- The “header from” domain name with the “d=domain name” in the DKIM signature
Often, third-party email senders cause issues by using their own “MFROM” domain. This may pass SPF or DKIM, but not alignment. This issue will require coordination with the vendor to properly adjust the SPF, DKIM, and DMARC files.
Insufficient Resources
Smaller organizations always struggle with time-intensive IT issues. Seth Blank admitted, “Frankly, setting up DMARC is complicated, which accounts for the gap between policies and policies at enforcement.”
Insufficient Staffing
Despite the simplicity of the specific technologies, the regular maintenance to keep SPF, DKIM and DMARC current can be difficult to keep up with for large companies with dedicated teams. For small organizations with small IT teams, the maintenance can be nearly impossible.
“DMARC is an intricate standard reliant on two additional email standards, SPF and DKIM. Both of these standards would be strenuous to configure on their own. Smaller companies without an IT department to dedicate to DMARC do not have the resources to implement these records together,” said Blank.
Insufficient Tools
The DMARC aggregate and forensic reports sent from the receiving email service providers include crucial email ecosystem information, but the machine-readable files will not be intuitive or easy to read for humans. Additionally, for even moderately-sized organizations the sheer volume of reports received can overwhelm an organization attempting to manually collate and parse the information in a meaningful way. Fortunately, many different DMARC reporting tools can be obtained to enable rapid and meaningful analysis of DMARC tools.
Failure to Escalate DMARC Settings
The most significant issue with DMARC stems from organizations failing to escalate their DMARC settings. Whether out of fear of blocking legitimate emails or simply because implementing teams overlook escalation, failure to switch from p=none to a more rigorous policy undermines the effectiveness of DMARC.
Unless an organization sets an enforcement policy to “quarantine” or “reject,” even emails recognized as fraudulent will still be allowed to pass through to inboxes. Without the more restrictive enforcement policy, organizations place an unnecessary burden on email security applications and increase the likelihood of a phishing attack successfully impersonating a brand.
“A policy not configured to ‘quarantine’ or ‘reject’ fraudulent actors is like a bouncer who checks IDs and lets everyone in regardless of age,” said Blank. “DMARC enforcement should be the first level of protection … Other network security measures, like AI-based monitoring, can be valuable, but validating IDs shows you who is trying to get access.”
Bottom Line: DMARC Enforcement Reduces Phishing
If every organization deployed DMARC with full enforcement, spoofed emails would be dramatically reduced and phishing emails would become much less effective. While not all email attacks can be stopped, reducing credible spoofing attacks will dramatically reduce the burden on our email security tools as well as the number of phishing victims for our organization and every other recipient. It is time to protect your brand, defend against BEC, and reduce SPAM globally with full deployment of SPF, DKIM, and DMARC.
