DMARC, which stands for "Domain-based Message Authentication, Reporting and Conformance," is an email authentication protocol that protects your domain from domain spoofing and impersonation attacks. Implementing a DMARC policy in your domain's DNS records helps to protect your email recipients from spam and malware, while maintaining your domain and brand credibility.
This article provides a brief overview on the importance of DMARC and how a DMARC policy relates to regulations, as well as common DMARC configuration issues and how to fix them.
Why DMARC Matters
DMARC, which works together with your Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) record, negotiates email authentication for email receivers to verify email senders and prevent fraudulent emails. These authentication checks protect against business email compromise by cybercriminals and phishing scams.
The Internet Engineering Task Force (IETF) defines the DMARC mechanism in RFC 7489. DMARC provides domain-specific message handling in concert with the domain-level authentication offered by DKIM and SPF records. The domain owner sets the DMARC policy, and receivers authenticate against that policy while providing feedback to senders in DMARC reports.
Your DMARC policy authenticates the validity of the domain that a sending email claims to be from. When you receive an email, your email provider's mail server will check the DMARC record for three things:
- Does the email come from a trusted IP address? That is, is the IP address among the IP addresses that are owned by the domain in the DNS records?
- Does the email carry a unique DKIM signature from the domain?
- Do both those tests fail?
This series of actions determines how the mail should be handled by the receiving mail servers. If the DMARC check is successful, the legitimate email will be routed to your inbox. If the DMARC check fails, then the receiving email service provider will reject the incoming message according to the parameters set by the DMARC policy.
Without a functioning DMARC policy, unauthorized emails that appear to be from your domain may be sent. These email spoofing attempts by spammers may be used for phishing attacks, malware attachments, credential spoofing, and other malicious cyber attacks. Email spoofing can occur without a DMARC policy that authenticates the sending domain, like when a missing DMARC record resulted in fraudulent emails that appeared to be sent from the World Health Organization's domain name in early 2020. Because email recipients typically assess the "From" header to gauge the legitimacy of their messages, it's important that your secure email policies include a DMARC record.
DMARC authentication methods allow email deliverability for legitimate messages. Your domain is at increased risk of fraudulent emails that appear to be authorized if you don't set a DMARC record of if your DMARC policies are not strict. Most email providers offer some spam protections, but the validity of an email can be set by the domain owner opting to use DMARC and protect anything sent on your behalf rather than placing the responsibility on the email recipient.
DMARC Regulations
Preventing email spam and ensuring email validity has become increasingly important and therefore codified in law.
In the United States, the 2017 Binding Operational Directive 18-01 set technical practices for enhancing email and web security. Directives like this one require governmental organizations to adhere to the guidance for federal information systems. In BOD 18-01, organizations are directed to include SPF and DKIM rules while setting a DMARC policy with p=reject to block delivery of unauthenticated emails. BOD 18-01 also requires that the DMARC policy be applied to all emails from the domain owner's mail stream.
Likewise, NIST Special Publication 800-53 defines standards around spam protection with System and Information Integrity 8 (SI-8) and its enhancements. The SI-8 control statement is clear:
"The organization:
a. Employs spam protection mechanisms at information system entry and exit points to detect and take action on unsolicited messages; and
b. Updates spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures."
(Cybersecurity and Privacy Reference Tool SI-8)
Email servers are included among the system entry and exit points, which is why a strong DMARC policy is one preventative measure that correlates to SI-8.
Related controls from other cybersecurity frameworks include the following:
- Cloud Security Alliance's Cloud Controls Matrix EKM-03 on Sensitive Data Protection, which includes data in transmission over email.
- Center for Internet Security's (CIS) Critical Security Controls 7.8 to implement DMARC and receiver-side verification.
- CIS Critical Security Control 8.7 to deploy and maintain anti-malware protections.
The Australian government has also issued guidance on email protection in their Information Security Manual (ISM) with a 2021 guide on how to combat fake emails and a 2023 guidelines for email. Controls ISM-1540 and ISM-1799 clarify the DMARC requirements set by the Australian government.
To prevent phishing and brand spoofing, the internationally recognized Payment Card Industry Security Standards Council (PCI SSC) has mandated DMARC in the Payment Card Industry Data Security Standards (PCI DSS) version 4.0 PCI DSS 4.0 takes full effect in March 2025, at which point all commerce organizations that process customer credit card information must comply with the updated requirements. PCI DSS v4.0 auditing may begin in 2024, so commerce organizations should take proactive steps to implement DMARC.
Read our blog on How to Prepare for a PCI DSS 4.0 Audit.
Because government regulations include DMARC as a necessary preventative measure for email security, it is critical that you establish a DMARC policy and configure valid syntax to protect your sending domain.
DMARC Configuration Syntax
DMARC configuration syntax must accord to the IETF specifications for the policy to work as expected. Your DMARC policy record must include the [.rt-script]v[.rt-script] and [.rt-script]p[.rt-script] tags in that order. Any syntax errors in the remainder of the record are typically discarded or ignored, so it is recommended to follow the necessary configuration sequence to ensure a functional DMARC policy.
DMARC policies are published as a [.rt-script]TXT[.rt-script] record in your DNS record. By referring back to the Domain Name System (DNS) as the distributed database for IP networking ownership, DMARC can confirm and validate domain ownership with Simple Mail Transfer Protocol (SMTP) communications.
DMARC records follow an extensible tag-value syntax but must be configured properly for the policy to function as expected. There are 11 valid tags that can be set for your policy:
- [.rt-script]adkim[.rt-script] specifies whether your policy uses a strict ([.rt-script]s[.rt-script]) or relaxed ([.rt-script]r[.rt-script]) mode for your DKIM Alignment.
- [.rt-script]aspf[.rt-script] specifies whether your policy uses a strict ([.rt-script]s[.rt-script]) or relaxed ([.rt-script]r[.rt-script]) mode for your SPF Identifier Alignment.
- [.rt-script]fo[.rt-script] provides options for failure reporting with four value options (sometimes referred to as forensic reports).
- [.rt-script]p[.rt-script] is a required tag that indicates how the policy will be enacted by the mail receiver, providing one of the possible values ([.rt-script]none[.rt-script], [.rt-script]quarantine[.rt-script], [.rt-script]reject[.rt-script]).
- [.rt-script]pct[.rt-script] indicates to what percentage of messages the DMARC policy is applied with an if/else statement and is used primarily for a slow rollout of enforcement.
- [.rt-script]rf[.rt-script] provides formatting for failure reports.
- [.rt-script]ri[.rt-script] indicates the requirements for aggregate reports.
- [.rt-script]rua[.rt-script] determines where aggregate feedback is sent in the "mailto:" URI.
- [.rt-script]ruf[.rt-script] determines where message-specific failure information is sent.
- [.rt-script]sp[.rt-script] indicates the subdomain policy.
- [.rt-script]v[.rt-script] is a required tag that sets the record retrieved and must have the value [.rt-script]DMARC1[.rt-script].
The [.rt-script]p[.rt-script] and [.rt-script]v[.rt-script] tags are required, and the [.rt-script]v[.rt-script] tag must appear first in the DMARC specification syntax. All other tags are optional, depending on your needs, but each additional parameter provides additional layers of email security.
As an example, UpGuard's current DMARC record specifies seven tags that govern email authentication and deliverability:
[.rt-script]v=DMARC1;p=reject;fo=1:d:s;rua=mailto:dmarc@upguard.com;ruf=mailto:dmarc@upguard.com;adkim=s;aspf=r[.rt-script]
Each tag and its corresponding value provide critical information during a DMARC check:
- [.rt-script]v=DMARC1;[.rt-script] — the record retrieved for the domain is a DMARC record, so the receiving email server should run a DMARC check.
- [.rt-script]p=reject;[.rt-script] — reject delivery for all messages that fail the check.
- [.rt-script]fo=1:d:s;[.rt-script] — generate a failure report if any underlying authentication mechanisms respond with something other than "pass" ([.rt-script]1[.rt-script]), generate a DKIM failure report if the signature fails ([.rt-script]d[.rt-script]), and generate an SPF failure report if the message fails SPF evaluation ([.rt-script]s[.rt-script]).
- [.rt-script]rua=mailto:dmarc@upguard.com;[.rt-script] — send high-level aggregate reports to [.rt-script]dmarc@upguard.com[.rt-script].
- [.rt-script]ruf=mailto:dmarc@upguard.com;[.rt-script] — send detailed reports for each individual failure to [.rt-script]dmarc@upguard.com[.rt-script].
- [.rt-script]adkim=s;[.rt-script] — use strict mode ([.rt-script]s[.rt-script]) for DKIM authentication to require an exact signature match.
- [.rt-script]aspf=r[.rt-script] — use relaxed mode ([.rt-script]r[.rt-script]) for SPF alignment to approve a shared organizational domain.
Refer to RFC 7489 for more information about DMARC specifications, and read our blog on What is DMARC to learn about the history behind the policy. Microsoft, Google (Gmail), and Yahoo are among the receiver-side email providers that support DMARC.
You can use an online policy validator to confirm if your syntax is valid. With misconfigured syntax, your DMARC policy may not function as expected.
DMARC Configuration Risks
If your DMARC policy is not enabled or the configuration includes a syntax error, you'll receive the following notifications in UpGuard BreachSight:
- DMARC policy not found
- DMARC policy is p=none
- DMARC policy is p=quarantine
- DMARC policy percentage is less than 100%
If you do not have DMARC enabled, you will be notified that the DMARC policy is not found. If your domain does not have DMARC, then you can establish it with a brief policy that includes the [.rt-script]v[.rt-script] and [.rt-script]p[.rt-script] tags. To configure DMARC, you must also have SPF and DKIM records enabled on the email domain.
When you set the Requested Mail Receiver policy with the [.rt-script]p[.rt-script] tag, the strongest policy is to reject any and all messages that fail the check. You can optionally set this value to take no action with [.rt-script]p=none[.rt-script] or to take limited action with [.rt-script]p=quarantine[.rt-script]. If you set the policy with [.rt-script]p=none[.rt-script], then the receiving email server will deliver all messages that appear to be from your organization. If you set the policy with [.rt-script]p=quarantine[.rt-script], then the receiving email server will follow the quarantine procedures to hold messages that fail a DMARC check or route them to a spam folder. Because both of these options still permit delivery of fraudulent email messages to the destination, you can set a reject policy with [.rt-script]p=reject[.rt-script] instead so that any fraudulent emails will be prevented from reaching end users.
The [.rt-script]pct[.rt-script] tag is optional but it determines what percentage of messages from the sending email domain will be controlled by DMARC failure actions. This tag is typically used to roll out a full DMARC policy, so anything less than 100% should be used judiciously during your configuration setup. If this parameter is set to less than 100%, then some amount of unauthorized emails will reach end users and appear to be authorized. To prevent spoofing and phishing emails, set [.rt-script]pct=100[.rt-script] in the DMARC record.
How UpGuard Can Help
With BreachSight, UpGuard provides continuous monitoring to ensure your policies are working as expected. If your DMARC policy is missing or the configuration settings still permit risk, you will receive a notification in your UpGuard account with the specific finding. You can then use that information to update your DMARC policy.
You can also monitor records for subdomains and subsidiaries to account for potential risk across your entire portfolio. If the DMARC-related findings appear, you will know what corrective action to take.
To create a DMARC policy, you can use our guide on How to create a DMARC policy.
How to Secure Your DMARC Policy
Once you set your DMARC policy, you can monitor it and review the reports to ensure that your email security policies and DMARC authentication are functioning as expected.
- Establish strong SPF, DKIM, and DMARC policies that determine your email authentication policies for your top-level domain and all subdomains.
- Include optional tags that add layers of security and reporting to your DMARC policy.
- Review the reports on a regular basis to ensure that your DMARC policy is functioning as expected.
- Use a continuous monitoring solution like UpGuard BreachSight to automate your email policy checks.
- Consider a vendor risk management solution like UpGuard Vendor Risk to monitor third-party information security risks.
