CAA Records: Restrict Which CAs Can Issue Your Certificates

Problem

You want to decide which certificate authorities may issue certificates for your domain — or a certificate request just failed with CAA record for <domain> prevents issuance and you need to find the record that did it. A CAA record is one DNS entry that answers a single question: who is allowed to issue for this name. Every publicly trusted CA has been required to honor it since 8 September 2017.

Symptoms

• An ACME client (Let’s Encrypt, ZeroSSL, and others) returns urn:ietf:params:acme:error:caa or the text CAA record for <domain> prevents issuance.
• A renewal that worked last quarter now fails, even though the DNS looks unchanged.
• A CA you just switched to cannot issue, while the previous one could.
• You have no CAA record at all, so any of the hundreds of trusted CAs may issue for your domain.

Top 3 Causes

1. The record names a different CA than the one issuing. issue "letsencrypt.org" authorizes Let’s Encrypt only; a request routed through DigiCert or Google Trust Services is refused.
2. A parent domain carries the blocking record. CAs climb the tree: they check the exact name, then drop the leftmost label and check again, up to the apex. A CAA on example.com governs app.example.com unless that subdomain has its own record — and the error message often names the subdomain, not the parent that actually blocked it.
3. An empty or wildcard-restricting value is doing exactly what it says. issue ";" forbids all issuance; issuewild ";" blocks wildcards while leaving normal certs alone. Left over from an old lockdown, these quietly stop renewals.

Diagnose with DechoNet

• DNS Lookup to read the CAA records on the failing hostname and on every parent label up to the apex — the blocking record is frequently one level above where the error points.
• SSL Certificate Check to confirm which CA actually issues your live certificate, so the issue value you set matches your real issuer instead of a guess.

Resolution Checklist

• Look up CAA on the failing hostname, then walk up each parent domain to the apex; the first label that has any CAA record wins, and labels above it are ignored.
• Confirm the issuer identifier your CA expects (Let’s Encrypt uses letsencrypt.org, Google Trust Services pki.goog, DigiCert digicert.com, Sectigo sectigo.com) and add an issue entry for it.
• If you need wildcard certificates, add a matching issuewild value — otherwise wildcard issuance silently follows issue.
• Lower the TTL on the CAA record before you change it; after editing, allow the CA’s cache to expire (the record TTL or 8 hours, whichever is greater) before retrying.
• Add an iodef entry (a mailto: or https:// URL) so the CA can report unauthorized issuance attempts back to you.
• For high-value zones, pin issuance to one ACME account with the RFC 8657 accounturi and validationmethods parameters — processing of these becomes mandatory for public CAs in 2027.

When to Escalate

• Escalate to your DNS provider if its panel cannot create a CAA record (type 257) or mangles the quoted value; a few legacy panels still handle it badly.
• Escalate to the CA’s support if issuance fails while your CAA records and account binding are demonstrably correct, since some validation methods and edge cases are CA-specific.
• Loop in whoever owns the parent zone when a CAA record above your delegation blocks a name you control but cannot edit yourself.