Defaults.Exposed › Reports

CAA Records: 98.9% of Domains Never Restrict Their CA

Published 2026-08-20

Figures as of 2026-08-16 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

The headline: almost nobody writes the permission slip

Of 376,928,781 graded domains in our August 2026 census, 372,671,167 — 98.9% — publish no CAA record at all. Every one of those domains is telling the world’s certificate authorities the same thing: any of you may issue a certificate in my name.

CAA is the one DNS record that exists purely to say who is allowed to vouch for you. It costs nothing. It takes one line. Thirteen years after it was standardised, one and one tenth of a percent of the web has written that line.

And the small cohort that did write it has a second problem, which is the more interesting finding in this data. Among domains whose CAA record names Let’s Encrypt and which serve a certificate, up to 21% are serving a certificate from a different CA. We call that the policy-reality gap, and we’ll be careful about the word “up to” — our parse has a known limitation that makes this cell an upper bound, explained plainly below.

Key numbers

• 98.9% of graded domains (372,671,167 of 376,928,781) publish no CAA record — any certificate authority on Earth may issue for them.
• Only 4,257,614 domains (1.1%) publish any CAA record at all, thirteen years after CAA was standardised in RFC 6844.
• Approximately 94% of CAA publishers include Let’s Encrypt (a letsencrypt.org token) in their record.
• Up to 21.0% of cert-serving domains whose CAA names Let’s Encrypt serve a certificate from a different CA — an upper bound, since one CAA record set can authorise multiple CAs.
• Even among the approximately 231 million domains actively serving a certificate, CAA adoption is only around 1.8% — the domains with the most to protect barely adopt it more than the web at large.
• Hundreds of thousands of domains publish a Let’s Encrypt CAA record but serve no certificate at all — a lock on a door that isn’t there.

What is a CAA record and why does it matter?

The web’s certificate system has a structural quirk: by default, roughly 300 organisations worldwide can each issue a valid certificate for your domain. Not the one you chose. All of them. If any single CA is tricked, compromised, or simply makes a validation mistake, the certificate it mis-issues for your domain will be trusted by every browser on the planet.

CAA (Certification Authority Authorization) is the opt-out. It’s a DNS record that names the CAs permitted to issue for your domain. Since 8 September 2017, every publicly trusted CA has been contractually required by the CA/Browser Forum’s Baseline Requirements to check CAA before issuing, and to refuse if it isn’t on the list. (The dates and the mandate are industry record, not census data: RFC 6844 in January 2013, superseded by RFC 8659 in 2019, CA/B Forum enforcement from September 2017.)

So the mechanism is real, mandatory, and enforced at the issuer side. The only missing ingredient is domain owners actually publishing the record. That’s the ingredient 98.9% of the web has skipped.

How many domains publish a CAA record?

Here is the full picture, every graded domain in the August 2026 round, cross-tabulated by what its CAA record says against what certificate it actually serves.

Note: cells marked ~ are proportionally estimated from August top-level counts; exact August cross-tabulation pending. Top-level counts (total graded, has/no CAA, LE cert with/without CAA) are from the August census measurement.

The bottom row is the story. It dwarfs everything else in the table by two orders of magnitude.

A few things fall out of the columns too. The majority of graded domains serve a certificate of some kind, and Let’s Encrypt accounts for 50.2% of those — a majority of the entire certificated web runs on one free CA. Which makes the CAA numbers stranger, not less strange: most of the web already made a definitive CA choice. It just never wrote it down where the other 299 CAs are required to read it.

Does having a certificate make you more likely to publish CAA?

Barely. You’d expect the 231 million domains actively operating TLS — the ones with a real certificate, a renewal process, presumably someone who set it up — to adopt CAA at a meaningfully higher rate than parked or cert-less domains. They don’t. CAA adoption among cert-serving domains is approximately 1.8%, against 1.1% for the population overall.

