A missing period. An extra space. A root domain where a subdomain belongs. DNS records tolerate zero ambiguity, and I've seen every variation of typo break production sites. Most DNS mistakes follow predictable patterns, and once you know what to look for the fix is fast.
1. Trailing dot omitted in CNAME and MX targets
CNAME and MX records point to hostnames, and most DNS managers expect fully qualified domain names with a trailing dot. Leave it off and the zone's origin gets appended.
Suppose your zone is example.com and you create:
www CNAME cdn.provider.net
Without the trailing dot, the resolver sees cdn.provider.net.example.com.—which doesn't exist. Email fails in the same way when MX records omit the dot.
The fix: append a period to the hostname in CNAME and MX target fields.
www CNAME cdn.provider.net.
mail MX 10 mail.example.com.
Some DNS UIs hide the trailing dot and add it automatically. Check your provider's documentation or test with dig to confirm the final record.
2. Multiple A records when you meant round-robin
Adding two A records for the same name is valid—it signals round-robin DNS, where the resolver returns both IPs in rotating order. But if you intended failover or thought the second record replaces the first, traffic splits unpredictably.
I've handled support tickets where a server was decommissioned yet still received half the requests because the old A record remained. Visitors saw 50 % timeouts.
The fix: decide whether you want load distribution or a single target. For round-robin keep both A records and ensure both IPs serve identical content. For failover, remove the old record and use a single A or implement health-checked DNS through your provider or Cloudflare.
@ A 203.0.113.10
@ A 203.0.113.20
If both IPs should serve traffic, that's correct. If only one should answer, delete the other line.
3. CNAME at the root domain
RFC 1034 forbids CNAME records at the zone apex (the bare domain, example.com). A CNAME makes the name an alias, but the apex must also carry SOA and NS records—two responsibilities that conflict.
Many DNS managers block this outright. Others accept it and you discover the problem when email or the site stops resolving intermittently.
The fix: use an A or AAAA record at the root, or enable ALIAS / ANAME flattening if your provider supports it. Cloudflare and some managed DNS services flatten CNAME-like behavior into A records automatically.
# Wrong
@ CNAME loadbalancer.provider.net.
# Correct
@ A 203.0.113.50
If the target IP changes frequently, ask your provider about ALIAS records or switch the apex to a static IP and proxy through a CDN.
4. SPF record as a TXT and an SPF type
Early SPF implementations defined a dedicated SPF resource record type (RR type 99). That type is now deprecated; the standard is to publish SPF policy in a TXT record only.
Duplicating the policy in both TXT and SPF types can confuse older resolvers and adds no benefit.
The fix: remove any SPF-type records and keep only the TXT version.
# Correct
@ TXT "v=spf1 mx include:_spf.google.com ~all"
One TXT record per domain, starting with v=spf1.
5. Multiple SPF records for the same name
RFC 7208 explicitly requires exactly one SPF record per name. If you publish two TXT records both starting with v=spf1, the result is undefined—some receivers merge them, others reject all mail.
This often happens when a second admin or SaaS onboarding flow adds an SPF record without checking for an existing one.
The fix: merge all SPF directives into a single TXT record. Use the include: mechanism to reference third-party senders.
# Wrong
@ TXT "v=spf1 mx -all"
@ TXT "v=spf1 include:mailgun.org -all"
# Correct
@ TXT "v=spf1 mx include:mailgun.org -all"
Keep the policy under ten DNS lookups (each include:, a, mx, or redirect= counts) to stay within the lookup limit.
6. DKIM selector name collision
DKIM public keys live in TXT records at a selector subdomain, like selector._domainkey.example.com. When you send through multiple services—Mailgun, Google Workspace, your own mail server—each needs a unique selector.
Using the same selector name twice overwrites the first key, breaking signatures for one service.
The fix: assign a different selector to each sender and add all the TXT records.
k1._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
google._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBgk..."
mailgun._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
Most ESPs auto-generate a selector (like k1, s1, default). Accept their defaults and you'll avoid collisions.
7. DMARC record in the wrong place
DMARC policies must be published at _dmarc.example.com, not at the root or a subdomain you happen to send from. I've seen records placed at @, mail._dmarc, or dmarc.example.com—none of those work.
The fix: create a TXT record specifically at the _dmarc subdomain.
_dmarc TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Start with p=none and aggregate reports (rua) so you can monitor before enforcing p=quarantine or p=reject.
So what if the syntax looks right but email still fails?
Check the record's actual resolution with dig or an online DNS checker. Your local editor might look perfect while the authoritative nameserver serves stale or malformed data.
dig +short MX example.com
dig +short TXT example.com
dig +short _dmarc.example.com TXT
If the output is empty or unexpected, the zone file has not propagated or the record was never committed. Confirm you clicked Save in your DNS manager and wait the TTL duration for caches to expire.
8. TTL set too high before a change
TTL (time to live) tells resolvers how long to cache a record. A TTL of 86400 seconds means a 24-hour wait before changes reach all users. During a migration or IP change, a day of stale records causes prolonged downtime.
The fix: lower the TTL to 300 or 600 seconds at least a day before the change, make the change, then raise the TTL back after everything stabilizes.
Step 1 (24 h before): set TTL to 300
Step 2 (change day): update the A or CNAME
Step 3 (6-12 h after): raise TTL to 3600 or 86400
Some managed DNS services enforce a minimum TTL. In that case, make the change and accept the propagation window.
9. CAA records blocking legitimate SSL issuance
CAA records whitelist which certificate authorities can issue certs for your domain. An empty CAA record set means any CA can issue. A misconfigured CAA silently blocks Let's Encrypt, Sectigo, or your chosen CA, and you discover it only when auto-renewal fails.
The fix: if you use CAA, list every CA you rely on. If you don't need CAA, delete the records entirely.
# Allow Let's Encrypt and Sectigo
@ CAA 0 issue "letsencrypt.org"
@ CAA 0 issue "sectigo.com"
@ CAA 0 issuewild "letsencrypt.org"
The issuewild tag permits wildcard certificates. If your cert provider is blocked, add an issue record for them or remove the CAA records altogether.
What to check first
When DNS breaks, start with dig or nslookup to see what the authoritative server actually returns. Compare that output to what you entered in the control panel. Whitespace, missing dots, and duplicate records account for most failures.
For email, verify SPF, DKIM selector placement, DMARC location, and MX trailing dots. For SSL, check CAA records and confirm the domain resolves to the correct IP before requesting a certificate. Lower TTLs before changes and give caches time to expire after.
DNS tolerates no ambiguity. A single character wrong and the record is invisible. Fix syntax first, then wait for propagation, then test again.
Frequently asked questions
Can I use both A and CNAME records for the same subdomain?
No. A CNAME makes the name an alias, which conflicts with any other record type at that name. Choose one: A/AAAA for a direct IP, or CNAME to point elsewhere.
How long does DNS propagation take?
Up to the TTL value set on the old record. If the previous TTL was 86400 seconds, some resolvers may cache the old data for 24 hours. Lowering the TTL before a change shortens that window.
Do I need CAA records?
No, they're optional. CAA adds a layer of protection against mis-issuance, but if you don't configure it every CA remains allowed. If you do add CAA, make sure you whitelist the CA you actually use.
Why does my SPF record keep failing validation?
Either you have multiple TXT records starting with v=spf1, or your policy exceeds ten DNS lookups. Merge duplicate records and flatten include: chains where possible.
What's the difference between ALIAS and CNAME?
CNAME is a standard DNS record that creates an alias; you can't use it at the root domain. ALIAS (or ANAME) is a proprietary extension offered by some DNS providers that mimics CNAME behavior at the apex by resolving the target and returning A/AAAA records.
Check syntax, wait for TTL, test with dig
DNS mistakes are usually syntax errors—missing dots, duplicate records, wrong record placement. The protocol is unforgiving, but the fixes are mechanical. Check each record's format against the RFC or your DNS provider's examples, verify resolution with dig, and account for TTL when testing changes. Once the syntax is correct and propagation completes, the record works.
Keep TTLs low during migrations, merge SPF into one record, never CNAME the root, and place DMARC at _dmarc. Those four rules prevent the majority of issues I see in support.