Why now
A CAA record (RFC 8659) names the certificate authorities allowed to issue for a domain. On its own it restricts which CA may issue, not who may ask: anyone who completes a DNS-01 or HTTP-01 challenge for the name still obtains a certificate from the allowed CA. RFC 8657 closed that gap in 2019 with two parameters — accounturi pins issuance to one ACME account, validationmethods limits the challenge types — but CAs were free to ignore them.
That changes on 15 March 2027. CA/Browser Forum ballot SC-098v2 (vote 4–11 May 2026; 22 certificate issuers in favour, one against; Apple, Google and Mozilla in favour) requires every publicly trusted CA to process both parameters. Let's Encrypt and a few others already do. The other date that bites first is closer: the 200-day validity limit applies to certificates issued since 15 March 2026, so renewals done on an annual reminder started expiring on 1 October 2026.
We wanted to know how the top of the web uses CAA before the mandate: how many domains publish records at all, who they allow, how many already pin accounts, how many records are broken — and how often the CAA set excludes the CA that is, in fact, issuing. ctlogs.dev indexes every public Certificate Transparency log, so the last question can be answered per domain.
Adoption
Of 765,900 registrable domains behind the CrUX August 2026 top million origins, 42,207 (5.5 %) publish CAA records at the apex. Adoption climbs steeply with popularity:
| CrUX rank | domains | with CAA | share | with accounturi | CAA excludes an issuing CA |
|---|---|---|---|---|---|
| top 1k | 822 | 172 | 20.9 % | 1 | 49 |
| top 10k | 7,569 | 1,046 | 13.8 % | 1 | 203 |
| top 100k | 72,246 | 6,486 | 9.0 % | 13 | 1,164 |
| top 1M | 685,263 | 34,503 | 5.0 % | 61 | 4,497 |
Among the domains with CAA: 76 (0.2 %) use accounturi and 77 (0.2 %) use validationmethods. 29,718 (70.4 %) say anything about wildcards with issuewild; 6,203 (14.7 %) give CAs a reporting address with iodef. 23 domains publish issue ";" — no CA may issue at all. 7,149 (16.9 %) of the CAA publishers are in DNSSEC-signed zones; for the rest a CA's resolver has no way to notice a spoofed CAA answer, which is also the assumption RFC 8657 makes.
In 64 cases 1.1.1.1 and 8.8.8.8 returned different CAA sets for the same name at the time of the check — propagation in progress, or a provider serving inconsistent data. It is the situation behind a recurring story: “my panel shows no CAA, yet my CA says one exists.” What the resolver returns is what the CA checks, not what the dashboard shows.
Who is allowed
The identifiers most often named in issue and issuewild records (a domain can name several):
| identifier | domains | share of CAA publishers |
|---|---|---|
letsencrypt.org | 36,289 | 86.0 % |
digicert.com | 28,880 | 68.4 % |
pki.goog | 25,899 | 61.4 % |
comodoca.com | 22,358 | 53.0 % |
ssl.com | 21,630 | 51.2 % |
sectigo.com | 10,088 | 23.9 % |
amazon.com | 7,809 | 18.5 % |
globalsign.com | 6,878 | 16.3 % |
amazonaws.com | 3,718 | 8.8 % |
amazontrust.com | 3,428 | 8.1 % |
awstrust.com | 3,005 | 7.1 % |
godaddy.com | 2,361 | 5.6 % |
certum.pl | 1,164 | 2.8 % |
harica.gr | 686 | 1.6 % |
entrust.net | 640 | 1.5 % |
For comparison, the CAs holding certificates for these domains in the window (by CA owner, any host under the domain):
| CA | domains with a certificate | share of all domains |
|---|---|---|
| Let's Encrypt | 616,580 | 80.5 % |
| Google Trust Services | 427,562 | 55.8 % |
| Sectigo Limited | 196,011 | 25.6 % |
| Amazon | 131,956 | 17.2 % |
| DigiCert Inc | 94,943 | 12.4 % |
| SSL Corporation | 85,708 | 11.2 % |
| GoDaddy.com, Inc. | 41,993 | 5.5 % |
| GlobalSign nv-sa | 37,100 | 4.8 % |
| GoDaddy.com | 30,568 | 4.0 % |
| ZeroSSL GmbH | 27,173 | 3.5 % |
| Asseco Data Systems S.A. | 6,929 | 0.9 % |
| Starfield Technologies, Inc. | 5,547 | 0.7 % |
| Certainly | 4,792 | 0.6 % |
| GoGetSSL | 3,219 | 0.4 % |
| Japan Registry Services Co., Ltd. | 3,108 | 0.4 % |
What is broken
Every record set was run through the same lint as the CAA checker. Counted per domain with CAA:
| finding | meaning | domains | share |
|---|---|---|---|
IODEF_MISSING | no iodef record | 36,004 | 85.3 % |
DNSSEC_UNSIGNED | zone not DNSSEC-signed | 35,058 | 83.1 % |
NO_ISSUEWILD_WITH_WILDCARDS | wildcard certificates but no issuewild record | 7,473 | 17.7 % |
CONFLICT_ISSUER | a CA with a certificate in the window is not allowed | 5,913 | 14.0 % |
ISSUE_UNKNOWN_IDENT | identifier no public CA recognizes (typo?) | 980 | 2.3 % |
CNAME_AT_APEX | apex is a CNAME | 336 | 0.8 % |
IODEF_BAD_URL | iodef is not mailto:/http:/https: | 289 | 0.7 % |
VALUE_SYNTAX | record value does not parse | 282 | 0.7 % |
TAG_UNKNOWN | unknown tag (ignored by CAs) | 277 | 0.7 % |
ISSUE_EMPTY_WITH_OTHERS | issue ";" next to named CAs | 160 | 0.4 % |
FLAG_RESERVED_BITS | reserved flag bits set | 145 | 0.3 % |
TAG_NONSTANDARD | contactemail / contactphone tags | 142 | 0.3 % |
DUPLICATE_RECORD | duplicate records | 94 | 0.2 % |
PARAM_UNKNOWN | parameter not defined by RFC 8657 | 68 | 0.2 % |
RESOLVER_DISAGREE | 1.1.1.1 and 8.8.8.8 returned different sets | 64 | 0.2 % |
LOOKUP_FAILED | a resolver gave no definite answer | 24 | 0.1 % |
MIXED_RESTRICTED_UNRESTRICTED | restricted and unrestricted record for the same CA | 13 | 0.0 % |
FLAG_CRITICAL_UNKNOWN_TAG | critical flag on an unknown tag — blocks every CA | 7 | 0.0 % |
Three of these deserve attention beyond their counts. FLAG_CRITICAL_UNKNOWN_TAG means no CA may issue for the domain at all, by the letter of RFC 8659 — usually a typo in the tag combined with flag 128. PARAM_DUP_ACCOUNTURI makes the record unsatisfiable: the named CA can never issue under it, so the domain has locked itself out of its own CA. MIXED_RESTRICTED_UNRESTRICTED is the quiet one: a carefully written record with accounturi sits next to an older plain record for the same CA, and the plain record still allows any account and any method. Records are additive; the weakest one wins.
CAA versus reality
5,913 domains (14.0 % of those with CAA) have a CAA set that does not allow a CA holding a certificate for them in the window — valid now, or expired within the last 90 days.
CT does not record when a CAA record was published, so each case is one of three things: the record is newer than the certificate (the domain changed CAs and the old certificate is still valid), the certificate came from a CDN or hosting provider that issues on the customer's behalf through its own CA, or the issuance was not expected. The first two are harmless until renewal time; the CDN case is the common way a tightened CAA breaks a site weeks later. The CAs most often on the excluded side:
| excluded CA | domains |
|---|---|
| Amazon | 1,968 |
| Let's Encrypt | 1,647 |
| Google Trust Services | 1,492 |
| Sectigo Limited | 449 |
| GoDaddy.com, Inc. | 444 |
| DigiCert Inc | 359 |
| GlobalSign nv-sa | 255 |
| GoDaddy.com | 236 |
| SSL Corporation | 219 |
| Certainly | 135 |
| ZeroSSL GmbH | 110 |
| eMudhra Technologies Limited | 99 |
| Starfield Technologies, Inc. | 42 |
| Asseco Data Systems S.A. | 28 |
| Hellenic Academic and Research Institutions CA | 27 |
2,871 of the conflicts (48.6 %) exclude Google Trust Services, Let's Encrypt or SSL.com — the CAs large CDNs issue through. A CAA that names only the CA your own tooling uses silently fights the certificates your CDN obtains for you.
How to set it up
Three lines cover most sites. Replace the account URL with your own (certbot keeps it in /etc/letsencrypt/accounts/…/regr.json, acme.sh in ca/…/account.json, lego in accounts/…/account.json):
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456; validationmethods=dns-01" example.com. IN CAA 0 issuewild ";" example.com. IN CAA 0 iodef "mailto:security@example.com"
Before publishing, look at who has been issuing for the domain: a CDN, a mail provider or a SaaS vendor with a custom domain may need its CA listed too. The checker shows that list, lints the records you have, and generates a set like the one above — the generator runs in the browser and never sends the account URI anywhere. Until March 2027 the parameters protect you only at CAs that already implement RFC 8657; after it, at every public CA.
Method and caveats
- Domains: the August 2026 Chrome UX Report top-1M origins (765,900 registrable domains after folding hosts to their eTLD+1). CrUX ranks are buckets (1k, 10k, 100k, 1M), hence the rank table.
- DNS: CAA at the apex via 1.1.1.1 and 8.8.8.8 with the DO bit set, on 4 October 2026; the public suffix above each apex was checked too. 761,914 apexes (99.5 %) received a definite answer (NOERROR or NXDOMAIN) from at least one resolver; the rest are counted as having no CAA. Host-level CAA (e.g. on
www) is not covered; in practice it is rare. - Certificates: every certificate in the public CT logs for any host under the domain, valid on the check date or expired within the previous 90 days, grouped by issuing CA; CA identifiers from CCADB's list of recognized CAA domains. “other” in the CA tables = intermediates that list does not cover (they are never counted as conflicts).
- Conflicts compare today's CAA with certificates issued over 90 days; the record may postdate the certificate.
- Lint codes and their definitions: ctlogs.dev/caa. Reproducible from the sweep table with the SQL in the ct-search repository.