Email DNS during a website move needs its own checklist because website hosting and email hosting are often separate services. A successful new homepage does not prove that incoming messages, outgoing authentication, or website-generated email still work.
MX records direct incoming mail, while SPF and DKIM support authentication of sending systems. Other records and service settings may also matter. The correct values come from the email providers you actually use, not from a generic set of defaults supplied by a new web host.
At getaboutcolumbia, this migration workflow helps preserve existing email services and test the messages customers and staff depend on.
Inventory receiving and sending separately
First decide whether the move changes only web records or transfers the entire DNS zone. The nameserver-versus-record distinction determines the scope of the risk. A record-only move can still affect mail indirectly if a mail hostname aliases the changing website address.
Export the current zone and record every email service: staff inboxes, transactional messages, newsletters, support software, and website form delivery. Identify each service owner and obtain current connection instructions from the provider’s own dashboard or documentation.
The Cloudflare email-record documentation explains the roles of receiving and authentication records and notes that exact values depend on the mail provider. Preserve MX priorities and targets, plus any address records needed by those targets. Do not point mail traffic at a web-only proxy.
For a hypothetical business, staff email may use one provider while order confirmations use another and newsletters use a third. Moving the web host does not automatically replace any of those services. A migration template that keeps only the staff MX records can still break the two sending systems.
Check aliases and old hosting dependencies carefully. If mail.example points to an address on the old shared hosting account, cancelling that account may terminate email even though MX records were copied correctly. DNS preservation and service continuity are related but distinct tasks.
Preserve authentication and verify real messages
The SPF specification in IETF RFC 7208 defines authorization for sending hosts and requires avoiding multiple competing SPF records for the same evaluated name. When adding a sender, update the intended policy according to the provider’s instructions instead of blindly adding another v=spf1 TXT record.
Keep unrelated TXT verification records intact. Several services may legitimately publish different TXT records at a domain. The issue is not the mere presence of multiple TXT records; it is whether the specific SPF policy becomes invalid or no longer authorizes the intended sender.
The DKIM specification in IETF RFC 6376 describes signatures and selectors used to locate public keys. Preserve the selectors required by active sending services. A new sender may use a new selector, so do not delete older keys merely because the newest setup instructions show only one.
Copy any existing DMARC policy and reporting destination as part of a full zone migration, and verify it against the organization’s email configuration. Avoid combining a hosting migration with an untested tightening of authentication policy. Keeping one change at a time makes failures easier to explain.
Prepare timing through the DNS TTL migration process and keep the former DNS zone consistent during the planned transition. When both old and new authorities can be consulted temporarily, they should not advertise different mail systems unintentionally.
After cutover, send a test message into an active mailbox from an independent service and reply from that mailbox. Then test each application sender separately: a password reset, order confirmation, contact form, or newsletter test. Use harmless test recipients and avoid triggering real customer workflows.
Inspect message headers or the provider’s delivery diagnostics for authentication results and the actual sending path. Arrival in one inbox is useful evidence, but it does not guarantee consistent delivery everywhere. Watch for bounces, delayed queues, and provider warnings after the move.
Website-generated email also depends on application settings and network access. Confirm that the new host can reach the configured sending service and that credentials remain valid. Include those checks in the questions agreed with a migration provider rather than assuming DNS is the only responsibility.
Keep the old email-related service active until the intended receiving and sending paths are verified. Record which account can safely be cancelled and which still supplies mailboxes, forwarding, SMTP, or DNS records. A combined invoice can hide those separate dependencies.
Mistakes to avoid
Do not replace every DNS record with the new web host’s suggested zone without comparing services. Automatic templates may be appropriate for a brand-new domain but incomplete for an established business.
Avoid deleting DKIM selectors or sender authorizations solely because they look old. Confirm that the associated service has stopped sending and follow its transition guidance before retiring the records.
Two final recommendations
Keep an email dependency inventory beside the website migration plan, with receiving and each sending platform listed separately. Assign a named owner to the post-migration tests.
Use a short acceptance checklist covering incoming mail, staff replies, transactional messages, and authentication diagnostics. Keep sanitized evidence so later delivery complaints can be compared with the cutover state.
Conclusion
Preserving email DNS during a website move means retaining the correct receiving routes and authentication records for every active mail service.
Inventory the zone and service dependencies, copy values carefully, avoid conflicting SPF policies, preserve DKIM selectors, and test real message paths.
Cancel old services only after confirming that they no longer support email. A website migration is complete when the communication workflows around the website continue to function.
