Switching email providers without breaking DMARC

example.com.  IN TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all"

Before cutover, still: the new provider's DKIM, enabled and proven

The second preparatory task matters at least as much: the new provider's DKIM signing must be enabled, published and verified before a single user moves. Concretely: on Google Workspace, publishing the google._domainkey selector as a TXT record and turning signing on in the console; on Microsoft 365, two CNAME records (selector1._domainkey and selector2._domainkey) pointing at Microsoft's infrastructure, then the explicit activation of signing for the domain — without that last step, messages leave signed by the technical onmicrosoft.com domain, with no alignment to the visible one.

Outside the two large suites the gesture is identical, but the console moves — and that is where migrations lose their days. On GoDaddy as on IONOS, the record goes into the registrar's DNS interface, which does not always offer a dedicated DMARC field and forces a raw TXT entry; on Infomaniak and on Zoho Mail, the DKIM selector is generated from the admin panel and then copied into the zone by hand, with the truncation risk that any long key carries. The difficulty is never conceptual: it lies in where the button hides.

Verification does not rest on the admin console's word, but on a real message: a test send to external mailboxes at several providers, then a reading of the Authentication-Results header — dkim=pass alone is not enough; the signature's d= must match the sending domain. That alignment, and it alone, is what DMARC counts.

Then comes the overlap period: two to four weeks during which both providers are fully authenticated and the migration advances in waves — a pilot department first, then teams in groups, applications last. Each wave that moves does so toward a destination whose SPF and DKIM are already green. That is the heart of the method: proof precedes movement.

During: RUA reports, read daily

Once the cutover is underway, the aggregate (RUA) reports change status: from a weekly dashboard, they become the daily steering instrument. Every morning of the migration window, a few simple questions find their answer in the previous day's data. Is the volume shifting from the old source to the new one at the pace of the waves? Which flows remain attached to the old infrastructure — and are they identified, scheduled, or forgotten? Is the new provider producing residual alignment failures, the telltale sign of a default domain or a misconfigured return path?

The reports also play their watchtower role: a completely unknown source appearing mid-migration is either a forgotten internal flow resurfacing, or an opportunistic impersonation attempt — fraudsters love periods of flux, when an "IT department" email announcing a mail-system change looks entirely plausible. In both cases, discovering it the next day beats discovering it a month later.

A spike of failures concentrated on one specific flow is a stop signal: the next wave waits until the cause is understood and fixed. That discipline is what separates a steered migration from a suffered one.

Stepping the policy down a notch: a trade-off, not a reflex

Should the DMARC policy be relaxed during the window? The honest answer: sometimes, and never by default. A domain at p=reject whose inventory leaves gray areas — poorly mapped applications, autonomous subsidiaries, dubious DNS history — can legitimately step down to p=quarantine for the duration of the move: a forgotten flow will land in spam, recoverable, instead of being destroyed.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:rua@example.com"

But this step-down is a documented trade-off, not a harmless technical tweak: it reopens a spoofing window for its entire duration. The decision deserves a written trace — reason, scope, planned return date — and the climb back to p=reject is an integral part of the migration plan, not a vague "later". Worth noting: DMARCbis, the current standard, removed the pct tag that once allowed gradual percentage-based enforcement; policy steps are now all-or-nothing, and test mode is expressed through the t=y flag. Stepping down a notch is therefore a whole choice, to be owned as such.

The useful benchmark: a domain with a complete inventory and a proven DKIM setup at the new provider migrates perfectly well at a constant p=reject. The step-down compensates for a visibility gap — it does not replace the preparation work.

After: purging the old provider

The migration doesn't end when the last user moves, but when the old provider has lost all power to send. This purge, too often neglected, has three parts. SPF first: the old provider's include is removed once thirty days of RUA reports show no legitimate emission from its infrastructure. DKIM next: the old provider's selectors are revoked from the DNS — signing keys left lying around amount to signing power handed to a party now out of contract, exactly the risk covered by a clean rotation of signing keys. Access last: service accounts, application passwords, outbound SMTP connectors, shared mailboxes and the temporary forwards created "for the transition" are closed one by one.

A poorly purged domain drags phantom authorizations around for years: an SPF include delegating emission to a forgotten infrastructure, a DKIM key still live at a provider left long ago. That is precisely the kind of liability that surfaces, on the buyer's side, in the email history of a purchased domain — better not to be the seller who left it behind.

The classic forgotten senders: printers, business applications, aliases

Three families of senders escape migration plans almost systematically, because no human ever sees them send. Copiers and scanners first: the "scan to email" function is configured with authenticated SMTP against the old server, with a password set five years ago by a contractor long gone. The day the old SMTP goes dark, scanning stops — and the link to the mail migration is not made immediately.

Business applications next: the ERP that sends invoices, the CRM that sends reminders, the monitoring stack that sends alerts, the backups that send their nightly summaries, the scheduled scripts written by a developer who has since left. Each one carries SMTP credentials from the old world. The typical symptom is delayed: everything works for three weeks, then the quarterly billing reminders fail en masse — because that particular flow only fires once a quarter.

Aliases and forwards last: a forward re-emits the message from the forwarding infrastructure, which breaks SPF downstream; only an intact DKIM signature keeps authentication alive at that point. A migration redraws those relay paths, and a historic alias can slip from a "DKIM survives" case into a "nothing passes anymore" case. The RUA reports of the overlap period are the only place where these quiet flows become visible.

The end-of-migration checklist

A migration is finished when every line of this list is an observed state — not an intention:

• the old provider's SPF include is removed, and the DNS lookup counter rechecked after removal;
• the old provider's DKIM selectors are revoked from the DNS, with the revocation date recorded;
• the service accounts, application passwords and SMTP connectors of the old infrastructure are closed;
• thirty days of RUA reports show no emission whatsoever from the old provider;
• the DMARC policy is back at its previous level if it had been stepped down, and the trade-off archived;
• the sender inventory is up to date, copiers, business applications and aliases included;
• the DNS documentation reflects the final state: a slimmed SPF, the active selectors, the DMARC record.

Seven lines, none of them heroic; their only difficulty is existing in writing and being checked on a fixed date rather than "someday".

In summary

An email migration breaks DMARC when it is played out of order: SPF replaced instead of extended, DKIM never proven, old provider cut too early or never purged. The safe sequence reverses the burden of proof: before cutover, an additive SPF lets both providers coexist and the new provider's DKIM is verified on real messages; during, the RUA reports are read daily and the policy only steps down a notch under a documented trade-off, with a return date; after, the old provider methodically loses all power to send — include removed, keys revoked, accounts closed. The copiers, the business applications and the forwarding aliases are the forgotten senders that decide, on their own, whether the migration ends well.

The right starting point depends on no cutover calendar: a free DMARC analysis of the domain shows, before any date is even picked, who really sends in its name and what the migration will have to preserve. And to steer the overlap window on each day's reports rather than blind, opening an account gives the migration the instrument it most often lacks: proof, day after day, that nothing broke.