CAA (Certification Authority Authorization) is a DNS record that specifies which certificate authorities (CAs) are allowed to issue SSL certificates for your domain. If an attacker tries to obtain an SSL certificate for your domain through an unauthorized CA, the CAA record blocks the issuance.
Why You Need a CAA Record
- Protection against fraudulent issuance of SSL certificates for your domain
- Prevention of "compromised CA" attacks
- Mandatory for organizations with high security requirements
- Recommended by NIST and required by some standards
CAA Record Syntax
# Allow only Let's Encrypt
@ IN CAA 0 issue "letsencrypt.org"
# Allow Let's Encrypt and Sectigo
@ IN CAA 0 issue "letsencrypt.org"
@ IN CAA 0 issue "sectigo.com"
# Allow Wildcard only from a specific CA
@ IN CAA 0 issuewild "letsencrypt.org"
# Email for failure notifications
@ IN CAA 0 iodef "mailto:security@example.com"Common CAs and Their CAA Values
| Certificate Authority | CAA Value |
|---|---|
| Let's Encrypt | letsencrypt.org |
| DigiCert | digicert.com |
| Sectigo (Comodo) | sectigo.com |
| GlobalSign | globalsign.com |
| Entrust | entrust.net |
Checking the CAA Record
dig example.com CAA
# Online: caatest.co.ukissuewild record for the same CA. Without it the CA will refuse to issue a Wildcard certificate even when a regular issue record exists.Common CAA Configuration Errors
| Symptom / Message | Cause | Fix |
|---|---|---|
Let's Encrypt: Error creating new order :: Policy forbids issuing for this domain | The CAA record allows a different CA, or doesn't list letsencrypt.org at all | Add 0 issue "letsencrypt.org" to the zone and wait for the record's TTL to propagate |
| A regular SSL certificate issues fine, but a Wildcard one doesn't | An issue record exists, but there's no separate issuewild for the same CA | Add 0 issuewild "letsencrypt.org" in addition to issue |
| A CA issues a certificate even though CAA explicitly forbids it | CAA is only checked by the CA at the moment a new certificate is issued — certificates issued earlier aren't revoked automatically | Explicitly revoke the unwanted certificate through the CA if it was issued before the CAA record existed |
| Several CAA records with different CAs seem to conflict | This isn't a conflict — multiple issue records work as an allow list (OR), not an exclusive one | To keep only one CA, delete the other issue records instead of adding them all |
Binding to a Let's Encrypt Account with accounturi
The accounturi parameter in a CAA record restricts issuance not just to a specific CA, but to a specific ACME account within that CA — even an employee of that same CA can't issue a certificate on someone else's behalf.
# Allow issuance only to a specific Let's Encrypt ACME account
@ IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567"The account ID can be found in the Certbot client's regr.json file or in the ACME client's logs from the first registration.
Checking Before Issuing a New Certificate
# Check the current CAA records
dig example.com CAA +short
# Check that the record is visible from a public resolver, not just locally
dig @8.8.8.8 example.com CAA +short
# Test certificate request in Let's Encrypt's staging environment
certbot certonly --staging -d example.com- If
digreturns no CAA record, either none exists yet or it hasn't propagated - Let's Encrypt's staging environment lets you test the whole chain without risking the production issuance limit (50 per week per domain)
- After adding a new CAA record, wait at least its TTL before retrying issuance
When CAA Can Get in the Way
- Switching CAs without updating the CAA record — the new SSL provider can't issue a certificate while the zone still restricts issuance to the old CA
- Using several services for different subdomains (for example, a CDN with its own SSL) — every CA used by any subdomain must be explicitly allowed at the zone level or on that specific subdomain
- Automatic issuance through third-party platforms (Cloudflare, hosting panels) — if CAA is configured manually and doesn't include that platform's CA, automation starts returning issuance errors
- Delegating a subdomain to a different DNS provider — CAA is checked in the zone of the subdomain requesting the certificate, not only in the root zone, see subdomain delegation
CAA Inheritance by Subdomains
A CAA record set at the zone root automatically applies to all subdomains that don't have their own CAA record. A subdomain's own record completely overrides the parent's record rather than adding to it.
| Where CAA Is Set | Does It Apply to mail.example.com |
|---|---|
| Only at @ (root) | Yes, if mail has no CAA of its own |
| Separately at mail.example.com | Yes, only the subdomain's record applies; the parent's is ignored |
Frequently asked questions
If a restrictive CAA record is added now, does it automatically revoke an already-issued certificate?
No, an existing valid certificate is not automatically revoked because of a new CAA record — the CA only checks CAA at the moment a new certificate is issued, not for certificates already in use. If the old certificate was issued before the restriction existed, it keeps working until it expires, unless explicitly revoked through the certificate authority.
Do visitors' browsers check the CAA record every time they load a site?
No, visitor browsers never read or check the CAA record at all — that check belongs only to certificate authorities and happens once, at the moment a certificate is requested. For a visitor, CAA remains a completely invisible technical mechanism on the DNS side, not part of the connection check a browser performs on every page load.
Does a CAA record cover mail S/MIME certificates, or only a site's SSL certificate?
It does, as long as the record's scope is not limited to one certificate type by its tag — the standard issue and issuewild tags cover regular and wildcard TLS certificates, while mail S/MIME certificates use their own separate tag with a different purpose. Without the right tag, the authority handling mail certificates may ignore the CAA record.
How long can it take after a CAA record changes before a certificate authority sees the new value?
The time depends on that record's TTL in the zone and how often the certificate authority's resolver re-queries DNS — while the old value stays cached somewhere along the path, the authority may still see it instead of the current one. The safest approach is not to guess, but to wait out the record's TTL before retrying the request.