CAA Records Explained: Control Who Issues Your SSL Certificates
Learn what a CAA record does, how certificate authorities check it, and how to set CAA records for Let's Encrypt, Cloudflare and AWS without breaking renewals.
Any public certificate authority can, in principle, issue a TLS certificate for your domain if someone passes its validation checks. A CAA record narrows that list to the CAs you actually use, so a mistake or a compromise at some other CA is much less likely to produce a valid certificate for your site. It takes one DNS line to set up, and one wrong line to break your next renewal, so this guide covers both: how CAA works, and how to set it correctly for the services you use.
Key takeaways
- A CAA record lists which certificate authorities may issue TLS certificates for your domain, and CAs must check it before issuing.
- List every CA you use before publishing CAA, because the next renewal fails for any service whose CA is not in your policy.
- CAA records on the apex cover all subdomains, but a subdomain's own CAA records replace the apex policy for that subdomain.
- Adding a CAA record does not affect existing certificates, as CAs check it only when they issue.
What a CAA record does
CAA stands for Certification Authority Authorization. It's a DNS record, defined in RFC 8659, that lists which CAs are allowed to issue certificates for a domain.
Since September 8, 2017, checking CAA has been mandatory for publicly trusted CAs under the CA/Browser Forum Baseline Requirements (Ballot 187). Before issuing, the CA looks up your CAA records. If they exist and don't name that CA, it must refuse.
A few things CAA is not:
- It isn't checked by browsers. It's a pre-issuance rule for CAs. A certificate that's already been issued stays valid regardless of later CAA changes.
- It doesn't replace domain validation. It's an extra restriction on top of the normal checks.
- It's optional. If you publish no CAA records, any CA may issue (subject to validation).
CAA record syntax
A CAA record has three parts: a flag, a tag and a value.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
; ^ ^ ^
; flag tag value
Flags
Use 0 in almost every case. The value 128 sets the "issuer critical" flag, which tells a CA it must refuse to issue if it doesn't understand the tag. It's only useful with non-standard tags.
Tags
| Tag | What it controls |
|---|---|
issue |
Which CAs may issue certificates for this name. Also covers wildcards unless issuewild exists. |
issuewild |
Which CAs may issue wildcard certificates (*.example.com). When present, it overrides issue for wildcards. |
iodef |
Where a CA can report a request that violated your policy (mailto: or https: URL). It doesn't block or allow anything. |
Values
The value for issue and issuewild is the CA's domain identifier, which each CA publishes in its documentation. Examples from the CAs' and platforms' own docs:
| CA | CAA identifier |
|---|---|
| Let's Encrypt | letsencrypt.org |
| Google Trust Services | pki.goog |
| Sectigo | sectigo.com |
| SSL.com | ssl.com |
| Amazon (ACM) | amazon.com, amazontrust.com, awstrust.com or amazonaws.com |
For any other CA, look up the identifier in its CPS or help docs rather than guessing. A typo in the identifier blocks that CA entirely.
A special value, a single semicolon, means "no CA may issue":
legacy.example.com. 3600 IN CAA 0 issue ";"
How CAs find your CAA record
This is the part that surprises people. The CA doesn't only look at the exact name in the certificate.
- It checks the requested name first, for example
shop.example.com. - If there's no CAA there, it climbs the tree:
example.com, then stops before the TLD. The first CAA set it finds is the one that applies. - CNAMEs are followed. If
shop.example.comis a CNAME toshops.platform.example, the CA applies CAA records found at the CNAME target. Let's Encrypt's docs and Cloudflare's docs both call this out.
In practice:
- Records on the apex cover every subdomain that doesn't have its own CAA records.
- A CAA record on a subdomain replaces the apex policy for that subdomain entirely. It doesn't add to it.
- A third-party platform you CNAME to can impose its own restrictive CAA, even if you have none.
Multiple issue records at the same name are additive: any CA listed in any of them is allowed.
How to set CAA records
Step 1: Inventory every place that issues certificates for you
This is the step that prevents outages. Check:
- Your web host or control panel (often Let's Encrypt).
- Your CDN or proxy. Cloudflare's docs list the CAs it uses for its managed certificates, including
pki.goog,letsencrypt.org,ssl.comandsectigo.com, and note the list isn't exhaustive. Cloudflare adds CAA records for those CAs automatically for its managed certificates, but its docs note that Advanced Certificate Manager certificates don't get them, and subdomain setups inherit the parent's CAA policy. - Cloud load balancers (AWS ACM, Google Cloud, Azure).
- Hosted services on your subdomains: help desk, status page, landing pages, email marketing tracking domains, store platforms.
- Any certificate you bought directly from a commercial CA.
You can see which CAs have issued for your domain recently by searching Certificate Transparency logs (for example at crt.sh). Every CA that shows up there with an active certificate needs to be in your policy, or that service will fail at its next renewal.
Step 2: Write the records
A site using Let's Encrypt for the origin and Cloudflare in front:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "pki.goog"
example.com. 3600 IN CAA 0 issue "sectigo.com"
example.com. 3600 IN CAA 0 issue "ssl.com"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
A site that uses Let's Encrypt for normal certificates but only allows wildcards from AWS Certificate Manager:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "amazon.com"
example.com. 3600 IN CAA 0 issuewild "amazon.com"
Because issuewild is present, Let's Encrypt can no longer issue wildcards here, even though it's listed under issue.
A domain that should never have certificates (a parked or email-only domain):
example.net. 3600 IN CAA 0 issue ";"
example.net. 3600 IN CAA 0 issuewild ";"
Step 3: Use CA-specific restrictions (optional)
Some CAs support extra parameters after a semicolon in the value. Let's Encrypt supports:
accounturito restrict issuance to your ACME account, so someone who briefly hijacks your DNS but doesn't have your account key can't get a certificate.validationmethodsto allow only certain challenge types (http-01,dns-01,tls-alpn-01).
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"
Only add these when you control all renewals for that name. Hosting panels and CDNs that issue on your behalf use their own accounts, and this will block them.
Step 4: Verify
dig example.com CAA +short
dig shop.example.com CAA +short # check subdomains and CNAME targets too
Then trigger a renewal or test issuance on each service before its certificates are due to expire. With certificate lifetimes getting shorter (see SSL certificate lifetime changes), renewals are more frequent, so a broken CAA policy surfaces faster.
Troubleshooting CAA errors
"CAA record for example.com prevents issuance." The CA found a CAA set that doesn't list it. Check the requested name, every parent, and any CNAME target. The blocking record is often on a subdomain you forgot about, or on a platform's domain you CNAME to.
SERVFAIL or timeout during the CAA check. CAs must be able to get a definite answer; a lookup failure isn't treated as "no records." Let's Encrypt's docs say SERVFAIL most often indicates a DNSSEC validation problem, and timeouts often come from firewalls or DNS servers that mishandle unfamiliar record types. Check your zone with DNSViz and see our DNSSEC guide.
Wildcard won't issue but normal certificates do. You have an issuewild record that doesn't include your CA. Remember that issuewild overrides issue for wildcards.
Changes don't seem to apply. CAs may use cached CAA results: the Baseline Requirements let a CA rely on a CAA check for up to the record's TTL or 8 hours, whichever is greater. Wait, then retry.
Check your domain
Run a free audit to see your CAA records in the DNS section next to your TLS certificate details, so you can confirm that the CA that issued your current certificate is one your policy allows.
Frequently asked questions
Do I need a CAA record?
It isn't required, and sites work fine without one. It's a low-cost hardening step that reduces the number of CAs that could mistakenly or maliciously issue for your domain. If you manage many services and can't keep an accurate inventory, start by publishing it on domains with simpler setups.
Will adding a CAA record break my existing certificate?
No. CAs check CAA only when they issue. Your current certificate stays valid until it expires, but the next renewal will fail if the issuing CA isn't in your policy, which is why you should inventory first.
Does a CAA record on my root domain apply to subdomains?
Yes, unless the subdomain has its own CAA records. CAs climb the tree from the requested name and use the first CAA set they find, so a subdomain record replaces the apex policy for that subdomain.
What does the iodef tag do?
It gives CAs an address to report issuance requests that violated your policy. It doesn't affect whether a certificate is issued, and support for sending reports varies by CA.
What to do next
Search Certificate Transparency logs for your domain, list every CA that appears, and publish issue records for exactly those CAs at the apex. Add an iodef address, test a renewal on each service, and put "update CAA" on the checklist for any new hosting or CDN provider. For the rest of your zone, see DNS records explained.
Related reading
- Is My Website Down or Just Me? How to Tell in 5 Minutes: Work out whether your website is down for everyone or only for you, find the broken layer (DNS, hosting, SSL, CDN or your own network) and know who to call.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 25 October 2026 . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
