What is DMARC?

What it is#

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a policy and reporting protocol that builds on SPF and DKIM. It solves a problem that neither SPF nor DKIM addresses on its own, ensuring that the domain in the From header, the address users actually see, is authenticated by the underlying protocols. DMARC introduces alignment (connecting SPF/DKIM results to the visible sender domain) and policy (telling receivers what to do when alignment fails).

How DMARC alignment works#

SPF authenticates the envelope sender. DKIM authenticates the signing domain. But neither inherently connects to the From header domain that the recipient sees. DMARC closes this gap by requiring alignment. At least one of SPF or DKIM must both pass and align with the From header domain.

Relaxed alignment (the default) requires the organizational domain to match, mail.example.com aligns with example.com.

Strict alignment requires an exact domain match, mail.example.com does not align with example.com. Most deployments use relaxed alignment because strict alignment breaks legitimate subdomain mail flows.

For a message to pass DMARC, at least one of these must be true:

• SPF passes and the envelope sender domain aligns with the From domain
• DKIM passes and the signing domain aligns with the From domain

Policy levels#

The DMARC record is a DNS TXT record published at _dmarc.example.com. The p= tag defines the policy:

• p=none. Monitor mode. Receivers send reports but take no action on failures. This is the starting point for DMARC deployment.
• p=quarantine. Receivers should treat failing messages as suspicious (typically routing to spam/junk)
• p=reject. Receivers should reject failing messages outright at the SMTP level

The sp= tag sets a separate policy for subdomains. Organizations often set sp=reject to prevent attackers from spoofing arbitrary subdomains (e.g., secure-login.example.com) even while the parent domain is still at p=quarantine.

Reporting#

DMARC provides two reporting mechanisms:

• Aggregate reports (rua=). XML reports sent daily by receiving mail servers, summarizing authentication results by source IP, domain, and disposition. These reveal which servers are sending mail using the protected domain, both legitimate and unauthorized.
• Forensic reports (ruf=). Per-message failure reports with more detail, including headers. Adoption is limited because of privacy concerns, and many large receivers do not send them.

Aggregate reports are the primary tool for understanding mail flows before tightening policy. Without analyzing rua data, organizations risk blocking legitimate mail when moving from none to quarantine or reject.

Deployment approach#

The standard deployment path is:

1. Publish p=none with a rua= address to start collecting data
2. Analyze aggregate reports to identify all legitimate mail sources
3. Ensure all legitimate sources pass SPF or DKIM with proper alignment
4. Move to p=quarantine and monitor for false positives
5. Move to p=reject once all legitimate mail is properly authenticated

This process typically takes weeks to months, depending on the complexity of the mail ecosystem. Rushing to p=reject without adequate report analysis commonly breaks newsletter delivery, transactional email, or mail from legacy systems.

For a broader view of how SPF, DKIM, and DMARC work as a system, see email authentication.

What DMARC does not protect against#

DMARC prevents exact-domain spoofing. No one can send unauthenticated mail as @example.com when the domain enforces p=reject. However, it provides no protection against:

• Cousin/lookalike domains. examp1e.com or example-support.com are separate domains with their own DMARC records (or none)
• Display name spoofing. The display name can say anything regardless of authentication results
• Compromised accounts. Mail from a genuinely compromised @example.com mailbox passes DMARC because it is legitimately sent from the domain

These gaps require additional controls, domain monitoring, display name rules, and mailbox anomaly detection. DMARC enforcement is the most impactful single action a domain owner can take to prevent direct spoofing, but once p=reject is in place, attackers are forced to use lookalike domains instead, which shifts the problem to one that brand protection tools are designed to solve.