From early sender–receiver collaboration to DMARC 2.0: the protocol milestones, provider policies, industry standards and scoped government requirements that changed how domains protect email.
RFC 9989, RFC 9990 and RFC 9991 replace the original DMARC RFC with Proposed Standards for the core protocol, aggregate reporting and failure reporting. The revision introduces DNS Tree Walk discovery and separates reporting so each part can evolve independently.
Google says it increased enforcement against traffic that does not meet its bulk-sender requirements, including temporary and permanent rejection. The baseline remains DMARC at p=none or stronger—not a universal p=reject rule.
Denmark’s updated technical minimum requirements direct state authorities to publish DMARC at p=reject on authority-owned main domains and subdomains, alongside SPF and DKIM controls. The scope is Danish state authorities, not every Danish organisation.
Microsoft requires domains sending more than 5,000 messages a day to Outlook.com consumer services to pass SPF and DKIM and publish aligned DMARC at p=none or stronger. Its update says non-compliant mail initially goes to Junk; a permanent-rejection date was not announced.
PCI DSS Requirement 5.4.1 makes automated mechanisms that detect and protect personnel against phishing part of assessments. PCI SSC names DMARC, DKIM and SPF as examples; it does not uniquely require DMARC or prescribe p=reject.
Apple’s iCloud Mail guidance says bulk senders must use SPF and DKIM and publish a DMARC policy; failure to meet all listed requirements can result in rejection. Apple does not publish a numeric bulk threshold or require a policy stronger than publishing DMARC.
PCI SSC publishes a limited revision that clarifies wording and corrects errors without adding or deleting requirements. It preserves the 31 March 2025 effective date for future-dated requirements, including 5.4.1.
Gmail begins applying authentication, alignment, complaint-rate and unsubscribe requirements to bulk mail sent to personal Gmail accounts. Yahoo starts a gradual rollout across its consumer brands, including AOL, and follows with one-click-unsubscribe enforcement in June.
Google defines a bulk sender as one sending about 5,000 or more messages to personal Gmail accounts in 24 hours. Yahoo announces comparable authentication expectations but deliberately publishes no numeric threshold, so Google’s number must not be applied to Yahoo.
PCI SSC publishes PCI DSS v4.0. New Requirement 5.4.1 introduces automated anti-phishing protection as a future-dated best practice, later becoming assessable in March 2025.
RFC 9091 defines an Experimental method for publishing DMARC policies at public-suffix domains. The registry-based experiment is later superseded by the DNS Tree Walk policy-discovery model in the 2026 core specification.
RFC 8617 publishes Authenticated Received Chain as an Experimental protocol. ARC lets intermediaries preserve authentication assessments through forwarding and mailing-list paths; it complements rather than replaces DMARC.
NIST SP 800-177 Rev. 1 names SPF, DKIM and DMARC among technologies recommended for authenticating sending domains. It is guidance for federal IT systems and other adopters—not a universal legal mandate.
The UK’s then-current Minimum Cyber Security Standard requires government organisations to publish DMARC, DKIM and SPF, enforce DMARC inbound and review reports. That standard is now withdrawn and superseded, making this a historical mandate rather than current general guidance.
DHS Binding Operational Directive 18-01 requires covered federal executive-branch agencies to deploy DMARC and move second-level domains and mail-sending hosts to p=reject within one year. Its authority is scoped; it is not a rule for every US organisation.
RFC 7960 explains how forwarding, mailing lists and other indirect flows can break SPF or DKIM alignment and therefore DMARC. It establishes the technical case for measured policy rollout rather than an indiscriminate jump to p=reject.
GOV.UK publishes guidance for internet email domains run by public-sector organisations. The current version requires DMARC and TLS as a minimum, DMARC/DKIM/SPF records, inbound enforcement and review of reporting.
RFC 7489 formalises domain alignment, DNS policy discovery, p=none, p=quarantine, p=reject, and aggregate and failure reporting. It is an Informational Independent Submission rather than an IETF Standards Track specification.
The DMARC specification is circulated as an Internet-Draft in March 2013 and moves to the Independent Submissions track in April 2014. That route determines the Informational status of the first RFC.
Fifteen senders, mailbox providers and security vendors announce DMARC.org and a draft specification combining SPF/DKIM alignment, published handling policy and receiver-to-sender reporting.
PayPal establishes authenticated sending and receiver feedback first with Yahoo Mail and later Gmail. DMARC.org describes this sender–receiver collaboration as the practical model on which DMARC was built.