What are CAA records, and how do they limit who can issue your TLS certificates?

Why CAA records exist

Before CAA records, any publicly trusted certificate authority could issue a TLS certificate for any domain, as long as the requester passed that CA’s own domain-validation check — usually proving control of a DNS record, an email address at the domain, or a file on the web server. That design means a domain owner has no direct say in which CAs are allowed to issue for their name; the only constraint is each CA’s own validation process, and different CAs have historically had different levels of rigor and different track records of mistakes or compromises. RFC 8659 closes that gap by letting a domain publish, in its own DNS, an explicit allow-list of CAs. The CA/Browser Forum’s Baseline Requirements — the rules publicly trusted CAs must follow to stay trusted by browsers — make checking CAA records mandatory before issuance, not optional best practice. That mandate is what gives CAA its teeth: it isn’t a suggestion a CA can ignore, it’s a condition of being in the trusted root program at all.

What a CAA record actually looks like

A CAA record has three parts: a flag, a tag, and a value. The two tags that matter for most domains are issue (which CA may issue standard certificates) and issuewild (which CA may issue wildcard certificates, checked separately so a domain can allow wildcards from a different, or no, CA). A typical record authorizing Let’s Encrypt looks like:

example.com.  CAA  0 issue "letsencrypt.org"

A domain can publish multiple issue records to permit more than one CA, or publish 0 issue ";" to explicitly permit no CA to issue at all — a deliberate “this domain should never get a new publicly trusted certificate” statement, sometimes used on domains that are parked or intentionally never served over public TLS. There’s also an iodef tag that names a URL or email address a CA should notify if it receives (and refuses) an unauthorized issuance request — a built-in early-warning signal most domains never configure, even though it costs nothing to set up.

What CAA does and doesn’t protect against

CAA closes one specific gap: it stops a different, unauthorized CA from issuing a valid certificate for your domain, whether because an attacker tricked that CA’s domain-validation process, exploited a bug in it, or because that CA’s own infrastructure was compromised. It’s a narrow but real risk — publicly documented CA mis-issuance incidents are the reason this record type exists at all, including cases where an attacker used BGP hijacking to reroute traffic and pass a CA’s domain-validation check well enough to obtain a fraudulent certificate.

What it does not do: protect against your own authorized CA being compromised, protect against someone who already controls your DNS (they can simply rewrite or delete the CAA record before requesting a certificate, as covered in our DNS hijacking guide), or validate anything about the certificate after it’s issued. CAA is purely a pre-issuance gate checked by CAs, not a runtime check performed by browsers or clients connecting to your server. If you want to verify what a currently-issued certificate for your domain actually contains — issuer, expiry, chain validity — that’s a separate check, covered in our guide on reading a TLS/SSL certificate check result.

How to check and set up CAA records

1. Check what’s currently published. Use AdminKit’s DNS lookup tool to query your domain’s CAA records. Many domains have none at all, which is valid (any CA may issue) but means you’re not using this protection.
2. Confirm it matches every CA you actually use. If you use more than one CA — for example a paid EV certificate from one provider and Let’s Encrypt for internal services — list both. Missing one is the single most common cause of a failed renewal.
3. Don’t forget issuewild if you use wildcard certificates. A CAA record with only issue set does not implicitly authorize wildcard issuance for a CA that checks the issuewild tag separately.
4. Set a realistic TTL. Like any DNS record, a CAA change takes effect only after cached copies expire; see our guide on DNS propagation and TTL if you’re planning a CA migration and need the old record gone before the new CA’s next issuance attempt.
5. Consider iodef if your DNS provider supports it, so you get notified of any issuance attempt your CAA record blocks — a free tripwire for exactly the attack CAA exists to stop.

Related checks

CAA controls who is allowed to issue a certificate; it says nothing about whether a specific certificate your server presents today is valid, expiring soon, or chained correctly. Run AdminKit’s SSL/TLS certificate check to verify the live certificate itself, and see reading a TLS/SSL certificate check result for how to interpret it. If a CA does mis-issue despite CAA, Certificate Transparency logs are how that becomes visible after the fact, and HSTS preload separately protects a first-ever connection from being downgraded to plain HTTP in the first place.