DMARCbis Readiness Checklist for MSPs

Introduction

In May 2026 the IETF published three new DMARC RFCs — RFC 9989, RFC 9990 and RFC 9991 — known collectively and informally as DMARCbis. Together they obsolete the original RFC 7489 from 2015 and move DMARC from Informational status onto the IETF Standards Track as a Proposed Standard. For most MSPs this is not an emergency. Correctly configured records keep working, and nothing breaks overnight. But "nothing breaks overnight" is not the same as "nothing to do." The specification your tooling, documentation and client conversations were built around has been replaced, and a methodical readiness pass is the difference between a clean transition and a slow trickle of avoidable surprises.

This article is a practical, work-through checklist for a managed-services practice. It is a companion to the DMARC for MSPs pillar and assumes you manage DMARC across many client domains rather than one. Work through each section once at the practice level, then use the closing recommendation to run the per-domain audit across your portfolio.

Why this checklist matters now

The three RFCs each own a distinct part of the protocol. RFC 9989 is the core: policy evaluation, alignment rules, record processing, domain discovery and Public Suffix Domain handling. RFC 9990 defines aggregate reporting — the daily, GZIP-compressed XML reports your platform ingests. RFC 9991 defines message-specific failure reporting, the mechanism formerly described loosely as "forensic." Because the change is split across three documents, and because it folds in the previously separate PSD extension (RFC 9091 is also obsoleted), the surface area an MSP needs to review touches software, parsers, runbooks and client-facing language all at once.

The reassuring part is that the changes are additive and legacy-tolerant by design. Old records remain valid, and removed tags are ignored by receivers rather than rejected. The work is therefore mostly hygiene and accuracy: making sure your platform, your documentation and your explanations reflect the standard now in force rather than the one it replaced. Do the practice-level items first, because they are one-time fixes that make the per-client work faster and safer.

One practical note on timing: there is no single cut-over date. Receivers adopt DMARCbis on their own schedules, and the ecosystem shifts over months rather than overnight. The operational deadline that matters in practice is when the large mailbox providers your clients actually send to announce support, not the RFC publication date itself. Completing this checklist ahead of those announcements is what keeps the transition uneventful, and it gives you a prepared answer for the handful of clients who will ask what DMARCbis means for them.

Platform and parsing readiness

Start with the software, because everything downstream depends on it.

• [ ] Confirm your DMARC platform explicitly supports RFC 9989, RFC 9990 and RFC 9991, not just "DMARCbis draft" behaviour. Publication tightened several details that late drafts had left open, so draft-era support is not automatically final-RFC support.
• [ ] Verify your aggregate-report parser handles the RFC 9990 report variations, including the fact that DKIM authentication detail is now required in reports rather than optional. Parsers that treated the DKIM block as optional may silently drop data or throw errors on well-formed modern reports.
• [ ] Confirm the parser reads GZIP-compressed XML reliably and tolerates the modernized aggregate schema. RFC 9990 keeps reports XML and GZIP-compressed, but the schema has been cleaned up, so brittle field-order or namespace assumptions are worth re-testing against live output.
• [ ] Check that failure-report handling reflects RFC 9991's message-specific model. These reports are privacy-sensitive, are not always sent, and should never be presented to clients as a guaranteed stream.

If you build any of this yourself, treat the published RFCs as the source of truth and re-test against real reports from Google, Microsoft and Yahoo, since receiver output is where schema assumptions actually get exercised.

Terminology and reporting language

• [ ] Update failure-reporting language across your platform and documents from "forensic reports" to "failure reporting." RFC 9991 formalizes the latter term, and aligning your wording avoids confusing clients who read the current standard.
• [ ] Review every client-facing reporting disclaimer. Failure reports are not always generated, aggregate reports can lag or gap, and both reflect what receivers choose to send. Your disclaimers should say so plainly rather than implying complete visibility.

Tag and discovery logic

• [ ] Review your handling of the removed tags — pct, rf and ri. Under DMARCbis, pct is gone (enforcement is now all-or-nothing rather than a percentage), rf is removed, and ri is removed and ignored by receivers. A record still carrying these tags generally stays valid, but your generator should stop emitting them and your analytics should stop relying on them.
• [ ] Make sure your team understands the three new tags — np, psd and t — and that your platform handles them safely. np sets policy for non-existent subdomains, psd flags Public Suffix Domain records, and t signals test or transitional mode. Our new DMARC tags explained article covers each in detail.
• [ ] Revisit any partial-enforcement workflow that depended on pct. The percentage model is gone; controlled rollout now moves through policy levels, with the t tag available as a testing signal. See why pct is going away.
• [ ] Review your organizational-domain discovery logic against RFC 9989, which folds the previously separate PSD extension into the core and defines domain-boundary handling directly. A single-domain admin rarely notices discovery edge cases; an MSP portfolio eventually does.

Client-facing materials

• [ ] Update client-facing templates — onboarding documents, QBR decks, MSA and SOW language, and status reports — so they describe the current standard. Anywhere you cite "RFC 7489" should now reference the DMARCbis RFCs where accuracy matters.
• [ ] Refresh every DNS example in your knowledge base and generator output. Remove pct= from sample records, and add examples that show np= and, where relevant, t=y, so your documentation models current best practice.
• [ ] Update your Microsoft 365, secure-gateway and ARC troubleshooting docs. The mechanics that cause DMARC to fail behind a filtering layer are unchanged by DMARCbis, but your docs should be current alongside everything else — see why DMARC fails with a gateway in front of Microsoft 365 and the DMARCbis for Microsoft 365 clients guide.

Running the checklist across a portfolio

The sections above are practice-level: you do them once. The per-domain work — validating each record, clearing legacy pct staging, confirming discovery and reporting are healthy — is where the volume is. Across dozens or hundreds of domains, that is the part worth automating, and it is the part that turns "something a client noticed and asked us about" into "something we handled during regular operations."

This is where DMARC AI earns its place in the workflow: use it to audit all of your client domains against modern best practices in a single pass. The platform flags legacy pct, rf and ri usage, validates records against the published RFCs, confirms aggregate reports are parsing cleanly with the now-required DKIM detail, and surfaces the domains whose discovery or subdomain posture needs a human decision. Run it once to establish a baseline, then let it hold the portfolio to the standard as receivers finish rolling out DMARCbis support. For any single record you want to review by hand, start with the DMARC checker and rebuild clean records with the DMARC generator.

Related articles

• DMARC for MSPs — complete guide
• New DMARC tags explained: np, psd and t
• pct is going away: rethinking partial DMARC enforcement
• DMARCbis for Microsoft 365 clients
• Why DMARC fails with a gateway in front of Microsoft 365

Authoritative references

• RFC 9989 — core DMARC protocol
• RFC 9990 — DMARC aggregate reporting
• RFC 9991 — DMARC failure reporting
• RFC 7489 — the obsoleted 2015 specification

Author: DMARC AI editorial team Last updated: August 2026