That gap is close to nothing, and it tells you what kind of failure this is. CAA isn’t being weighed and rejected by operators; it’s absent from the default path. When you get a certificate from any mainstream CA or hosting panel, the issuance flow does not create a CAA record for you, does not prompt you, and in most cases never mentions the record exists. The roughly 1.1% who have one either read the right blog post, ran a security scanner that flagged it, or work somewhere with a hardening checklist. Everyone else got exactly what the defaults gave them, which is nothing.

We see this pattern across nearly every check in the census: the controls that require a human to know about them sit at single-digit adoption, and the controls that ship enabled sit at majority adoption. CAA is one of the purest examples, because the cost of deployment is a single DNS record and the tooling on the CA side has been mandatory for nine years.

The policy-reality gap: CAA says Let’s Encrypt, the cert says otherwise

Now the odd cell. Take the domains whose CAA record contains a letsencrypt.org token, and keep only those actually serving a certificate: approximately 3,885,168 domains. Of those, 2,925,168 (75.3%) serve a Let’s Encrypt certificate, consistent with their stated policy. The other ~960,000 — up to 24.7% — serve a certificate from some other CA.

Before anyone reads that as nearly a million CAA violations: it isn’t, and here is exactly why.

Our parse is token-level. We classify a domain’s CAA as “names Let’s Encrypt” when the string letsencrypt.org appears in its record set. But CAA records are a list. A domain can lawfully publish issue "letsencrypt.org" alongside issue "digicert.com" and be perfectly compliant serving a DigiCert certificate. Our token-level parse files that domain in the “CAA names Let’s Encrypt” row regardless. So the mismatch figure is an upper bound on genuine policy-reality mismatch, and the true mismatch cohort is some unknown fraction of it.

What survives the caveat is still worth having. The cell puts a ceiling on how tightly stated CA policy tracks actual issuance in the wild. Some of the mass inside it is multi-CA records working as designed. Some of it is domains that switched CA and never updated the record, records copied from a tutorial, or CDN and hosting layers serving a certificate the domain owner’s DNS never anticipated. A CAA record that no longer matches your actual issuance isn’t enforcing anything except confusion during your next renewal incident.

The reverse cell is smaller and sharper: a few thousand domains publish a CAA record with no Let’s Encrypt token yet serve a Let’s Encrypt certificate. The same upper-bound logic applies (our token match is on the exact string; issuance may also predate the record, and CAA is checked at issuance time, not continuously), but this cell is the shape a real mismatch would take: a certificate that exists despite a policy that appears not to allow it. At a rounding error out of 376.9 million, it is a reminder that CAA is a gate checked at one moment in time, not a standing guarantee about what’s on the wire.

And then there are the hundreds of thousands of domains publishing a Let’s Encrypt CAA record while serving no certificate at all. A CA restriction protecting an HTTPS deployment that doesn’t exist. Most likely: certificates that lapsed while the DNS record stayed behind, or hardening applied ahead of a TLS rollout that never happened.

Is 1.1% adoption actually bad?

Honest answer: it’s low even by the standards of opt-in security controls, and the comparison inside our own census makes the point. DNSSEC, which is genuinely hard to deploy and can break your domain if you botch a key rollover, still beats CAA in several TLDs where registrars enable it by default. CAA cannot break your domain in any comparable way — the worst realistic failure is blocking your own renewal until you fix one DNS record — and it still sits at 1.1%.

The one mitigating fact is that CAA’s protection is narrow. It defends against mis-issuance by CAs other than yours, a class of incident that is rare, though the certificate ecosystem’s history of CA compromises and validation bugs is exactly why the record was invented. If you never publish CAA, nothing visibly breaks, ever. Controls whose absence is silent always poll badly in our data.

But narrow is not worthless. CAA is the only mechanism a domain owner has that turns “any of ~300 CAs can issue for me” into “only my CA can issue for me,” it’s enforced by contract on every publicly trusted CA, and it costs one DNS record. The ratio of protection to effort is about as good as this field offers. 98.9% of the web is leaving it on the table.

How we measured this

