TR
← Back to blogGuides

CAA Records Explained: Control Who Can Issue Your Certificates

What a CAA record is, how CAs evaluate it (tree climbing, CNAMEs, issue vs issuewild), ready-to-use examples, and how to add one without breaking renewals.

Published: · 6 min read

Any publicly trusted certificate authority can, technically, issue a certificate for any domain. The system relies on each CA validating domain control properly, and history has examples of that going wrong. A CAA record (Certification Authority Authorization) is your way to narrow the field: a DNS record that says "only these CAs may issue certificates for this domain". A CA that is not listed must refuse.

It costs nothing, takes five minutes, and has exactly one way of hurting you: forgetting it exists when you change CA. This guide covers both halves.

What CAA does and does not do

CAA is defined in RFC 8659 (which replaced the original RFC 6844), and since September 2017 the CA/Browser Forum's Baseline Requirements oblige every publicly trusted CA to check CAA before issuing.

  • It is checked by the CA, at issuance time. Browsers never look at it. A certificate that was issued while CAA allowed it stays valid if you change the record afterwards.
  • No CAA record means no restriction. Every CA may issue, as before.
  • It reduces the risk of mis-issuance through a CA you do not use, for instance by somebody who briefly controls a web server or a mailbox and tries a CA with a weaker validation method. It does not stop an attacker who controls your DNS, because they can change the CAA record too.
  • It is not a revocation mechanism and not a substitute for monitoring Certificate Transparency logs.

Anatomy of a CAA record

example.com.   3600   IN   CAA   0 issue "ca.example"
;                                │ │     └ value
;                                │ └ tag
;                                └ flags

Flags is 0 in practically all cases. The value 128 sets the "critical" bit, meaning a CA that does not understand the tag must not issue.

Tags:

Tag Meaning
issue The named CA may issue certificates for this name. Applies to wildcard certificates too, unless issuewild is present.
issuewild Rules for wildcard certificates only. If present, it replaces issue for wildcard requests.
iodef Where a CA may report a request that violated the policy (mailto: or https:). Support among CAs is limited; treat it as optional.
issuemail The same control for S/MIME certificates (RFC 9495).

Value for issue/issuewild is the identifying domain name that each CA documents, for example in its CAA or CPS page. It is not always the CA's brand name or website, and CAs that resell another CA's certificates use the upstream CA's identifier. Look it up; do not guess. The special value ";" means "nobody".

Examples

One CA, no wildcards, with a reporting address:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild ";"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Two CAs (say, your ACME CA and the one your CDN uses):

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issue "ca-two.example"

A domain that should never have certificates:

parked.example.  IN  CAA  0 issue ";"

Wildcards from a different CA than ordinary certificates:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild "ca-two.example"

How a CA finds the relevant record

This is the part people get wrong. For a certificate request covering www.shop.example.com, the CA:

  1. queries CAA at www.shop.example.com;
  2. if there is no CAA record set there, queries shop.example.com;
  3. then example.com, and so on up the tree;
  4. stops at the first name that has any CAA records and uses only those.

Consequences:

  • A record at example.com covers every subdomain that has no CAA of its own.
  • Records are not merged. A CAA at shop.example.com completely replaces the one at example.com for everything under shop. You can use this deliberately to give one subdomain a different CA.
  • CNAMEs are followed. If shop.example.com is a CNAME to stores.saas.example, the CAA query for shop.example.com is answered with the CAA records of the target. A SaaS provider's CAA policy can therefore apply to your hostname. Under the current RFC, the CA does not climb the target's tree; if the target has no CAA, climbing continues at your parent, example.com.
  • A lookup failure is not the same as "no record". If the CA cannot get a clean answer (timeout, SERVFAIL, broken DNSSEC), it must not issue. Flaky authoritative DNS shows up as failed renewals.

Each name in a multi-name certificate is checked separately.

Binding issuance to an account or method

RFC 8657 adds parameters that make CAA considerably stronger for ACME users:

example.com. IN CAA 0 issue "ca-one.example; accounturi=https://acme.ca-one.example/acct/12345"
example.com. IN CAA 0 issue "ca-one.example; validationmethods=dns-01"

accounturi restricts issuance to one ACME account, so that somebody else with an account at the same CA cannot obtain a certificate even if they pass validation. validationmethods restricts how control may be proven. Both only work with CAs that implement them; check the CA's documentation before relying on them, and remember to update the record if you ever recreate the ACME account.

Adding CAA without breaking anything: a checklist

  1. Find out who issues for you today. Inspect the certificates on every hostname, or search the Certificate Transparency logs for your domain. Typical surprises: the CDN, the load balancer's managed certificates, the hosted shop, the status page, the mail service, and an internal team using a different ACME CA.
  2. Collect the CAA identifier of each CA from its documentation.
  3. Check subdomains that are CNAMEs to third parties: query CAA on them and see what comes back.
  4. Publish the records at the zone apex with a moderate TTL (3600). CAs may cache the result of a CAA check for at most the record's TTL or 8 hours, whichever is greater.
  5. Test a renewal right away (certbot renew --dry-run does a full validation against the staging environment, which for most ACME CAs includes a CAA check) rather than finding out in 60 days.
  6. Document it where the next person will look when they switch CDN or CA.

Query what is published:

$ dig +short example.com CAA
0 issue "ca-one.example"
0 issuewild ";"
$ dig +short www.shop.example.com CAA      # empty → the CA will climb

Common mistakes

  • Switching CDN or hosting provider and forgetting that the new one uses a different CA. The new certificate silently fails to issue, and the old one runs out. See SSL certificate expired: what to do.
  • Using the CA's marketing name instead of its documented CAA identifier.
  • issuewild ";" while a wildcard certificate is in use somewhere.
  • Believing that issue at the apex and another issue at a subdomain add up. The subdomain's set wins alone.
  • A DNS provider that does not support the CAA type, where people try to store it as TXT. That does nothing.
  • Quoting errors in control panels: the value is a quoted string, the flag and tag are not.
  • Expecting CAA to invalidate existing certificates. It only affects new issuance.
  • Moving nameservers and not copying the CAA records; they are among the records most often lost, as noted in changing nameservers without downtime.

Check it with OrbitProbe

The OrbitProbe DNS lookup includes CAA among the record types it queries, with the TTL, as public resolvers return it at that moment. Run it on the bare domain first, then on any subdomain that is a CNAME to an external service, to see which policy a CA would actually find there. For the wider picture of how CAA sits next to the other record types, see DNS record types explained.