CAA record checker and lookup

What the result shows

The records that apply: The CAA records a CA uses for the name: its own, or the nearest parent’s. issue names a CA that may issue certificates, issuewild one that may issue wildcards, and iodef where a CA may report a refused request. A value of ; allows nobody.
Where the lookup looked: Each name asked, in order, with its answer, until one had records: what a CA does before it issues.
May renew: Whether the CA that issued the certificate the site serves now may issue for the name again. We ask our certificate checker for that certificate at the same time, and use its issuer.
Which certificate authorities may issue: The same answer for each common CA, for ordinary certificates and for wildcards, so you can plan a change of CA.

How CAs find the records

RFC 8659, section 3 sets the order. For shop.eu.example.com, a CA asks for the CAA records of shop.eu.example.com, then eu.example.com, then example.com, then com, and stops at the first name that has any. Those records decide; the names above don’t matter. If no name has any, every CA may issue.

Each lookup follows CNAMEs, as any DNS lookup does. When www.github.com is a CNAME to github.com, the answer for www.github.com is github.com’s CAA records:

Terminal

dig CAA www.github.com +noall +answer

output

www.github.com.         695     IN      CNAME   github.com.
github.com.             1829    IN      CAA     0 issue "sectigo.com"
github.com.             1829    IN      CAA     0 issuewild "digicert.com"
github.com.             1829    IN      CAA     0 issuewild "letsencrypt.org"
github.com.             1829    IN      CAA     0 issuewild "sectigo.com"
github.com.             1829    IN      CAA     0 issue "digicert.com"
github.com.             1829    IN      CAA     0 issue "globalsign.com"
github.com.             1829    IN      CAA     0 issue "letsencrypt.org"

Captured on October 24, 2026 with DiG 9.10.6. So whoever runs a CNAME’s target, often your host or CDN, decides which CAs may issue for your name.

The CAA name of each CA

Each CA documents the name its records need. A record with any of a CA’s names allows it; the first is the usual one.

CAA names of common certificate authorities
Certificate authority	Record to add	Source
Let’s Encrypt	0 issue "letsencrypt.org"	Let’s Encrypt’s CAA page
Google Trust Services	0 issue "pki.goog"	Google Trust Services’s CAA page
ZeroSSL	0 issue "sectigo.com"	ZeroSSL’s CAA page
Sectigo	0 issue "sectigo.com"	Sectigo’s CAA page
DigiCert	0 issue "digicert.com"	DigiCert’s CAA page
Amazon	0 issue "amazon.com"	Amazon’s CAA page
GlobalSign	0 issue "globalsign.com"	GlobalSign’s CAA page
Microsoft	0 issue "microsoft.com"	Microsoft’s CAA page
Apple	0 issue "pki.apple.com"	Apple’s CAA page
GoDaddy	0 issue "godaddy.com"	GoDaddy’s CAA page
HARICA	0 issue "harica.gr"	HARICA’s CAA page
Telekom Security	0 issue "telesec.de"	Telekom Security’s CAA page
Certainly	0 issue "certainly.com"	Certainly’s CAA page
SSL.com	0 issue "ssl.com"	SSL.com’s CAA page

A failed lookup is not a block

A record that doesn’t name your CA blocks it. A lookup that fails, with a SERVFAIL, a refusal or no answer, blocks nothing: it means nobody could read the records. Let’s Encrypt treats it as a reason to stop anyway, since “there’s no way to tell whether we are allowed to issue” (its CAA page), so the certificate still doesn’t renew. The fix is different, though: not a CAA record, but your DNS. Let’s Encrypt says a SERVFAIL “most often” means a DNSSEC failure; other causes are name servers that answer CAA queries wrongly and firewalls that drop them. The result says which you have.

Questions

Something else? Send us a note, right from the page.

What is a CAA record?

A DNS record that names the certificate authorities allowed to issue certificates for a domain (RFC 8659). With none, any publicly trusted CA may issue. With one, a CA it doesn’t name must refuse, which at Let’s Encrypt reads “CAA record for example.com prevents issuance”.

Do I need a CAA record?

No. Without one, any CA may issue for the domain, and most domains work that way. Add one to rule the others out, and then list every CA you use, including the ones your host or CDN uses for you.

Why does the checker look at parent domains?

Because CAs do. If a name has no CAA records, the records of its parent apply, then the parent’s parent, up to the top-level domain. One record at example.com covers www.example.com and every other name below it that has none of its own.

What does a CNAME do to CAA?

A CA follows it, like any DNS lookup: if www.example.com is a CNAME to a host’s name, the host’s CAA records apply to www.example.com. If the target has none, the climb goes on from example.com, the original name’s parent, not the target’s.

Is a SERVFAIL the same as a CAA block?

No. A SERVFAIL or a timeout means the lookup failed, so nobody can tell which records apply. Let’s Encrypt still refuses to issue while it lasts, but the fix is in your DNS (often DNSSEC, or name servers that mishandle CAA queries), not in a CAA record.

How do I allow Let’s Encrypt?

Add 0 issue "letsencrypt.org" at the name where your CAA records are, beside the records for your other CAs. Records add up, so you don’t have to remove anything.

For wildcard certificates, check for issuewild records: when there are any, only the CAs they name may issue wildcards, so add 0 issuewild "letsencrypt.org" too.

Is the CAA checker free?

Yes, with no account. It shares the limit of the other checks here, about 20 a minute from one address.

Get an email before it expires.

Expiry Watch checks the domain every day and emails you if the certificate’s renewal looks late, or before the certificate or the registration runs out.

CAA record checker

CAA for @@domain@@