DMARC — Domain-based Message Auth, Reporting & Conformance
The policy layer that ties SPF and DKIM together — telling receivers what to do with unauthenticated email and giving you visibility into who is sending on your behalf.
Policy, Alignment, and Reporting
DMARC builds on SPF and DKIM by adding two things: alignment and policy. Alignment means the authenticated domain (from SPF or DKIM) must match the header From domain that users see. Policy tells receiving servers what to do when a message fails alignment — none, quarantine, or reject.
DMARC is published as a DNS TXT record at _dmarc.example.com. It references SPF and DKIM results, checks alignment, and — critically — enables aggregate reports (daily XML summaries) and forensic reports (per-failure samples) sent to addresses you specify. These reports are the most valuable output of DMARC: they reveal who is sending email using your domain before you ever enforce policy.
A message passes DMARC if at least one of SPF or DKIM passes and is in alignment with the header From. A message can fail SPF (due to forwarding) but pass DMARC via DKIM alignment — or fail DKIM but pass via SPF alignment.
Policy Modes: none, quarantine, reject
No action is taken on failing messages — they are delivered normally. Reports are still generated and sent. This is the starting point for every new DMARC deployment. Use p=none for weeks or months to collect aggregate reports, identify all legitimate sending sources, and ensure SPF/DKIM are properly configured before enforcing.
Failing messages are placed in the spam/junk folder rather than being rejected. A useful intermediate step between none and reject — it enforces policy without causing delivery failures that could affect legitimate mail you haven't yet identified. Use pct= to apply quarantine to only a percentage of failing mail during rollout.
Receiving servers reject failing messages outright — they never reach the inbox. This is the target state for all domains. Once at p=reject, spoofed email using your domain is blocked at the perimeter of the receiving mail system. Required by PCI-DSS 4.0 (March 2025) and recommended by CISA for government domains.
The pct= tag applies the enforcement policy to only a percentage of failing messages (default: 100). Setting pct=10 means only 10% of failing messages are quarantined or rejected; the rest are treated as p=none. Use this to gradually increase enforcement and confirm no legitimate mail is affected.
Relaxed vs. Strict Alignment
Alignment compares the header From domain against the domain authenticated by SPF (envelope From) or DKIM (d= tag). There are two modes:
Relaxed alignment (adkim=r / aspf=r) — the authenticated domain and the header From domain must share the same organizational domain (registered domain + TLD). Example: DKIM signed with mail.example.com is in relaxed alignment with From: user@example.com. This is the default and recommended for most organizations.
Strict alignment (adkim=s / aspf=s) — the authenticated domain and the header From domain must match exactly. A subdomain mailing on behalf of the parent domain will fail strict alignment. Use strict only when you have complete control over all sending infrastructure.
Reading DMARC Aggregate Reports
Aggregate reports (RUA) are sent daily by receiving mail systems as XML files, one per reporting organization. Each report covers a 24-hour period and lists: source IP, message count, SPF and DKIM pass/fail, alignment pass/fail, and the applied disposition. They are invaluable for discovering shadow IT senders, misconfigured ESPs, and spoofing attempts.
Raw XML is readable but unwieldy. Use a DMARC reporting service to aggregate, parse, and visualize reports across all your domains. Major services include dmarcian, Valimail, Proofpoint Email Fraud Defense, and free options like Google Postmaster Tools (for gmail.com traffic) and parsedmarc (open source).
- rua= receives daily aggregate XML reports (gzip attachment)
- ruf= receives per-failure forensic reports (actual message samples — privacy-sensitive)
- fo=0: report if all mechanisms fail (default) | fo=1: report on any failure
- Reports from Google, Yahoo, Microsoft cover the majority of consumer email traffic
- Cross-domain reporting: use
mailto:dmarc@reports.example.comand publish a verification record at the receiving domain to confirm consent
The Journey to p=reject
Publish p=none with reporting addresses
Start collecting aggregate reports without any enforcement. Use rua= to receive daily XMLs. Set a low TTL (300s) for easy future changes. Give this at least 2–4 weeks to collect data from major mailbox providers.
Audit all sending sources
Review aggregate reports to identify every IP and mail system sending email on behalf of your domain. Common surprises: old marketing platforms, partner integrations, development systems sending alerts, acquisition-era domains.
Ensure all legitimate senders have SPF and DKIM
Add each legitimate sender to your SPF record. Verify DKIM is configured for each mail system. Confirm alignment passes in aggregate reports — each sender should show 100% DMARC pass rate.
Move to p=quarantine with pct=10
Begin gradual enforcement. Start at pct=10 to verify no legitimate mail is caught. Monitor reports for any new DMARC failures appearing after quarantine begins. Step up: 25%, 50%, 100%.
Promote to p=reject
Once quarantine at pct=100 shows no legitimate mail failing DMARC, switch to p=reject. This is the goal: phishing and spoofing attempts using your domain are rejected at the receiving server before reaching inboxes.