DMARC.

Domain-based Message Authentication, Reporting and Conformance (DMARC), specified in RFC 7489, builds on SPF (RFC 7208) and DKIM (RFC 6376) by requiring identifier alignment between the visible From: domain and the domain authenticated by SPF or DKIM. This closes the gap those two protocols leave open: SPF and DKIM each validate a domain, but neither guarantees it is the one the recipient actually sees. Domain owners publish a TXT record at _dmarc.<domain> carrying a policy (p=none, quarantine, or reject), subdomain handling (sp=), alignment mode (aspf/adkim, relaxed or strict), a rollout percentage (pct=), and reporting URIs (rua, ruf).

Deployment and enforcement

The safe rollout path is p=none first: aggregate XML reports (RFC 7489) reveal every legitimate sender — including forgotten marketing and ticketing platforms — so they can be authenticated before tightening to quarantine and then reject. Skipping this step blackholes real mail.

DMARC underpins BIMI (which shows a verified brand logo only at p=quarantine/reject) and became a practical mandate when Google and Yahoo's bulk-sender rules took effect in February 2024, requiring senders of ~5,000+ messages/day to Gmail to pass aligned SPF or DKIM, publish at least p=none, and offer one-click unsubscribe. The DMARCbis revision published in 2026 obsoletes RFC 7489, keeping v=DMARC1 records working while replacing Public Suffix List lookups with a DNS "Tree Walk" to find the organisational domain.

flowchart TD
  A[Inbound message] --> B{SPF pass?}
  A --> C{DKIM pass?}
  B --> D{From aligned<br/>with SPF domain?}
  C --> E{From aligned<br/>with DKIM domain?}
  D --> F{Either check<br/>passes & aligns?}
  E --> F
  F -->|Yes| G[DMARC pass - deliver]
  F -->|No| H[Apply p= policy]
  H --> I[none: monitor]
  H --> J[quarantine: spam folder]
  H --> K[reject: bounce]
  G & H --> L[Send rua aggregate report to domain owner]