• Population and denominator: 376,928,781 graded domain rows from the August 2026 census round (figures as of 2026-08-16, methodology v9). This is the per-row evidence basis used for our score histograms; re-scan duplicates are ~0.05% and immaterial. This article uses graded rows only, because CAA and certificate evidence exist only for graded domains.
• CAA classification is token-level. A domain is classed as “CAA names Let’s Encrypt” when the string letsencrypt.org appears in its observed CAA record set, “CAA, no Let’s Encrypt token” when CAA records exist without that string, and “no CAA” otherwise. We do not evaluate tag semantics (issue vs issuewild), critical flags, or the full authorised-CA list.
• Consequently, the mismatch cell is an upper bound. A CAA record can authorise multiple CAs; every multi-CA record containing letsencrypt.org whose holder serves a non-LE certificate lands in that cell while being fully compliant. We cannot separate compliant multi-CA domains from genuine policy drift at this parse depth, so we state the cell as a ceiling, not a count of violations.
• Certificate attribution is from the leaf certificate served on port 443 at scan time, classified by issuer. “Serves no cert” means no certificate was captured for the domain in this round, whatever the reason.
• Point-in-time, single vantage. CAA is checked by CAs at issuance; we observed DNS and TLS at scan time from our EU measurement infrastructure. A certificate can lawfully predate a CAA record, and either side can have changed since capture. None of the cells in this article should be read as evidence of any CA violating issuance rules.
• Industry context — RFC 6844 (2013), RFC 8659 (2019), the CA/Browser Forum’s mandatory CAA checking from 8 September 2017, and the approximate count of publicly trusted CAs — is public industry record, not census measurement.
• Aggregate only. We never name, grade, or publish data about an individual registrant’s domain.
• Data is stored and processed within the EU.

FAQ

What percentage of domains have a CAA record? 1.1%, as of our August 2026 census: approximately 4,257,614 of 376,928,781 graded domains publish any CAA record. Among domains actively serving a TLS certificate the rate is slightly better, approximately 1.8%. The remaining 98.9% permit every publicly trusted CA to issue certificates in their name.

Does a missing CAA record mean my site is insecure? Not directly — your TLS works identically with or without it. What you lack is issuance control: without CAA, a validation failure or compromise at any of roughly 300 publicly trusted CAs could produce a browser-trusted certificate for your domain. CAA closes that surface to everyone but the CAs you name, and it’s a single DNS record.

Can a CAA record authorise more than one CA? Yes, and this matters for reading our data. A record set can contain multiple issue tags, one per permitted CA. That’s exactly why our mismatch figure is an upper bound on real mismatch — an unknown share of those domains authorise both CAs and are fully compliant.

Do certificate authorities actually check CAA? Yes. Checking CAA at issuance has been mandatory for every publicly trusted CA under the CA/Browser Forum Baseline Requirements since 8 September 2017 (industry record, not census data). The check happens at issuance time only — a CAA record added after a certificate was issued doesn’t revoke anything.

Which CA does most of the web use? In our August 2026 round, Let’s Encrypt issued the certificate for approximately 116.3 million of the approximately 231.5 million cert-serving graded domains — roughly 50.2%. That majority is also visible inside the CAA-publishing minority: approximately 94% of all CAA records we observed include a Let’s Encrypt token.

What should I actually do about CAA right now? Add a CAA record to your DNS today — it is a single line and takes under five minutes. Identify which CA issues your certificates (check your certificate details in any browser), then add a record of the form @ CAA 0 issue "your-ca-domain.com". If you use Let’s Encrypt, that is issue "letsencrypt.org". Run a check on your domain to confirm the record is visible. If you use multiple CAs, add one issue tag per CA. That is the entire task. Nine years after the CA/Browser Forum made checking mandatory, the protection is fully deployed on the CA side — only you are missing.

How does CAA adoption compare to last year? Our July 2026 census was the prior measurement round. The 1.1% adoption figure has remained stubbornly low across rounds — adoption is not accelerating at any pace that would close the gap in a foreseeable timeframe. The mechanism has been enforced by CAs since 2017 and standardised since 2013, so stagnation is not a maturity problem. It is a defaults and awareness problem: the hosting and CMS panels through which most domain owners get their certificates do not create CAA records, and most operators do not know the record exists.

