The new website went live on Thursday. So did the email outage

The site looks good. It went live on Thursday afternoon, everyone was pleased with it, and the developer has done exactly what was asked.

By Friday lunchtime nobody can send an email.

That is the fast version of this, and it is the lucky one. The slow version is that email carries on working, apparently fine, and three weeks later customers start mentioning that they never received your quote.

One domain, two things that know nothing about each other

Your website and your email are unrelated systems. What they share is the domain name, and specifically the short list of records that sits behind it: where to send someone who types your address into a browser, where to deliver mail addressed to you, which servers are permitted to send mail in your name, and where a handful of other services live.

The website is one or two lines of that list. Everything else on it belongs to something that is not the website.

Nobody in this story is careless. The developer was told to point the domain at the new site and pointed the domain at the new site. The IT provider, who looks after the mailboxes, was never told there was a launch date. Both of them did their job properly and the business lost its email anyway.

Moving the nameservers is not the same as changing a record

There are two ways to send a domain to a new website, and they are not the same size of change.

The small one is a single record. The address for the website is updated to the new host and nothing else in the list is touched. Mail delivery, mail authentication and every other service carry on without noticing.

The large one is moving the nameservers, which hands the whole list to a new provider. From that moment, the only records that exist are the ones somebody recreated there. Anything not copied across is simply gone, and nothing warns you, because from the new provider's point of view those records were never there.

The second is the one that takes the email down. It is also the one chosen more often, because it is the easier instruction to give and the quicker thing for a developer to be handed.

There is a worse variant. Some hosting platforms generate a default set of records when a domain arrives, and that default can include a mail destination of their own. Mail then does not bounce. It goes somewhere, quietly, to a mailbox nobody has ever opened.

What else is on that list

In a ten-person firm using Microsoft 365 or Google Workspace, the records that matter and are not the website usually include:

• The mail delivery records, which decide where your email physically arrives
• The record saying which servers may send mail as your domain
• The signing records your mail provider created when the mailboxes were set up
• A policy record telling receiving servers what to do with mail that fails those checks
• The verification record your mail provider left behind to prove you own the domain
• Subdomains pointing at other things entirely: a booking system, a help desk, a tracking link, an old server somebody still uses

That last group is the one nobody remembers, because each was added once, years apart, by a different person solving a different problem.

The failure you notice, and the one you do not

Lose the delivery records and mail starts bouncing inside the hour. Everyone knows immediately, the day is ruined, and it is usually fixed before the end of it.

Lose the authentication records and nothing breaks at all. Mail still leaves your office. It arrives looking slightly less trustworthy than it did last week, and receiving servers make their own decisions about that, gradually and without telling anyone. It shows up as a customer saying they never got something, weeks after a website launch nobody connects it to. We have written separately about what the receiving server is actually asking, and the short version is that those records are the answer.

The loud failure is the cheap one. The expensive failure is the one where everything appears to work.

The order of the work

1. 01Export or screenshot the whole current list before anything changes
2. 02Shorten the record lifetimes a few days ahead, so a mistake takes minutes to undo rather than a day
3. 03Decide which of the two changes you are making, and give both suppliers the date
4. 04If the nameservers are moving, recreate every record, not just the website
5. 05Check mail and its authentication after the switch, not only that the site loads
6. 06Put the record lifetimes back

The checking step is where most of the value is, and it takes about ten minutes. Send a message to an external address you control and read the message headers for the authentication results. Send one from anything that emails on your behalf as well as from a person: the quoting system, the scanner, the website's own contact form. Then open whatever lives on a subdomain. A website that loads proves exactly one record is right.

Most website moves should not move the nameservers at all

This is the part developers tend to disagree with, so it is worth putting plainly.

Keep the list where your mail is managed, and point one record at the new site. The developer gets what they need, which is traffic arriving at their server, and the records that carry your email stay under the control of whoever understands them. There are genuine exceptions, mostly platforms that need to issue certificates or manage subdomains themselves, and a developer who says so can usually explain exactly why in a sentence.

What should not happen is the whole list moving by default because it was the simpler thing to ask for.

Underneath all of this sits a governance question most small firms have never answered: who is allowed to change these records, and who finds out when they do. It is the most damaging control in the business, it usually has three or four people holding keys to it, and there is rarely a written answer. Who holds the domain in the first place is the related question, and worth settling at the same time.

Why we see this one often

We design, build and host websites, and we also migrate firms onto Microsoft 365, including a full on-premise Exchange cutover planned and rehearsed out of hours. Sitting on both sides of that fence is the only reason this post exists. A web supplier is not being negligent when they do not ask about mail authentication, and an IT provider cannot warn you about a launch date nobody mentioned.

We are usually called on the Friday. If you have a launch booked and nobody has yet said which of the two changes it involves, that is a cheaper conversation to have on the Tuesday before.