Introduction
For most MSPs, "email" and "Microsoft 365" are nearly synonyms — the majority of client tenants run on it, and any change to email authentication standards is really a question about how it interacts with M365. So when the IETF published DMARCbis in May 2026 as RFC 9989, RFC 9990 and RFC 9991, the practical question for an M365-heavy practice was immediate: what changes on our tenants, and what do we need to do? The reassuring answer is that the new standard does not upend Microsoft 365 DMARC work. The important answer is that it also does not remove any of the things that already made M365 authentication tricky — connectors, gateways and forwarding still complicate results exactly as before.
This article bridges the new RFCs to the most common MSP environment and turns them into a concrete checklist. It assumes you already run DMARC on M365 tenants and focuses on what DMARCbis does and does not change, so you can update your playbook without re-learning the platform. It pairs with the DMARCbis for Google Workspace clients sibling and the DMARC for MSPs pillar.
What DMARCbis changes for an M365 tenant — and what it doesn't
Start with the changes, because they are small and manageable. The specification is now a Proposed Standard rather than an Informational document; the pct tag is gone and ignored by receivers, so any M365 tenant whose record still carries it is effectively at full enforcement for whatever p= states; and three new tags — np, psd and t — are available, of which np (policy for non-existent subdomains) and t (a transitional testing signal) are the two you will actually use on business tenants. Aggregate reporting is tidied up in RFC 9990, with DKIM detail now required rather than optional, which makes the reports you read for M365 tenants slightly richer.
What does not change is everything about how mail actually authenticates on the platform. Microsoft 365 still publishes its SPF include, still requires you to enable DKIM signing explicitly, and still evaluates inbound DMARC the same way. Crucially, the new standard does nothing to remove the need for aligned SPF or aligned DKIM — that requirement is the heart of DMARC, and it is untouched.
The alignment requirement has not moved
It is worth stating directly, because it is the most common misconception when a standard changes: DMARCbis does not make alignment optional, easier, or automatic. A message from an M365 tenant still passes DMARC only when it produces an aligned SPF result or an aligned DKIM result against the visible From domain. Every M365-specific pitfall that used to break alignment still breaks it — a marketing platform signing with its own domain instead of the client's, DKIM never enabled in the tenant, or an SPF record that quietly blew past the ten-lookup limit. The new RFCs give you cleaner reporting and a few new tags to reason with; they do not sign your mail for you.
Where M365 authentication results get complicated
The environments where M365 DMARC results surprise people are the ones with something sitting in the mail path. Three patterns cover most cases.
Connectors
Inbound and outbound connectors route mail between M365 and other systems — an on-prem Exchange server, a third-party filtering service, a line-of-business application. Mail arriving through a connector may carry authentication results that reflect the connector's IP rather than the original sender, and unless M365 is told how to interpret that traffic, legitimate mail can appear to fail. This is exactly the problem Enhanced Filtering for Connectors exists to solve, discussed below.
Gateways in front of M365
When a security gateway or appliance sits in front of the tenant, it can modify and re-originate messages so that the SPF and DKIM results M365 finally evaluates no longer align. This is one of the most common causes of "DMARC says fail but the mail is legitimate" on M365, and it has its own detailed walkthrough in why DMARC fails with a gateway in front of Microsoft 365. DMARCbis does nothing to change this behaviour; the gateway problem is a mail-flow problem, not a specification problem.
Forwarding
User-level forwarding and mailbox rules relay mail from M365, or into it from other systems, breaking SPF and sometimes DKIM in the process. On tenants where forwarding is common, forwarded legitimate mail will generate DMARC failures that you need to recognize as such before enforcing.
Enhanced Filtering for Connectors still matters
If a client routes mail through a gateway before it reaches M365, Enhanced Filtering for Connectors remains directly relevant under DMARCbis. It lets Microsoft 365 look past the immediate connecting IP — the gateway — to the true originating source, so that SPF and the filtering stack evaluate the real sender rather than the appliance in front of it. Without it, a gateway-fronted tenant can see widespread authentication failures for perfectly legitimate mail. Nothing in the new RFCs replaces or removes this need — if anything, the move toward enforcement makes getting it right more important, because the cost of a false failure rises once you are at reject. The configuration and rationale are covered in Enhanced Filtering for Connectors for MSPs.
Document ARC and gateway behaviour
For any M365 tenant with an intermediary in the mail path, document how that intermediary behaves and whether ARC is in play. Microsoft 365 both applies and evaluates the Authenticated Received Chain, which can preserve a legitimate authentication result across a hop that would otherwise break alignment — but only when the intermediary seals correctly and the result is trusted. The point for an MSP is not to assume ARC is silently saving you; it is to know, per tenant, what modifies mail, whether it seals with ARC, and how M365 treats the result. That documentation is what lets you interpret the reports and predict what will happen when you move to reject. The broader mechanics are in ARC explained.
Re-check the record against the new standard
DMARCbis is a good prompt to bring each M365 tenant's DMARC record up to current best practice. Three checks cover most tenants. Remove any pct tag, since it is now inert and its presence implies a partial rollout that no longer exists. Consider np=reject to cover non-existent subdomains, which on a typical M365 business tenant is a low-risk hardening step because those names carry no legitimate mail — the reasoning is in new DMARC tags explained. And where a tenant is genuinely mid-transition, use t=y as an honest testing signal for a defined window, rather than leaving a stalled rollout looking like a settled policy.
Validate before moving a tenant to reject
The discipline that mattered before DMARCbis matters just as much after it: validate the tenant's real mail before enforcing. That means confirming DKIM is enabled and aligned, that the SPF record covers every sender within the lookup budget, that connectors and gateways are handled with Enhanced Filtering where needed, and that the aggregate reports show a clean picture with failures confined to sources you do not recognize. When a specific message needs explaining — a real message that failed, or a delivered one the reports flagged — the email header analyzer shows the SPF, DKIM and alignment results for that exact message on the tenant. Only once that picture is clean should a tenant move through quarantine to reject, following the sequence in DMARC enforcement after RFC 9989.
The M365 DMARCbis checklist
For a practice updating its M365 tenants, the work packages into a short, repeatable checklist:
- Confirm DKIM is enabled and signing with the tenant's own domain, not just Microsoft's default, and that it aligns with the From domain.
- Verify the SPF record includes every legitimate sender and stays within the ten-lookup limit.
- Identify any connector, gateway or appliance in the mail path, and confirm Enhanced Filtering for Connectors is configured where a gateway fronts M365.
- Document ARC and gateway behaviour per tenant so that report anomalies are explainable rather than mysterious.
- Remove inert
pcttags and, where appropriate, addnp=rejectand a time-boxedt=y. - Read the RFC 9990 aggregate reports until legitimate mail authenticates cleanly and only unknown sources fail.
- Move the tenant through quarantine to reject only once that evidence is in hand.
None of these steps is new to DMARCbis; the new standard simply confirms that the M365-specific care they represent is still required. For practices running mixed estates, the Google Workspace equivalent is covered in the DMARCbis for Google Workspace clients sibling.
Related articles
- DMARC for MSPs — complete guide
- Enhanced Filtering for Connectors for MSPs
- Why DMARC fails with a gateway in front of Microsoft 365
- DMARCbis for Google Workspace clients
- DMARC enforcement after RFC 9989: p=reject still requires care
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