CAA Records: The DNS Fix That Blocks Rogue Certificates
2026-10-13 · 8 min read · By the DomainGuard team
The short version
A CAA (Certification Authority Authorization) DNS record is a public declaration of which certificate authorities are allowed to issue TLS certificates for your domain. Certificate authorities have been required to check CAA before issuing since September 2017. If you publish no CAA record at all, any CA on earth may issue for your domain, and an attacker who finds a lax or compromised CA only needs one to say yes. Two or three lines of DNS close that hole. After the October 2026 registry-hijack certificate forgeries, Google's published guidance to domain owners named restrictive CAA records as one of the two essential defenses, alongside CT log monitoring.
What CAA records actually do
Think of CAA as an allowlist for certificate issuance, published in your DNS where every CA can see it. Before issuing, a compliant CA looks up your domain's CAA records. If the records say only letsencrypt.org may issue, and the request came through some other CA, issuance is refused. No record at all means no restriction, the CA proceeds as if you'd authorized everyone.
This matters because the CA ecosystem is large and uneven. There are dozens of publicly trusted CAs, and their validation rigor varies. An attacker doesn't need to fool your CA; they need to fool any CA. CAA shrinks the attack surface from "every CA on the planet" to "the one or two you actually use." It's not glamorous. It's a fence, and fences work.
The honest caveat, straight from October 2026: CAA is enforced by CAs checking your DNS. In the .gh/.sl/.as registry hijacks, the attackers controlled the authoritative DNS, they could have published permissive CAA records of their own. CAA stops CA-shopping, mis-issuance, and social-engineering-against-a-lax-CA. It does not stop an attacker who already controls your DNS or your registry. That's why it pairs with CT monitoring, CAA prevents most bad issuance, CT catches whatever happens anyway.
The records to publish
Replace example.com with your domain and letsencrypt.org with the CA you actually use:
example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 issuewild ";" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
Three records, three jobs:
- issue — which CAs may issue ordinary (non-wildcard) certificates. One record per authorized CA. This is the core allowlist.
- issuewild ";", forbids all wildcard issuance. The semicolon means "nobody." If you actually use wildcard certificates, put your CA's domain here instead of ";".
- iodef, an email address (or URL) where the CA must report issuance attempts it blocked because of your policy. This is free threat intelligence: a blocked-attempt report means someone tried to get a certificate for your domain through an unauthorized CA.
The tag zoo: every CAA tag worth knowing
CAA has a small vocabulary, and each tag does exactly one thing. The three above cover nearly every real deployment, but here's the full set from RFC 8659 plus the widely used extension:
- issue, authorizes a CA for non-wildcard certificates. Value is the CA's domain name (e.g. "letsencrypt.org"), optionally followed by ;key=value parameters.
- issuewild, authorizes a CA for wildcard certificates specifically. If no issuewild exists, the issue records govern wildcards too — which is why an explicit issuewild ";" is the safe default.
- iodef, "incident object description exchange format": where violation reports go. mailto: and https: values are both valid.
- contactemail, a newer tag some CAs honor for reaching the domain owner. Harmless to include alongside iodef.
- accounturi / validationmethods, parameters (not standalone tags) that bind issuance to a specific ACME account or specific validation methods. This is what Google meant by "CAA records with ACME account bindings" in its October 2026 guidance: even your authorized CA will only issue for your specific ACME account, so a hijacked validation at that CA for a different account still fails. If your CA supports it, use it.
Which value to use for your CA
The issue value is the CA's domain identifier, not a marketing name. The common ones:
Let's Encrypt "letsencrypt.org" DigiCert "digicert.com" Sectigo "sectigo.com" Amazon (ACM) "amazon.com" ZeroSSL "zerossl.com" SSL.com "ssl.com" GoDaddy "godaddy.com" GlobalSign "globalsign.com"
If you use more than one CA, say Let's Encrypt for most things and DigiCert for EV or a legacy system, publish one issue record per CA. When in doubt, check your CA's documentation for their exact CAA identifier; using the wrong string is the same as using none.
How to add them at your DNS provider
The steps are the same everywhere; only the UI labels differ:
Cloudflare: DNS → Records → Add record → type CAA. The dashboard gives you separate fields for tag and value, tag issue, value letsencrypt.org (no quotes needed in the UI; it adds them). Repeat for issuewild and iodef.
Route 53: hosted zone → Create record → record type CAA, then enter each as 0 issue "letsencrypt.org" format — flag, tag, and quoted value on one line.
Registrars (GoDaddy, Namecheap, Cloudflare Registrar, etc.): DNS management → add record → type CAA. Some older registrar DNS editors don't offer a CAA type at all, if yours doesn't, that's a genuine reason to move your DNS to a provider that does, because you can't publish the records otherwise.
After adding, wait out your TTL, then verify from any terminal:
$ dig CAA example.com +short 0 issue "letsencrypt.org" 0 issuewild ";" 0 iodef "mailto:security@example.com"
If dig returns nothing, the records haven't propagated or weren't saved correctly. DomainGuard's free report checks your CAA posture automatically, it's one of the fastest wins in the report because so many domains have nothing published at all.
Common mistakes we see
Blocking wildcards wrong. issue ";" blocks non-wildcard issuance only; a CA could still issue a wildcard unless issuewild is also restricted. The pair, issue naming your CA plus issuewild ";", is the correct lockdown for non-wildcard users.
Forgetting a CA you actually use. The classic outage: you publish CAA for Let's Encrypt, then your CDN provisions a certificate through DigiCert and issuance fails. Before publishing, inventory every certificate you hold — crt.sh with a %.yourdomain.com search shows the issuers you've actually used.
Publishing and never testing. CAA is one of the few DNS records where a typo causes a hard failure at renewal time, 60–90 days later, when nobody remembers the change. Verify with dig immediately, and re-verify after any CA change.
Assuming CAA covers subdomains automatically. CAA lookups walk up the DNS tree: a CA checking app.example.com looks for CAA at app.example.com, then example.com, then com. Records at your apex cover subdomains unless the subdomain has its own CAA set. Delegated subdomains with their own DNS need their own records.
Switching CAs: the migration checklist
Changing certificate authorities with CAA in place needs a sequence, not just a swap: add the new CA's issue value alongside the old one, verify propagation, complete the migration and confirm the new certificates are live, then, and only then, remove the old CA's record. Do it in the other order and your renewal fails in the gap. Keep the iodef record pointed at an inbox someone actually reads throughout; migration windows are exactly when you'd want to hear about blocked attempts.
What CAA can't do
Honest limits, all in one place: CAA doesn't stop issuance through a hijacked account at your own authorized CA (that's what ACME account bindings mitigate). It doesn't help if your DNS itself is compromised (the October 2026 lesson). It doesn't revoke anything already issued. And it's only as good as CA compliance, though non-compliance risks a CA's trusted status, which is a powerful incentive. One layer, properly placed, paired with CT monitoring so you see every certificate actually issued regardless.
FAQ
Will CAA break my existing certificates?
No. CAA is checked at issuance time only. Existing certificates keep working until they expire. The risk is at renewal: if your CAA doesn't authorize the CA doing the renewal, renewal fails. That's why you inventory issuers via crt.sh before publishing.
How long does it take to take effect?
As soon as the records propagate through DNS, typically minutes to a few hours depending on your TTL. CAs check CAA live at issuance, so there's no separate activation step.
Should subdomains have their own CAA records?
Only if they're delegated to separate DNS or managed by a different team with a different CA. Otherwise the apex records cover them via the tree-walking lookup. Document which case applies to each delegated subdomain so nobody guesses.
Is iodef reporting actually useful?
More than most people expect. A blocked-issuance report is one of the few signals that means "someone actively tried to get a certificate for your domain through an unauthorized CA." Volume is low and signal quality is high, route it to your security inbox, not a general alias.