Two SPF Records Will Quietly Break Your Email. Here Are the Other Four DNS Mistakes That Cause Most Tickets.

Here are the five mistakes behind nearly all of them, and the one that's the easiest to introduce by accident.

The one that breaks mail silently: more than one SPF record

A domain is allowed exactly one SPF record. Not one per service, one, period. If your email platform adds an SPF entry and your marketing tool adds another, you now have two TXT records both claiming to define your domain's SPF policy, and mail validation doesn't average them together or pick the "right" one. It just fails.

The fix isn't deleting one. It's merging every service's requirement into a single string:

v=spf1 include:_spf.google.com include:sendgrid.net -all

One record, every legitimate sender included, one -all at the end. This is the mistake most likely to happen without anyone noticing they caused it, because each individual change (add this one service) looks completely reasonable in isolation.

CNAME on the root domain, which DNS won't actually let you do properly

A root domain (example.com, not www.example.com) can't hold a CNAME record. It conflicts with the SOA and NS records that have to live at the apex. If you need the root to point somewhere the way a CNAME would, use an A record instead, or your provider's flattening feature: Cloudflare calls it CNAME flattening, Route 53 calls it an ALIAS record, other providers use ANAME. Same underlying idea everywhere: the provider resolves the target itself and serves an A record to the world, so the DNS spec's rule against a root CNAME never gets violated.

The Name field mistake that looks like a typo but isn't

Most DNS providers auto-append your domain to whatever you type in the Name or Host field. If the provider does this and you also type the full domain, you get www.example.com.example.com, a record that technically saved successfully and technically resolves to nowhere useful.

The rule: for a subdomain, enter only the label, www, not www.example.com. For the root, enter @. If you're not sure whether your provider auto-appends, create the record, then verify it with dig before assuming it's right. Don't trust the save confirmation, verify the actual result.

MX records pointing at the wrong kind of target

An MX record's value has to be a hostname with its own A record, a real, resolvable mail server. Pointing MX at an IP address directly, or at a CNAME target, both fail, even though the interface might let you type either one in. Mail routing depends on that hostname resolving through a proper A record, no shortcuts.

TTL, or why your fix from ten minutes ago hasn't taken effect yet

Every DNS record has a TTL, how long resolvers are allowed to cache it before checking again. If you're about to make a change you'll need to cut over quickly, lower the TTL first, something like 300 seconds, and wait for the old TTL to expire before making the real change. Otherwise you make the fix, it looks broken for an hour, and the natural response is to assume the fix itself was wrong when really it just hasn't propagated yet.

Verify with the actual tool, not the provider's dashboard

The dashboard shows you what you entered. It doesn't show you what the internet actually sees:

bash
dig +short A example.com
dig +short CNAME www.example.com
dig +short MX example.com
dig +short TXT example.com

If dig returns nothing, the record name is wrong or it never actually saved, regardless of what the dashboard implies. Check propagation across multiple resolvers with a tool like dnschecker.org before declaring anything fixed.

The provider-specific trap worth knowing before you touch Cloudflare

If you're on Cloudflare, the orange cloud (proxied) versus grey cloud (DNS only) toggle changes what the world actually sees when they resolve your record. Proxied means visitors see Cloudflare's IPs, not your real origin server. That's usually what you want for a website. It is almost never what you want for a domain-verification TXT record or an MX record, those need to resolve to the real value, not Cloudflare's proxy layer. Grey-cloud anything that isn't meant to be publicly proxied.

The pattern underneath all five

Every one of these mistakes has the same shape: the change saves without complaint, and the failure shows up somewhere else, later, disconnected enough from the original edit that it doesn't feel related. That's what makes DNS tickets frustrating to troubleshoot blind and fast to troubleshoot once you know the five specific places to look.

If you found this useful, hit the Subscribe button below to get more articles like this delivered straight to your inbox.

Want to see what our AI agents do with a DNS ticket like this? Start a free trial and throw your trickiest record configuration at them.

What's the DNS mistake that took you the longest to actually trace back to its cause? Tell me in the comments.