All guides · Security

CAA Records: Control Who Can Issue Your Certificates

A Certification Authority Authorization (CAA) record is a DNS record that names the certificate authorities (CAs) allowed to issue TLS certificates for your domain. Public CAs must check it before issuing, and must refuse if they are not listed. CAA is defined in RFC 8659.

Why it matters

Any of the many publicly trusted CAs can technically issue a certificate for any domain, as long as the requester passes that CA’s domain validation. If one CA has a weaker validation process, or an attacker briefly controls a DNS record or web path on your domain, they could obtain a valid certificate from a CA you never use. That certificate would let them impersonate your site.

CAA narrows the field to the CAs you actually use. It does not stop a listed CA from making a mistake, and it is not checked by browsers, only by CAs at issuance time. It is a cheap extra layer that removes a whole class of mis-issuance.

What we check

We look up CAA records the way a certificate authority does: first for the scanned hostname, then, if there are none, for its parent, then the parent’s parent, stopping before the top-level domain. The first name that has CAA records is the one that applies.

No CAA record is reported as “needs attention”. We report which CAs your records name, but we do not judge whether they match the certificate you currently use. Check that yourself before publishing (see below).

This means a record on example.com also covers shop.example.com, unless shop.example.com has CAA records of its own, which then replace the parent’s.

How to fix

1. Find out which CAs you use

List every place that obtains certificates for your domain and its subdomains: your web server’s ACME client, your CDN, your load balancer, your email provider’s web front end, and any SaaS product on a custom subdomain. Check the issuer of each live certificate in the browser’s certificate viewer or with:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer

2. Publish CAA records for them

Each CA documents the identifier to use. Some common ones:

Example zone entries for a site that uses Let’s Encrypt and Google Trust Services:

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

• issue authorizes a CA to issue certificates for the name.
• issuewild controls wildcard certificates separately. ";" means no CA may issue wildcards. Leave it out if you need wildcard certificates; issue then covers them as well.
• iodef gives a contact for CAs to report requests that violated your policy. Not every CA uses it.
• The leading 0 is the flags field. Use 0 unless you have a specific reason not to.

Most DNS providers have a CAA record type in their dashboard with separate fields for flags, tag and value.

CDNs and managed certificates

If a CDN or platform issues certificates for you, its CAs must be in your records too, or its renewals will fail. Check its documentation for the identifiers it needs. Some providers, including Cloudflare, add the records for their own CAs automatically when you publish CAA records in their DNS; confirm in your provider’s documentation.

Optional: restrict further

RFC 8657 lets you pin a CA to a specific ACME account or validation method, for example:

example.com.  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456"

Support for these parameters varies between CAs, and pinning an account means a lost account key blocks renewals. Use it only if you manage your ACME accounts carefully.

Avoid breaking renewals

A CAA record that leaves out a CA you rely on will make that CA’s next renewal fail, and the current certificate will then expire. After publishing:

• trigger a test renewal where you can, for example certbot renew --dry-run;
• remember to add the new CA’s identifier first if you ever change CA or CDN;
• keep certificate expiry monitoring in place, so a failed renewal is noticed in time.

Last updated October 24, 2026