Every visit to your website and every email to your domain begins the same way: something, somewhere, asks DNS where to go. The answer that comes back decides which server the browser connects to and which mail server the message is handed to.
By default, nothing about that answer proves it came from you.
DNSSEC is the mechanism that fixes it. Your DNS provider signs the records in your zone, your registrar publishes a small fingerprint — a DS record — in the zone above yours, and a resolver that checks signatures can then tell a genuine answer from a forged one. Two moving parts, in two different control panels, owned in many organisations by two different people.
That split is where it goes wrong.
Four states, and only one of them is fine
A domain is in exactly one of four states, and the difference between them is not a matter of degree. Two of the four are worse than never having started.
Not signed at all. No signing keys, no trust anchor. Nothing distinguishes a real answer for your domain from a forged one, so anyone able to inject DNS replies can send your visitors and your mail somewhere else — with no certificate warning, no browser interstitial, nothing that looks wrong to the person it happens to. This is the common case and it grades a C: a real gap, but an ordinary one.
Signed, but never anchored at the registrar. Your DNS provider publishes signing keys. Your registrar publishes no DS record pointing at them. Resolvers therefore treat the zone as unsigned and ignore every signature — so the protection you can see in your DNS dashboard does not exist anywhere outside it.
This is the state worth understanding, because it is the one that lies to you. Somebody turned DNSSEC on, saw the confirmation, and never completed the second step at the registrar. Everything internal says protected. Nothing external is. It grades a D, below doing nothing at all, precisely because it reads as done.
A broken chain. The registrar publishes a trust anchor, and the zone no longer serves the signing it points at. Now the failure inverts: resolvers that check signatures — including the largest public ones — refuse every answer for the domain as untrustworthy.
For those users your domain is simply down. No website, no mail, and no error message that names the cause; it looks like your site is broken rather than like your DNS is. It usually follows a DNS provider migration where the old DS record was left behind at the registrar, which means it typically arrives days after a change everyone considered finished. It grades an F, because it is not a risk of an outage. It is an outage, happening now, to some fraction of the internet.
Signed and anchored. Keys published, trust anchor published, signatures validating. An A.
Why counting records is not enough
There is a trap here worth naming, because it is the difference between a check that works and one that flatters you.
You can determine three of those four states by counting: how many signing keys does the zone publish, how many DS records does its parent publish. But a zone can publish both and still fail validation everywhere — the keys and the anchor disagree, or the signatures have lapsed. By counting alone that domain looks signed and anchored, and would be graded A.
There is a well-known domain that exists specifically to demonstrate this. It publishes keys, it publishes a DS record, and every validating resolver refuses to resolve it. A check that counted records would award it top marks while it was unreachable for a large share of the internet — the worst output such a check could produce.
So the counts are taken with validation deliberately switched off, to see the records as published, and a separate query asks resolvers that do validate whether they will accept the zone. Where the parent publishes a trust anchor, that second answer overrides the first. And it fails closed: if that query cannot be completed, the scan fails and refunds rather than reporting a pass it did not establish.
The other half: who is allowed to issue certificates for you
The same check reads one more record, and it answers a different question.
A CAA record lists the certificate authorities permitted to issue certificates for your domain. Publishing one narrows the field: an authority that honours CAA — and the public ones do — will refuse a request for your name if it is not on your list.
On its own that is a policy. What makes it interesting is comparing the policy against reality, using the public certificate transparency logs, which record essentially every publicly trusted certificate ever issued. The policy says who may. The logs say who did.
A certificate obtained in your name from an authority you never authorised is one of the earliest signals available that somebody is preparing to impersonate you — earlier than the phishing email, earlier than the look-alike domain going live. It is also the kind of thing nobody discovers by accident.
And if you have not named an address for authorities to report refused requests to, then when one is stopped on your behalf, nobody tells you it happened.
What to do about it
Three steps, in order, and the second is the one that gets skipped:
- Turn on DNSSEC at your DNS provider. For most providers this is a single switch.
- Publish the DS record it gives you at your registrar. This is the step that makes the first one count. Until it is done, the signing protects nothing — and your dashboard will not tell you.
- If you are migrating DNS providers, deal with the DS record before you move. Remove it, migrate, then publish the new one. A stale DS record left behind at the registrar is the single most common route into a broken chain, and the outage it causes is invisible from inside your own network.
Then publish a CAA record naming the authorities you actually use, with an iodef address so refusals reach somebody.
Where this sits
ClickScan's Domain and DNS Security Check answers all of this in one run. It reads public DNS and public certificate logs and connects to nothing of yours, so it needs no proof of ownership and can be pointed at any domain — including a supplier's, or an acquisition target's, before you inherit their DNS.
It judges the registrable domain rather than whatever hostname you typed, and the finding names the zone it looked at, so there is no ambiguity about what was graded.
The two failure states above are not rare and they are not visible from your own desk. If you have never checked which of the four your domain is in, that is the answer worth having today — see what ClickScan checks for the rest of what runs alongside it.