What is a CAA record?
CAA (Certification Authority Authorization, RFC 8659) defines in DNS which certificate authorities (CAs) may issue certificates for a domain. Since September 2017 every publicly trusted CA must check the CAA record before issuing. If it is not listed, it has to reject the request. That makes it harder to obtain a certificate for someone else's domain from an arbitrary CA through weak validation.
Without a CAA record every CA may issue. That is the normal state of most domains and not an error; the checker reports it as a hint.
Structure of the record
A CAA record consists of flag, tag and value. A typical set for a domain that uses Let's Encrypt and Sectigo and needs no wildcard certificates:
- Flag: normally 0. 128 (critical) means a CA that does not know the tag must not issue.
- issue: a CA that may issue certificates for this name, one record per CA. issue ";" forbids any issuance.
- issuewild: applies only to wildcard certificates (*.example.com) and takes precedence over issue there. Without it, issue applies to wildcards as well. issuewild ";" forbids wildcards but still allows normal certificates.
- iodef: an address (mailto: or https://) where a CA can report rejected requests. Optional, and not every CA uses it.
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "sectigo.com"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef "mailto:security@example.com"From the host name upwards
A CA looks for the CAA set at the host name itself first, for example shop.example.com, then at example.com, then at com. The first name with CAA records applies, everything above it is irrelevant. A record at example.com therefore also covers every subdomain without a record of its own. If www.example.com is a CNAME to a hosting provider, a CAA record at the alias target counts; the climb, however, continues at example.com, not at the provider's domain. RFC 8659 removed climbing at the CNAME target from its predecessor RFC 6844, and the checker follows it.
Matching against the current certificate
A CAA record on its own says little. What matters is whether it allows the CA that actually issues. The checker reads the issuer from the certificate the server serves on port 443 and maps it to the CAA identifiers that CA accepts. Around 30 CAs are known, among them:
- Let's Encrypt: letsencrypt.org
- Sectigo and ZeroSSL (ZeroSSL issues through Sectigo): sectigo.com, formerly comodoca.com
- DigiCert including GeoTrust, Thawte and RapidSSL: digicert.com
- Google Trust Services: pki.goog
- Cloudflare: edge certificates come from Google Trust Services, Let's Encrypt, SSL.com or Sectigo depending on the zone, and Cloudflare may switch between them. If you set your own CAA records, allow all of the CAs Cloudflare uses.
- Wildcard certificate: if the certificate contains *.example.com, the checker tests issuewild at example.com, because that is what the renewal depends on.
- Additional names: if the certificate also covers www.example.com or other names of the domain, the checker tests their CAA set too. The renewal needs permission for every name.
- Unknown CA or a certificate that does not cover the name at all (the host's default certificate): no verdict instead of a false alarm.
Common mistakes
- CA changed, record forgotten: the record was set for one CA, later the hosting provider or CDN switches to another. The current certificate stays valid, the next renewal is refused and weeks later the certificate expires. The most common and most expensive CAA mistake.
- Wildcard forgotten: issuewild ";" or issuewild for another CA only, although the certificate contains *.example.com.
- Quotes: in a zone file the value belongs in quotes. Web interfaces often add them themselves; typing them in as well publishes a value no CA recognises.
- Critical flag with an unknown tag: a typo like "0 isue" is ignored, "128 isue" on the other hand forbids any issuance.
- Identifier of the wrong company: ZeroSSL expects sectigo.com, RapidSSL digicert.com. What counts is the CA that signs the certificate, not the reseller.
How to read the result
- No CAA record: hint, every CA may issue. It costs no points in the domain check.
- CAA allows the current CA: all good.
- CAA locks out the current CA: warning. The certificate stays valid, the next renewal will fail.
- Invalid record or unknown tag with the critical flag: warning. In the second case every CA refuses to issue.
- No issue tag, only issuewild or iodef: hint. Normal certificates are then unrestricted.
- No iodef: hint, purely optional.
Monitor CAA continuously
A CAA record does not go stale on its own, but its surroundings change: the host switches CA, a CDN is added, a subdomain gets its own certificate. DomainWarn matches the CAA policy daily for every customer domain and every host name with a certificate against the actual issuer and reports when the record locks out your own CA, before the renewal fails.
Frequently asked questions
- Do I need a CAA record?
- No. Without a record every CA may issue and everything works. A CAA record is an extra safeguard. If you set one, however, you have to update it with every change of CA, otherwise the renewal fails.
- Why does a wrong record only show weeks later?
- CAA is only checked at issuance. The current certificate has already been issued and stays valid until it expires. Automatic renewal usually starts a few weeks before; if the attempts fail silently, the certificate expires.
- Does the record apply to subdomains?
- Yes, as long as the subdomain has no CAA record of its own. If it has one, only that applies and the domain's record plays no role for it.
- How quickly does a change take effect?
- CAs query afresh for every issuance but may reuse a result for up to eight hours. On top of that comes the TTL of the old record in resolver caches. After a change, wait a few hours if in doubt before triggering issuance again.