CAA Has Been Mandatory Since 2017 but 93.1% of Company Domains Skip It

CAA (Certification Authority Authorisation) is a DNS record that specifies which certificate authorities are permitted to issue certificates for a domain. A domain that only wants Let's Encrypt to issue for it publishes:

example.com. IN CAA 0 issue "letsencrypt.org"

Any other CA that gets a certificate request for example.com is required to check for this record and refuse, even if the request would otherwise pass that CA's own validation. CAA has its own DNS resource record type (RR type 257), defined in RFC 6844 in January 2013. Since September 2017, every publicly trusted certificate authority has been required by the CA/Browser Forum's Baseline Requirements to check for a CAA record before issuing a certificate. If a domain publishes no restrictive CAA record, CAA places no additional restriction on which publicly trusted CA may issue after successful domain validation.

We checked the DNS records for 130,700 domains in CipherCue's tracked entity set, observed through 2026-09-01. 121,721 of them (93.1%) have no CAA record. This is a snapshot of CipherCue's dataset, not a statistically representative sample of every company worldwide; the method note below covers how the cohort is built.

The requirement applies to certificate authorities, not domain owners. CAs have to check CAA before issuance, but domain owners are not required to publish a record. If there is no restrictive record to find, CAA does not narrow the set of eligible public CAs.

Issuer restrictions

A CAA record does not stop a domain from getting a valid certificate. It restricts which CAs are authorised to issue one, using an issue tag (or issuewild for wildcard certificates) naming a CA, for example 0 issue "letsencrypt.org". A domain can list more than one.

The concrete scenario CAA is aimed at: any CA in a browser's trust store can issue for any domain by default, using its own domain validation process (proving the requester controls the domain, typically via a DNS token or an HTTP file at a well-known path). When DigiNotar, a Dutch CA, was compromised in 2011, the attacker used its systems to issue more than 500 fraudulent certificates for domains including google.com, none of which DigiNotar had any legitimate relationship with. That predates CAA; the mechanism didn't exist yet. A domain that names its usual CAs in a CAA record today removes every other CA from the pool for that domain: if a CA the domain doesn't use is compromised or has a validation bug, that CA is contractually and technically required to refuse a request for the domain regardless.

That's narrower than it might sound. CAA does not prevent DNS compromise, and an attacker with enough control over a domain's DNS to pass a CA's validation check can typically also alter or remove the CAA record protecting it. It doesn't revoke certificates already issued, even ones a later CAA record would no longer authorise. It isn't a runtime trust check either; browsers don't consult CAA when deciding whether to trust a certificate they're shown, only CAs consult it at issuance time, and a CA still has to run its own domain validation regardless of what CAA says. It also doesn't replace DNSSEC, which protects the DNS answers CAA depends on (including the CAA record itself) from being forged or stripped in transit.

We pulled the raw CAA issuer values from the 6.9% of domains that have a record. Among 8,979 domains with at least one CAA record, the five most-named CAs are:

The full issuer list, including smaller entries:

Occurrences exceed the number of domains with a record because most CAA-using domains name more than one CA. Some entries (pki.goog, digicert.com) also appear with a cansignhttpexchanges=yes parameter, an unrelated tag for Signed HTTP Exchanges, counted here with the base issuer since it names the same CA.

We also counted how many distinct CAs each domain authorises, among the domains with at least one CA-domain issuer entry (8,961 domains; see method note for how this excludes contact-only records):

