CAA Certification Authority Authorization Flagship

What it's for

A CAA (Certification Authority Authorization) record specifies which certificate authorities (CAs) are permitted to issue TLS/SSL certificates for a domain. Before CAA existed, any trusted CA on the internet could technically issue a certificate for your domain — CAA closes that gap by letting you explicitly whitelist the CAs you actually use.

Since September 2017, CAA checking has been mandatory for all publicly trusted CAs (a CA/Browser Forum baseline requirement), so this isn't just a "nice to have" hardening step anymore — it's an active control that CAs are required to honor before issuing a cert.

Format & syntax

example.com.    3600    IN    CAA    0 issue "letsencrypt.org"
example.com.    3600    IN    CAA    0 issuewild "digicert.com"
example.com.    3600    IN    CAA    0 iodef "mailto:[email protected]"

• Flags — an integer, currently only 0 (no flag) or 128 (critical — the CA must not issue if it doesn't understand this record) are meaningful.
• Tag — the type of authorization:
  • issue — authorizes issuing regular (non-wildcard) certificates
  • issuewild — authorizes issuing wildcard certificates specifically (if absent, issue governs wildcards too)
  • iodef — a URL (often a mailto:) where CAs should report policy violations, like an unauthorized issuance attempt
• Value — the CA's domain (for issue/issuewild) or a URL (for iodef), in quotes

A domain can have multiple CAA records to authorize more than one CA. If a domain has no CAA record at all, the old behavior applies — any CA can issue for it.

How it's used in practice

• Locking down cert issuance to your actual CA(s) — if you exclusively use Let's Encrypt, a CAA record naming only letsencrypt.org means even if an attacker somehow tricks or compromises validation at a different CA, that CA is required to refuse issuance for your domain.
• Restricting wildcard issuance separately — using issuewild to allow wildcard certs from a more tightly controlled CA/process than regular single-domain certs, since wildcard certs are a bigger blast radius if compromised.
• Monitoring for issuance attempts — the iodef tag gives you visibility into unauthorized issuance attempts, since compliant CAs will notify the address you specify if a disallowed request comes in.
• CT (Certificate Transparency) integration — CAA can specify accepted CT policies alongside the issue/issuewild tags in more advanced configurations, though for most domains a simple issue record covering your CA(s) is sufficient.

Common mistakes & gotchas

• Adding CAA that blocks your actual CA — the most common self-inflicted outage: you set a CAA record naming one CA, then later switch certificate providers (say, from your host's built-in Let's Encrypt integration to a paid CA) and forget to update the CAA record — new certificate issuance silently fails with no obvious DNS-level error message to the person requesting the cert.
• Missing issuewild when you need wildcard certs — if you only have an issue tag and no issuewild, that's fine (issue covers both) — but if you add an issuewild record at all, it exclusively governs wildcards from then on, so make sure it lists every CA you use for wildcard certs specifically.
• Forgetting CAA exists during a CA migration — teams that set up CAA once and forget about it are the most common victims of this; treat CAA as something to check off any "switching certificate providers" checklist.
• Assuming CAA replaces TLS validation — CAA only controls who is allowed to issue, it doesn't replace domain validation (proving you control the domain) which the CA still has to perform through its normal process (HTTP, DNS, or email validation).
• Case sensitivity and exact matching — the CA domain in the value field needs to exactly match what the CA expects (check their documentation) — a typo here silently blocks issuance rather than throwing an obvious error.

Comparison & FAQ

Do I need a CAA record if I use a single certificate authority?

It's optional but recommended — without one, any publicly trusted CA can technically issue a certificate for your domain. A CAA record naming your actual CA closes that gap and is considered a baseline hardening step.

What happens if I switch certificate authorities but don't update my CAA record?

New certificate issuance from the new CA will fail, since CAA checking is mandatory for all publicly trusted CAs — they're required to refuse issuance if your CAA record doesn't authorize them, even if every other part of the validation process succeeds.

What's the difference between issue and issuewild?

issue authorizes regular, single-domain (or specific subdomain) certificates. issuewild specifically governs wildcard certificates (*.example.com); if it's absent, the issue tag's authorization covers wildcards too, but once you add an issuewild tag, it becomes the sole authority for wildcard issuance.

Does having no CAA record mean my domain is unprotected?

It means the pre-CAA default applies — any publicly trusted CA can issue a certificate for it, which was standard behavior for the entire history of TLS before CAA existed. It's not itself a vulnerability, but adding a CAA record narrows that trust to only the CA(s) you actually use.