DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that protects your domain from unauthorized use. It provides instructions to receiving email servers on how to handle messages that claim to be from your domain but fail security checks. By setting a DMARC policy, you improve email deliverability and shield your brand from being used in phishing or spoofing attacks.
What is DMARC?
DMARC is a DNS-based policy and reporting protocol that builds on two older authentication methods: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). While SPF and DKIM verify the sender's identity, DMARC adds a layer of "alignment" to ensure the domain in the "From" header matches the domains validated by those protocols.
The protocol was formalized when the IETF RFC Editor published RFC 7489 on March 18, 2015 (dmarc.org). It is maintained as a public, non-licensed specification available for any domain owner to implement via a TXT record in their Domain Name System (DNS) settings.
Why DMARC matters
- Prevents brand impersonation. It stops malicious actors from using your domain for business email compromise (BEC) and phishing scams.
- Improves deliverability. Setting up DMARC may improve the deliverability of messages (Wikipedia) by helping mailbox providers identify your legitimate mail.
- Provides visibility. You receive aggregate reports (RUA) and forensic reports (RUF) that show who is sending email on behalf of your domain.
- Reduces security gaps. A Federal Trade Commission study found that while a third of businesses implement DMARC, fewer than 10% use it to reject unauthenticated messages (Federal Trade Commission).
How DMARC works
The protocol functions through a series of checks performed by the receiving mail server:
- DNS Lookup: The receiver looks for a DMARC record at
_dmarc.yourdomain.com. - Authentication: The receiver checks the email against SPF and DKIM records.
- Alignment Check: The receiver verifies that the domain in the "From" header matches the domain found in the SPF and/or DKIM authentication results.
- Policy Application: If the email fails both SPF and DKIM alignment, the server follows your DMARC policy (none, quarantine, or reject).
- Reporting: The receiver generates a report and sends it to the email address specified in your DMARC record.
DMARC Policies
You can choose one of three policy levels (the p= tag) to signal how servers should treat failed emails:
| Policy | Description | Use Case |
|---|---|---|
None (p=none) |
No action is taken against the email. It is delivered normally. | Used for monitoring and data collection during initial setup. |
Quarantine (p=quarantine) |
The email is sent to the recipient's spam or junk folder. | Used when you are confident in your setup but want to mitigate risk. |
Reject (p=reject) |
The email is blocked entirely and never reaches the recipient. | The highest security level; ensures only authorized mail is delivered. |
Best practices
- Start with p=none. Use this monitoring phase to gather reports and identify all legitimate mail sources, such as your CRM, ESP, or billing software.
- Analyze aggregate reports. Use tools to parse the XML files you receive, as they identify spoofing attempts and misconfigurations in your SPF or DKIM.
- Use the percentage tag. Gradually increase enforcement by using the
pcttag. For example,p=quarantine; pct=20applies the policy to only 20% of failing emails. - Set up SPF and DKIM first. DMARC requires at least one of these to be authenticated and aligned to pass.
- Secure non-sending domains. Even if a domain does not send email, publish a DMARC
p=rejectpolicy to prevent scammers from using it.
Common mistakes
Mistake: Jumping directly to p=reject.
Fix: Start at p=none to ensure you don't accidentally block legitimate business emails from third-party vendors.
Mistake: Ignoring subdomain policies.
Fix: Use the sp= tag if you need a different policy for subdomains than the one set for your root domain.
Mistake: Forgetting alignment.
Fix: Ensure your "From" address domain matches the domain in your DKIM signature or SPF envelope. If they don't align, DMARC will fail even if SPF and DKIM technically "pass."
Mistake: Overlooking mailing list disruptions.
Fix: Be aware that mailing lists often modify headers, which can break alignment. In April 2014, Yahoo and AOL changed their policies to p=reject (Wikipedia), which caused widespread delivery issues for mailing lists at the time.
FAQ
What is the difference between RUA and RUF reports?
RUA (Aggregate) reports are daily XML files providing high-level data on all mail perceived to be from your domain, including IP addresses and authentication results. RUF (Forensic/Failure) reports are real-time, redacted copies of individual emails that failed authentication, used for deep troubleshooting.
Can I use DMARC without DKIM?
Technically, yes. DMARC requires either SPF alignment or DKIM alignment to pass. However, many experts recommend using both to prevent "false negatives" if one protocol fails due to email forwarding or temporary DNS issues.
What is "Alignment" in DMARC?
Alignment is the core concept of DMARC. It checks that the domain the user sees in their "From" field is the same domain that was validated by SPF (the "Return-Path") or DKIM (the "d=" tag in the signature).
How long does it take to reach a "reject" policy?
It depends on the complexity of your email ecosystem. Most organizations spend several weeks or months at p=none or p=quarantine while they identify and authorize all legitimate sending sources.
What does a basic DMARC record look like?
A simple record might look like: v=DMARC1; p=none; rua=mailto:[email protected];. This tells receivers to use DMARC version 1, take no action on failures, and send reports to the specified email.
