DNS & Email Safety During a Website Migration
Change website hosting without accidentally disrupting business email, verification records or other DNS-dependent services.
Record the current DNS zone
Before changing nameservers or DNS providers, export or screenshot the existing records. Identify MX, SPF, DKIM, DMARC, verification records, subdomains and third-party services.
Change only what the website needs
Moving a website often requires updating an A, AAAA or CNAME record. It does not automatically require changing mail records or nameservers. Smaller changes reduce collateral risk.
Lower TTL in advance where appropriate
For planned cutovers, lowering TTL ahead of time can shorten cache persistence. Do this before launch rather than at the moment of migration, and restore sensible values later.
Test email independently
Send and receive test messages after DNS changes. Website success does not prove mail flow is healthy.
Document ownership
Record registrar access, DNS provider, hosting provider and who controls each account. Migration projects often expose long-standing ownership confusion that should be fixed while attention is focused on infrastructure.
A practical DNS change record
Before the cutover, write down the current website IP, target IP, authoritative nameservers, current TTL values and the exact records you intend to change. Add the expected result beside each change. This turns DNS work into a controlled checklist instead of an improvised sequence of clicks. It also makes it easier to compare what the provider shows with what public DNS resolvers return after the change.
What to test after the switch
Test the root domain, www host, any booking or application subdomains, inbound and outbound email, password-reset email if applicable, SPF/DKIM/DMARC alignment, and third-party verification records. If the business uses Microsoft 365, Google Workspace, payment gateways or CRM tools, confirm those DNS-dependent services separately rather than assuming they survived because the homepage loads.