CAA Record Helper
Every public CA is required to check CAA before issuing. Publishing nothing means any of them may issue for you — this builds the records that change that.
What a CAA record actually does
A CAA record names the Certificate Authorities allowed to issue for your domain. Under the CA/Browser Forum baseline requirements every public CA must check it before issuing and refuse if it is not on the list — which makes it one of the few controls where a single DNS record genuinely stops a mis-issuance rather than merely recording one.
Publishing nothing means every CA in the world may issue for you. That is the default, and for most domains it is the only real gap left between an attacker who can pass a domain validation check and a certificate with your name on it.
How to use it
Enter the domain, tick the CAs you actually use, and copy the records out. Nothing is sent anywhere — the records are assembled in your browser as you type.
The three tags
- issue — CAs permitted to sign ordinary certificates. Listing one forbids all the others.
- issuewild — CAs permitted to sign wildcards. If you publish none, the
issuelist governs wildcards too; if you publish any, it takes over completely for wildcard requests. - iodef — where a CA should report an issuance it refused. Optional, and not every CA sends them.
What people get wrong
- Forgetting the CAs that issue on your behalf. This is the one that causes outages. A CDN terminating TLS, a load balancer with managed certificates, a mail or storage provider with its own hostname — each has its own CA, and each stops renewing the moment you publish a list that leaves it out. The failure surfaces weeks later, at renewal, not when you make the change.
- Expecting it to affect certificates that already exist. CAA is read at issuance and never again. Publishing a restrictive record does nothing to a certificate already in the wild — for that you need CT log search to find it and the CA to revoke it.
- Putting it on a name that is a CNAME. DNS does not allow other records alongside a CNAME, so the change will be refused. Put it on the registrable domain instead; it is inherited downwards.
- Assuming subdomains inherit unconditionally. They do — but only until a subdomain publishes a CAA set of its own, which then replaces the parent's entirely rather than adding to it.
Locking a domain down completely
For a parked domain, an internal-only name, or anything that should never have a public certificate, publish an empty issue set. Every compliant CA is then required to refuse, unconditionally. It is the strongest statement CAA can make and costs one record.