Change email DNS safely: provider migrations, new senders and rollbacks

Email depends on more records than the MX. Inbound routing and outbound identity use separate mechanisms, so a change to one rarely fixes or breaks the other in the way you expect.

A sender inventory connects each legitimate mail stream to an owner, a platform and the identity it authenticates with. Without it, any change to SPF or DMARC is a guess, and an unfamiliar source in a DMARC report is something you can only panic about rather than resolve.

1. List every kind of mail sent as your domain: staff mailboxes, marketing, billing and invoices, support and helpdesk, application notifications, and device-generated mail such as scanners, printers and monitoring systems.
2. Give each stream a responsible owner, a named person or team, not "IT".
3. Send a sample from each path and record the visible From domain, the envelope (return-path) domain, the DKIM d= domain and the selector (s=).
4. Compare the list with your DMARC aggregate reports and investigate every source that doesn't match an entry. How to read DMARC reports explains the fields.

This is how you catch the billing tool nobody included in the original checklist: its sample message reveals an unaligned stream before stronger DMARC enforcement is published. An IP list alone is not an inventory. Shared platforms use large, changing IP ranges, so ownership has to be recorded by platform and identity, not by address.

Save the current records from the authoritative nameservers, not from your own resolver's cache and not from a screenshot of the DNS editor. Include TTLs, because they decide how long the old answer survives after you change it.

$ dig +short NS example.com
ns1.dnshost.example.net.
$ NS=ns1.dnshost.example.net
$ for name in example.com _dmarc.example.com _mta-sts.example.com _smtp._tls.example.com; do
    dig @$NS +noall +answer $name TXT
  done
$ dig @$NS +noall +answer example.com MX
$ dig @$NS +noall +answer google._domainkey.example.com TXT
$ dig @$NS +noall +answer s1._domainkey.news.example.com CNAME
$ curl -s https://mta-sts.example.com/.well-known/mta-sts.txt

• Every MX, SPF, DKIM, DMARC, MTA-STS and TLS-RPT record with its TTL, saved as text with a UTC timestamp.
• The MTA-STS policy file, if you publish one.
• Provider account state: which domains are verified, which DKIM keys are active, which API keys or SMTP credentials each application uses.
• Current health findings. If you are an agency taking over a domain, existing issues belong to the baseline, not to your first change.

The email health check gives you a quick snapshot of SPF, DKIM, DMARC and MX in one run that you can save alongside the raw dig output.

A DNS review establishes the intended behavior, the affected senders and the rollback path. A record can be syntactically valid and still authorize the wrong service or route mail to the wrong place. Write each change request as a short record:

• Intent in plain language: "Authorize ESP B to send for news.example.com and sign with selector s2", not "add TXT record".
• Exact before and after values for every record touched.
• Dependencies: which mail streams rely on the record, and which provider instructions the value comes from.
• Checks: SPF lookup count after the change, one SPF record per name, DKIM key length, DMARC syntax. Use the SPF checker and DMARC checker on the proposed values.
• Publisher and verifier: one person makes the change, a second confirms the public result.
• Rollback: the previous values and what else must still be running for them to work (next section).

Avoid bundling unrelated changes. Tightening DMARC from p=none to p=quarantine on the same day as an MX migration means that when something breaks, you can't tell which change did it.

A rollback plan includes the previous configuration and the services needed to make it work again. Restoring a DNS record cannot bring back a mailbox tenant that was disabled or a DKIM private key that was deleted.

1. Capture previous records, TTLs, the MTA-STS policy file and provider account state before the change (the baseline above).
2. List the old infrastructure that must stay operational during the transition: the old mail tenant, the old ESP account and its DKIM keys, the SMTP relay the application still uses.
3. Define the evidence that triggers a rollback, such as bounces with a specific code, dkim=fail on a named stream, or inbound mail not arriving at the new provider within an agreed window.
4. After rolling back, verify the restored path with fresh messages, exactly as you would verify the change itself.

Example: the old MX value is saved, but the old mail tenant was already disabled. Reverting DNS would point mail at a service that can no longer receive it. Keep the old service alive until the new one is proven.

