DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that builds on SPF and DKIM, adding domain alignment checks and policy e
DMARC — Domain-based Message Authentication, Reporting, and Conformance — is a DNS TXT record that extends SPF and DKIM by adding two critical capabilities: alignment checking (the authenticated domain must match the visible From header domain) and policy enforcement (ISPs are told what to do with messages that fail the check).
Without DMARC, a spammer can send email that passes SPF authentication using a legitimately registered domain in the SMTP envelope while showing your company's domain in the From header visible to recipients. SPF alone doesn't protect against this because it checks the envelope sender, not the From header. DMARC closes this gap by requiring that the domain authenticated by SPF or DKIM must align with the domain in the From header.
When a receiving mail server receives a message, it:
A DMARC check "passes" if either SPF or DKIM passes with proper alignment — both don't need to pass. This is important: if your DKIM signature is valid and aligned with the From domain, DMARC passes even if SPF fails (which can happen when email is forwarded through another server).
A DMARC record is published as a DNS TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com; sp=none; adkim=r; aspf=r
| Tag | Meaning | Options |
|---|---|---|
| v=DMARC1 | Version identifier (required) | Must be DMARC1 |
| p= | Policy for From domain failures | none, quarantine, reject |
| sp= | Policy for subdomain failures | none, quarantine, reject (inherits p= if omitted) |
| pct= | Percentage of failing mail to apply policy to | 1–100 (default 100) |
| rua= | Aggregate report destination | mailto: URI |
| ruf= | Forensic report destination | mailto: URI (optional) |
| adkim= | DKIM alignment mode | r (relaxed) or s (strict) |
| aspf= | SPF alignment mode | r (relaxed) or s (strict) |
p=none: Monitor-only. ISPs accept mail regardless of DMARC result and send reports to your rua address. No email is rejected or quarantined. This is the starting point for all DMARC deployments — it lets you see your authentication landscape before enforcing anything.
p=quarantine: Failing mail is treated as suspicious — typically routed to the spam/junk folder. This is an intermediate enforcement level that catches most spoofing attacks while being less disruptive than p=reject if any legitimate sources are misconfigured.
p=reject: Failing mail is rejected outright. This is the gold standard — it means spoofed email claiming to be from your domain never reaches recipient inboxes. Required for BIMI implementation and provides the strongest brand protection.
The standard deployment sequence:
DMARC aggregate reports (rua) arrive as XML files from major ISPs — Gmail, Outlook, Yahoo, and others. They show per-IP sending data including volume, SPF pass/fail, DKIM pass/fail, and DMARC disposition for every IP that sent mail claiming your domain.
For operational use, parse these XML files through a DMARC reporting tool (dmarcian, EasyDMARC, Valimail, or PowerDMARC). These tools transform the raw XML into dashboards that show authorized vs unauthorized senders, authentication rates by source, and any active spoofing campaigns targeting your domain.
The first week of DMARC aggregate reports typically reveals sending sources that domain owners didn't know existed — old CRM integrations, partner notification systems, automated alerts from cloud services. Each of these needs to be addressed before moving past p=none.
Last updated: January 2026 · Email Infrastructure Glossary
