Introduction
When the IETF published DMARCbis in May 2026 — three new RFCs, numbered 9989, 9990 and 9991 — the technical community had plenty to talk about. Your clients, on the other hand, mostly want the answer to one question: does this affect me, and do I need to worry? The account-management difficulty is that two honest answers are true at once. Nothing about a client's existing setup fails the moment the RFCs are published, and yet a modern review is genuinely worthwhile. How you hold those two truths together is what separates a conversation that builds trust from one that manufactures panic.
This article gives MSP owners, technical account managers and vCISOs a set of calm, accurate messages for talking about the new standard, along with a script you can use almost verbatim. The goal is to inform clients and open the door to worthwhile work without ever resorting to alarm. It sits alongside the cluster overview, DMARC has changed: RFC 9989, 9990 and 9991 for MSPs, and the broader DMARC for MSPs guide.
The instinct to avoid
There is a well-worn sales reflex in security: find the scary headline, wave it at the client, and let fear do the closing. DMARCbis offers plenty of raw material for that approach — a brand-new IETF standard, an old specification formally obsoleted, familiar configuration tags removed. It would be easy to send an email that begins "URGENT: the DMARC standard has changed and your record may now be non-compliant." Easy, and wrong. It is inaccurate, because existing records keep working; it damages trust, because the client eventually learns nothing was actually on fire; and it trains clients to discount your next warning, which may be the one that matters. The messages below are built to be truthful first, which is also what makes them persuasive.
Nothing necessarily breaks today
The single most important thing to convey is reassurance grounded in fact. The publication of RFC 9989 did not invalidate anyone's DMARC record overnight. Receivers continue to honour existing records, mail continues to flow, and the core logic clients rely on is unchanged: a message still passes DMARC when it produces an aligned SPF or an aligned DKIM result. The one concrete change worth mentioning is that the old pct tag is now ignored by receivers implementing the new standard, so a record that relied on it for a partial rollout is, in practice, fully enforcing — a detail to review, not an emergency. Leading with "nothing necessarily breaks today" gives the client permission to engage with the topic calmly instead of defensively.
The standard has matured
The second message reframes the change as progress rather than disruption. For a decade, DMARC lived as an Informational document, RFC 7489 — useful and near-universally deployed, but never a formal internet standard. DMARCbis moves it onto the IETF Standards Track as a Proposed Standard, splitting the specification into a clear core protocol and two dedicated reporting documents. For a client, the useful translation is simple: the technology they already depend on has been formalized and tidied up by the standards community, which is a sign of maturity and long-term stability, not a reason for concern. Framed this way, the news becomes reassuring — the thing protecting their brand just became a proper standard.
Your domain may still deserve a modern review
With the reassurance established, you can introduce the value. The maturing of the standard is a good prompt to check that a client's specific configuration reflects current best practice. Many DMARC records in the wild were set up once, years ago, and never revisited: they may still sit at p=none, carry a now-inert pct tag, point their reporting at a mailbox nobody reads, or omit newer protections such as a policy for non-existent subdomains. None of that is broken in the sense of causing an outage, but all of it represents protection the client is paying for in theory and not receiving in practice. A modern review is how you find the gap between "we have DMARC" and "DMARC is actually protecting us."
A TXT record is not the same as protection
This is the message that reframes the client's mental model, and it is worth stating plainly. Having a DMARC record published is not the same as being protected by it. Protection comes from three things working together: a policy actually set to enforce, a complete and accurate inventory of the systems allowed to send as the domain, and reporting good enough to notice when something changes. A domain can have a valid TXT record and still be wide open, because the policy is none and anyone can spoof it, or because a legitimate sender is failing quietly and nobody is watching the reports. Reporting quality and enforcement posture matter far more than the mere presence of a record — and DMARCbis, by cleaning up and formalizing exactly those reporting mechanisms, is a natural moment to make that point.
A good moment to move from monitoring to enforcement
The final message turns the standard's arrival into a recommended next step. Plenty of clients have been parked at p=none for a long time, monitoring but never enforcing, often because an earlier rollout stalled or because moving to enforcement felt risky. The maturing of the standard, and the removal of the pct tag that used to make "partial" enforcement seem like a soft option, together make this a sensible moment to finish the job. The path is well understood and low-risk when done properly — confirm the senders, watch the reports, then step from monitoring to quarantine to reject. Positioning enforcement as the natural conclusion of a review, rather than a scary leap, is what converts a conversation into a project. The mechanics live in DMARC enforcement after RFC 9989.
A script you can use
When you need to open the conversation in writing — an email, a portal message, a line in a quarterly review — this wording is deliberately calm, accurate and non-alarming, and you can use it close to verbatim:
“ DMARC has recently been updated and formalized by the IETF. Your current record may still work, but this is a good moment to verify whether your domain is properly protected, whether all legitimate senders are aligned, and whether your policy can safely move toward enforcement. “
It works because it does three things in order: it states the news as a neutral fact, it reassures ("may still work"), and it proposes a specific, bounded piece of value — verification of protection, senders and enforcement readiness. There is no manufactured deadline and no fear, which is precisely why clients respond to it.
Answering the questions that follow
A few predictable questions come back, and calm answers keep the tone consistent.
When a client asks whether they have to do anything right now, the honest answer is no, not urgently — nothing breaks today, and this is a review worth scheduling rather than an incident to resolve. When they ask whether their record is now invalid, the answer is that it remains valid and functioning; the standard has been modernized, and the review simply checks that their configuration reflects it. When they ask what actually changed, keep it to the essentials: the specification became a formal standard, the reporting was tidied up, a few obsolete tags such as pct were removed, and a few precise new controls were added. And when they ask why they should act at all if nothing is broken, return to the core point — a published record is not the same as real protection, and the review is how you confirm they have the protection they are paying for.
Turning the conversation into work
Handled well, the DMARCbis conversation is not a compliance scramble; it is a natural reason to re-engage every client with a domain under management. A quick check with the DMARC checker shows you at a glance which client records are still at p=none, still carry a pct tag, or point reporting somewhere unhelpful — the exact evidence that makes the review concrete. From there, the work packages cleanly into a modern DMARC review and, where appropriate, a staged move to enforcement. This is also the moment to make sure your own service offering reflects the new standard, which is covered in how MSPs should update their DMARC service offering.
Related articles
- DMARC for MSPs — complete guide
- DMARC has changed: RFC 9989, 9990 and 9991 for MSPs
- DMARC enforcement after RFC 9989: p=reject still requires care
- How MSPs should update their DMARC service offering
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