DMARC

From Guidelines to Standards Track: Where Email Authentication Pressure Goes Next

September 17, 2026

Randy Hall, CEO— AI-assisted and reviewed prior to publication.

Printed RFC specification pages next to a DNS record printout on a technician's desk with server logs on screen

For eleven years, DMARC operated on borrowed authority. It was widely deployed, cited in vendor documentation, and required by two of the largest inbox providers on earth, yet it carried no formal standing inside the body that governs the internet's core protocols. That changed on May 20, 2026, when the IETF's RFC Editor published three documents moving DMARC onto the Standards Track, the same designation held by SMTP and IMAP.

What Does It Mean That DMARC Is Now a Standards Track Protocol?

It means DMARC has moved from an Informational document with no formal IETF backing to a Proposed Standard vetted through IETF consensus process. Existing v=DMARC1 records keep working without changes. What shifts is the weight behind the specification itself, and the pace at which enforcement expectations from mailbox providers, auditors, and insurers are likely to harden.

The three documents involved are not a single monolithic update. RFC 9989 replaces the original protocol description, RFC 7489, and covers the core DMARC mechanism itself. Two companion documents split out reporting: RFC 9990 governs aggregate reporting, the machine-readable data domain owners pull from mailbox providers, and RFC 9991 covers failure reporting, the per-message forensic data used to diagnose spoofing attempts. Splitting these concerns into standalone Proposed Standards was a deliberate structural choice, separating "how the protocol works" from "how you monitor it."

Why This Sits on Top of an Enforcement Trend Already in Motion

The standards track move did not create pressure on email authentication. It formalized pressure that mailbox providers had already been applying for two years. Google and Yahoo began requiring authentication from bulk senders in February 2024, and Microsoft followed in May 2025, both citing the same underlying logic: unauthenticated bulk mail is a primary vector for phishing and spoofing at scale.

Google's own sender guidelines are explicit about what bulk senders must maintain, including a DMARC policy at minimum p=none, SPF and DKIM alignment, and TLS for message transmission, with the added detail that Gmail's own quarantine enforcement now extends to protecting its own From: headers against impersonation, as Google's Gmail Help documentation lays out. Microsoft's parallel rollout was blunter in its consequences. Once the May 5, 2025 deadline passed, Microsoft began rejecting rather than junking noncompliant bulk mail outright, with messages failing to meet the bar bounced with a 550 5.7.15 error, a shift confirmed by DMARC monitoring vendor dmarcian's coverage of the rollout.

That pattern, warn first, then quarantine, then reject, is not new. The U.S. federal government ran the same playbook nearly a decade earlier. CISA's Binding Operational Directive 18-01, issued in 2017, required federal civilian agencies to move to a DMARC policy of p=reject, and the directive explicitly frames email authentication by sending domains as a requirement rather than a suggestion, as documented in CISA's own directive text. The three biggest inbox providers on the planet arrived at the same enforcement conclusion the federal government reached in 2017. The IETF standards track move is best read as the specification catching up to where enforcement already was.

What Actually Changed Inside the Protocol

The DMARCbis update, as the working group called it during drafting, is evolutionary rather than a rewrite. Domain owners running existing p=none, p=quarantine, or p=reject policies do not need to touch their DNS records to stay compliant with the new specification. A handful of structural changes matter for anyone building or auditing DMARC policy going forward.

A non-existent subdomain policy tag. Domains can now explicitly signal handling instructions for subdomains that were never provisioned to send mail, closing a spoofing gap that previously relied on inconsistent implementation choices.
Deprecated and clarified tags. Several tags carried over from the original 2015 specification that saw little real-world adoption have been marked obsolete, trimming ambiguity for tooling vendors writing DMARC record parsers.
A formal testing mechanism. The update introduces a dedicated way to signal that a policy is being evaluated rather than enforced, reducing the informal workarounds domain owners previously used during rollout.

None of these changes require existing records to be rewritten immediately, but they do give auditors and monitoring platforms a firmer specification to test against, which is where the practical impact for MSPs actually lands.

How Should MSPs Read the Standards Track Move?

MSPs should treat this as confirmation that authentication policy is moving from optional hygiene to a documented technical baseline that clients, insurers, and mailbox providers will increasingly expect by default. The protocol did not get harder to implement. The cost of not implementing it correctly, in the form of blocked mail, insurance friction, or audit findings, is what keeps rising.

That cost is already visible in adjacent markets. Cyber insurance underwriters have begun asking about DMARC enforcement posture during applications, treating a monitoring-only p=none record as a weaker signal than an enforced quarantine or reject policy, a trend multiple carriers and brokers now factor into premium and coverage decisions. NIST's own guidance on trustworthy email, published as Special Publication 800-177 Revision 1, lays out DMARC alongside SPF and DKIM as baseline controls for federal and enterprise mail systems well before the IETF formalized the protocol, which is part of why the standards track update reads more like ratification than innovation.

For MSPs managing dozens or hundreds of client domains, the practical work has not changed in kind, only in urgency. Records still need to be published, aligned, monitored, and moved from none to quarantine to reject on a deliberate schedule. What has changed is the argument for doing that work on a defined timeline rather than an open-ended one. A domain still sitting at p=none in mid-2026, with the three largest inbox providers enforcing rejection and the underlying protocol now sitting on the same standards track as SMTP itself, is a harder position to defend to a client or an insurer than it was two years ago.

Building the Case Without Overpromising

None of this changes what DMARC can and cannot guarantee. A correctly aligned, enforced DMARC policy reduces the ability of outside parties to spoof a domain in the From: header. It does not stop look-alike domain registration, business email compromise routed through compromised accounts, or phishing that never touches the protected domain at all. MSPs presenting DMARC work to clients should frame it as one control among several, not a complete answer to email fraud.

Where the standards track move genuinely helps MSPs is in the conversation itself. Pointing a client to a formal IETF Proposed Standard, backed by the same process that produced SMTP, carries different weight than pointing to a decade-old best-practice document. Tools that continuously check SPF, DKIM, and DMARC alignment across a client portfolio, of the kind detailed in ActiScan's getting-started guide, turn that conversation into an ongoing audit trail rather than a one-time configuration task. Firms evaluating which tier fits their client count can review the options on the pricing page before rolling monitoring out across a book of business, and MSPs who have not yet run a baseline scan against their client domains can get a first look through signing up directly.

The specification just grew up. The enforcement pressure that made it necessary arrived years earlier, and it is not slowing down.