2026-07-21 · RESEARCH · The Offensive Technology team

How many top domains restrict who can issue their certificates?

Short answer: We took the 1,000 busiest domains on the internet, resolved 994 of them, and read the CAA record each one publishes in DNS. Only 32.4% publish a CAA record at all. The other 67.6% place no DNS-level limit on which certificate authority may issue a TLS certificate for their name, so any of the dozens of publicly trusted CAs could, in principle, be tricked or compromised into issuing a valid certificate for them, and nothing the domain published would have said no. Among the minority that do set CAA, fewer than half (42.5%) ask to be told when a CA sees a request that breaks their policy, which is the one line that turns CAA from a quiet fence into an alarm. Every number here comes from passive public DNS lookups we ran ourselves against a published top-sites list. No host was contacted, nothing was scanned. Here is exactly how we measured it, and what it does and does not prove.

The finding in one chart

For each domain we asked three public questions. Does it publish a CAA record? If so, does it name a reporting contact (iodef) so a CA can warn it about violations? And does it control wildcard issuance separately from ordinary issuance? Each layer is smaller than the last:

What a CAA record actually does

Every browser trusts dozens of certificate authorities, and by default any one of them can issue a valid TLS certificate for any domain. That is convenient and it is also the soft spot: if a single CA is tricked through a flawed domain-validation check, coerced, or compromised, it can mint a certificate for a name that is not its customer, and a browser will accept it. Certificate mis-issuance is not hypothetical; it is why the industry built layered defenses around issuance in the first place.

CAA (RFC 8659, which replaced the earlier RFC 6844) is the DNS-level half of that defense. A domain publishes a short record that says, in effect, "only these CAs may issue for me." Since a CA/Browser Forum ballot took effect on 8 September 2017, every publicly trusted CA is required to read that record at issuance time and refuse to issue a certificate the record does not authorize. It is a rare control that is both free to set and actively enforced by the other side.

A CAA record set has a few moving parts:

• issue names a CA that may issue ordinary certificates, for example 0 issue "letsencrypt.org". An issue ";" with a semicolon means no CA may issue at all.
• issuewild governs wildcard certificates (*.example.com) separately, which matters because a single wildcard is a bigger blast radius than one hostname.
• iodef gives a URL or mailbox where a CA can report a request that violates the policy. It is the difference between silently blocking a bad request and finding out one was attempted.

Two thirds of the busiest domains set nothing

The headline number is the absence. Of the 994 domains that resolved, 672 (67.6%) publish no CAA record. For those domains, the DNS says nothing about who may issue their certificates, so the answer is: anyone in the public trust store. That is not a breach and it is not, on its own, a vulnerability. It is a missed opportunity to shrink the attack surface for a class of attack, using a record that costs one line and no money.

Among the 322 domains that do publish CAA, most are not leaning on a single provider: two thirds (66.5%) authorize more than one certificate authority, with a median of three. That is normal and sensible for an organization that uses different CAs for different systems, an internal PKI provider here, a public CA for the marketing site there. What stands out is the reporting gap. Only 42.5% of publishers set an iodef contact, so the majority have built a fence but no alarm: a CA that receives a request breaking their policy will refuse it, but the domain owner never hears that someone tried. This ties directly to the same theme as our study of email-authentication exposure across these domains, where the pattern was the same: the basic record is set more often than the setting that would actually raise an alarm.

How we measured this

A skeptic should be able to rebuild this from scratch, so here is the whole method with nothing hidden.

• The population. We used the Tranco list (list N29KW, generated 20 July 2026), a research-oriented top-sites ranking that averages several providers over 30 days to resist day-to-day manipulation. It is published, versioned, and permanently citeable, which matters more for reproducibility than any single vendor's list. See tranco-list.eu and the underlying NDSS 2019 paper.
• The sample. The top 1,000 domains from that list. 994 resolved to live name servers; 6 did not and were dropped, so the denominator is 994.
• The lookups. For each domain, a dig CAA <domain> query against public recursive resolvers, plus an NS query as a liveness gate. We parsed the answer for issue, issuewild, and iodef tags and read them at the domain's apex, which is the conventional adoption metric and the record a CA consults for the registered domain.
• What we did not do. We never requested a certificate, connected to a web server, or scanned anything. Reading a public DNS record is a lookup, not a probe. This is the same line between a check and a crime that governs every engagement we run.
• What we kept. Aggregate counts and percentages only. Per-domain results lived in memory for the duration of the run and were never written to disk. No domain is named. We recorded only whether an iodef tag was present, never its contact value, and gathered no personal data; domains and their DNS records are not personal data.

