A DNS cutover that keeps mail and the website alive

When a website moves and the email stops, the story people tell is usually “DNS is flaky.” DNS is not flaky. It does exactly what the zone says. The zone just did not say what anyone remembered it said.

A DNS cutover that keeps mail and the site alive is a boring, written plan: know every record in the old zone, copy what must survive, lower the TTL ahead of time, change in a window, verify with a list, and keep the old zone for a week. Everything below is that plan, in the order we run it for Montreal companies.

Inventory before anything moves

The registrar, the DNS host, the website host, and the mail platform are often four different companies, set up by four different people across eight years. The first job is a single sheet that says who controls what.

We ask for or pull:

• Who the domain is registered with, and whose login owns it
• Where the nameservers point today
• A full export of the current zone, not just the records someone remembers
• Where mail lives (Microsoft 365, Google Workspace, an old host)
• Any third parties that send as you: invoicing, CRM, newsletters, support desk

If the registrar account is a former freelancer’s email, that is the first fix, before any record changes. We cover why in our notes on hardening: a domain with no recoverable owner is a business risk, not a technical footnote.

The records people lose

Websites need an A or CNAME record. Mail needs more, and the extras are where cutovers fail:

• MX records route incoming mail. Drop them and mail bounces or goes elsewhere.
• SPF (a TXT record) lists who may send as your domain. Merge, do not duplicate; two SPF records is a failure.
• DKIM records (usually CNAMEs or TXT) sign outgoing mail. Missing ones make messages look suspicious.
• DMARC (a TXT at `_dmarc`) tells receivers what to do with failures.
• Autodiscover or similar records that make Outlook find the mailbox without prompts.
• Verification TXT records for Microsoft 365, Google, Search Console, and ad platforms. Removing them can quietly break admin features months later.
• Subdomains for the portal, the staging site, and the thing someone set up in 2019.

The rule: copy everything first, then remove things deliberately and with a name beside each deletion. “Looks old” is not a reason.

Choose what actually changes

“Moving DNS” covers three different jobs, and they carry different risk:

1. Pointing one record at a new host. Lowest risk: change the A or CNAME for the website and leave the rest alone.
2. Moving the DNS host. Medium risk: the full zone is recreated elsewhere, then nameservers change at the registrar.
3. Transferring the domain registration. Separate task with its own lock and waiting period; do not combine it with the first two on the same day.

Many “migrations” only need option 1. We would rather change one record in a clean window than rebuild a zone for the sake of tidiness.

Lower the TTL days before

TTL tells resolvers how long they may cache a record. If it is 24 hours when you cut over, some visitors see the old site for up to a day. If you lower it to a few minutes two or three days earlier, the switch lands quickly and a rollback is quick too.

Sequence:

1. Note the current TTL for the records you will change
2. Lower them to something short, and wait out the old TTL
3. Perform the change in the window
4. Raise TTL back after the dust settles

It is an unglamorous step, and it is the difference between a calm evening and an uncomfortable one.

The window and the rollback

We schedule the change outside peak traffic, usually early evening Eastern time, by written agreement, with a named contact on your side who can answer a question in minutes. The plan states:

• The exact records to change, from and to
• How we will know it worked
• The point of no return, if there is one
• How to revert: normally, restore the old values, which is only fast because we lowered the TTL

Keep the old host live for at least a week. If the new site misbehaves on day three, the old one is still there to point back to.

Verify with a list, not a feeling

After the change, we do not announce success because the homepage loads. We run a short list:

• Website loads over HTTPS on the root and `www`, with the certificate valid
• Redirects behave (no loops, no dead old URLs)
• Send a test email in and out, to and from outside addresses
• Check headers on a received message for SPF, DKIM, and DMARC passes
• Confirm a calendar invite and a shared mailbox still work
• Check forms: a test submission arrives where it should, in your CRM if it feeds one
• Search Console and any analytics verification still hold

If one fails, we fix or roll back that item, not “keep an eye on it.”

Where Microsoft 365 fits

For companies on Microsoft 365, the mail side of the zone is not optional decoration. The required MX, autodiscover, and verification records come from the tenant, and they should be read from there at cutover rather than from memory. If you are also tightening identity or guest access around the same time, our overview of the Microsoft 365 and Azure workplace shows what usually travels together.

Who should own this

A DNS cutover is a good job for the person who already runs your day-to-day IT, because they know the odd sender and the odd subdomain. If that person is the founder in the evening, it is a good job to hand off. That is the kind of work we take on under hands-off IT in Montreal: a named operator, a written change, and a record of what the zone looked like before and after.

What we need from you

• Registrar and DNS host names, and someone who can approve access
• The list of services that send mail as your domain
• The date the new website or mail platform is ready
• A person reachable during the cutover window

We answer weekdays, 9 to 17 ET. Send the domain name and a short note on what is moving to hello@aervio.io or call +1 438-498-3913. We will read the existing zone and tell you what could break before anyone changes a record. If the question is bigger than one cutover, start from our IT services.

Questions

How long does a DNS cutover take?

The change itself is minutes. Propagation depends on the TTL you set beforehand, which is why we lower it a few days earlier. Plan for the window plus a verification pass, not for an instant switch.

Will we lose email during the change?

Not if the zone is copied correctly before nameservers or records move. Mail loss almost always traces to a missing MX, SPF, DKIM, or autodiscover record, which is exactly what the inventory step catches.

Can you do this outside business hours?

Yes, by written agreement. Our default coverage is Montreal weekdays, 9 to 17 ET. Evening cutovers are scheduled in advance with a named contact on your side and a stated rollback point.