DMARC

DMARCbis, p=reject, and the Next Phase of Email Authentication Enforcement

September 17, 2026

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

For most of its life, DMARC has operated on borrowed authority. The protocol that decides whether a spoofed invoice or a fake payroll update ever reaches an inbox was, until recently, published only as an informational document rather than a ratified internet standard. That changed in May 2026, when the IETF published RFC 9989, formally obsoleting the original 2015 specification and putting DMARC on the Standards Track for the first time. The timing matters less than the direction. Enforcement has been tightening for two years already, and the new RFC set gives that trend a firmer technical foundation.

The short answer: DMARCbis, now published as RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting), does not force any domain to change its policy overnight. What it does is codify, in normative language, the enforcement behavior mailbox providers and regulators have already been demanding. For MSPs, the practical work is unchanged: get client domains off p=none and into p=reject, deliberately.

What Is DMARCbis, and Why Does the Upgrade to a Proposed Standard Matter?

DMARCbis is the working name the IETF community used for years while it rebuilt DMARC's foundational document. The finished result is not one RFC but three, splitting the original single specification into a core protocol document and two reporting documents. The core document explains that DMARC lets a domain owner enable validation of the domain's use, state a handling preference for mail that fails that validation, and request reporting on how the domain is being used, exactly as the original spec did, but now with IETF consensus behind it rather than an independent submission's informational status, as described in the published RFC 9989 text.

That shift from Informational to Proposed Standard is a governance change more than a technical one. Existing v=DMARC1 records keep working without modification. What changes is the weight the specification carries when auditors, regulators, and procurement teams cite it, since a document that has been through IETF review and IESG approval reads differently in a compliance framework than one that was submitted independently over a decade ago.

The reporting split is the more concrete technical change. Failure reporting now lives in its own document, RFC 9991, which updates RFC 6591 and formally obsoletes RFC 7489 on that front, while aggregate reporting has its own home in RFC 9990. Splitting the specification this way lets each reporting mechanism evolve on its own schedule instead of dragging the whole protocol through a single monolithic revision every time.

How Are Mailbox Providers Already Forcing the Move Beyond p=none?

They are doing it through graduated enforcement rather than a single flag day. Google and Yahoo began requiring bulk senders, those sending roughly 5,000 or more messages a day, to authenticate mail and publish a DMARC record starting in February 2024, though the initial bar was only a policy of p=none. Microsoft followed with its own bulk sender authentication requirement for outlook.com, hotmail.com, and live.com starting May 5, 2025, extending the same expectations to a mailbox base most MSPs also manage on behalf of clients, according to dmarcian's tracking of the rollout.

The floor has stayed at p=none on paper, but the consequences of sloppy authentication have gotten sharper. Google confirmed that starting in November 2025 it began ramping up enforcement on non-compliant traffic, with messages that fail sender requirements now facing temporary and permanent rejections rather than a quiet trip to spam, as Google's own sender guidelines FAQ lays out. A domain sitting at p=none with no active monitoring is no longer just leaving reputation on the table. It is now more likely to see its own legitimate mail bounce when SPF or DKIM alignment drifts, because the mailbox provider has stopped giving marginal traffic the benefit of the doubt.

Why Are Government and Regulatory Mandates Pulling in the Same Direction?

Because the federal government got here first and proved the model works at scale. CISA's Binding Operational Directive 18-01, issued in 2017, required all federal civilian executive branch agencies to set a DMARC policy of reject for all second-level domains and mail-sending hosts within one year of the directive, explicitly stating that this policy tells recipients to drop mail that does not match the specified SPF and DKIM alignment, as documented on CISA's own directive page. That eight-year-old mandate has become the template regulators elsewhere point back to when justifying their own enforcement timelines.

CISA has since layered newer directives on top of that baseline. Binding Operational Directive 25-01, issued in December 2024 under the Secure Cloud Business Applications initiative, requires federal agencies to implement a defined set of secure configuration baselines for widely used SaaS platforms and to deploy CISA's own assessment tooling to check compliance against them, with CISA's implementation guidance confirming DMARC posture as part of that baseline for Microsoft 365 tenants. The pattern across both directives is consistent: publish a monitoring policy quickly, then move to enforcement on a fixed clock, with automated tooling checking the work rather than relying on self-attestation.

What Should MSPs Do Before Flipping Client Domains to Reject?

Move in phases, and do not treat p=reject as a single DNS edit. The risk in DMARC enforcement was never the policy tag itself. It is the shadow IT that shows up in aggregate reports once a client's marketing platform, invoicing tool, or forgotten subdomain suddenly stops delivering mail because nobody knew it was sending on the domain in the first place.

A defensible rollout for a client domain generally follows this sequence:

• Publish p=none first and let aggregate reports run long enough to surface every legitimate sending source, including third-party platforms and forgotten subdomains.
• Fix SPF and DKIM alignment for each identified sender before touching the policy tag again.
• Move to p=quarantine with a low percentage and watch for false positives across a full business cycle, including month-end billing runs.
• Only then advance to p=reject at full percentage, and keep monitoring afterward, since new senders get added to client environments constantly.

This is where the practical difference between "DMARC is published" and "DMARC is actually protecting the domain" shows up. A domain can carry a p=reject record for years while forensic visibility into who is failing and why has quietly gone stale, an outcome that is invisible until a client's own vendor emails start bouncing. ActiScan's getting-started guide walks through that discovery-to-enforcement sequence in the same order described above, which is the order that avoids breaking a client's legitimate mail flow mid-rollout.

Where This Leaves MSPs Managing Dozens of Client Domains

None of this changes what MSPs were already supposed to be doing. It raises the cost of not doing it. A domain that has been sitting at p=none since 2022 is not meaningfully more protected today than it was then, and the mailbox providers enforcing bulk sender rules and the federal directives setting the compliance tone are both converging on the same expectation: monitor first, then enforce, and keep watching after enforcement lands.

For an MSP with a handful of client domains, tracking this by hand in a spreadsheet was always tedious. For an MSP with fifty or five hundred, it stops being a spreadsheet problem and becomes an operational one, since drift in SPF records or an expired DKIM selector on one client can go unnoticed for months without dedicated scanning. ActiScan's plans are built around that multi-domain reality, scaling coverage and alerting as a book of business grows rather than charging per manual audit. MSPs who want to see where their current client domains actually stand against this enforcement curve can create an account and run that inventory before the next mailbox provider tightens the screws further.

DMARCbis will not be the last update to this protocol. RFC 9989 explicitly frames the DNS-based domain discovery method it introduces as a replacement for the aging Public Suffix List dependency the original spec acknowledged as a known limitation, which signals the working group expects continued refinement rather than a finished product. The direction of travel, though, has been set for years now, and it points one way: toward enforcement, toward visibility, and away from the comfortable but increasingly risky default of p=none.