DMARC checks that SPF or DKIM passed for the domain in the From address, and tells receivers what to do and whom to report to when it did not.
Key points
- DMARC was first published as RFC 7489 in 2015; in May 2026 the IETF replaced it with RFC 9989, now a Standards Track protocol, plus separate RFCs for reporting [1].
- A message passes DMARC when either SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) passes and the authenticated domain matches the From domain, a rule called Domain Alignment [1].
- The policy lives in a TXT DNS Record at _dmarc.example.com, with p=none, p=quarantine or p=reject, and optional rua= addresses for aggregate reports [1].
- Gmail requires senders of more than 5,000 messages a day to its users to publish DMARC, Yahoo sets the same rule for bulk senders, and p=none is enough to comply [2][3].
- Outlook applied the same rule to high-volume senders from May 2025, returning 550 5.7.515 for domains that fail [4].
- An enforced policy, quarantine or reject, is a prerequisite for BIMI logos in the inbox.
How a DMARC check works
When a message arrives, the receiver extracts the domain from the From header, the address a person actually sees, and looks up its DMARC record. It then checks whether SPF (Sender Policy Framework) passed for the Return-Path domain and whether a DKIM (DomainKeys Identified Mail) signature passed for its d= domain. If at least one of those passing domains aligns with the From domain, the message passes DMARC [1]. Alignment is relaxed by default, so mail.example.com aligns with example.com, and it can be set to strict with the adkim and aspf tags. If neither aligns, the receiver consults the policy: none means monitor only, quarantine suggests the spam folder, and reject asks the receiver to refuse the message. Receivers treat the policy as a strong request, not a command, and apply their own Spam Filter logic too.
What changed with RFC 9989
RFC 9989, published in May 2026, moved DMARC from an informational document to an IETF standard and split aggregate and failure reporting into RFC 9990 and RFC 9991 [1]. The core idea is unchanged, but several details differ. The pct tag, which let owners apply a policy to a sampled share of mail, was removed because receivers rarely honored values other than 0 or 100; a t= test flag takes its place. Receivers now find the organizational domain by walking up the DNS tree instead of relying on the Public Suffix List. A new np= tag sets policy for subdomains that do not exist, which blocks a common spoofing trick. Existing records that use v=DMARC1 with p, sp, rua and ruf keep working, so most domains need no urgent change.
Rolling out DMARC safely
The usual path is to start with p=none and an rua= address, then read the aggregate reports for a few weeks. They show every source sending as your domain and whether each one passes SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) with alignment. Any legitimate service that fails, such as a CRM or billing tool, needs its authentication fixed before you tighten the policy. Google recommends this gradual approach in its setup guide, moving to quarantine and then reject once reports are clean [5]. For outreach, a Secondary Sending Domain needs its own record, and a missing one leaves the domain open to spoofing and counts against Bulk Sender Requirements. DMARC is also the base layer for BIMI and a clear signal of good Email Authentication practice to every major provider.
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — IETF
- Email sender guidelines — Gmail Help
- Sender Best Practices — Yahoo Sender Hub
- Strengthening the email ecosystem: Outlook's new requirements for high-volume senders — Microsoft Tech Community
- Set up DMARC — Google Workspace Admin Help
Related terms
Outreach without the busywork.
PineLead finds new B2B prospects every day, qualifies them against your criteria and writes the first email in your voice. You approve — PineLead sends.
Start free with 100 credits →