Remember that caches outlive a rollback. Resolvers keep the new answer until its TTL expires, and senders that cached an MTA-STS policy keep applying it until its max_age runs out. Plan for a period where some senders see the old state and some see the new.

A resolver that has cached a record keeps using it until the TTL expires. Lowering the TTL only helps once the old, longer TTL has run out, so the reduction has to happen ahead of the change.

1. At least one full old TTL before the change (often a day or two before, since 3600 to 86400 seconds is common), lower the TTL on the records you will change to something like 300 seconds.
2. Make the change at a quiet time when the owner of each affected stream is available to test.
3. Query the authoritative nameserver first, then a few public resolvers, to confirm the new answer.
4. Verify with fresh messages (see below), then raise the TTL back once you're confident you won't roll back.

$ dig @ns1.dnshost.example.net +noall +answer s2._domainkey.news.example.com CNAME
s2._domainkey.news.example.com. 300 IN CNAME s2.domainkey.u7654321.esp-b.example.net.
$ dig @1.1.1.1 +noall +answer s2._domainkey.news.example.com CNAME
$ dig @8.8.8.8 +noall +answer s2._domainkey.news.example.com CNAME

Copying a platform's DNS instructions is only the first stage. A new sender needs identity verification and a real message test before it carries production volume.

1. Get the account-specific DKIM and return-path values. They are usually unique to your account, so don't copy them from another client's setup or a generic tutorial. Platform-specific steps are in the setup guides, for example Amazon SES and Postmark.
2. Add the platform to the sender inventory with an owner.
3. Publish the records, then verify the public answers with the DKIM checker and SPF checker.
4. Send a representative message through the exact production configuration (same API key, subaccount, sending domain and template type) and inspect the delivered headers.
5. If it sends marketing mail, check the one-click unsubscribe headers and endpoint; the bulk sender requirements guide covers what's required.
6. Confirm the application handles the platform's bounce and complaint events, so suppressions actually happen.

A common failure: the test mailbox sends correctly, but the production API key belongs to a different subaccount that doesn't have the authenticated domain. The platform's green "domain verified" badge doesn't prove every application stream uses that configuration. Test the route that will actually send.

A mailbox provider migration, such as moving to Microsoft 365 or Google Workspace, affects inbound routing and outbound identity through separate mechanisms. Treat MX, mailbox provisioning, SPF and DKIM as coordinated but distinct workstreams, and run old and new in parallel until the new path is proven.

• Keep the old server accepting mail after the MX change. Senders that cached the old MX, or that queued mail before the change, may still deliver there for days; RFC 5321 suggests senders keep retrying for at least 4 to 5 days.
• Changing MX does not move application SMTP settings or outbound DKIM signing. Inbound mail moves, but an application still submitting through the old provider will break the moment you remove its SPF include.
• With MTA-STS in enforce mode, a new MX host that isn't in the cached policy will be refused by senders that honor it. Update the policy well before the cutover, or move to mode: testing first. See MTA-STS and TLS-RPT.
• Compare inbound and outbound samples, queue results and DMARC reports from both providers before retiring the old one.

Retiring a vendor means confirming that no live stream still depends on its credentials or DNS records, then removing its authorization. Stale includes waste SPF lookups and keep authorizing a service you no longer control.

1. Check application settings, environment variables, scheduled jobs and recent DMARC reports for continued use of the vendor.
2. Ask the business owner about monthly, quarterly and seasonal sends. Zero traffic in a two-week window doesn't prove a monthly invoice run is gone.
3. Move or stop the remaining streams and verify the replacement with a delivered message.
4. Remove the SPF include, the DKIM selector record or CNAME, the return-path CNAME and any verification TXT.
5. Close or downgrade the vendor account and revoke its API keys, then record the retirement date in the inventory.

A marketing contract ends, but a monthly invoice job still uses the same platform. Traffic review and a question to finance catch the dependency before cleanup does. When you stop signing with a DKIM selector, leave its public key published for a few days so that messages already queued or delayed still verify, then remove it.

Saving a record is not verification. Confirm the public state and the behavior of a new message sent through the affected path.

