CAA Record Generator
Build CAA records to control which Certificate Authorities can issue TLS certificates for your domain — and stop unauthorized mis-issuance.
Your Domain
Records are published at the domain root (host @).
Quick Add Certificate Authority
Authorized Certificate Authorities
Options
Where a CA reports a certificate request that violated your policy. A bare address becomes a mailto: URI.
Your CAA Records
example.com. CAA 0 issue "letsencrypt.org"
How to add these records:
- Log in to your DNS provider (Cloudflare, Route 53, GoDaddy, etc.)
- Add a CAA record for each line above (host
@, flags0) - Most panels have separate fields for flags, tag, and value — the value is the part in quotes
- Save and wait for DNS propagation (typically 5-60 minutes)
Why publish a CAA record?
A CAA record(Certification Authority Authorization, RFC 8659) is a small DNS record that names exactly which Certificate Authorities are allowed to issue TLS/SSL certificates for your domain. The default state of the web is permissive: any of the dozens of publicly trusted CAs can issue a certificate for your domain if someone passes that CA's domain-validation check. CAA flips that to an allow-list, so only the CAs you actually use can mint certificates for you.
The mechanism is enforced at issuance, not in the browser. Since 2017 the CA/Browser Forum baseline requirements make CAA checking mandatory for every publicly trusted CA. When you request a certificate, the CA looks up your CAA record — walking up the DNS tree from the requested name to the registrable domain if no record exists at the exact name — and refuses to issue unless its own identifier is in the list. Browsers never read CAA during a TLS handshake, so a CAA record adds zero latency for visitors; it is purely a control on who can obtain a certificate.
Each record uses flags, a tag, and a value. The flags are almost always 0. The three tags are issue (authorize a CA for standard certificates),issuewild (authorize a CA specifically for wildcard certificates such as *.example.com, overriding issue for wildcards), and iodef(a contact URL, usually a mailto:, where a CA can report a request that violated your policy). The value is the CA's identifier domain — for exampleletsencrypt.org, digicert.com, or amazon.com for AWS Certificate Manager.
The benefit is defense in depth against mis-issuance. A misconfigured or compromised process at a CA you do not use cannot silently produce a valid certificate for your domain, because that CA is obliged to check your CAA record and back off. It is one of the lowest-effort security wins in DNS: a handful of records, no performance cost, and a meaningful reduction in your certificate attack surface.
The one real pitfall is over-restriction. CAA blocks issuance when it is wrong, so if you list onlyletsencrypt.org and later request a certificate from another CA — or from the CA behind your CDN or load balancer — issuance fails. Include every CA in your stack, add anissuewild entry (or matching issue) if you use wildcard certificates, and verify with the IntoDNS.ai scanner after publishing.
CAA record format
| Field | Example | Meaning |
|---|---|---|
| flags | 0 | Almost always 0. A value of 128 marks the property as critical (rarely needed). |
| issue | 0 issue "letsencrypt.org" | Authorize this CA to issue standard (non-wildcard) certificates. |
| issuewild | 0 issuewild "digicert.com" | Authorize this CA for wildcard certificates; overrides issue for wildcards. |
| iodef | 0 iodef "mailto:[email protected]" | Contact URL for a CA to report a policy-violating request. Not an authorization. |
| ";" | 0 issue ";" | An empty value (a single semicolon) forbids all issuance of that type. |
Full example: example.com. CAA 0 issue "letsencrypt.org"