I've seen the same DNS mistakes in hundreds of support tickets. Most break email delivery or cause downtime that could've been avoided with five minutes of double-checking. The records themselves aren't complicated—A, CNAME, MX, TXT—but the syntax rules are strict, and one typo or logical error will quietly fail.
Here are the nine setup mistakes I see most often, with the correct approach for each.
Mistake 1: Forgetting the trailing dot in CNAME and MX targets
When you set a CNAME or MX record target, many DNS systems require a trailing dot if you're specifying a fully qualified domain name. Without it, the system appends your zone name to the end.
Say your zone is example.com and you create an MX record pointing to mail.example.com (no dot). The server reads that as a relative name and turns it into mail.example.com.example.com. Email breaks.
The fix is simple: always end FQDN targets with a dot.
; Wrong
mail IN MX 10 mail.example.com
; Right
mail IN MX 10 mail.example.com.
Some DNS control panels (cPanel, Cloudflare) add the dot automatically or treat everything as absolute. Check your provider's docs—but when in doubt, add the dot yourself.
Mistake 2: Using a CNAME at the zone apex
You cannot point the bare domain (example.com) to another hostname with a CNAME. The DNS spec forbids it because a CNAME replaces all other records at that name, and every zone apex must have SOA and NS records.
I see this constantly when someone tries to point their root domain to a CDN hostname:
; This will break
example.com. IN CNAME cdn.provider.com.
Instead, use an A or AAAA record at the apex. If your CDN or hosting provider only gives you a hostname (not an IP), look for ALIAS or ANAME record support—these are proprietary extensions offered by Cloudflare, Route 53, and some other providers. They resolve the target hostname to an IP behind the scenes and serve the result as an A record.
Alternatively, redirect the apex with an HTTP 301 to the www subdomain and put the CNAME there.
Mistake 3: Conflicting CNAME with other record types
A CNAME cannot coexist with any other record type at the same name. If www.example.com has a CNAME, you can't also add an A, MX, or TXT record for www.example.com.
This breaks subtly. You add a CNAME for mail.example.com pointing to your email provider, then later try to add an MX or TXT (SPF) at mail.example.com. One of them won't resolve, or the server will reject the zone.
The correct approach: if you need multiple record types at a name, use A/AAAA records instead of a CNAME. Many SaaS platforms publish both options—prefer the A record when you need flexibility.
Mistake 4: Wrong MX priority and missing fallback
MX records take a priority number. Lower numbers are tried first. I've seen setups with a single MX at priority 10 and no backup, or two MX records both at priority 10, leaving the mail server selection to chance.
For a single mail server, priority 10 is fine:
example.com. IN MX 10 mail.example.com.
For redundancy, use distinct priorities:
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
Sending servers will try mail1 first, then fall back to mail2 if mail1 is down. Equal priorities mean round-robin, which can confuse mail queue logic.
Also, the MX target must be a hostname (A or AAAA record), never an IP address or CNAME. If your provider gives you a CNAME target for mail, create the MX pointing to that hostname, and let the CNAME resolve separately.
Mistake 5: SPF records with syntax errors or multiple records
SPF is a TXT record that lists which servers can send mail for your domain. Common mistakes:
- Publishing more than one SPF record for the same domain (the spec says exactly one).
- Forgetting the
v=spf1prefix. - Missing the final
~allor-allmechanism. - Too many DNS lookups (the 10-lookup limit).
A basic SPF record looks like this:
example.com. IN TXT "v=spf1 mx a:mail.example.com include:_spf.google.com ~all"
v=spf1declares the version.mxauthorizes your MX hosts.a:mail.example.comauthorizes the A record for that hostname.include:_spf.google.comdelegates to another SPF record (Google Workspace in this case).~allis a soft fail for everything else (-allis a hard fail).
Each include, a, mx, and redirect counts as a lookup. If you chain too many includes, you'll exceed the 10-lookup limit and SPF fails open. Flatten your record or use an SPF flattening service if you need many includes.
Never publish two SPF TXT records. Combine them into one. If you see two, delete one and merge the mechanisms.
Mistake 6: Setting TTL too high before a migration
TTL (time to live) controls how long resolvers cache your record. The default is often 3600 seconds (one hour) or 86400 (one day). That's fine for stable records, but if you're about to migrate a site or change an IP, a high TTL means visitors will see the old address for hours after you update DNS.
Lower the TTL to 300 (five minutes) at least 24 hours before the change. After the migration is stable, raise it back to 3600 or higher to reduce query load.
I've watched migrations fail because the old TTL was still in effect and half the internet was caching the old IP for another six hours.
So what about AAAA records—do you even need them?
IPv6 adoption is real. If your server has an IPv6 address, publish an AAAA record alongside the A record:
example.com. IN A 203.0.113.10
example.com. IN AAAA 2001:db8::1
Mistake 7: publishing an AAAA without confirming your web server and firewall actually accept IPv6 traffic. Clients will try the AAAA first and time out if the service isn't listening. Test with curl -6 or ping6 before you go live.
Some CDN providers (Cloudflare, Fastly) handle IPv6 automatically when you proxy through them. In that case, you don't manage the AAAA yourself.
Mistake 8: Wildcard DNS without understanding the scope
A wildcard record (*.example.com) matches any subdomain that doesn't have an explicit record. It's useful for catch-all subdomains but dangerous if you forget you set it.
Common issue: you create *.example.com pointing to a server, then later add a specific CNAME for blog.example.com. The CNAME takes precedence—fine. But anything-else.example.com still resolves to the wildcard, and if that server isn't configured for arbitrary subdomains, you'll serve the wrong vhost or a 404.
Use wildcards only when you control the web server and either configure a default vhost or explicitly want every possible subdomain to resolve. Otherwise, create records only for the subdomains you actually use.
Mistake 9: Forgetting to update NS records when changing DNS providers
Your domain registrar holds the authoritative nameserver (NS) records for your zone. Those NS records point to the DNS provider (Cloudflare, Route 53, your registrar's default, etc.). If you move DNS hosting but don't update the NS records at the registrar, your changes never propagate—the internet is still asking the old nameservers.
After moving DNS:
- Get the new nameserver hostnames from your new provider (usually two to four, like
ns1.newprovider.com). - Log into your domain registrar (Namecheap, GoDaddy, etc.).
- Update the NS records to the new hostnames.
- Wait for propagation (up to 48 hours, often much faster).
You can verify with dig or nslookup:
dig NS example.com +short
If the output still shows the old nameservers, your registrar update hasn't propagated yet. Until it does, all your new DNS records are invisible to the world.
Quick reference: record types and their rules
- A: maps a name to an IPv4 address. No trailing dot on the IP.
- AAAA: maps a name to an IPv6 address.
- CNAME: maps a name to another name (alias). Cannot coexist with other types at the same name. Cannot be used at the zone apex. Target should end with a dot.
- MX: specifies mail servers. Needs a priority number. Target must be a hostname (A/AAAA), not an IP or CNAME. End target with a dot.
- TXT: arbitrary text, often used for SPF, DKIM, domain verification. Quote the value. SPF must start with
v=spf1. Only one SPF record per name. - NS: delegates a zone or subdomain to nameservers. Usually managed at the registrar for the main zone.
- SRV: specifies service locations (less common). Requires priority, weight, port, and target.
FAQ
Can I use an IP address in an MX record?
No. MX targets must be hostnames with A or AAAA records. If you only have an IP, create an A record first, then point the MX to that hostname.
Why does my SPF record stop working after adding another include?
You've probably hit the 10-lookup limit. Each include, a, mx, and redirect counts as one lookup. Flatten your SPF or reduce the number of includes.
What happens if I set two MX records with the same priority?
Mail servers will pick one at random (round-robin). That's fine for load balancing identical servers, but if one is primary and one is backup, use different priorities.
How do I know if I need the trailing dot?
Check your DNS provider's docs. BIND zone files require it; many control panels add it automatically. When in doubt, add it yourself for CNAME and MX targets. It never hurts.
What to check first
When DNS breaks, start with the NS records at your registrar—confirm they point to the right provider. Then check for trailing dots in CNAMEs and MX records. Look for CNAME conflicts (especially at the apex or alongside other types). Verify your SPF record syntax and count the lookups. Those four areas cover 80% of the mistakes I see.
DNS is unforgiving but predictable. Once you've internalized the rules—no CNAME at the apex, trailing dots for FQDN targets, one SPF record, distinct MX priorities—you'll stop breaking things and spend less time in support queues.