DNS (Domain Name System) is the plumbing of the internet. When it works, you never think about it. When it breaks, your website disappears from the internet, your business email bounces, and you spend four hours frantically editing text records while your phone rings with panicked client calls.
In my third year running client websites, I was migrating an e-commerce client to a new hosting provider. I updated their root A record, but forgot that their Google Workspace email configuration relied on an existing MX routing setup linked to their old host’s nameservers.
By noon the next day, their customer support team had stopped receiving customer emails, their transactional order confirmations were bouncing, and it took twenty-four hours for the updated DNS records to propagate across global ISP resolvers.
DNS errors are painful because they don’t give you instant feedback. An invalid code syntax error fails immediately on your screen; a bad DNS record works fine on your local machine while quietly failing for 40% of your visitors worldwide due to cached resolver records.
Here are the three most catastrophic DNS mistakes small operators make, and the exact configuration standards to prevent them.
Mistake 1: The Apex CNAME Conflict (and CNAME Flattening)
Under the official DNS RFC specifications, a CNAME record cannot coexist with any other record type on the exact same domain name.
This creates a massive problem for the “root” or “apex” domain (example.com without www):
Your root domain must have NS (nameserver) records and SOA (start of authority) records. Therefore, legally according to DNS rules, you cannot place a standard CNAME on example.com.
When beginners try to point their root domain to modern serverless hosting (like Cloudflare Pages, Vercel, or Netlify) that provides a target URL like cname.vercel-dns.com, they frequently break their email delivery because the invalid CNAME wipes out their MX records.
The Solution: CNAME Flattening (or ALIAS / ANAME)
Modern DNS providers like Cloudflare, DNSimple, and Route 53 solve this using CNAME Flattening:
They allow you to enter a CNAME on the root apex, but their DNS nameservers automatically resolve the target hostname to raw IP addresses in the background and serve them as standard A records to requesting browsers.
If your DNS registrar does not support CNAME flattening (many legacy registrars do not), migrate your nameservers to Cloudflare (free). It enables clean apex routing without breaking email records.
Mistake 2: Breaking SPF and DKIM During Nameserver Changes
When you update your domain’s nameservers to point to a new host or CDN, your old DNS zone file is not automatically copied over.
If you don’t manually export and re-create your email authentication records, your domain’s email deliverability will instantly collapse:
- SPF (Sender Policy Framework): A
TXTrecord specifying which servers are authorized to send email on behalf of your domain. - DKIM (DomainKeys Identified Mail): Cryptographic public keys that prove your outgoing email was not intercepted or forged.
- DMARC: The policy instruction telling receiving mail servers (Gmail, Outlook) what to do if SPF or DKIM fails.
If these records are missing from your new DNS zone, Gmail and Yahoo will reject your outgoing customer emails or dump them directly into spam folders.
The Migration Checklist:
Before you click “Update Nameservers” at your registrar, open your existing DNS dashboard and copy these exact records into your new provider:
- All
MXrecords (e.g., pointing toaspmx.l.google.com). - The
TXTrecord starting withv=spf1 .... - The custom
CNAMEorTXTselectors used for DKIM (e.g.,google._domainkey). - The
_dmarcTXT record.
Mistake 3: The 86,400-Second TTL Trap
TTL (Time to Live) tells global DNS resolvers how long (in seconds) they are permitted to cache a DNS record before querying your nameservers again for updates.
The default TTL on many legacy registrars is 86,400 seconds (24 hours).
If you leave your TTL set to 24 hours, update your server IP address on Tuesday morning, and realize at noon that your new server has an unpatched configuration error, you cannot roll back quickly.
Even if you change the IP address back to your old server in your dashboard, millions of internet users around the world will continue routing to your broken server for the next twenty hours because their local ISP resolver cached the old record.
The Pre-Migration Protocol:
- 72 Hours Before Migration: Log into your DNS dashboard and drop the TTL on your
AandCNAMErecords to 300 seconds (5 minutes). - Wait 48 hours: This ensures that all old, long-cached records expire across global resolvers.
- Execute the Migration: Switch the IP or hostname. If an unexpected error occurs, you can revert the record and global traffic will redirect back to safety in under five minutes.
- Post-Migration Stability: Once the new server has run reliably for forty-eight hours with zero errors, raise the TTL back to 3600 (1 hour) or 14400 (4 hours) to reduce redundant DNS queries.
Respect your DNS plumbing, double-check your TXT records, and lower your TTLs before touching production servers.
Related Operational Guides
For deeper frameworks and complementary operational workflows, see: