Email & Collaboration Threat Protection

DMARC is now a Proposed IETF Standard — is your organization ready?

Here’s what changed, what it signals for compliance and insurance requirements, and why p=none is no longer a safe place to sit

by Alexander Decarne

juin 01, 2026

Key Points

DMARC has moved from an Informational document to a Proposed Standard (RFC 9989) on the IETF Standards Track. Its requirements now carry official consensus weight.
Existing v=DMARC1 records remain fully valid. RFC 9989 introduces structural updates organizations can adopt at their own pace, but the compliance and insurance pressure to move toward enforcement is accelerating.
Cyber insurers are increasingly asking about DMARC enforcement during underwriting. A p=none posture, monitoring only, is being treated as a weaker signal than enforced policy by a growing number of carriers.

After eleven years as a widely adopted community convention with no formal IETF standing, DMARC is now an IETF Standards Track document. RFC 9989, published in May 2026, obsoletes RFC 7489 and places DMARC on the same Standards Track as foundational protocols like SMTP and IMAP. For most organizations, this might read as a technical footnote. It isn't.

Why the status change matters

The original RFC 7489 was published in 2015 via the IETF's Independent Submission Stream, meaning it carried no formal IETF consensus weight, which is why implementations diverged and gaps went unaddressed for years. RFC 9989 changes that: DMARC's requirements now reflect formal IETF consensus, reviewed by the community and approved by the IESG.

The practical consequence: regulated sectors and procurement frameworks now have a citable, stable reference for mandating DMARC adoption. An IETF Proposed Standard is the kind of document that ends up in government security baselines, financial sector guidance, and enterprise vendor risk frameworks. The EU's NIS2 Directive and DORA already require organizations to implement email security controls; RFC 9989 gives those frameworks a precise technical anchor.

Two supporting standards accompany RFC 9989. RFC 9990 covers aggregate reporting and RFC 9991 covers failure reporting, both now standalone Proposed Standards. Separating reporting from the core protocol makes implementation expectations clearer for senders, receivers, and tooling vendors alike.

The cyber insurance angle you shouldn’t ignore

Beyond technical compliance, cyber insurers are factoring DMARC posture into underwriting decisions, and RFC 9989 is likely to sharpen that scrutiny. Gallagher's 2025 Cyber Insurance Market Conditions Outlook documents that insurers are evaluating organizations’ security posture more granularly, with email authentication explicitly named alongside MFA, EDR, and backup practices as factors influencing premium pricing and coverage availability.

Underwriting applications from major carriers now routinely ask whether organizations have implemented SPF, DKIM, and DMARC. But the question behind the checkbox is increasingly whether policy is enforced. A p=none posture, which monitors email flows but takes no action on failing messages, is a weaker signal to underwriters than p=quarantine or p=reject. Organizations running p=none as a permanent posture may face additional scrutiny at renewal, less favorable terms, or reduced coverage limits.

Five changes IT teams need to understand

Existing records beginning with v=DMARC1 remain fully valid, with no migration deadline. But several structural changes will affect DNS lookup behavior, report handling, and rollout strategy.

1. Three tags are removed: pct=, rf=, and ri=

The pct= (percentage-based rollout) tag is gone; in practice it was rarely used with nuance. The rf= (report format) tag is also removed — only one format was ever used. And ri= (requested report interval) is removed; RFC 9989 recommends receivers send reports daily. If your records still carry these tags, nothing breaks — unknown tags are silently ignored per RFC 9989 §4.7 — but they can be cleaned up.

2. The t= tag replaces pct= with predictable, graduated behavior

The t= tag has two values. t=y signals testing mode: p=quarantine combined with t=y treats failing messages as p=none; p=reject combined with t=y treats them as p=quarantine — one step softer than the stated policy. t=n (the default) enforces policy normally. This replaces the ambiguity that made pct= inconsistent across implementations.

3. New tag: np= for non-existent subdomains

RFC 9989 introduces np=, which defines DMARC policy specifically for non-existent subdomains — those with no DNS record. Previously these fell under sp= or defaulted to the organizational domain's p= value. Attackers sometimes send from subdomains with no DNS existence, exploiting that ambiguity. The np= tag gives domain owners explicit control.

4. DNS Tree Walk replaces the Public Suffix List

Organizational domain discovery previously relied on the Public Suffix List (PSL), a static, manually maintained external database. RFC 9989 replaces this with the DNS Tree Walk algorithm, which dynamically traverses the DNS hierarchy from the From: header domain until it locates the relevant _dmarc TXT record — removing a known source of policy misattribution in complex domain structures.

5. PSD support and the psd= tag are now core

Public Suffix Domain support was previously experimental (RFC 9091). RFC 9989 obsoletes RFC 9091 and integrates PSD handling into the core spec. The psd= tag is now standard, not experimental — particularly relevant for organizations operating under country-code second-level domains such as .co.uk.

What this signals for the industry

For organizations still at p=none, RFC 9989 raises the stakes on two fronts simultaneously. Audit frameworks and procurement requirements now have a formal, citable standard to reference, and sector-specific mandates will increasingly anchor to RFC 9989 rather than its informational predecessor. At the same time, insurance pressure to move to enforcement is building independently of compliance drivers.

The path to enforcement is unchanged: visibility first, every sending source identified, every SPF and DKIM failure resolved before policy tightens. One meaningful technical shift is worth noting: RFC 9989 explicitly discourages p=reject for indirect mail flows, including mailing lists and forwarding — receivers are directed to treat those cases as p=quarantine rather than rejecting them outright.

Nothing currently deployed breaks. But organizations running p=none as a permanent posture are exposed on three fronts: the spoofing risk they were already carrying, a standard with enough formal weight to appear in regulatory baselines and vendor risk assessments, and a cyber insurance market that increasingly distinguishes between monitored and enforced authentication.

Staying ahead with Mimecast

Mimecast is monitoring the adoption of RFC 9989 and its companion standards closely. For organizations using Mimecast DMARC Analyzer, the transition should be seamless. The platform provides continuous visibility to manage domain authentication posture as standards and enforcement expectations evolve. As part of a broader platform serving over 42,000 organizations globally, Mimecast helps security teams stay ahead of the compliance and insurance requirements now converging around DMARC enforcement.

Want to understand what RFC 9989 means for your DMARC implementation and how we can help? Schedule a demo and speak to one of our experts.

Sources:

RFC 9989 (IETF, May 2026) — https://www.rfc-editor.org/rfc/rfc9989
Gallagher 2025 Cyber Insurance Market Conditions Outlook (cited via AutoSPF analysis, May 2026) — https://autospf.com/blog/email-authentication-cyber-insurance-dmarc-pricing-underwriters-2026-insurance-applications/
BindLedger, DMARC, SPF, and DKIM for Cyber Insurance Renewals (March 2026) — https://www.bindledger.com/blog/dmarc-spf-dkim-for-cyber-insurance