Is migrating to DMARCbis necessary? The no-stress checklist

_dmarc.example.com.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:reports@example.com"

What NOT to do

• No second DMARC record. As before, one _dmarc record per domain. A second one makes the policy ambiguous and may be ignored.
• No jump to p=reject in the name of "modernizing," while sources remain unaligned. DMARCbis doesn't change this golden rule: tightening on an incomplete inventory breaks legitimate mail. The sequence stays the one in how to get to p=reject.
• No rush to psd. That tag concerns public suffix domain operators (registries), not ordinary organizations.

In what order to migrate

The order depends on the starting point.

For a domain already at p=reject with clean alignment (the ideal case):

1. add np=reject;
2. remove pct;
3. check the reports. Done.

For a domain still at p=none or p=quarantine:

1. add np=reject right away (risk-free, independent of the rest);
2. continue the normal ramp toward p=reject (inventory → alignment → quarantine with t=y → reject);
3. remove pct along the way. The priority here isn't DMARCbis: it's reaching enforcement.

How to verify everything is fine

After each change, two simple checks:

1. Re-reading the record with an analyzer to confirm the syntax and the presence of the expected tags (np, absence of pct) — our free analyzer does it in seconds and attaches a grade.
2. Watching the aggregate reports for a few days. What should show up: legitimate sources still aligned, and spoofed non-existent subdomains now showing a reject disposition. Learning to read them: how to read aggregate reports.

A two-speed ecosystem, and that's fine

During the transition period, receivers won't all adopt DMARCbis at the same time. The same message can therefore be evaluated by an up-to-date server that honors an np=reject, and by another that doesn't know the tag yet and simply ignores it. Nothing to worry about: that's exactly the behavior backward compatibility was designed for. The practical consequence shows up in the aggregate reports — for the same spoofed traffic on a non-existent subdomain, some receivers will report a reject disposition while others still apply the historical policy. That heterogeneity is not a configuration bug, nor a sign the migration failed: it will fade on its own as implementations update. Above all, the record shouldn't be "fixed" to make it go away.

How long does it take?

For a well-run domain, the DMARCbis "migration" boils down to two DNS touch-ups — a few minutes, plus propagation time. For a domain still at p=none, the real work isn't DMARCbis but aligning the sources, which can take from a few days to a few months depending on the size of the sending estate (see how to get to p=reject).

Three concrete cases, before / after

Depending on the starting point, the "migration" takes a different shape. Here are three real records, before and after.

Case 1 — already protected domain. Before:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:reports@example.com

After:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:reports@example.com

pct=100 goes (useless), np=reject arrives. Two seconds of work.

Case 2 — monitoring domain. Before:

v=DMARC1; p=none; rua=mailto:reports@example.com

After (np goes in right away, the ramp toward reject continues):

v=DMARC1; p=none; np=reject; rua=mailto:reports@example.com

np=reject doesn't depend on p: even at p=none, non-existent subdomains can be locked down with no risk.

Case 3 — parked domain (no sending). Before: often nothing at all. After:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:reports@example.com

A domain that never sends should refuse everything. It's the strictest configuration, and the easiest to justify.

Three myths about migration

• "DMARCbis requires v=DMARC2." False. The identifier stays v=DMARC1. A tool recommending v=DMARC2 is a red flag.
• "An old record will be rejected." False. A 7489 record remains a valid DMARCbis record. Nothing "expires."
• "Everything has to migrate on the same day." False. There's no deadline. np can go in today, pct come out next month — or an already-healthy domain can stay untouched. DMARCbis imposes no schedule.

Frequently asked questions about migration

How many domains should be handled? Every domain owned, including those that never send — those are precisely the most spoofed. A multi-domain estate deserves a review; the principle (add np, remove pct) is the same everywhere.

Do I need to warn my host or email provider? No. The migration boils down to editing a TXT record in DNS. Where a provider manages the DMARC record, the request is simply to add np and remove pct.

What about a DMARC monitoring service? Most update to reflect DMARCbis (np appearing, pct disappearing from reports). The thing to confirm is that the tool interprets np; otherwise, switching tools or adding the tag by hand works — it stays valid regardless.

Do I need to redo my DKIM keys or SPF? No, DMARCbis touches neither SPF nor DKIM. Authentication that works today works after migration. Still, it's a good moment to confirm the DKIM keys are stored in the right place, not in a stray file.

Migrating a multi-domain estate

For an organization managing several domains — most do, if only counting brand domains and parked domains — migration is a review, not an emergency. The method:

1. Inventorying every domain, including ones no longer used but still owned. These are often the most exposed, because nobody watches them.
2. Sorting them into two groups: those that send mail (to handle carefully, alignment included) and those that don't (parked domains, to move straight to p=reject; sp=reject; np=reject).
3. Applying the same two touch-ups everywhere: add np, remove pct. For parked domains, it's a chance to publish a first strict record if there wasn't one.
4. Prioritizing by exposure: the consumer-facing brand domains come first, being the most likely to be spoofed, before internal or technical domains.

The benefit of handling them as a batch is consistency: an estate where every domain enforces the same strict policy leaves no weak link. And because np=reject is risk-free, it can roll out across a whole estate in one pass, without fear of breaking anything — none of these domains sends from a non-existent subdomain. Each domain's aggregate reports will then confirm that nothing legitimate was affected.

One organizational tip: assign an owner for the estate's DMARC posture. Domains drift — a new vendor here, a forgotten campaign subdomain there — and without someone watching, a once-clean estate slowly regresses. The migration to DMARCbis is a good moment to put that ownership in place, since every record is being touched anyway. Done once, with the responsibility documented, the next change — DMARCbis or otherwise — becomes routine rather than a project.

In short

There is no mandatory migration: DMARCbis is backward-compatible and an existing v=DMARC1 record stays valid. The only two worthwhile touch-ups are adding np=reject and removing pct. For a domain still at p=none, the real priority remains reaching p=reject by the usual method. And above all: no v=DMARC2 — it doesn't exist.

The move is routine housekeeping: a few minutes per domain, no downtime, no risk to legitimate mail. The only domains that need real project work are those still stuck at p=none, where aligning the senders — not adopting DMARCbis — is the actual task. Everything else is two small DNS edits, doable today and ticked off the list, safe in the knowledge that an out-of-date receiver will simply ignore what it doesn't yet understand.

Thomas handles the migration

Two lines of DNS, but no room for approximation. Thomas, the virtual CISO, reads the domain's real state, generates the exact DMARCbis record to publish (np, t, no pct), and checks on the reports that no legitimate source is affected. One approval, one copy-paste, done.

Free DMARC analysis or account signup. For the full context, everything is in this new standard explained simply.