A DNS change stopped your email: what broke, and how to get it back

This one arrives every few weeks and it always sounds the same. The website moved to a new host on Tuesday, the site looks fine, and on Wednesday afternoon somebody notices that no email has come in since the move. Usually it is a customer who phones to ask why nobody replied.

It is recoverable, almost always completely. It helps to understand what happened first, because the instinct in the first ten minutes is to start changing records, and that is what turns a two hour problem into a two day one.

Your domain is a signpost, not a building

A domain name does not hold anything. It is a set of records that tell the rest of the internet where the things with your name on them actually live. The A record points at the machine serving your website. The MX records point at the machine that accepts your mail. The two are almost always different companies, and they have nothing to do with each other except that they share a name.

When somebody moves a site to a new host, the new host usually offers to “take over DNS” and hands you a fresh, clean set of records for the domain. Clean means it contains the records the new host knows about, which are the website ones. Your mail records were never theirs to know, so they are not in the new set. Nothing was deleted maliciously. The signpost was replaced with a signpost that only has one direction painted on it.

Why your own inbox looks fine

Here is the part that causes most of the confusion. You open your mail app and it still shows all your old mail, and you can still send. That is because your mail app is logged in directly to your mail provider and does not consult DNS to do it. Your mailbox is fine. Everything inside it is fine.

What is broken is the delivery of new mail from outside. A sender’s mail server looks up your MX records, finds nothing or finds the wrong server, and either queues the message or bounces it. Most providers queue for somewhere between one and three days before giving up, which is genuinely good news: a lot of the mail that looks lost is sitting in a queue waiting for you to fix the record.

The three records that decide whether mail arrives at all

Even with MX restored, mail can still land in spam or be rejected outright, because three more records decide whether a receiving server believes a message claiming to be from you is really from you.

SPF is a single text record listing which servers are allowed to send mail using your domain. If it is missing, mail you send may be treated as suspicious. If there are two SPF records, which happens easily when two providers each add their own, the result is worse than having none: the standard says more than one is invalid, and receivers may fail the check outright.

DKIM is a cryptographic signature. Your mail provider signs outgoing messages, and the public key lives in DNS. Lose the key record and the signature no longer verifies, which quietly reduces how much of your mail reaches an inbox rather than a spam folder.

DMARC tells receivers what to do when SPF and DKIM fail. If your policy is set to reject, and a migration broke SPF, you have instructed the world to throw your own mail away. This is the combination behind most “we stopped getting replies and nobody bounced” reports.

The first ten minutes

Resist the urge to paste in records from memory or from an old screenshot. Do this instead.

1. Find out who is actually authoritative for the domain now. Whoever was handed control during the migration holds the live records. Changing records in the old panel does nothing at all, and people lose hours to this.
2. Get the correct records from your mail provider, not from anywhere else. Every provider publishes its exact MX, SPF and DKIM values in its own documentation. These values are provider-specific and sometimes account-specific.
3. Restore MX first. That reopens the door. Queued mail from the last day or two will begin arriving once it does.
4. Then SPF, exactly one record. Merge, do not duplicate. If two services need to send as you, both go in the single record.
5. Then DKIM, using the selector your provider gives you.
6. Leave DMARC until last, and if it was set to reject, consider moving it to none for a day while the rest settles, then put it back.

Why nothing seems to change for an hour

Every DNS record carries a TTL, a number of seconds that other servers are allowed to keep the old answer before asking again. If the broken record had a TTL of four hours, some senders will keep using the broken answer for up to four hours after you fix it. This is normal and it is not a sign that your fix failed.

The practical consequence: if you know in advance that a migration is coming, drop the TTL on your mail records to five minutes a day before it, then put it back afterwards. It costs nothing and turns a slow recovery into a fast one.

What to send the desk

If you would rather hand this over, the fastest possible email contains four things: the domain name, who is hosting DNS now, who your mail provider is, and roughly when the last email arrived. That is enough to check the live records, compare them against what your provider requires and tell you exactly which ones are wrong, usually before you have finished making coffee.

Please do not send mailbox passwords. Nothing in this list requires access to your mail. It requires access to DNS, and read-only checks need no access at all.

How to stop it happening again

Two habits prevent almost every repeat of this.

Before any migration, export the full current DNS zone and save it somewhere that is not the panel you are about to lose access to. A screenshot of every record is a poor substitute but far better than nothing. Recovery from a good export takes minutes.

After any migration, send one test email in from an outside address, and one out to an outside address, before you tell anyone the move is done. A site that loads is not evidence that mail works, and the gap between those two facts is where these outages live.