DNSSEC in 2026: Only 6.28% of Domains Validly Signed
Published · updated
Figures as of 2026-07-29 · methodology v8. Aggregate census data; we never publish an individual domain’s status or grade. See how we grade.
Sixteen years after the DNS root was signed, roughly one domain in every sixteen has followed. DNSSEC is the extension that lets a domain cryptographically sign its DNS records, so resolvers can spot forged answers. This edition’s census covers 297 million domains. We could complete a DNSSEC evaluation on 275,666,275 of them; the rest were dead, unreachable, or otherwise beyond this check’s reach. Of the domains we could evaluate, just 17,317,905 publish a valid, verifiable DNSSEC chain — 6.28%. Another 258,108,354 (93.63%) are unsigned. No resolver on the planet can cryptographically verify a single answer those domains give.
The rest of the evaluated domains form the strangest group in the dataset: 240,016 domains that signed their zone and then broke it. For them, DNSSEC is not merely absent. For anyone behind a validating resolver — one that checks DNSSEC signatures — it risks taking the domain offline.
What does DNSSEC actually protect you from?
DNS was designed for a network that was assumed to be honest. When your mail server asks where to deliver an invoice, or a customer’s browser asks where your website lives, the answer arrives with no proof it is genuine. An attacker who can inject a forged response can silently redirect that traffic. Cache poisoning (planting a fake answer in a resolver’s memory) is one way in. An attacker sitting on the network path is another. Either way, the resolver cannot tell a real answer from a fake one.
DNSSEC is designed to close exactly that hole. Zone operators sign their DNS records with cryptographic keys. Validating resolvers then check each answer against a chain of trust that runs from the root, through the TLD (the domain’s ending, such as .com or .ie), down to the individual zone. A forged answer fails validation and gets thrown away. The protection runs as far as the validating resolver, though. Guarding against a compromised resolver, or the last mile between it and your device, takes local validation or encrypted DNS on top.
What DNSSEC does not do matters just as much. It does not encrypt your DNS traffic, and it is not a substitute for TLS. It authenticates the map, not the journey. But everything layered on top starts from a DNS lookup — including the certificate checks your customers’ browsers perform. Without DNSSEC, an attacker can rewrite that lookup.
Why did TLS 1.3 win while DNSSEC stalled?
The gap is not about merit. It is about who has to flip the switch.
| Standard | What it secures | Who has to act | Adoption this edition |
|---|---|---|---|
| TLS 1.3 | The connection to your site | Server software and CDN defaults | 94.8% |
| DMARC at enforcement | Who can send email as you | The domain owner, deliberately | 11.84% |
| DNSSEC, validly signed | The DNS answer itself | DNS host, registrar and TLD together | 6.28% |
Each figure is a share of the domains we could evaluate for that check this edition. For TLS 1.3, that is the ~210 million TLS-reachable domains; for DMARC and DNSSEC, the domains we could evaluate for each check. The bases differ — the contrast in scale is the point.
TLS 1.3 negotiates on 94.8% of the domains we probed for it, and almost nobody running those sites ever chose it. It shipped inside web-server upgrades and CDN rollouts. Operators inherited it by doing nothing.
DNSSEC works the other way round. Doing nothing leaves you unsigned. To sign, your DNS host must generate and rotate keys. Your registrar must accept and publish a DS record — the small fingerprint record, held at your registrar, that links your keys into the chain of trust. And your TLD must support the whole chain. That is three parties. A minority of DNS hosts, registrars and registries automate the DS handoff using CDS/CDNSKEY records; everywhere else, at least one step is manual copy-paste. And nowhere is signing the default.
The proof lives in the exceptions. A handful of ccTLD registries, mostly in northern and central Europe, made signing the default or paid registrars for every signed zone. It shows. National endings where the registry drove adoption validate at 35.8% this edition. Other ccTLDs sit at 4.7%. We measured whether mandatory DNSSEC works; the answer is in the multiples. Same protocol, same tooling, different default — wildly different outcome. That is the thesis this site is named for: adoption is a property of the registration pipeline, not of the standard.
Broken DNSSEC: the 240,016 domains SERVFAILing themselves
Being unsigned leaves you exposed. Being badly signed is another matter entirely. This edition found 240,016 domains whose DNSSEC chain fails validation. The usual causes in the wild are expired signatures, DS records at the registrar pointing to keys the DNS host no longer serves, and key rollovers started but never finished.
This is the one configuration worse than doing nothing. Validating resolvers treat a broken chain as a possible attack — exactly as designed. That includes the largest public resolvers: Google Public DNS, Cloudflare’s 1.1.1.1 and Quad9. They answer SERVFAIL, the DNS error that means “I could not get a trustworthy answer”. For users behind those resolvers, your domain does not degrade. It disappears.
Meanwhile, users behind non-validating resolvers see a perfectly healthy site. That produces the most maddening failure mode in operations: an outage that hits only some people, on some networks, some of the time. Most internal monitoring resolves DNS through a non-validating path, so your own health checks will miss it. The only way to see it is from outside your own network, through a validating resolver. That is exactly how the free defaults.exposed check looks at your domain.
The classic route in is the silent migration. A business moves DNS providers. The new provider does not sign. The old DS record sits at the registrar, vouching for keys that no longer exist. Nothing looks wrong in either dashboard. But to a validating resolver, the domain is now cryptographically proving that its own answers are forged.
Unsigned, your DNS can be attacked. Broken-signed, it attacks itself.
Should you enable DNSSEC on your domain?
If you are still asking what DNSSEC is, start with our plain-English explainer. What follows is the operational decision. Before you decide anything, find out which of the three groups you are in today: run the free check. A DS record left behind by a previous DNS provider can put you in the broken group without you ever choosing to sign.
The honest answer: it depends on who does the work — you or the machines.
Start by checking whether your TLD and registrar both support DNSSEC. If either does not, the decision has been made for you — note it for your next renewal review.
Sign if the machines do the work. Does your DNS host automate signing and key rollover? Does it, or your registrar, automate DS updates? (Look for CDS/CDNSKEY support — the records that let your DNS host push key updates to your registrar automatically, no copy-paste.) If yes to both, turn it on. The 240,016-domain graveyard above is the kind of failure manual key management produces. Automation makes it far less likely you join it.
Manual steps change the calculation entirely. If updating a DS record means copy-pasting hex strings between a DNS console and a registrar form, you are signing up for a recurring, unforgiving ritual. An expired signature breaks resolution just as surely as a hostile one.
Finally, plan your exits before you need them. Most breakage happens at transitions: a business moves DNS providers, the new provider does not sign, and the old DS record sits at the registrar vouching for keys that no longer exist. If you do sign, treat any future DNS-provider migration as a DNSSEC project first — remove the DS record, wait out the TTLs, migrate, re-sign, republish. In that order, every time.
What DNSSEC risk means for your business
DNS sits upstream of everything you run: website, email, APIs, SaaS logins. That gives DNSSEC an unusual risk profile in both directions.
The risk of staying unsigned is quiet and external. A successfully forged DNS answer can redirect customer traffic or intercept email without touching your infrastructure at all. You would be one of 258,108,354 domains in that position. Attackers are not short of targets, and domains where money moves by email make attractive ones.
Sign badly, though, and the exposure is loud and self-inflicted. Everything fails at once, but only for some users, only some of the time, while your own monitoring stays green. Google Public DNS, Cloudflare’s 1.1.1.1 and Quad9 all validate. For the share of your customers behind them, every page load, inbound email and API call fails for as long as the chain stays broken. Price one day of that against the revenue that moves through your domain. A broken DNSSEC chain is more than a security finding — it can amount to a rolling partial outage with your name on it.
DNSSEC is also, increasingly, a checklist item. Some government procurement frameworks, financial-sector supplier reviews and security-rating services can read it straight off your public zone, exactly the way our census does. It is posture, visible to anyone who looks. You can see the same view those reviewers get in under a minute: check your domain to see your DNSSEC status alongside the other 33 checks they can pull from your public footprint.
Quick answers
What percentage of domains use DNSSEC? As of 2026-07-29, 6.28% of the domains evaluated in the defaults.exposed census publish a valid DNSSEC chain — 17,317,905 in total. 93.63% remain unsigned. Live figure: what percent of domains use DNSSEC.
Why does broken DNSSEC cause SERVFAIL errors? Validating resolvers treat an invalid chain as a possible attack, so they refuse to serve the answer and return SERVFAIL. For users behind those resolvers the domain stops resolving entirely, while unsigned domains resolve normally. This census edition found 240,016 domains in that state; see why broken DNSSEC is worse than none.
Why is DNSSEC adoption so much lower than TLS 1.3? TLS 1.3 is on by default: servers and CDNs enable it, so it negotiates on 94.8% of the domains we could probe for TLS (~210 million). DNSSEC needs coordinated, often manual, action from the DNS host, the registrar and the TLD. It sits at 6.28% of the domains we could evaluate for it.
How do I check whether my domain’s DNSSEC is valid? You need a view from a validating resolver outside your own network. The free defaults.exposed check reports whether your domain is validly signed, unsigned, or signed-but-broken, alongside its full security grade.
Your domain is in one of three groups today: validly signed, unsigned, or silently broken. The third group usually has no idea. Run the free check at defaults.exposed to see where you stand, alongside your full security grade — before a validating resolver, or an attacker, finds out for you.