Less than a quarter of domains with a CAA record name a single CA. Most name several, which is consistent with domains buying certificates from more than one vendor (a primary CA plus a CDN or cloud provider's own issuance, for example) rather than pinning to one issuer.

Country breakdown

The Netherlands has the highest CAA presence in this group at 10.1%. The UK is lowest at 4.3%. Every country shown is below 11%.

CAA presence by DMARC enforcement level

We compared CAA presence against DMARC status for the same 130,700 domains.

CAA presence rises at each stricter DMARC level: 2.7% with no DMARC record, up to 14.9% at p=reject. Even at the strictest DMARC level in this table, 85.1% of domains still have no CAA record.

CAA is also absent on domains enforcing DMARC

charitycommission.gov.uk, the UK government's charity regulator, is one example: DMARC enforced at p=reject with reports routed to a gov.uk DMARC service, and no CAA record. It's not an isolated case in the cohort; we found the same pattern, DMARC enforcement at p=reject paired with no CAA record, on other domains as well. Checked against live DNS at time of writing, separately from the dataset snapshot.

These domains have deliberately configured DMARC enforcement, which means someone edited their DNS zone with that specific goal. CAA wasn't part of that pass. DMARC generates reports when rua= is configured. CAA has no comparable reporting mechanism that tells a domain owner a record is absent.

Check your own domain

A CAA lookup is a single query:

dig CAA example.com

or, for just the record values:

dig +short CAA example.com

A typical restrictive record looks like:

0 issue "letsencrypt.org"
0 issue "digicert.com"

The issue tag authorises a CA to issue standard certificates. issuewild does the same for wildcard certificates and can be set separately, if a domain wants to allow different CAs (or none) for wildcards. iodef is unrelated to authorisation: it names a contact (usually a mailto: or https: URI) that CAs can notify when they see a request for the domain from an unauthorised issuer. A record with only an iodef tag and no issue tag doesn't restrict issuance at all.

Implementation checklist

1. Identify every CA currently used for certificate issuance across the domain and its subdomains.
2. Check whether wildcard certificates are in use, since they need their own issuewild entry.
3. Publish issue records for those CAs (and issuewild, if applicable).
4. Test certificate issuance and renewal before narrowing the policy further.
5. Monitor the record for unexpected changes.

An incomplete CAA policy can break legitimate certificate issuance or renewal later, if a CA gets added to the domain's certificate pipeline without a matching CAA update. Don't copy a single-CA example without checking which CAs are actually in use.

The standards history

CAA was published as RFC 6844 in January 2013, a Proposed Standard. It was refined and re-published as RFC 8659 in November 2019, also Proposed Standard, clarifying the record's tree-walking algorithm and issuer-matching rules based on real-world deployment. The CA/Browser Forum voted in March 2017 (Ballot 187) to make CAA checking mandatory for publicly trusted CAs, effective September 2017. That's a check performed by issuers at the moment of certificate issuance; it has no mechanism for making a domain owner publish a record. More than 13 years after the original RFC, and just over 9 years after CAA checking became mandatory for CAs, 93.1% of domains in this cohort have not published one.

Method note

Source and cohort: CipherCue's own DNS observations (direct queries for the CAA, DMARC, SPF, MTA-STS, and DNSSEC records), not a third-party dataset. 130,700 domains, latest observation per domain as of 2026-09-01. This is a domain count, not a deduplicated-organisation count: a company can own several domains, and each is counted separately.

CAA presence means at least one CAA resource record was returned for the domain's apex. Our DNS query captures the CAA record's value field but not its tag field, so the stored data doesn't directly distinguish issue, issuewild, and iodef records. To estimate the split, we treated any issuer value written as a bare domain (for example letsencrypt.org) as an issuance authorisation, and any value written as a mailto: or http(s): URI as an iodef-only contact record, since iodef values are always URIs and issue/issuewild values are always CA identifiers. On that basis, 8,961 of the 8,979 domains with a CAA record (99.8%) have at least one issuance-authorising entry; only 18 domains show CAA records that, by this heuristic, look contact-only. This is an inference from the stored values, not a direct read of the tag field, and we're flagging it as an estimate rather than a verified count.

CA-count-per-domain is calculated only over the 8,961 domains identified above as having at least one issuance-authorising entry, using the same domain-vs-URI heuristic to exclude iodef contacts from the count.

CAA vs DNSSEC: we planned to compare CAA presence against DNSSEC validation status, but our current DNSSEC check returns zero validated domains across the entire 130,700-domain cohort (a measurement-tooling limitation covered in our earlier DMARC article, not a claim that no domain has DNSSEC configured). With zero domains in the validated bucket, the comparison isn't usable and we're not reporting it.

External references: RFC 6844, RFC 8659 (IETF Datatracker). CA/Browser Forum Baseline Requirements, Ballot 187 (March 2017, mandatory CAA checking).

Finding this in your own market

CipherCue tracks CAA alongside DMARC, SPF, MTA-STS, and DNSSEC. The directory can be filtered by CAA status, country, and sector.