Website migrations have a well-earned reputation for creating problems that nobody anticipated. One of the most damaging problems is not a broken page or a missing image. It is email. A web developer launches a new site and within hours your helpdesk starts receiving calls from a panicked client whose entire team has stopped receiving messages. A common cause is a developer who did not understand DNS touching the live zone and overwriting records they should have left alone.
This failure is usually preventable. It happens because the web-development side and the network-management side of a client’s infrastructure operate in separate silos, with no defined protocol for how one team hands off work to the other. In that situation, the IT partner’s role is to close the gap before the developer gets near a live DNS zone.
How DNS Changes Break Email During Migrations
Most web developers understand how to point a domain at a new web server. They know that an A record maps a domain name to an IP address. What inexperienced developers often do not understand is that a DNS zone contains multiple record types simultaneously, and that changing one type without protecting the others can silence every service that depends on the records you accidentally removed.
The typical failure scenario works like this. A developer is launching a new website for your client. The site is built, tested, and ready to go live on a new hosting provider. The developer logs into the domain registrar or DNS management console, navigates to the DNS settings, and makes their changes. The careless move is using the new hosting provider’s “import zone file” or “use default DNS” feature, which replaces the entire existing DNS configuration with a fresh, generic zone file that only contains the records needed for the website. That generic zone file has no MX records because the hosting provider has no idea where your client’s email is hosted. MX records tell the internet where to deliver email for a domain. When the MX records disappear, incoming mail stops arriving. Depending on how the mail server handles delivery failures, messages may be bounced back to senders, silently discarded, or queued and delayed.
The developer considers the launch a success because the website works. Nobody checks email deliverability in the post-launch checklist. Your helpdesk fields the calls the next morning.
Your Pre-Migration Protocol
The pattern that tends to prevent this is a protocol that executes before any web agency is granted access to anything connected to the client’s domain. That protocol protects the client and protects the support queue.
It usually starts with a complete DNS zone audit. The authoritative DNS management console for the client’s domain should yield a full zone export, including A records, CNAME records, MX records, TXT records including SPF, DKIM selectors and their corresponding TXT values, DMARC policy records, and any SRV records used by business applications. This document is the baseline that makes everything work today. A copy outside the registrar account makes manual restoration possible if someone overwrites the zone.
Pay particular attention to the email authentication records. An SPF record specifies which mail servers are authorized to send email on behalf of the domain. A DKIM record provides the cryptographic key that email recipients use to verify that messages were not tampered with in transit. A DMARC record tells receiving mail servers what to do with messages that fail SPF or DKIM checks. If the web team overwrites the DNS zone and wipes these records, your client’s outgoing email starts failing spam checks at recipient mail servers. Messages from the client’s team begin landing in junk folders or getting rejected entirely. This is sometimes harder to detect than missing incoming mail because the sending side appears to work fine.
Lower the TTL on key DNS records several days before the scheduled migration window. TTL, or Time to Live, is the value that tells DNS servers around the world how long they should cache a particular record before checking for an update. Standard TTL values are often set at 3600 seconds (one hour) or higher. Lowering TTL values to 300 seconds (five minutes) before a migration can reduce how long stale records persist in caches. If something goes wrong, you may be able to correct it faster. After the migration is complete and stable, raise the TTL values back to their normal setting.
The domain registrar account needs to be locked down before the developer starts work. Two-factor authentication belongs on the registrar account, and the recovery email address needs to be one the organization controls, not the developer’s personal email. The web team typically needs only the access required for the specific DNS changes in scope. For a standard website migration, that usually means permission to modify the A record for the domain and potentially a CNAME record for the `www` subdomain. It does not require registrar-level control. When the registrar supports delegated DNS access, or when DNS is managed in a separate service, the safer pattern is a narrow account that leaves the rest of the zone locked.
Scoping the Developer’s Access Precisely
The conversation with the web agency before a migration should include an explicit technical handoff. The developer should be able to specify in writing exactly which DNS records need modification to complete the launch. For a standard website migration, that is usually the A record for the apex domain and the A record or CNAME for www, plus occasionally a CNAME for a subdomain used by the hosting platform’s CDN.
If a web developer says they need access to “all the DNS settings” or asks for registrar login credentials, that is a red flag. It usually means they plan to manage the entire zone from the hosting provider’s dashboard rather than make surgical changes to specific records. The safer pattern is for the IT owner to make the specific record changes directly, or to provide a restricted account that can modify only the explicitly approved records.
Document the agreed-upon changes in writing before the migration window opens. Confirm the new IP address for the A record, the specific records being changed, and the records that must not be touched under any circumstances. Both parties should sign off on this document. If something goes wrong after the migration, this document tells you immediately whether the developer followed the protocol or deviated from it.
Verifying Email Integrity After Launch
Teams that avoid silent email failures usually run a post-launch verification checklist within the first hour of any website migration. That checklist is separate from whatever testing the web developer does.
That check usually includes a test email to the client’s domain from an external account, an outgoing test from the client’s mail system to an external address, and an email-header review confirming SPF and DKIM authentication are passing. If the client has DMARC reporting configured, that review belongs on the checklist as well.
An MX lookup using a DNS query tool usually follows, along with the same comparison for SPF, DKIM, and DMARC. Those checks take only a few minutes and often catch problems before anyone on the client team notices them.
What a Good Web Partner Looks Like
Boston Web Group operates within a strict scope when executing website migrations. We identify the specific DNS records we need to modify to complete a launch, communicate that list to the IT partner before we begin, and make only those changes. We do not touch MX records, email authentication records, or any record outside the agreed-upon scope. We treat the DNS zone as a shared environment that belongs to the client and their IT infrastructure, not a configuration file we have permission to overwrite.
We work within this model because it produces better outcomes for the client and because it makes the MSP relationship work. When your client’s email keeps running through a website migration, your helpdesk stays quiet, the web launch is considered a success by everyone involved, and the client trusts both you and the web team more than they did before the project started.
That outcome is worth the preparation required to make it happen.
Related reading: What Actually Happens During a Website Migration, The Security Risk of Bundling Your Domain, Hosting, and Email, and How to Hand Off Your Website to a Professional Without Losing Control of Your Business.