How to Configure CAA Records Correctly

A Certification Authority Authorization (CAA) record is one of the simplest security controls you can add to a domain, and also one of the easiest to get subtly wrong. It is a DNS record that says, in effect, “only these certificate authorities may issue TLS certificates for this name”. Since September 2017 every publicly trusted certificate authority has been required by the CA/Browser Forum Baseline Requirements to check CAA before issuing a certificate. If the record exists and does not authorise that CA, the request must be refused.

That makes CAA a useful guard against mis-issuance: a compromised account at a different CA, a careless employee ordering a certificate from an unapproved vendor, or a CA whose domain validation is tricked. It also means a broken CAA record can quietly stop your own certificate renewals. This guide walks through the syntax defined in RFC 8659, the tags you will actually use, how CAs look records up, and how to test everything before it matters.

What a CAA record contains

RFC 8659, published in 2019, replaced the original RFC 6844 and is the current standard. Every CAA record has three parts:

• Flags – a number from 0 to 255. In practice you use 0. The value 128 sets the “issuer critical” bit, which tells a CA that it must refuse to issue if it does not understand the tag.
• Tag – the property name, such as issue, issuewild or iodef.
• Value – a quoted string whose meaning depends on the tag, usually a CA’s domain name.

In zone file syntax a basic record looks like this:

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

You can publish several CAA records at the same name. Each issue record adds one more permitted CA; they are combined, not overwritten.

The three tags you need to know

issue

The issue tag authorises a CA to issue any certificate for the name, including wildcards unless an issuewild record says otherwise. A special value of a single semicolon, ";", means “no CA is allowed”. That is useful for domains that should never have a certificate, such as parked names or mail-only domains.

issuewild

The issuewild tag applies only to wildcard certificates like *.example.com. When at least one issuewild record is present, CAs ignore issue for wildcard requests and use issuewild exclusively. A common pattern is to allow ordinary certificates from one CA while blocking wildcards entirely:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"

iodef

The iodef tag gives a URL where a CA may report a request it refused because of your policy. It accepts mailto: and https: addresses. Support is optional, so treat it as a bonus signal rather than a monitoring system.

example.com.  IN  CAA  0 iodef "mailto:security@example.com"

CA identifiers for common providers

The value of an issue record must match the identifier the CA itself publishes, normally in its Certificate Policy or CPS. Getting this string wrong is the most frequent cause of failed issuance. The identifiers below are widely documented, but check your CA’s current documentation before relying on them.

Remember that many services obtain certificates on your behalf. A CDN, a managed WordPress host or an email security product may use a CA you never chose directly. Before you lock things down, find out which CA every provider in front of your domain uses.

How CAs find your record: tree climbing

A CA does not only look at the exact name in the certificate request. RFC 8659 defines a search that starts at the requested name and moves up one label at a time. The first name that returns a non-empty CAA record set is the one that counts, and the search stops there.

For a request for shop.eu.example.com, the CA checks in this order:

1. shop.eu.example.com
2. eu.example.com
3. example.com
4. com

Two practical consequences follow. First, a single set of records at the apex usually protects every subdomain, which is why most domains only need CAA at example.com. Second, a CAA record on a subdomain completely replaces the apex policy for that subtree; it does not add to it. If you add 0 issue "digicert.com" to eu.example.com, Let’s Encrypt is no longer allowed there even if the apex permits it. If no CAA record exists anywhere in the chain, any CA may issue.

CNAME records and CAA

CNAMEs are where CAA gets confusing. When a CA queries the CAA type for a name that is a CNAME, normal DNS resolution follows the alias and returns whatever CAA records exist at the target. If the target has CAA records, those are used for the original name.

Under RFC 8659, if the alias target has no CAA records, the CA continues climbing the tree of the original name, not the target’s parents. The earlier RFC 6844 behaviour of also climbing the target’s tree was dropped. This matters when www.example.com points to something like example.cdn-provider.net:

• If the CDN publishes CAA at the target, its policy applies to your www name, and your apex record is never reached.
• If the target has no CAA, the CA moves on to example.com and applies your apex policy.

Because you cannot publish other records alongside a CNAME at the same name, you cannot override a target’s policy at the alias itself. If a provider’s CAA blocks the CA you need, ask the provider or use a different hostname setup.

A step-by-step configuration

1. Inventory your certificates. List every hostname with TLS and which CA issued it. Certificate Transparency logs such as crt.sh help you find certificates you forgot about.
2. Decide on a policy. Pick the CAs you will allow and whether wildcards are needed.
3. Publish records at the apex. Add one issue per CA, optional issuewild, and an iodef contact.
4. Use a low TTL at first. A TTL such as 300 seconds lets you correct mistakes quickly; raise it once things are stable.
5. Test a renewal. Trigger a staging or dry-run renewal to confirm the CA can still issue.

A complete example for a domain that uses Let’s Encrypt for the website and Sectigo for a wildcard looks like this:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "sectigo.com"
example.com.  3600  IN  CAA  0 issuewild "sectigo.com"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

Some CAs also support extra parameters defined in RFC 8657, such as accounturi to restrict issuance to one ACME account, and validationmethods to allow only specific validation types. They tighten security further, but confirm that your CA supports them first.

Testing CAA records with dig

Always query public DNS rather than trusting your provider’s dashboard. These commands show what a CA will see:

dig example.com CAA +short
dig www.example.com CAA +short
dig @1.1.1.1 example.com CAA
dig +trace example.com CAA

A healthy response for the earlier example looks like:

0 issue "letsencrypt.org"
0 issuewild ";"
0 iodef "mailto:security@example.com"

If a subdomain returns nothing, that is normal; the CA will climb to the parent. What you do not want is a SERVFAIL. A CA that cannot get a definitive answer will generally refuse to issue, and some older DNS servers and appliances respond badly to the CAA record type. If you also need to see which nameservers and registrar a domain uses, the TLDix WHOIS lookup shows that alongside the expiry date.

Common mistakes to avoid

• Switching CAs without updating CAA. Add the new CA first, issue the certificate, then remove the old one.
• Typos in identifiers. letsencrypt.com or lets-encrypt.org silently block issuance.
• Forgetting third-party services. A CDN or SaaS custom domain may need its CA listed.
• Setting the critical flag casually. 128 on an unrecognised tag stops all issuance.
• Ignoring DNSSEC. CAA is only as trustworthy as the DNS answer; DNSSEC makes spoofing far harder.

CAA works best as part of a wider routine: track certificate expiry dates, watch Certificate Transparency logs and review DNS changes. If you are new to record types, our guide to DNS records basics is a good starting point.