/guides · /guides/email-broke-after-dns-change
Email stopped working after you changed nameservers
Changing nameservers moves the whole zone, not just the records you were thinking about. Every record you did not copy stops existing the moment the new servers start answering.
What actually happened
People move nameservers to change where a website points, which is a reasonable thing to want. But the nameservers do not serve the website record alone — they serve the whole zone. MX, TXT, SPF, DKIM, the lot. The new provider starts with an empty zone and fills in what it can guess, which is usually an A record and nothing else.
So the site comes up, looks right, and you move on. Mail breaks quietly in the background, because nothing on the website tells you that MX records no longer exist.
Which half is broken
Incoming and outgoing mail fail for different reasons, and the symptom tells you which one you have. Work out which before changing anything.
A DNS lookup answers the first two directly: it returns the MX records public resolvers are currently being given, each with its priority. An empty MX result on a domain that receives mail is the whole diagnosis.
Finding what you lost
The records are not gone, they are in the zone you left behind. Log in to the old provider — the registrar panel, or the previous DNS host — and its copy of your zone is almost certainly still there, untouched. That is your source of truth for what to recreate.
If the old zone has been deleted, your mail provider publishes the records it needs. Every hosted mail service documents its MX hostnames and priorities, and that documentation is authoritative in a way a half-remembered screenshot is not. Copy from the provider, not from memory.
Recreate MX first, because that restores delivery. Then the TXT records: SPF, the DKIM selector, and DMARC if you had one. Those three do not stop mail arriving, but without them your outgoing mail starts failing authentication at the receiving end, which is how a working mailbox ends up in everyone's spam folder.
How long before it works
The honest answer is the TTL. Our DNS lookup prints it beside the A and AAAA rows, which is where the underlying resolver hands it to us; MX, TXT and NS rows come back without one, so for those the number has to come from your own DNS panel, which shows the TTL you set.
There is a sharper point for the outage case. If the previous answer was that no MX record exists, that negative result was cached too, and negative caching is governed by the zone's SOA rather than by a record you can see. In practice it is shorter than most positive TTLs, but it is why mail can keep bouncing for a while after you have obviously fixed the records.
Nothing you do makes that faster. Resubmitting the records, deleting and re-adding them, or changing provider again only resets the clock. Caching is the mechanism, not a fault.
Doing it without the outage next time
The whole failure is avoidable with ten minutes of preparation. Before moving nameservers, export or screenshot the existing zone in full — every record, not the ones you think matter. Build the new zone completely at the new provider while the old one is still live and answering. Only then change the delegation.
Lower the TTLs a day ahead if you can, which makes the cutover quick and a rollback quicker. And if the change did not appear to do anything at all rather than breaking mail, the problem is a different one: see editing a zone nobody queries.