What is DNSSEC?
Every email authentication check you publish — SPF, DKIM, DMARC, your MX records — lives in DNS. Receivers trust whatever answer DNS gives them. DNSSEC, the DNS Security Extensions, makes that answer provable: your DNS records are signed, and a resolver can check the signature all the way up to the root of DNS.
The problem it solves
Plain DNS has no way to tell a genuine answer from a forged one. An attacker who can get a fake answer accepted — by poisoning a resolver's cache, for example — can point your MX record at their server or replace your DKIM key with their own. Nothing in plain DNS would reveal it.
With DNSSEC, a validating resolver rejects an answer whose signature does not check out. A forged record is not just suspicious; it is refused.
How the chain works
- Your DNS host signs your zone with its own keys and publishes signatures next to your records.
- Your registrar publishes a DS record for your domain in the parent zone (for
example.com, in.com). The DS record is a fingerprint of your zone's key. - The parent zone is signed too, and so on up to the root, whose key resolvers already trust.
A validating resolver follows that chain. If every link holds, it marks the answer as authenticated. Both halves are needed: a signed zone with no DS record is ignored, and a DS record with a broken or missing signature makes your domain fail for validating resolvers.
Turning it on safely
- If your registrar is also your DNS host, DNSSEC is usually one switch in the control panel; they sign the zone and publish the DS record together.
- If they are different companies, turn on signing at the DNS host first, copy the DS record it gives you, and add it at the registrar.
- Before you move to a new DNS host, remove the DS record first (or set up the new host's keys in advance). A DS record that points at keys the new host does not have makes the domain unresolvable for validating resolvers — mail to you stops.
That last point is the real cost of DNSSEC: a mistake breaks resolution, where a missing SPF record only weakens it. Done carefully, it is a set-and-forget protection.
Who uses it
DNSSEC is required for some government and public-sector domains in several countries, and it is the foundation DANE is built on. Many registrars and DNS hosts now offer it for free.
What the Domain health card shows
| Result | What it means |
|---|---|
| not signed | No DS record for your domain. Optional: turned on at your registrar or DNS host. |
| signed | Signed, and the chain validates from the root. For a subdomain inside a signed parent zone the note says it is covered by the parent. |
| not validated | A DS record exists, but the answers were not marked as validated — typically a signing algorithm the resolvers do not support. Check the algorithm at your DNS host. |
| validation fails | A DS record exists and validating resolvers refuse your DNS answers. Either DNSSEC is broken or your nameservers are not answering. This is urgent: mail delivery to you is affected. |
| couldn't read | Our DNS lookup failed. This says nothing about your domain — press Re-check. |
We only show validation fails when the lookups of your SPF and DMARC records failed in the same check too. If those came back fine, the resolvers accepted your domain a moment earlier, so a single failed answer reads couldn't read instead.
The mail transport security rows — MTA-STS, TLS-RPT, DNSSEC and DANE — are part of the Starter, Scale and Enterprise plans; on the Free plan they are shown locked, marked Upgrade.