DNS Record Lookup
Every record a domain publishes, with what they imply about its mail and certificates.
The records, and what they are actually for
| Type | Points at | Comes up when |
|---|---|---|
A | An IPv4 address | Always. This is the one that makes a domain load. |
AAAA | An IPv6 address | Increasingly. Mobile networks are frequently IPv6-only. |
CNAME | Another name | Pointing www at the apex, or a subdomain at a SaaS provider. |
MX | A mail server, with a priority | Mail is not arriving. Lower priority number wins. |
NS | The zone’s authoritative nameservers | You changed provider and want to know whose answer you are getting. |
TXT | Free-form text | SPF, DKIM, DMARC and every domain-verification token you have ever pasted. |
SOA | Zone metadata and timers | Debugging replication between nameservers. |
CAA | Permitted certificate authorities | Restricting who may issue certificates for you. |
“Propagation” is the wrong word
The single most useful thing to understand about DNS, because it turns an unpredictable wait into a number you control.
Nothing propagates. There is no push, no distribution, no wave of updates rolling across the internet. Your nameserver has the new value the instant you save it. What takes time is that every resolver in the world holds a cached copy of the old answer, and each will keep it until the TTL it was given expires.
So the delay is not mysterious — it is precisely the TTL that was published when each resolver last asked. If your record had a 3600-second TTL, some resolvers ask again in five minutes and others in an hour, which is why a change appears to reach people unevenly.
Which gives the procedure for any planned change:
- A day ahead, drop the TTL to 300 seconds. Wait for the old TTL to expire so everyone has picked up the short one.
- Make the change. It now takes five minutes rather than a day.
- Once it has settled, put the TTL back up.
The reason to raise it again is that a low TTL means more queries, more latency on a cache miss, and a harder outage if your nameservers become unreachable — nobody has a usable cached answer to fall back on.
The mail records, which is where most problems are
Three TXT records govern whether your mail is believed. They are frequently misconfigured and the failure is silent — mail is delivered to spam rather than bounced, so nobody tells you.
SPF
Lists which servers may send mail for your domain. The mistakes, in order of frequency:
- Two SPF records. RFC 7208 requires receivers to treat this as a permanent error, so the check fails entirely. Merge them into one.
- More than ten DNS lookups. Every
include:counts, and includes nest. A mail provider plus a marketing platform plus a helpdesk gets you there quickly, and exceeding it fails the check. - Ending in
~allor?all. Both mean “probably not us, but do as you like”. Only-allasks receivers to reject.
DKIM and DMARC
DKIM signs each message with a key whose public half lives in a TXT record at a selector name such as selector1._domainkey.example.com — you have to know the selector to look it up, which is why it is not in the default query above. DMARC lives at _dmarc.example.com and tells receivers what to do when SPF and DKIM disagree, plus where to send reports.
Look up _dmarc.yourdomain.com in the tool above. If nothing comes back, receivers have no instruction and will apply their own judgement to anything spoofing you.
The CNAME rule at the apex
A CNAME cannot coexist with any other record for the same name. The apex of a domain must have SOA and NS records, so the apex cannot have a CNAME — which is why example.com pointing at a SaaS provider is awkward while www.example.com is trivial.
The workarounds are provider-specific: ALIAS, ANAME or CNAME flattening, all of which resolve the target server-side and answer with an A record. They work, they are not standard, and they are worth knowing about before you spend an afternoon on it.
Related
Once the records point where you meant, check the certificate the host actually presents and what headers it returns. To find out which network owns an address a record points at, the ASN lookup answers that.
DNS questions
I changed a record and it still shows the old value. Why?
Caching, at several layers. Every record has a TTL saying how long resolvers may keep it, and until that expires you will keep seeing the old answer regardless of what the authoritative server now says. Your operating system and browser cache on top of that. The lookup here goes to a resolver rather than straight to the authoritative nameserver, so it sees cached values too. To check what is really published, query the domain's own nameserver directly: dig @ns1.example.com example.com A.
How long does DNS propagation take?
There is no propagation — that framing is the source of the confusion. Nothing is pushed anywhere. Resolvers simply hold their cached copy until its TTL expires and then ask again, so the delay you experience is exactly the TTL that was published when they last asked. Lower the TTL a day before a planned change and the switch takes minutes instead of hours; forget to, and a 24-hour TTL means a day of some visitors seeing the old value.
What is a CAA record and do I need one?
It lists which certificate authorities are allowed to issue certificates for your domain, and CAs are required to check it before issuing. Without one, any public CA in the world may issue for your domain — so an attacker who compromises a validation process at any one of a hundred CAs gets a valid certificate. With one, the attack surface is the CAs you named. It is one line and it is worth adding.
Why does my SPF record fail even though it looks right?
Three common causes. Two SPF records on the same domain is a permanent error under RFC 7208 and fails the whole check — publish exactly one. Exceeding ten DNS lookups (each include: counts, and includes nest) also fails; that limit is easier to hit than it sounds once you have a mail provider, a marketing tool and a helpdesk. And ending in ~all or ?all only advises receivers rather than instructing them, so mail from other hosts is often delivered anyway.
What is the difference between an A record and a CNAME?
An A record points a name directly at an IPv4 address. A CNAME points a name at another name, which then has to be resolved in turn. The rule that catches people is that a CNAME cannot coexist with any other record for the same name — which means the apex of a domain, which must have SOA and NS records, cannot have a CNAME. Providers work around this with ALIAS or ANAME records that behave like a CNAME at the apex but resolve server-side.
Which resolver does this use?
Our server's own, deliberately. Querying a fixed public resolver such as 8.8.8.8 would report what Google sees rather than what an ordinary client sees, and the two differ more often than you would like — geographically split answers, split-horizon DNS and resolver-level filtering all produce that gap.
DNS is also the part of your own browsing that is most often unencrypted. Which resolver answers your queries determines who can see every domain you visit, whatever else is encrypted. Test which resolver you are really using
Last reviewed . Found something out of date? Tell us.