Fix “CAA record prevents issuance”

What the error says

Let’s Encrypt checks CAA before it issues, and when the records don’t allow it, its CA software builds the error from two parts (Boulder’s CAA check):

While processing CAA for www.example.com: CAA record for example.com prevents issuance

The first name is the one you asked a certificate for. The second is where the CAA records that refused it were found, which can be a parent: here, example.com’s records decided for www.example.com. The ACME error type is caa (urn:ietf:params:acme:error:caa), which is what Certbot prints on its Type line. Other CAs word it differently, but the cause is the same.

Find the record that blocks it

Ask for the CAA records of the name in the error:

dig CAA google.com +noall +answer

google.com.		84032	IN	CAA	0 issue "pki.goog"

0 issue "pki.goog" lets only Google Trust Services (pki.goog) issue certificates for google.com, so Let’s Encrypt would refuse. A name with no CAA records of its own uses the nearest parent’s: www.google.com has none, so google.com’s record applies to it too.

dig CAA www.google.com +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23686
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

NOERROR with ANSWER: 0 means the name exists and has no CAA records, so the search goes up a level. Both captured on October 24, 2026, with DiG 9.10.6.

The rules, from RFC 8659, section 3:

• The closest name with records decides. A CA asks for shop.eu.example.com, then eu.example.com, then example.com, then com, and stops at the first that has any. The ones above it don’t matter.
• CNAMEs are followed. If your name is a CNAME to your host’s, the host’s CAA records apply to your name, and dig shows the CNAME line first. If the host’s name has none, the search goes on from your name’s parent.
• No records anywhere means no restriction. Any CA may issue.

The CAA record checker does this climb for you and names the record that decides.

Add a record for your CA

Records add up: each issue record allows one more CA, so add a line for yours and keep the others. In a zone file:

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

Put it on the name the error names (here example.com), so it covers every name below it without records of their own. Each CA publishes the name to use:

Three more things that make the same error:

• Wildcards use issuewild when there is any. If the records include an issuewild line, only the CAs it names may issue *.example.com, whatever the issue lines say (RFC 8659, section 4.3). Add 0 issuewild "letsencrypt.org" too.
• Conditions on the record. A record like 0 issue "letsencrypt.org; accounturi=…" or …; validationmethods=dns-01 allows only that ACME account or validation method (RFC 8657). Let’s Encrypt checks both, so a renewal from another account, or over HTTP-01, gets this error with letsencrypt.org right there in the record.
• A critical record it doesn’t know. A record with flags 128 and a tag Let’s Encrypt doesn’t recognize stops it issuing at all (RFC 8659, section 4.5). Remove the record or set its flags to 0.

In Cloudflare

Cloudflare’s steps (CAA records): on the DNS Records page, select Add record, choose CAA as the Type, enter your domain as the Name, choose a Tag (the one that allows a CA to issue), enter the CA’s name such as letsencrypt.org as the CA domain name, and save. Repeat for each CA.

With Universal SSL on, Cloudflare adds records for the CAs it uses for its own edge certificates as soon as your zone has any CAA record, and they don’t show in the dashboard. In Cloudflare’s words, they appear with dig, so dig is the place to see what a CA sees.

Then renew

Run the renewal again. A changed record can take up to its old TTL, the number in dig’s second column, to reach the CA. For Certbot, start with a dry run, as in Certbot renew failed.

If the lookup fails: SERVFAIL or a timeout

When Let’s Encrypt can’t get an answer at all, the error is a DNS problem, not a CAA one. Boulder’s wording, from its DNS errors:

DNS problem: SERVFAIL looking up CAA for example.com - the domain's nameservers may be malfunctioning

No record is refusing anything here: nobody could read the records. Let’s Encrypt still won’t issue, because “there’s no way to tell whether we are allowed to issue” (its CAA page). This is how a domain with broken DNSSEC answers a resolver that checks it:

dig @1.1.1.1 CAA dnssec-failed.org +noall +comments

; <<>> DiG 9.10.6 <<>> @1.1.1.1 CAA dnssec-failed.org +noall +comments
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35887
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 09 6e 6f 20 53 45 50 20 6d 61 74 63 68 69 6e 67 20 74 68 65 20 44 53 20 66 6f 75 6e 64 20 66 6f 72 20 64 6e 73 73 65 63 2d 66 61 69 6c 65 64 2e 6f 72 67 2e ("..no SEP matching the DS found for dnssec-failed.org.")

Captured on October 24, 2026, against Cloudflare’s resolver. The last line is the resolver’s reason: no key in the zone matches the DS record its parent publishes for it. When the resolver gives a reason like this, Boulder prints it in place of SERVFAIL, as in DNS problem: looking up CAA for example.com: ….

The usual causes:

• DNSSEC. Let’s Encrypt says a SERVFAIL “most often” means a DNSSEC validation failure. Check the zone with DNSViz; a DS record left at the registrar after moving DNS providers is a classic.
• Name servers that mishandle CAA. Some answer a query for an unknown record type with an error instead of “no records”; that breaks CAA lookups even for domains with no CAA records (RFC 8659, section 6.2).
• Timeouts. A firewall in front of the name servers that drops queries for unusual types (section 6.1).
• A subdomain delegated to private name servers. Public resolvers can’t reach them and answer SERVFAIL (section 6.3).

Each of these is for whoever runs the DNS to fix. Adding a CAA record changes nothing while the lookup itself fails.

Sources

All sources were checked on October 24, 2026. The command output comes from our own runs on that date, with DiG 9.10.6.

• RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record, IETF, November 2019: section 3 (which records apply), sections 4.2 to 4.5 (issue, issuewild, the critical flag) and section 6 (lookup errors).
• RFC 8657: CAA Record Extensions for Account URI and ACME Method Binding, IETF, November 2019.
• Certificate Authority Authorization (CAA), Let’s Encrypt, last updated October 4, 2026.
• Boulder, Let’s Encrypt’s CA software: va/caa.go (the CAA error) and bdns/problem.go (the DNS errors).
• CAA records, Cloudflare, last updated April 21, 2026.
• Each CA’s CAA name: Google Trust Services, Sectigo, ZeroSSL, DigiCert, AWS Certificate Manager, GlobalSign and SSL.com.