CAA: constraining who may issue

Any publicly trusted certificate authority can, by default, issue a certificate for your domain to anyone who satisfies its validation checks. CAA is the record that narrows that list. It is one record, it takes ten minutes, and it is missing from most domains.

What it does

A CAA record names the certificate authorities permitted to issue for a domain. Since 2017 the CA/Browser Forum baseline requirements have obliged every publicly trusted CA to check it and refuse issuance if it is not listed — RFC 8659 is the protocol.

$ dig +short CAA github.com

0 issue "digicert.com"
0 issue "globalsign.com"
0 issue "letsencrypt.org"
0 issue "sectigo.com"
0 issuewild "digicert.com"
0 issuewild "letsencrypt.org"
0 issuewild "sectigo.com"

Checked 2026-09-12. Four CAs may issue; three of those may issue wildcards, and GlobalSign may not.

$ dig +short CAA paypal.com

0 issue "digicert.com"
0 issue "quovadisglobal.com"
0 issue "visa.com"

Checked 2026-09-12. A much tighter list, including their payment-network's own CA.

Reading one

0 issue "letsencrypt.org"
^ ^      ^
| |      the CA's identifier, as that CA documents it
| the property tag
the flags byte

Tag	Meaning
`issue`	This CA may issue certificates for this domain.
`issuewild`	This CA may issue wildcard certificates. If absent, `issue` covers wildcards too; if present, it overrides `issue` for wildcards.
`iodef`	Where to report a policy violation. Reporting is optional for the CA, so treat this as best-effort.

The flags byte has one defined bit: the critical flag. With it set, a CA that does not understand the tag must refuse to issue rather than ignore it. Leave it at 0 for the standard tags.

To forbid issuance entirely, publish an empty value — useful for domains that should never have a certificate:

parked.example.com.  CAA  0 issue ";"

How a CA finds the record

The lookup climbs. For shop.eu.example.com a CA checks that name, then eu.example.com, then example.com, stopping at the first name with a CAA record. So a policy at the apex covers everything beneath it unless a subdomain overrides it — which makes one record at the apex the sensible starting point.

There is a step before the climb that catches people out: aliases are chased first. The CAA query for a name follows CNAME and DNAME the way any query does (RFC 8659 §3 is explicit — "in particular, chasing aliases"), so an aliased hostname takes the policy of its target, not of its own parent.

$ dig +short CNAME www.github.com ; dig +short CAA www.github.com

github.com.
github.com.
0 issue "digicert.com"
0 issue "globalsign.com"
0 issue "letsencrypt.org"
0 issue "sectigo.com"
...

Checked 2026-09-12. There is no CAA record at www.github.com. The alias is followed to github.com and that policy applies — the climb to a parent never happens.

This matters when a hostname is a CNAME into a CDN or a SaaS platform. The policy that governs issuance for it is whatever that provider publishes, which may be nothing at all — and a restrictive CAA record at your own apex will not apply to it.

The check happens at issuance, and only then

CAA is not consulted by browsers and has no effect on certificates that already exist. Adding it today does not revoke anything issued yesterday. It constrains the future, which is worth doing and is not a remediation for a certificate already mis-issued.

What it does not do

It does not stop a CA that ignores it. Compliance is a requirement of the trusted-root programmes, not a technical enforcement. A compromised or non-compliant CA can issue anyway — CAA raises the bar and does not remove the risk, which is why certificate transparency monitoring remains necessary.
It does not authenticate the requester. It narrowswhich CA, not who. Anyone who can pass your permitted CA’s validation can still obtain a certificate.
It does not apply to private CAs or to internal certificates outside the public trust model.

The interaction with automated issuance

If you use ACME with a DNS-01 challenge, the CA does two DNS operations: it reads your CAA policy, and it reads the _acme-challenge TXT record you publish. Both must be correct and both must be visible. Two failure modes follow:

CAA does not list the CA — issuance is refused with a clear policy error. Easy to diagnose.
CAA lists the CA but the challenge record is not visible to it — the CA queries authoritative servers directly, so a record that has not reached every one of them produces an intermittent failure. On a signed zone, a challenge record that is not correctly signed fails the same way.

Knowledge check

A domain publishes only: 0 issue "letsencrypt.org". A team requests a wildcard certificate for *.example.com from Let's Encrypt. What happens, and what would change if 0 issuewild "digicert.com" were added?

It succeeds now. Adding the issuewild record would make Let’s Encrypt unable to issue the wildcard.
It fails now, because wildcards always require an explicit issuewild record.
It succeeds now, and adding the issuewild record would have no effect on Let’s Encrypt.
It fails now, because CAA records must be published at the wildcard name itself.

Correct — It succeeds now. Adding the issuewild record would make Let’s Encrypt unable to issue the wildcard. With no issuewild present, issue covers wildcards too, so Let’s Encrypt may issue. As soon as any issuewild record exists it overrides issue for wildcards entirely — so a lone issuewild for DigiCert would permit only DigiCert to issue wildcards, and Let’s Encrypt would be refused. This override is the part that surprises people.

Not this — It fails now, because wildcards always require an explicit issuewild record. The opposite: issuewild is optional, and in its absence the issue tag governs wildcards as well. Requiring it explicitly would break a great many working configurations.

Not this — It succeeds now, and adding the issuewild record would have no effect on Let’s Encrypt. The first half is right. But issuewild does not add to issue for wildcards — it replaces it. Introducing one for a different CA removes Let’s Encrypt’s wildcard permission.

Not this — It fails now, because CAA records must be published at the wildcard name itself. CAA is looked up by climbing from the name toward the apex. There is no requirement to publish a record at a wildcard name, and doing so is not how the check works.

What it does

Reading one

How a CA finds the record

What it does not do

The interaction with automated issuance

Go deeper