How to Read a WHOIS Record and Your DNS Settings

Every domain has two separate records, and confusing them is the root of a surprising number of outages. The registration record says who owns the domain, when it expires, and which nameservers it's delegated to — it lives at the registry. The DNS records say where traffic actually goes — they live on those nameservers. One is the deed to the house; the other is the address on the mailbox. They can disagree, and when they do, things break in ways that look inexplicable.

Both are public, and you can pull them together with our free WHOIS & DNS lookup. This guide is about what you're looking at once you have them.

Part one: the registration record

Modern lookups use RDAP, the structured successor to the old text-based WHOIS protocol. Registries and registrars now serve it as the authoritative source, so that's what our tool queries — but people still say "WHOIS", and the fields mean the same thing.

The dates

Three dates matter, and only one of them is famous:

Created — when the domain was first registered. Useful for judging a domain's age, which matters for trust signals and for spotting a domain registered last Tuesday that's pretending to be your bank.
Updated — the last time anything in the registration changed. This one is underrated: an unexpected "updated" date is a signal worth investigating, because it means someone touched the registration.
Expiry — when it lapses. (For the full picture of what happens after that date, see what happens when a domain expires — the domain doesn't become available immediately.)

EPP status codes: the locks on the door

This is the most useful and least understood part of a registration record. EPP status codes are flags set by the registry or your registrar, and they tell you what operations are currently allowed. You'll typically see several:

Status code	What it means
`clientTransferProhibited`	Your registrar blocks transfers to another registrar
`clientUpdateProhibited`	Registration details can't be modified
`clientDeleteProhibited`	The domain can't be deleted
`clientRenewProhibited`	The domain can't be renewed (rare, usually a billing issue)
`serverTransferProhibited`	The registry blocks transfers — often a dispute or legal hold
`ok` / `active`	No locks at all

The client* prefix means your registrar set it; server* means the registry did.

Here's the counterintuitive part: seeing several "prohibited" codes is good. They're protective locks against domain hijacking — someone who compromises your registrar account still can't transfer the domain out while clientTransferProhibited is set. A valuable domain showing only ok and no locks is less safe, not more. The one time they're a problem is when you're deliberately transferring a domain and forgot to unlock it first.

Two other statuses signal trouble rather than safety: pendingDelete and redemptionPeriod mean the domain has already lapsed and is on its way out — see grace and redemption periods for what's still recoverable.

Nameservers and DNSSEC

The registration also lists the nameservers the domain is delegated to, and whether DNSSEC is enabled. DNSSEC cryptographically signs DNS answers so a resolver can detect tampering — good to have on, but be careful: it's the one setting that can take a domain completely offline if you change providers without migrating the signing keys correctly.

Part two: the live DNS records

The registration says which nameservers are authoritative. The DNS records are what those nameservers actually answer. Here's what each type you'll see does:

Record	What it does	What to look for
A	Maps the domain to an IPv4 address	The address your site actually resolves to
AAAA	Same, for IPv6	Absent is fine; wrong is worse than absent
MX	Where email for the domain is delivered	Priority numbers — lower wins; missing MX means no inbound mail
NS	The authoritative nameservers, per DNS itself	Compare with the registry's list (see below)
TXT	Free-form text, used for verification and email auth	Your SPF and DMARC records live here
CNAME	An alias pointing at another hostname	Can't coexist with other records at the same name
CAA	Which certificate authorities may issue certs for you	Empty means any CA can issue
SOA	Administrative metadata for the zone	Mostly a health signal that the zone exists

Three of these deserve more than a table row.

TXT records are where your email authentication lives. SPF sits in a TXT record on the domain itself, DMARC on the _dmarc subdomain. If mail is landing in spam, this is where you look — and our SPF & DMARC checker reads them specifically, with a full walkthrough in how to check your SPF and DMARC records.

CAA records are the ones nobody sets. A CAA record restricts which certificate authorities are allowed to issue certificates for your domain. With no CAA record, any public CA will issue to whoever passes their validation — which is exactly the gap that makes unexpected certificates possible. Setting one is a five-minute job that meaningfully narrows your attack surface.

CNAMEs have a rule people trip over constantly: a hostname with a CNAME can't have any other records. That's why you can't put a CNAME on your root domain alongside its MX records — the standard forbids it. Providers work around this with "ALIAS" or "flattened CNAME" records, which is why your DNS host's UI may let you do something the protocol technically doesn't.

When the two records disagree

The single most useful diagnostic this lookup gives you: compare the registry's nameservers against the live NS records. They should match. When they don't, one of two things is true:

You recently changed nameservers and the change hasn't finished propagating. Resolvers cache the old delegation for as long as the TTL says, so a gap of hours is normal and resolves itself.
Something changed that you didn't authorize — which is the serious case, because whoever controls the nameservers controls where your traffic goes, regardless of who owns the domain.

That distinction — expected change versus unexpected change — is the whole game. A nameserver change you made is routine. The identical change made by someone else is a domain hijack, and it looks exactly the same in a one-off lookup.

A quick diagnostic checklist

Symptom	Look at
Site won't load at all	A/AAAA records, then NS vs registry nameservers
Email not arriving	MX records — priority and whether they exist
Your mail lands in spam	TXT records — SPF and DMARC
Certificate errors	The SSL checker, then CAA
Transfer is blocked	EPP status codes — `clientTransferProhibited`
Domain "disappeared"	Expiry date and `redemptionPeriod` status
Unexpected subdomains	The subdomain finder

A lookup is a snapshot

Everything above tells you what's true right now. That's enough to diagnose a problem you already know about, but the failures that actually hurt are the ones nobody was looking for: nameservers changed at 2am, a certificate issued by a CA you've never used, a registration that quietly slid into its grace period.

That's the case for watching rather than checking. DomainChest tracks registration and certificate expiry across your domains and notices when DNS and certificates change underneath you — then emails you, instead of waiting for you to run a lookup. There's more on the DNS change monitoring page.

Start with a WHOIS & DNS lookup on a domain you own. If anything in it surprises you, that's the point.