DMARC

DMARC Just Became a Standard — What That Comes to Mean Beyond Google and Yahoo

September 17, 2026

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

For eleven years, DMARC ran on borrowed authority. Every mailbox provider that checked it, every auditor that referenced it, and every insurer that asked about it was relying on a document that the IETF itself had never formally blessed. That gap just closed. In May 2026, the IETF published RFC 9989, moving DMARC onto the Standards Track and obsoleting the original RFC 7489. For MSPs who have spent years explaining DMARC to skeptical clients, this is the moment the ground shifts from "industry best practice" to formal Internet Standard.

What Actually Changed on the IETF Standards Track?

DMARC moved from an Informational document with no IETF consensus behind it to a Proposed Standard reviewed and approved by the Internet Engineering Steering Group. The practical effect: DMARC's requirements now carry the same formal weight as protocols like SMTP and IMAP, giving regulators and procurement teams a citable, stable reference instead of a community convention.

The original DMARC specification, RFC 7489, was published in 2015 through the IETF's Independent Submission Stream. That route meant it never carried formal IETF consensus, which is part of why vendor implementations diverged over the years and why some interoperability gaps sat unresolved for so long. The RFC Editor's record for RFC 9989 confirms the new document represents the consensus of the IETF community and has been approved for publication by the IESG, a status the earlier document never held.

DMARC's promotion did not arrive alone. Two companion documents, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting, were published as standalone Proposed Standards at the same time. Collectively, the industry has started calling this bundle "DMARCbis," and it replaces the aging report-format guidance that DMARC operators have leaned on since 2015.

In plain terms: DMARC is no longer just a widely-followed convention that mailbox providers happen to enforce. It is now a formally ratified IETF Internet Standard, which means existing v=DMARC1 records keep working exactly as before, but the specification behind them now carries the procurement and regulatory weight that only Standards Track documents get.

Why Google and Yahoo Were Never the Real Story

Google and Yahoo's 2024 bulk sender rules got the headlines because they were visible and immediate. Starting in February 2024, both providers began requiring bulk senders to authenticate with SPF and DKIM and to publish a DMARC record, with Google moving to reject a percentage of non-compliant mail that April. That deadline forced tens of thousands of domain owners to finally publish DMARC records they had ignored for a decade.

But mailbox provider policy was always a private business decision, not a technical mandate with any formal standing behind it. Google could change its enforcement thresholds tomorrow and nothing in the DNS would break. What RFC 9989 does is different in kind: it gives every framework that references DMARC a fixed technical anchor that does not depend on one company's inbox policy.

That distinction matters most for federal and regulated environments. CISA's Binding Operational Directive 18-01 already required civilian federal agencies to move toward a DMARC policy of p=reject, and it pointed to NIST SP 800-177 as the detailed implementation guide agencies were expected to follow. Directives like that were written against a specification with no IETF standing. Now the reference document underneath them has one.

Who Actually Feels This Beyond the Big Mailbox Providers?

Cyber insurance underwriters, EU regulators, and government procurement teams feel it first. Each of these groups treats an IETF Proposed Standard differently than a decade-old convention when writing baselines, and DMARC's promotion gives them a document they can cite directly rather than pointing to industry practice.

Cyber insurers have been asking about email authentication posture during underwriting for a while now, and a growing number of carriers already treat a p=none monitoring-only policy as a weaker signal than an enforced reject policy. That pattern is documented across multiple underwriting guides, including analysis noting that organizations demonstrating DMARC at enforcement have a documented advantage in standardized risk assessments that regulators are increasingly requiring insurers to run. A Standards Track RFC gives those underwriting questionnaires a firmer technical basis than "most vendors recommend this."

Government and critical-infrastructure buyers move the same way. An IETF Proposed Standard is exactly the kind of document that tends to show up in security baselines, financial sector guidance, and enterprise vendor risk frameworks going forward, according to reporting on the change from Mimecast. Procurement language that once said "DMARC or equivalent" now has a specific RFC number to point to, which tends to close loopholes rather than open them.

What Changes Technically for the Domains MSPs Already Manage?

Existing v=DMARC1 records remain fully valid under RFC 9989, so nothing breaks on day one. The update introduces new optional tags and one structural change worth flagging: DMARC now uses a DNS tree walk algorithm to locate policy records instead of relying on the Public Suffix List, a change documented in the updated specification's discovery mechanism.

The new tags are additive rather than mandatory. Domain owners can add np to set a policy for non-existent subdomains, psd to flag public suffix domains, and t for an explicit testing mode, while the older pct, rf, and ri tags are deprecated in the updated guidance. None of this forces an MSP to touch a working record today, but it does mean the next round of client audits should check for compatibility rather than assume yesterday's configuration guide still reflects the current spec.

For MSPs running scans across client portfolios, the practical task list looks familiar even if the underlying document has changed status:

• Confirm every client domain still resolves a valid DMARC record under the tree walk discovery method, not just the old PSL-based lookup.
• Flag any domain still sitting at p=none as a candidate for enforcement, since that posture is now visible to a wider set of auditors and underwriters than before.
• Review SPF and DKIM alignment on domains that send through multiple platforms, since alignment failures are the most common reason enforcement rollouts stall.

None of this is a one-time project. Because DMARC enforcement risk changes as clients add marketing platforms, help desks, and CRM tools that send mail under the primary domain, ongoing monitoring is what actually catches drift between audits. That is the gap that scanning tools are built to close, and it is worth checking a provider's pricing against how many domains and how much report volume a given plan actually covers before committing a client base to it.

What This Means for MSP Positioning Going Forward

The compliance conversation just got easier to win and harder to dodge. When a client asks why DMARC enforcement matters, the answer no longer rests on "most major providers recommend it." It rests on a ratified IETF standard sitting behind the same procurement and insurance frameworks that regulated clients already have to satisfy for other reasons.

That is a stronger sales conversation for MSPs who have been trying to move stalled clients off p=none for years, but it also raises the bar for what a "DMARC is handled" checkbox actually means. Reviewing a domain once and walking away is no longer defensible when insurers and auditors are asking about enforcement status, not just record existence. MSPs onboarding new domain security clients can walk through the current baseline using a structured getting-started guide rather than reconstructing the checklist from memory each time.

The dmarc.org working group has been explicit that this update is meant to formalize existing practice rather than upend it, and the organization's own summary of the May 2026 publication of the three companion RFCs frames the change as bringing the protocol in line with how mail actually runs today. For MSPs, the sensible response is not urgency, it is precision: audit records against the new discovery method, tighten enforcement on domains still sitting at monitoring-only, and treat the standard's new formal status as leverage in conversations that used to rely on goodwill. Teams that want to see where their current client domains stand against the updated spec can run that check directly through signup rather than waiting for the next scheduled audit cycle.