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, most organizations don’t complete the setup to enforce a DMARC policy, leading to far less secure email systems than they think they have.
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.
What is DMARC?
DMARC provides widely established standards for email authentication and is adopted by all U.S. email domain providers and many corporate and government entities. DMARC builds upon the Sender Policy Framework (SPF) and the Domain Keys Identified Message (DKIM) technologies to add security and instructions for a specific domain.
What is DKIM?
The signature-based email authentication technique called DKIM merges the specifications for domain keys and identified-internet-mail specifications. This technique adds to email security by allowing a domain to add a digital signature and asymmetric cryptography to authorized emails.
The private key of the sender’s domain is encoded in the digital signature of every sent email. A public key is stored with the Domain Name System (DNS) for download by any email server receiving emails with the encrypted digital signature.
What is SPF?
SPF email authentication counters spoofing by publishing to DNS records a list of email-sending Internet Protocol (IP) addresses authorized by the sending domain. Domains receiving emails can compare the envelope of the email and compare against DNS records. Emails that do not match the published DNS records may be rejected without examining email text or exposing the recipient systems to malicious code within the email.
DMARC Implementation and Fees
To set up DMARC, an organization publishes a text file with DNS registrars. DMARC files may be published at no charge and the company can modify their text file as frequently as they want.
As an example, Microsoft’s DMARC.TXT file reads as:
_dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:firstname.lastname@example.org; ruf=mailto:email@example.com; fo=1"
How Does DMARC Work?
When anyone sends an email, the sending email server builds the header of the email with the “From” address visible on the email, and several domains buried in the code of the email header (return_path, DKIM-Signature d=). Upon receiving an email, a recipient email server will perform its security checks to determine if the email should be delivered.
Email servers that implement DKIM and SPF perform the following steps:
- DKIM Process
- Retrieve verified DKIM domains cited in the header from DNS
- Check that the downloaded encryption key successfully unlocks the encrypted digital DKIM signature
- SPF Process
- Retrieve “Envelope From” SPF information from the DNS domain cited in the header
- Compare verified SPF domains against the sending email IP address
Additional DMARC Steps
If an organization only uses DKIM and SPF, a spoofing organization can put their own domain (Ex: ripyouoff.io) as the domain in the header. If the attacker also properly establishes their own domains on DNS, the spoofed email will pass DKIM and SPF.
Email servers that also implement DMARC will perform additional steps:
- Lookup the sending domain with DNS to check registered DMARC IP addresses
- Check for matches with SPF and DKIM domains
- Any misalignment will be then handled* as set up in the DMARC failure settings established by the domain owner:
- p=none: non-approved emails may go to the recipient’s inbox
- p=quarantine: non-approved emails should be sent to the SPAM folder
- p=reject: non-approved emails should be blocked
- Reports of DMARC failure will be sent by the recipient email server to the email address specified in the DMARC.txt file published with DNS
*Some email services will treat ‘reject’ and ‘quarantine’ the same. For example, Microsoft 365 publishes guidance that both categories will be forwarded to the spam folder in 365 Outlook accounts.
DMARC Benefits Include Even Marketing Email Delivery
Barracuda notes that attackers use brand impersonation in more than 80% of spear-phishing attacks. These spoofing attacks use the credibility of the impersonated brand to improve the credibility of the message in the phishing email.
Deploying DMARC with ‘p=none’ can provide a company with benefits such as:
- Minimize false positives where the spoofed domain is recognized as legitimate
- Robust authentication reporting and insight into how often their domain is used by spammers in spoofing domains
- Document the various domains that send out emails claiming to be from that company
- Reduce successful phishing delivery using the protected domain
- Minimize complexity for anti-spoofing enforcement
- Note potential conflicts between DMARC, DKIM, and SPF in legitimate emails
As noted above, many email programs will adhere to the ‘p=none’ setting and allow the spoofed email to be delivered. Fully enforced DMARC that applies the more stringent ‘p=quarantine’ or ‘p=reject’ settings will provide more tangible benefits.
From a brand perspective, more stringent enforcement will reject most spoofed phishing emails and lower the risk of having one’s brand associated with malware or hackers. For some organizations, impersonation can be even more damaging than hackers, and DMARC can prevent unauthorized and damaging emails pretending to be from a political party or other prominent organization.
Beyond brand protection, the stringent settings provide real protection against many types of Business Email Compromise (BEC) fraud. In these attacks, scammers attempt to impersonate legitimate business contacts within the company or in the supply chain (vendors, customers, etc.) to trick victims into sending money.
The more stringent DMARC settings will prevent the enforcing domain from appearing to be the source of BEC phishing emails by blocking all spoofing emails originating from the incorrect domains.
Lastly, DMARC may also help improve deliverability of marketing emails. Some organizations cite 5% to 10% improvements in campaign delivery rates after enforcing DMARC policies.
Common Issues with DMARC Deployment
Many organizations see value in tightening email security by implementing DMARC. DMARC policies increased by 43% in 2020 and grew a further 84% in 2021 to reach nearly 5 million valid DMARC records confirmed by DNS.
Seth Blank, CTO of Vailmail and co-chair of the DMARC Working Group, notes that “Despite [DMARC’s] growing popularity, fraudulent email remains the leading source of all cybercrime. Why does email provide such easy pickings for criminals? Because not enough businesses are at DMARC enforcement.”
Over 1.28 million domain owners have configured DMARC for their domains, but only 14% actually protect against spoofing through enforcement. Even for large enterprises, DMARC can be difficult to fully implement.
“DMARC requires many intricate steps,” Blank explains. “Even small mistakes could result in a number of issues such as accidentally filtering legitimate emails. The risks associated with reaching enforcement may be one reason why just 43.4% of enterprise DMARC policies are at enforcement.”
Considering the resources of the largest organizations, 43% enforcement is pretty bad, but it is a vast improvement over the paltry 14% of all organizations. It seems counterintuitive that filing a .txt policy with DNS could be so difficult, but the difficulty lies with the details.
When implementing DMARC, organizations start with ‘p=none’ to avoid rejecting improperly configured but legitimate emails. The three common ways for the rejection of legitimate emails are:
- 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.
SPF limitations can also lead to rejections such as when companies try to implement a human-readable ‘from” address that does not match the SPF records or companies exceed the SPF 10-lookup limit. Either of these situations may lead to inconsistencies and rejected emails.
DMARC requires updates. Companies may switch the IP addresses for email servers as they upgrade or transition to the cloud and each IP address change requires an update to the filed policy.
Most 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 new vendors are adopted or these vendors change their email infrastructure, again, DMARC will also need to be updated.
DMARC Mistakes Are Easy to Make
Text files are small and simple; however, simplicity also means that mistakes can create big problems. The DMARC working group publishes a list of common problems with DMARC records that includes very detailed issues such as:
- Incorrectly published DMARC records
- Extra text or incorrect text that invalidates the records
- Formatting errors
- Bad record contents
Lack of IT Resources
Smaller organizations always struggle with time-intensive IT issues. Blank admits “Frankly, setting up DMARC is complicated, which accounts for the gap between policies and policies at enforcement.”
“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.
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.
Solving DMARC Problems
To establish an effective DMARC policy, organizations need to employ a precise understanding of the DMARC requirements and effectively trouble-shoot their initial failures. Best practices for trouble-shooting include:
- Verify 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
“A policy not configured to ‘quarantine’ or ‘reject’ fraudulent actors is like a bouncer who checks IDs and lets everyone in regardless of age,” sighs Blank. “DMARC enforcement should be the first level of protection … Other security measures, like AI-based monitoring, can be valuable, but validating IDs shows you who is trying to get access.”
For the email servers receiving the emails, an enforced DMARC policy can allow the server to immediately reject emails after a quick examination of the header. Without DMARC enforcement, the email security programs must then turn to much more processor-heavy processes such as malware detection, AI analysis, and SPAM detection.
Email providers such as Microsoft 365 and Gmail provide tutorials and specialized instructions for properly configuring DMARC policies for their email customers. IT teams can review these guides and follow the instructions.
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.
Blank suggests, “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.
Enforcement Could Greatly Reduce Phishing
If every organization deployed DMARC with full enforcement, spoofed emails would be dramatically reduced and phishing emails would become much less effective. If even the 1.2 million companies that already published DMARC policies simply enforced them, we would see a dramatic drop in spoofing campaigns. With enforcement, email servers simply block fraudulent emails from even tempting a victim.
Trouble-shooting and deploying a correctly formatted DMARC policy will continue to 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.
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 our brands, defend against BEC, and to reduce SPAM globally
It is time for organizations of all sizes to work towards full deployment of SPF, DKIM and DMARC.
Read next: Best Secure Web Gateway Vendors