DMARC Explained: How to Stop Domain Spoofing

• DMARC (Domain‑based Message Authentication, Reporting & Conformance) tells receiving mail servers what to do when an email fails SPF or DKIM authentication. It provides the enforcement mechanism that SPF and DKIM lack.
• In May 2026, the IETF published RFC 9989, 9990, and 9991, moving DMARC from Informational to Standards Track. The pct= and rf= tags are deprecated, and new tags (np=, psd=) have been introduced.
• DMARC has three policy levels: p=none (monitor only), p=quarantine (send to spam), and p=reject (block). Only p=reject provides full protection against domain spoofing.
• Only 10.7% of domains globally have full p=reject enforcement, leaving the vast majority vulnerable to impersonation attacks. DMARC adoption has reached 52.1% (937,931 domains) in 2026, up from 47.7% in 2025.
• DMARC alignment requires that the domain in the header From matches either the domain authenticated by SPF or the domain authenticated by DKIM. Without alignment, even a passing SPF or DKIM check will fail DMARC.

• Verifies alignment – checks that the domain in the header From matches the domain authenticated by SPF or DKIM
• Defines policy – tells receiving servers what to do with unauthenticated email (none, quarantine, or reject)
• Provides reporting – sends aggregate (RUA) and forensic (RUF) reports about email authentication activity

• SPF alignment: The domain in the Return‑Path matches the domain in the header From
• DKIM alignment: The domain in the DKIM signature (d=) matches the domain in the header From

• r (relaxed): Allows subdomain matches (e.g., sub.example.com aligns with example.com)
• s (strict): Requires an exact match

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; sp=reject

• psd=y – treat the domain as an organisational domain
• psd=n – do not treat as an organisational domain
• psd=u – unknown (default behaviour)

v=DMARC1; p=reject; np=quarantine; psd=y; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com

1. Phase 1: p=none (Monitoring) – Collect data for 30–60 days. Identify all legitimate sending sources.
2. Phase 2: p=quarantine (Testing) – Test enforcement. Identify and fix any remaining issues.
3. Phase 3: p=reject (Full protection) – Block all unauthenticated emails.

• Format: XML
• Content: Summary of all authentication results, including source IPs, message counts, SPF/DKIM results, and DMARC disposition
• Frequency: Daily
• Purpose: Monitor authentication performance and identify legitimate senders

• Format: XML (standardised by RFC 9991 in May 2026)
• Content: Per‑message failure details, including sender IP, From/Return‑Path mismatch, and the specific mechanism that failed
• Frequency: Per failure event
• Purpose: Debug authentication failures

dig TXT _dmarc.example.com +short

"v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Authentication-Results: dmarc=pass header.from=example.com;

1. Start with p=none to collect data. Monitor aggregate reports for 30–60 days.
2. Identify all legitimate sending sources. Include marketing platforms, transactional email, CRMs, and cloud services.
3. Move to p=quarantine after verification. Test enforcement and identify any remaining issues.
4. Move to p=reject after 90+ days. Full protection.
5. Configure subdomain policy. Use sp=reject for subdomains.
6. Use the new np= tag. Set np=reject for non‑existent subdomains.
7. Set up both RUA and RUF reporting. Monitor authentication performance.
8. Remove deprecated tags. pct=, rf=, and ri= are no longer used.
9. Use relaxed alignment (adkim=r; aspf=r) for initial deployment, then consider strict later.
10. Monitor reports continuously. DMARC is not a set‑and‑forget solution.

• DMARC provides enforcement that SPF and DKIM lack, telling receiving servers what to do with unauthenticated email.
• Only 10.7% of domains have full p=reject enforcement, leaving the vast majority vulnerable to impersonation attacks.
• DMARC alignment requires the header From domain to match either the SPF or DKIM authenticated domain.
• DMARC reporting provides visibility into who is sending email using your domain, including attackers.
• Implementation follows a progression: p=none → p=quarantine → p=reject.
• RFC 9989 (May 2026) introduced new tags (np=, psd=) and deprecated pct=, rf=, and ri=.
• DMARC is now an IETF Standards Track protocol, not merely Informational.

• RFC 7208 – Sender Policy Framework (SPF)
• RFC 6376 – DomainKeys Identified Mail (DKIM)
• RFC 7489 – DMARC
• BIMI Specification