DNS Explained: Why Changing It Breaks Email
By CodexierPublished 5 min read
A common Monday morning: the new website went live over the weekend, and now no email is arriving. The website move changed the domain's DNS, and the records that told the world where to deliver your email were lost on the way. DNS is not complicated once you see what each record does. This guide explains the records a small business uses, why website and email are linked through them, and a routine for making changes without surprises.
What DNS does
Three roles are involved, and they are often at different companies. The registrar is where you rent the domain, for example a .se domain through a registrar accredited by Internetstiftelsen. The DNS host holds the zone, the list of records, and is named by the domain's nameservers. The services, your web host, Microsoft 365 or Google Workspace for email, are what the records point to. When a web agency says move your nameservers to us, they are asking to become your DNS host, and from that moment their zone decides where your email goes too.
Records for the website
| Record | What it does | Typical use |
|---|---|---|
| A | Points a name to an IPv4 address | The bare domain, example.se, to the web server |
| AAAA | Points a name to an IPv6 address | Same, for IPv6 |
| CNAME | Points a name to another name | www.example.se to a hosting provider's address |
| NS | Says which DNS host is responsible | Set at the registrar; changing it moves the whole zone |
Moving a website usually means changing the A record and the www CNAME. Nothing else needs to change for the site to move.
MX records and email
MX records tell other mail servers where to deliver email for your domain. If you use Microsoft 365, they point to Microsoft; with Google Workspace, to Google. They have nothing to do with the website, which is why a website move should never touch them. The failure happens when nameservers are moved to a new host whose zone was created from scratch, with only the website records in it. From the moment the new nameservers take effect, the world asks the new zone where to deliver email, finds no MX record, and messages bounce or disappear.
TXT records for verification and security
TXT records hold text that other services read. They prove you own the domain to Google Search Console, Microsoft 365 and many other services, and they carry the email security settings that decide whether your messages land in the inbox or in spam. Losing them breaks verifications and hurts deliverability even if email keeps flowing. Our guide to SPF, DKIM and DMARC explains the email records in detail.
- SPF: a TXT record listing which servers may send email for your domain.
- DKIM: public keys, often as CNAME or TXT records, that let receivers verify your email signatures.
- DMARC: a TXT record at _dmarc telling receivers what to do with email that fails the checks.
- Verification strings: proof of ownership for Google, Microsoft, Meta, Apple and others.
Making changes safely
- Export or screenshot every record in the current zone, including TXT and CNAME records you do not recognise.
- Decide whether you are changing records or moving the zone. Prefer changing only the website records at your current DNS host.
- If the zone must move, recreate every record at the new host first and compare the two lists before switching nameservers.
- Lower the TTL on the records you will change a day in advance, so the change spreads quickly and can be reversed quickly.
- Make the change at a quiet time, then test the website, send and receive email externally, and check verifications.
- Raise the TTL again once everything works, and store the final record list in your documentation.
When you do not need help: if your agency only asks you to change an A record and a CNAME, the routine above is enough, and you can do it yourself at your registrar. When nameservers are moving, several services depend on the domain or nobody knows who holds the logins, it is worth having someone own it. DNS and domain control are part of our monthly maintenance package; see the pricing page or book a call.
Frequently asked questions
How long does a DNS change take to work?
Changes spread as cached records expire, according to their TTL. With a low TTL, most visitors see the change within minutes to an hour. Nameserver changes can take longer, up to a day or two in some networks.
Our email stopped after the website launch. What do we do first?
Look up your domain's MX records with a public DNS lookup tool. If they are missing or wrong, add the correct values from your email provider's admin centre at whichever DNS host the nameservers now point to. Then restore SPF, DKIM and DMARC.
Should our web agency control our DNS?
They may manage it, but the domain and the DNS account should be registered to your company with logins you hold. That way you can change agencies without asking permission, and nobody can lock you out of your own email.
Does a .se domain work differently from a .com?
The DNS records work the same way. The difference is at the registry level: .se is run by Internetstiftelsen and registered through accredited registrars, with rules on holder details. Keep the holder as your company, not an individual.
Check your DNS before your next change
Book a short call before a website move or email switch. We look at your current records and tell you exactly which ones will change and which must stay.
Book a free 15-minute call