How it works
CAA (RFC 8659) is a dedicated DNS record type. An entry like 0 issue "letsencrypt.org" allows only Let's Encrypt to issue; several issue entries allow several CAs. The issuewild tag controls wildcard certificates separately, and iodef names an address such as mailto:security@example.com where CAs can report rejected requests.
Since September 2017, public certificate authorities have been required to check CAA before every issuance. They search upward from the requested name: for shop.example.com they look there first, then at example.com, and the first record set they find applies. With no CAA record at all, any CA may issue.
Flag 128 marks an entry as critical, meaning a CA that doesn't understand its tag must refuse. Extensions like accounturi and validationmethods (RFC 8657) can further tie issuance to a specific ACME account or validation method, where the CA supports them.
Why it matters
Without a CAA record, any public CA can issue a certificate for your domain once someone passes domain validation, for example after a DNS takeover or through a dangling subdomain. CAA narrows the field to the providers you actually use.
The opposite mistake is more common: the record still allows only the old CA while the host or CDN has long since switched to another. The current certificate keeps working, but the next automatic renewal fails silently, and weeks later the site greets visitors with an expired certificate.
How to prevent it
- Find every CA that issues for the domain and its subdomains (host, CDN, mail provider), for instance via Certificate Transparency logs, and add an issue entry for each.
- Add a matching issuewild entry for wildcard certificates, or deliberately set issuewild ";" if no wildcards should be issued.
- Add an iodef entry pointing to an address someone actually reads.
- Before switching certificate providers or CDNs, extend the CAA record first and only then make the switch.
- Avoid unknown tags with flag 128, and only use extensions like accounturi if your CA supports them.
How DomainWarn detects it
The CAA check finds the effective CAA record set following RFC 8659, including parent names and wildcards, and compares it with the certificate authority of the current certificate on port 443; it knows around 30 CAs. If the record locks out the CA in use, DomainWarn opens a “CAA blocks the CA in use” incident after two runs, because the next renewal would fail. Unreadable records and unknown tags with the critical flag lead to “CAA record invalid”.
A missing CAA record, a record without issue or issuewild entries, and a missing iodef entry are notices. Added, changed and removed CAA records are reported as changes; the check runs once a day. New certificates from unfamiliar issuers are also surfaced by the Certificate issuance check.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.