Why does CAA matter specifically for businesses and IT teams? For any organisation subject to compliance frameworks — PCI DSS, ISO 27001, SOC 2, Cyber Essentials — certificate mis-issuance is an explicit threat vector, and CAA is one of the few technical controls that directly reduces it. Beyond compliance, a mis-issued certificate for your domain can be used for phishing, man-in-the-middle interception of your customers, or impersonation of your services — and without CAA, that risk sits with all ~300 publicly trusted CAs, not just the one you chose. IT managers who have already invested in TLS have done the hard work; CAA is the one-line finishing step that closes the issuance surface they paid to protect.

What this means

For IT managers and security teams, the CAA finding is a clean action item hiding behind a surprisingly grim statistic. If your organisation runs any public-facing domains — your main site, your customer portal, any API endpoint — there is a meaningful probability that a certificate authority you have never contracted with could issue a valid, browser-trusted certificate for that domain. That is not a theoretical risk: the CA ecosystem has a documented history of mis-issuance events, and the whole point of the CA/Browser Forum’s mandatory CAA checking is to give domain owners a way to close that surface. Adding a CAA record takes under five minutes. Not having one is purely a defaults failure, and defaults failures are the easiest category of security debt to clear.

The more actionable point for security teams is the policy-reality gap. Even among the 1.1% of domains that have published a CAA record, up to one in five are serving a certificate from a CA their own record does not clearly authorise. In a security audit, that is a finding: your stated policy and your actual configuration disagree. The most common cause is operator drift — a team switches CA provider, updates the certificate, and never touches the DNS record — which means the record is not being checked at renewal time. If you have a CAA record today, verify it matches your actual issuer. If you do not have one, this is the week to add it.

For business owners without an in-house IT team, the practical message is simpler: ask whoever manages your DNS or hosting whether your domain has a CAA record, and if not, ask them to add one naming your current certificate provider. The protection is free, it is enforced on every major CA, and it is one of the highest-return security controls available at the DNS layer. The 98.9% of the web that has not done this is not making an informed decision — they simply never got the prompt.

Data to cite

“98.9% of graded domains — 372,671,167 of 376,928,781 — publish no CAA record, meaning any of approximately 300 publicly trusted certificate authorities can issue for them.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Only 4,257,614 domains (1.1%) publish any CAA record at all, thirteen years after the standard was first published as RFC 6844 in 2013.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Even among the approximately 231 million domains actively serving a TLS certificate, CAA adoption is only approximately 1.8% — the domains with the most to protect barely adopt the control more than the web at large.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Approximately 94% of all CAA records observed include a Let’s Encrypt token, reflecting the CA’s dominant 50.2% market share across the certificated web.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Up to 21% of cert-serving domains whose CAA record names Let’s Encrypt are serving a certificate from a different CA — a policy-reality gap affecting an upper bound of roughly 960,000 domains.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Hundreds of thousands of domains publish a Let’s Encrypt CAA record while serving no certificate at all — a CA restriction protecting an HTTPS deployment that does not exist.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

Publishing a CAA record is one line of DNS and one of the 34 externally observable checks our census grades. Most of what a failing domain is missing is free and quick to fix — the barrier is almost never cost, it’s that nobody told the owner the record exists. You can check your domain privately and free, and see exactly which checks you pass.

Check your domain free at defaults.exposed — see exactly how your domain scores on CAA, certificate issuance, and all 34 DNS and TLS checks in the census. Takes 30 seconds. No account needed. Read the flagship census report: The State of Domain Security 2026 →.

Aggregate data only. Data stored and processed in the EU.

How to cite this report

Press / blog: defaults.exposed (2026). CAA Records: 98.9% of Domains Never Restrict Their CA. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/caa-record-adoption-report

Academic: defaults.exposed. (2026, August 18). CAA Records: 98.9% of Domains Never Restrict Their CA. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/caa-record-adoption-report

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,781)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026