1. Repeat the exact DNS or endpoint check that originally failed (or that the change affects), and save the result with its time.
2. Send a new representative message through the affected stream to an external mailbox and read the receiver's Authentication-Results. The header analyzer breaks it down.
3. Watch DMARC reports and bounce logs for that stream over the next few days before closing the change.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@news.example.com header.s=s2 header.b=Zx81Qp0a;
       spf=pass smtp.mailfrom=bounces@em7654.news.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=news.example.com

Example: the new DKIM key resolves, but the application still signs with the previous selector. Only a fresh message reveals that the fix was half applied. Rechecking an old message doesn't test the new configuration either, because its signature was made before the change. Keep the original failing evidence separately so you can show before and after.

A sender that runs once a quarter or once a year can drift unnoticed between campaigns. Its DKIM selector may have been removed in a cleanup, its credentials may have expired, or its template may have lost the unsubscribe headers. A previous year's successful campaign is not current verification.

• Confirm the platform account, authenticated domain and intended recipient list are still current.
• Send a representative message through the production path a week or more before launch and inspect authentication and unsubscribe handling.
• Review the planned sending volume and pattern; a sudden spike from a cold sender can trigger deferrals such as Gmail 421 4.7.28.
• Name who watches delivery during the campaign.

A yearly event tool that still references a selector deleted months earlier fails DKIM silently. A preflight message catches it before the event announcement goes out to everyone.

A weekly review should focus on what changed and what is still unresolved, not on re-reading green checks. Compare the latest records and findings with the last approved baseline, review new sources and alignment changes by stream in DMARC reports, and give each meaningful difference an owner and a next step. A new DKIM selector that appears after an approved provider rotation gets linked to its change record rather than escalated as an unknown sender. The review supplements alerts; it is not a reason to wait a week on an active delivery failure.

When an alert fires, verify scope and impact before touching DNS. Unrelated edits made in a hurry erase evidence and add a second problem.

1. Record the domain, the finding, the previous value and the first time it was observed.
2. Repeat the lookup or message test yourself, and check the change log for an approved change.
3. Assign the likely owner and decide whether this is active delivery impact (bounces, failing DMARC on a live stream) or a configuration improvement that can be scheduled.

Example: a DKIM record disappears during a provider migration. Triage confirms whether it was retired on purpose before anyone restores a value that may be obsolete. If a check recovers on its own, keep the evidence anyway; transient resolver problems and partial outages are real and tend to recur. HealthCheck Email's monitoring keeps a history of record changes and DMARC report sources, which is the comparison a weekly review needs.

An evidence pack lets a mailbox provider or ESP investigate without a long series of vague back-and-forth requests. "Email is broken" becomes a precise case: one stream, one receiver, three message IDs, the same rejection over a defined interval.

• Sending service, affected domain and stream, and the receiving domain.
• UTC timestamps for the first and latest failures.
• Message-IDs or queue IDs for a few affected messages.
• Exact SMTP replies, copied in full, for example 550 5.7.26 from Gmail or 550 5.7.515 from Outlook.com. Run them through the bounce analyzer and link the matching fix page, such as Gmail 550 5.7.26 or Outlook 550 5.7.515.
• Relevant Authentication-Results from a trusted receiver and the current DNS answers with query times.
• What you expected, what happened, how many messages or recipients are affected, and every change made near the start of the incident.

Share it only through the provider's authorized support channel. Redact message bodies, tokens, unsubscribe links and unrelated recipient addresses: more raw data is not better evidence.

When you manage email DNS for clients, establish the division of responsibility before the first alert. An agency can detect a broken record but often can't edit the client's registrar or DNS host. Naming the DNS owner prevents an alert from stalling in the agency inbox.

1. Confirm the domains in scope, including sending subdomains.
2. Get the client's sender inventory and the name of whoever can publish DNS.
3. Run baseline checks and record existing findings before you change anything, so pre-existing issues aren't attributed to your work.
4. Choose alert recipients and a response workflow, then walk through one sample incident together.

Handing monitoring to another team should transfer decisions and ownership, not just dashboard access. Document the domains, sender owners, DNS authority, alert routes and open findings; review a past incident together; then send an approved test alert to confirm it reaches the new team. A webhook left pointing at a retired chat channel means monitoring keeps running while nobody sees its alerts. Remove the old team's access through your normal account process, and never put passwords or DKIM private keys in a handoff document.