Introduction
For a decade, DMARC lived in a single document. RFC 7489, published in 2015, carried the "Informational" status label and defined the whole protocol — policy, alignment, reporting — in one place. In May 2026 that arrangement ended. The IETF published three new RFCs, RFC 9989, RFC 9990 and RFC 9991, which together replace RFC 7489 and are informally known as "DMARCbis". In the same step, DMARC moved from Informational to Proposed Standard on the IETF Standards Track.
For MSPs managing DMARC across dozens or hundreds of client domains, this is the most consequential update to the protocol since it first appeared. The reassuring part is that nothing breaks overnight — a valid record keeps working. The important part is that the way you deliver, document and talk about DMARC as a managed service now deserves a deliberate review against the new specifications. This article is the map, and it links to a detailed explainer for each piece.
If you run DMARC as a service, keep the DMARC for MSPs pillar open alongside this piece — it covers the operational playbook that these standards sit underneath.
Why one RFC became three
RFC 7489 tried to describe three quite different things in a single specification: how a receiver evaluates a message against a policy, how a receiver sends back a daily statistical summary, and how a receiver optionally forwards a copy of an individual failing message. Those are separate concerns with separate audiences and separate implementation risks, and bundling them made the document harder to implement consistently.
DMARCbis splits them cleanly:
- RFC 9989 is the core protocol — policy evaluation, alignment rules, record processing, organizational-domain discovery and Public Suffix Domain handling.
- RFC 9990 is aggregate reporting — the daily, GZIP-compressed XML reports that are the operational backbone of DMARC.
- RFC 9991 is failure reporting — the message-specific reports formerly and loosely called "forensic" reports.
The split also absorbs an older experimental document. RFC 9091, the Public Suffix Domain (PSD) extension, is obsoleted as well; PSD handling now lives inside the core standard rather than in a separate add-on. The net effect is a protocol that is easier to implement correctly and easier to reason about — which matters when you are the party accountable for getting it right across many tenants.
RFC 9989: the core, refined not reinvented
The heart of DMARC is unchanged. A message passes DMARC when it has an aligned SPF pass or an aligned DKIM pass — one is enough. If you have been running rollouts on that principle, you will keep running them on that principle.
What RFC 9989 does is tighten the edges. Organizational-domain discovery and policy handling are described more precisely, PSD handling is folded in, and the tag set is modernized. Three tags are removed — pct, rf and ri — and three are added — np, psd and t. The single most visible change for practitioners is the removal of pct, the percentage tag, which has its own article below. The full technical walkthrough is in RFC 9989 explained, and the tag changes have a dedicated piece in the new DMARC tags np, psd and t explained.
RFC 9990: aggregate reporting becomes its own standard
Aggregate reports are the data you actually operate on — the per-source, per-receiver view of who is sending as a domain and whether it authenticates. Under DMARCbis they get their own Standards Track document. The reports remain XML and GZIP-compressed, but the format is modernized and made more uniform, and one previously optional element is now required: DKIM detail must be present. That is a genuine quality-of-life improvement for anyone troubleshooting DKIM alignment or planning a key rotation. The full breakdown is in RFC 9990 explained.
RFC 9991: failure reporting, named honestly
Failure reporting — the message-specific reports some receivers send when a message fails authentication — now has its own document too. These are not the same as aggregate reports, they may contain privacy-sensitive message detail, and they are not always sent by receivers. DMARCbis prefers the term "failure reporting" over the older, misleading "forensic" label. Because their availability is inconsistent, they are a supplement to your operational picture, never its foundation. See RFC 9991 explained.
Informational to Standards Track: why the label matters
The status change from Informational to Proposed Standard is easy to overlook because it changes no bytes in a DNS record. For an MSP, though, it is a useful lever. DMARC is now a formal IETF standard rather than an informational note, which makes it easier to position as a recognized compliance and security control in client conversations, security questionnaires, cyber-insurance applications and audit scopes. When a client's compliance officer asks whether email authentication is "a real standard", the answer is now unambiguous. How to frame that with clients is covered in how the new DMARC standard affects client conversations.
Do existing client records break?
No. A valid RFC 7489 record generally remains a valid DMARC record under DMARCbis — nothing breaks overnight, and there is no emergency migration. The one behavioral change worth flagging is that pct= is now ignored: a record that relied on pct=50 to hold enforcement at a partial level no longer behaves that way, because enforcement is effectively all-or-nothing under the new model. Records that still carry rf= or ri= are not harmed; those tags are simply obsolete and ignored.
So the correct posture is not panic, but review. Existing records should be checked for best practice — removing dead tags, deciding whether the new np and t tags belong, and confirming that any pct-based staging has been re-expressed as a deliberate policy choice. The structured way to do that across a fleet is the DMARCbis readiness checklist for MSPs. The reasons pct is going away, and what to do instead, are covered in pct is going away: rethinking partial DMARC enforcement.
What MSPs should review now
The work divides into four practical areas, none of them urgent in the drop-everything sense, all of them the kind of quiet fleet-wide hygiene that distinguishes an MSP that manages DMARC from one that merely publishes it.
- Tooling and parsers. Confirm that your DMARC platform ingests the modernized RFC 9990 aggregate format and treats the now-required DKIM detail correctly. If you maintain any in-house parsing, it needs testing against the new schema.
- Client records. Sweep your managed domains for obsolete
pct,rfandritags, and identify records where removingpctchanges real-world enforcement behavior. A DMARC checker and a DNS lookup make the sweep quick. - Generation and templates. Update any record templates and your DMARC record generator defaults so that new records use the current tag set rather than deprecated tags.
- Documentation and onboarding. Refresh runbooks, onboarding documents, statements of work and client-facing explainers so they describe DMARCbis. The one-time cost of updating templates pays off across every future engagement.
The technical floor has not moved. What has moved is the standard your service should be measured against, and closing the gap between the two is exactly the sort of proactive work clients pay a managed provider to do.
Related articles
- RFC 9989 explained: the new core DMARC standard for MSPs
- RFC 9990 explained: DMARC aggregate reporting for MSPs
- RFC 9991 explained: DMARC failure reporting for MSPs
- DMARCbis readiness checklist for MSPs
- The new DMARC tags: np, psd and t explained
- pct is going away: rethinking partial DMARC enforcement
- How the new DMARC standard affects client conversations
Tools mentioned
- DMARC checker — inspect a published record and confirm it parses cleanly.
- DMARC record generator — build records with the current DMARCbis tag set.
- DNS lookup — read the raw TXT record for any managed domain.
Author: DMARC AI editorial team Last updated: August 2026