DNS Records Explained: How to Connect Your Domain Without Breaking Email

Changing your website host shouldn't silently kill your incoming client emails, but changing one wrong row in your DNS dashboard drops messages into a black hole every single day. The worst part is that everything looks fine on your screen: the shiny new homepage loads instantly, while prospective clients get bounce notifications you never see.

DNS (Domain Name System) has a reputation for being dark wizardry, but it is really just a public spreadsheet of instructions. Once you understand what each record type does, pointing your domain to Shopify, Squarespace, or a custom server takes five minutes—without risking your inbox or your security.

Your domain is just a signpost, not your hosting or inbox

When you buy a domain at a registrar like Namecheap, you own an address, not an actual website or email account. Think of your domain as a name in a directory, your web host as the office building where your files live, and your email provider as the post office box where your letters arrive.

DNS is the list of instructions that connects that name to those separate physical locations. Your website can live on one server, your email can live on Google Workspace or Microsoft 365, and your newsletter tool can run through a third service entirely. DNS simply tells the internet which server handles which specific job.

Because these services are separate, updating your website does not mean you have to touch your email settings. Trouble only starts when people delete records they do not recognize or hand over control of the whole directory by mistake.

The four DNS records that do almost all the work

You will encounter dozens of acronyms in a DNS control panel, but small businesses only ever need to manage four of them:

• A Record (Address): Points a domain name directly to a specific IPv4 address (a string of numbers like 192.0.2.1). This is what directs visitors to your primary website server.
• CNAME Record (Canonical Name): Acts as an alias that points one name to another name instead of an IP number. For example, you use a CNAME to point www.yourbusiness.com to yourbusiness.com or directly to a host like shops.myshopify.com.
• MX Record (Mail Exchange): Tells sending mail servers where to deliver email addressed to your @yourbusiness.com domain. MX records always point to a server name (like smtp.google.com), never a raw IP address, and they carry a priority number.
• TXT Record (Text): Holds arbitrary snippets of plain text. Today, these are primarily used for site verification tokens (proving you own the domain to Google Search Console) and anti-spam authentication when setting up domain email.

If you are only connecting a new website, you should only be touching A records or CNAME records. If you touch an MX record while launching a web page, you are asking for email downtime.

The biggest mistake is switching nameservers blindly

The most common way business email breaks during a website redesign is changing nameservers instead of adding individual records. When a web designer or platform says "point your nameservers to us," they are asking you to hand over the entire DNS control panel to their host.

When you change your nameservers at your registrar, the new host takes over answering all DNS queries. If that new host only knows about the website files and has blank settings for your MX and TXT records, every email sent to your company starts bouncing the moment the change propagates.

Keep your nameservers managed where you registered the domain (or at a dedicated DNS manager), and only update the specific A or CNAME records provided by your site builder. That keeps your email and security records intact and completely untouched.

The root domain cannot be a CNAME

A classic trap when connecting modern website platforms is the root domain rule (the naked domain without www, like example.com). Under core internet standards, the root domain can never be a CNAME record because a CNAME overrides all other records for that exact name—including MX records.

Most site builders solve this in one of two ways:

1. They provide one or two static A records (IP addresses) for the root domain @, and a CNAME pointing www to their platform.
2. Your DNS provider offers "CNAME Flattening" or an "ALIAS record" that mimics a CNAME at the root level behind the scenes.

If your platform gives you both an A record and a CNAME, put the A record on the root (@) and the CNAME on www. Then configure your website builder to redirect one version to the other so you do not split your search traffic.

Missing TXT records ruin your email deliverability

Even if your MX records stay safe, touching your DNS can accidentally wipe out the three TXT records that protect your email reputation: SPF, DKIM, and DMARC. These records prove to providers like Gmail and Yahoo that messages using your business domain are legitimate rather than forged spam.

When people clean up their DNS list and delete "random strings of text" they do not remember adding, their outbound invoices and proposals start landing straight in client spam folders. If you want to understand how those three work together, take a look at my breakdown of SPF, DKIM, and DMARC.

The rule of thumb is simple: if you see a TXT record that starts with v=spf1, v=DMARC1, or contains domainkey, leave it alone.

What to check if something goes wrong after an update

If you made a DNS change and your site does not load or email stops arriving, work through these diagnostic checks before panicking:

• Give propagation a short buffer: DNS changes do not happen instantly worldwide. While modern DNS often updates in 15 minutes, local internet providers and routers cache old entries for several hours (governed by the TTL or "Time to Live" value). Test your domain on an external lookup tool or mobile data before assuming it is broken.
• Check for conflicting A records: If you added a new A record for your new website but forgot to delete the old host's A record, DNS will alternate between them. Half your visitors will see the new site and half will see an error.
• Verify your SSL certificate status: Modern hosts auto-provision free SSL certificates as soon as your DNS points to them. If you see a privacy warning right after switching, give the host 30 minutes to verify the DNS and issue the certificate before touching settings again.
• Check your MX host values: If email stopped arriving, check whether your MX records are still present in your active DNS provider's dashboard and pointed to your mail host's correct addresses.

A five-minute safety routine before hitting save

To make sure you never lose mail or knock your site offline, follow this routine on every DNS edit:

1. Take a full screenshot or export a backup of your existing DNS table before modifying or deleting a single row.
2. Keep nameservers at your registrar unless you have a specific technical reason to move them, and edit individual A or CNAME rows instead.
3. Only touch the records your host specifically requested. Leave MX, TXT, and SRV records untouched.
4. Lower the TTL to 300 seconds (5 minutes) an hour before making big server migrations so changes take effect rapidly, then raise it back to standard (automatic or 1 hour) once verified.