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 (mailbox providers 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.
How DMARC Works: The Technical Mechanism
When a receiving mail server receives a message, it:
- Extracts the From header domain (what the recipient sees)
- Runs SPF check against the envelope sender and checks alignment with From domain
- Verifies DKIM signature and checks that the d= tag aligns with From domain
- Looks up the From domain's DMARC record
- If both SPF and DKIM fail alignment, applies the policy in the DMARC record
- Sends a report to the rua address in the DMARC record
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 — see ARC for the protocol that preserves authentication across forwarding).
DMARC Record Syntax
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) |
DMARC Policy Levels Explained
p=none: Monitor-only. Mailbox providers 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.
Deployment Roadmap: p=none to p=reject
The standard deployment sequence:
- Phase 1 (Weeks 1–4): p=none — Collect aggregate reports. Identify all sending sources (ESPs, CRMs, applications, partner tools) that send email on behalf of your domain.
- Phase 2 (Weeks 4–8): Authentication cleanup — Configure DKIM signing and SPF authorization for every legitimate sending source identified in Phase 1. Still at p=none.
- Phase 3 (Weeks 8–10): p=quarantine pct=10 — Apply quarantine policy to 10% of failing mail. Watch for legitimate mail being affected.
- Phase 4 (Weeks 10–12): p=quarantine — Full quarantine. Continue monitoring.
- Phase 5 (Week 12–14): p=reject pct=10 — Begin rejection at 10% to catch any missed legitimate sources.
- Phase 6: p=reject — Full enforcement. Ongoing monitoring to catch new sending sources.
Reading DMARC Aggregate Reports
DMARC aggregate reports (rua) arrive as XML files from major mailbox providers — 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.
How DMARC Fits in the Authentication Stack
DMARC is the policy and reporting layer that sits on top of SPF and DKIM. Once your domain reaches enforcement (p=quarantine or p=reject), additional authentication-related deployments become possible: BIMI (verified brand logos in supported inboxes) requires DMARC at enforcement; ARC preserves DMARC results across forwarding paths that would otherwise break SPF and DKIM. On the transport-security side, complementary protocols protect the connection itself: MTA-STS mandates TLS for inbound mail, DANE provides DNSSEC-anchored TLS validation, and TLS-RPT aggregates daily reports of TLS handshake outcomes — all building on STARTTLS as the foundation. DMARC enforcement is also the prerequisite for serious investment in sender reputation work; without it, your domain is fundamentally spoofable and reputation has no anchor.