A neutral look at who gets authorized

One aggregate is worth showing because it describes the certificate authorities, not the sites we measured, and names no domain. Across the 322 CAA-publishing domains, these issuers appeared most often in the authorized lists. Read it as a popularity map of trusted CAs, not a scoreboard of anyone's security:

What this does not prove

Honest limits, because a number without its caveats is marketing.

• It is a snapshot. DNS changes daily. These figures describe 20 July 2026, not a trend. A domain with no CAA today may add one next week.
• Missing CAA is not a vulnerability. It is a control that was not turned on. Plenty of well-run organizations skip CAA and rely on other layers. We are measuring adoption of a hardening step, not counting holes.
• CAA is not a wall. It binds only CAs that honor it, does not revoke certificates already issued, and does nothing against a CA you did authorize being compromised. It narrows the set of issuers that can act, and iodef reports attempts. Catching unexpected issuance after the fact is the job of Certificate Transparency monitoring, which pairs naturally with CAA.
• Apex only. We read the CAA record at each registered domain's apex. Because CAA is evaluated by climbing the DNS tree, a subdomain can inherit or override this; we did not enumerate subdomains, and we would not, because that starts to look like mapping someone's estate rather than reading a single public record.
• The top of the list is mixed. The busiest domains include CDNs and infrastructure whose certificate practices differ from a typical company's. The population is "the most trafficked names," not "companies like yours," so treat the percentages as a landscape, not a benchmark for your own risk.

Why an attacker cares, and why you should

A forged-but-valid certificate is a powerful thing. It lets an attacker who is already in a position to intercept traffic, through a hijacked network path or a poisoned resolver, present your domain with a padlock the browser trusts, with no warning to the visitor. Mis-issuance is rare precisely because CAs are audited and CAA is enforced, but "rare" is doing a lot of work when the cost of raising the bar is a single DNS record. Publishing CAA removes every CA you do not use from the equation, and adding an iodef contact means that if someone does try to get a certificate through a CA you never authorized, you hear about it instead of finding out from a customer.

The fix is unglamorous and mostly free: list the CAs you actually use, add an issuewild entry if you issue wildcards, and set an iodef mailbox you read. The hard part is never the DNS edit. It is knowing every place your organization legitimately gets certificates from, so that turning CAA on does not quietly break a renewal you forgot about. That is judgment, and it is the same judgment behind knowing which of your exposed surfaces actually matter and which are noise.

Certificate authorization: quick answers

What is a CAA record?

CAA (Certification Authority Authorization, RFC 8659) is a DNS record listing which certificate authorities may issue TLS certificates for a domain. Since September 2017 the CA/Browser Forum has required publicly trusted CAs to check it and refuse issuance the record does not authorize. No CAA record means no restriction: any public CA may issue.

What share of top domains publish a CAA record?

In our July 2026 check of the 1,000 busiest domains (994 resolved), only 32.4% published a CAA record; 67.6% publish none. Among publishers, 42.5% also set an iodef reporting contact and 36% control wildcard issuance separately.

Does a CAA record stop all certificate mis-issuance?

No. It is defense in depth: it binds only CAs that honor it, does not revoke certificates already issued, and does not stop an authorized CA being compromised. It narrows who can issue and, with iodef, reports attempts. Pair it with Certificate Transparency monitoring.

How do I check and set my own CAA record?

Read it with dig CAA yourdomain.com. To set one, authorize only the CAs you use (for example 0 issue "letsencrypt.org"), add an issuewild entry if you use wildcards, and add 0 iodef "mailto:[email protected]" so a CA can report violations. Checking your own record is a passive lookup, so it is safe and free.

Related reading

• How exposed are the top domains to email spoofing?
• What can attackers actually see about your company?
• Why authorization comes before any testing