A and AAAA
The addresses a name resolves to — IPv4 and IPv6. Without one of these, or a CNAME, nothing can reach the domain by name at all.
Most DNS lookup sites print a table and stop. This one reads the records and tells you what will break because of them — which is usually mail, and usually for a reason that looks fine in a table.
The addresses a name resolves to — IPv4 and IPv6. Without one of these, or a CNAME, nothing can reach the domain by name at all.
Where mail for the domain goes, in priority order (lower is tried first). No MX record means mail falls back to the A record or bounces, and neither is usually intended.
TXT records carry policy. The one beginning v=spf1 lists who may send mail as this domain — and is where most deliverability problems live.
Which certificate authorities may issue for the domain. With no CAA record, any of them may, which is one fewer obstacle between an attacker and a valid certificate.
More than one SPF record. RFC 7208 makes this a permanent error. Compliant receivers do not pick one — they fail the check outright, so a domain with two SPF records is worse off than one with none. It happens whenever a second mail provider is added and appends its own record instead of merging.
SPF past the ten-lookup limit. Each include:, a, mx or redirect= costs a DNS lookup, and the limit is ten. Chaining a few providers reaches it faster than anyone expects, and past it the record stops protecting anything — silently.
A CNAME beside other records. Invalid per RFC 1034, and resolvers disagree about what to return. The result is not a clean failure but an intermittent one, which is considerably harder to find.
A single nameserver. Most registries require two for a reason: with one, the domain disappears entirely while it is unreachable.
DMARC at the apex. DMARC belongs at _dmarc.example.com. A record published at the domain itself is simply ignored, so the policy everyone believes is in force is not.
Mail may be arriving via the A record, which is the fallback senders use when no MX exists. It works until it does not — the fallback is poorly supported, and any change to the web host silently breaks mail. If the domain receives mail, publish MX records. If it does not, a null MX record says so explicitly and makes senders reject immediately rather than retry for days.
Receivers that enforce RFC 7208 return a permanent error instead of a pass or fail, and most treat that as no SPF at all. So the record you think is protecting the domain is doing nothing, and the failure is invisible from the sending side — your mail still leaves, it just arrives with less trust or not at all.
Public resolvers — Cloudflare, Google and Quad9 — which is what the rest of the internet sees. That is usually what you want, but it means a change made in the last few minutes may still be cached. For whether a change has propagated, that distinction is the whole question, and a propagation checker is the right tool.
They are not required, and nothing breaks without them. What they do is restrict which certificate authorities may issue for your domain, so a mis-issued or fraudulently obtained certificate from some other authority is refused at issuance. For a domain that matters, it is a few minutes of work for a meaningful reduction in exposure.
Because those are different facts. A record type that genuinely does not exist and one we could not ask about look identical in a table, and acting on the wrong one wastes an afternoon. If a query errored, the tool says so rather than showing an empty row.
A record changed by someone who left, a registrar nobody has the login for, a zone signed but never delegated. We take over the operation of this properly — documented, monitored, and changed through a process rather than through whoever is awake.