CAA Records Explained — Control Which CAs Can Issue Your Certificates

One month from today, on September 8th, a quiet but significant rule takes effect across the entire certificate industry: every certificate authority in the world must check your domain's CAA records before issuing a certificate for it, and must refuse to issue if the records don't permit them to. The requirement comes from ballot 187 of the CA/Browser Forum — the body whose baseline requirements every publicly-trusted CA has to follow — passed earlier this year.

That turns CAA from an obscure, voluntarily-honored DNS record into something with real teeth. It's one of the cheapest security wins available for a domain you care about — a few DNS records, ten minutes of work — and also one of the easiest things to get subtly wrong if a service issues certificates on your behalf without you thinking of it that way. Here's the whole picture.

What a CAA record is

CAA — Certification Authority Authorization, defined in RFC 6844 back in 2013 — is a DNS record type that answers one question: which certificate authorities are allowed to issue certificates for this domain?

Today, any of the dozens of publicly-trusted CAs on Earth can issue a certificate for your domain, provided someone passes that CA's validation checks. Your relationship with your chosen CA doesn't restrict the others in any way. That's a wide attack surface: a validation weakness at any CA — one you've never heard of, in a country you've never been to — can be used against your domain.

A CAA record narrows that surface to the CAs you actually use. It's an allowlist, published in DNS, and from September 8th checking it stops being optional politeness and becomes a hard requirement of issuance.

The syntax — issue, issuewild, iodef

A CAA record has three parts: a flags byte, a tag, and a value. In practice you'll use three tags. A realistic zone looks like this:

example.com.    IN CAA 0 issue "letsencrypt.org"
example.com.    IN CAA 0 issue "digicert.com"
example.com.    IN CAA 0 issuewild ";"
example.com.    IN CAA 0 iodef "mailto:security@example.com"

Reading it line by line:

• issue names a CA permitted to issue certificates for this domain. Multiple issue records mean "any of these." The value is the CA's designated domain string — check your CA's documentation for the exact one, since it isn't always guessable.
• issuewild controls wildcard certificates separately. The special value ";" means "nobody" — the example above allows normal certificates from two CAs but forbids wildcards entirely. If you omit issuewild, the issue records govern wildcards too.
• iodef gives CAs a place to report violations — a mailto: or https: URL. If someone requests a certificate your records forbid, a CA can tell you about it. It's a free tripwire; set it.
• The leading 0 is the flags byte. 128 marks a record critical — meaning a CA that doesn't understand the tag must refuse to issue. For the standard tags above, 0 is what you want.

One more rule worth knowing: CAA lookups climb the tree. When a CA checks shop.example.com, it looks for CAA records there first, and if none exist it walks up to example.com and beyond. Records at your apex therefore cover every subdomain that doesn't override them — one set of records protects the whole domain.

What CAA protects against — and what it doesn't

Worth being precise about, because CAA is often oversold or undersold:

• It protects against mis-issuance through rule-following CAs. An attacker who can trick or pressure some CA's validation process — but who doesn't control your DNS — now hits a wall: the CA is required to check CAA and refuse. That's the realistic bulk of mis-issuance risk, and CAA addresses it directly.
• It doesn't stop a compromised or rogue CA. A CA willing to ignore the rules will ignore your DNS records too. (It will, however, be violating an auditable requirement — which is how CAs end up distrusted.)
• It doesn't affect existing certificates. CAA is checked at issuance time only. Adding records today doesn't invalidate anything already issued, by anyone.
• Browsers never check it. CAA is an agreement between you and the CAs, enforced at issuance — your visitors' browsers are not involved and see nothing.
• It's only as strong as your DNS. An attacker who controls your DNS can simply change your CAA records before requesting a certificate. CAA raises the bar; it doesn't replace securing your DNS provider account (and DNSSEC, if you're ready for it, hardens this further).

Rolling it out without breaking issuance

The one real risk of CAA is self-inflicted: publish records that forget a legitimate issuer, and a future renewal quietly fails. The rollout order matters:

1. Inventory who issues for you. Your main CA is easy. The subtle ones are services that obtain certificates on your behalf: CDNs that terminate TLS for your domain, load balancers with managed certificates, your hosting platform's one-click SSL. Each of those has a CA behind it, and that CA needs to be in your issue list. (We've written before about how much invisible machinery sits in front of your site — this is another place it surfaces.)
2. Check your DNS provider supports the record type. CAA is still new enough that some providers can't publish it yet. If yours can't, you're not worse off than today — no CAA record means "any CA may issue," exactly as before. Nothing breaks on September 8th for domains without records; the mandate only changes behavior for domains that have them.
3. Publish, then verify from outside:

dig CAA example.com +short

4. Add iodef so attempted violations reach a mailbox someone reads.
5. Watch your next renewal. The first renewal after publishing CAA is the moment a forgotten issuer shows up — better to catch it with weeks of certificate lifetime left than with hours.

Ten minutes now, or a mystery outage later

CAA is that rare security measure with almost no downside: free, invisible to visitors, and from next month, enforced industry-wide. The only failure mode is forgetting about it — publishing records, changing CDN or CA two years later, and wondering why renewal fails at the worst possible moment.

That failure mode is exactly what monitoring is for. CompleteStatus watches your SSL certificates from the outside and alerts you well before expiry — so a renewal that silently failed against your CAA policy becomes an email weeks ahead of time, not a browser warning your customers find first. It's the same shared-infrastructure vigilance we preached after Cloudbleed, applied to your certificates. Create a free account, add your domains, and then go spend the ten minutes publishing your CAA records — September 8th is coming either way.