Most MX cutovers are planned as a routing exercise: change the records, wait for the TTL, watch mail flow, done. That plan fails more often than people admit, and the failure is quiet. Mail arrives at the new provider, users see no bounce, and yet DMARC starts flagging alignment failures within a day because SPF and DKIM were left pointing at the old infrastructure. Routing and authentication have to be decided as one change, not two.
The silent split between routing and authentication
MX records route inbound mail to a mail server. That is their entire job. SPF, DKIM and DMARC govern outbound mail only. A migration engineer who treats the DNS zone as a single „email” block will move the MX records and assume the rest follows, but nothing about an MX change touches the TXT records that tell receivers which hosts are allowed to send for the domain. The sending side keeps signing with a key the new provider does not know about, or keeps authorizing an IP range that no longer sends anything.
The result is a domain that receives mail perfectly and sends mail that fails alignment. Receivers see a message claiming to be from your domain, signed with a DKIM selector whose public key does not match, and sent from an IP outside the SPF record. Depending on the DMARC policy, that mail lands in spam, gets quarantined, or is rejected outright. The help desk ticket says „our email is broken,” but inbound is fine. Only the outbound path is broken, and only from the receiver’s perspective.
This split is easy to miss because the two systems use different tools. MX records are visible in a dig query and in every mail admin panel. DKIM selectors live under names like selector1._domainkey and are easy to forget when you are staring at a cutover checklist. A standard mail server will happily accept the new inbound stream while the domain’s authentication story quietly falls apart on the outbound side.
Why the failure stays hidden for days
DMARC aggregate reports arrive on a delay, typically 24 to 48 hours after the fact, and only if the domain publishes a rua address. Without reports, the failure surfaces as vague deliverability complaints weeks later. That lag is exactly why the migration runbook has to sequence DNS TXT changes with MX changes and verify with a DMARC report before anyone declares the cutover finished.
Sequencing the cutover so routing and signing move together
The safe order is to prepare the sending side first, cut inbound second, and keep the old path alive until reports confirm the new one. Start by generating DKIM keys at the new provider and publishing the public key as a TXT record under its selector. Do this days before the MX change, not minutes before. DNS propagation for TXT records is usually fast, but negative caching and third-party resolvers can stretch it.
Next, update SPF to include the new sending hosts while still including the old ones. Two authorized senders in one SPF record is a valid transitional state. Then move the MX records. this article provides further background on the subject. Once inbound mail flows through the new server and DKIM signing is confirmed on a test message, remove the old sender from SPF and retire the old DKIM selector after a grace period long enough for in-flight mail and any forwarding paths to clear.
A working catch-all setup requires DNS pointing at the right host and a server accepting unknown recipients, and the same discipline applies here: the DNS side and the server side must agree. If the new provider is meant to accept every message sent to a domain, confirm that before the MX change, not after. A standard mail server replies with 550 no such user when no mailbox matches, and a provider that has not enabled unknown recipient acceptance will do the same, turning a planned catch-all domain into a bounce generator the moment MX points at it.
Verifying with DMARC reports and checking the edge cases
Before the cutover, publish a DMARC record with a rua address you actually monitor and a policy of p=none. That gives you a baseline and a feedback channel. After the MX change, send test mail from every sending path: transactional systems, marketing platforms, the CRM, and any application that relays through the domain. Check the Authentication-Results headers on received messages for both spf=pass and dkim=pass with the correct domain alignment.
Watch the aggregate reports for a full week. What you are looking for is the disappearance of sources you retired and the appearance of the new provider’s IPs with passing alignment. If a legacy application still sends through the old host and you removed it from SPF, the reports will show it failing. That is the report doing its job. Fix the sender before tightening the policy to quarantine or reject.
Two edge cases deserve attention during verification. First, forwarding breaks SPF by design, which is why DKIM alignment matters so much on a migrated domain: a forwarded message can survive SPF failure if the DKIM signature and alignment hold. Second, catch-all and wildcard mailbox configurations interact with verification. A catch-all email accepts every message sent to a domain, including addresses invented by a spammer or generated during a sign-up flow. That is the feature and the risk in one line. During a migration, catch-all domains are used for unlimited unpredictable addresses in automation and sign-ups, so confirm the new provider’s catch-all behavior matches the old one before you retire the old MX.
Keep in mind that catch-all differs from alias, forwarding and disposable addresses. An alias maps a known address to a real mailbox. A catch-all is a fallback rule at the mail server for anything unmatched. If your migration runbook treats them as interchangeable, you will discover the difference when a 550 no such user appears where a message used to land. A catch-all email is configured on the mail server, not in DNS, so no MX or TXT change will create or fix one.
Treat the MX cutover and the SPF and DKIM changes as a single unit of work with a defined order: publish DKIM first, widen SPF, move MX, verify with a live DMARC report, then narrow SPF and retire old selectors. Keep the old sending path authorized until the reports show clean alignment from the new one. If you run a catch-all domain, test unknown recipient acceptance on the new host before you point MX at it. For a broader reference on how catch-all behavior fits into domain email routing, AllMail.one publishes a guide to catch-all email that pairs well with this cutover sequence.