What a CAA record does, and how to add one

7 October 2026 · Alex

Any public certificate authority can, in principle, issue a certificate for your domain. Not just the one you use — any of them. If a CA can be persuaded that you control the name, it can produce a certificate that browsers will trust.

That is the design. It is also the risk: you are exposed not only to your own CA's diligence, but to every CA's. Mis-issuance has happened often enough to end several of them.

A CAA record is how you narrow that down, and it costs one line.

What it does

CAA — Certification Authority Authorization, RFC 8659 — lists which CAs are allowed to issue for your domain:

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

That says: only Let's Encrypt may issue certificates for this name. Any other CA that follows the rules will check, find itself excluded, and refuse.

The important part is the obligation. Since 2017 the CA/Browser Forum's Baseline Requirements have made the check mandatory — a CA must query CAA immediately before issuing and must honour what it finds. This is not advisory. A CA ignoring CAA is violating the requirements it is audited against.

What it does not do

Be clear about the boundary, because CAA is sometimes oversold:

• It does not stop a CA that is actively malicious or compromised. It is a rule, not an enforcement mechanism. A CA that ignores it is breaking its obligations, which is a matter for its auditors and the browser root programmes.
• It does not affect certificates already issued. Adding CAA today does nothing about a certificate someone obtained last year.
• It is checked at issuance only. Browsers never look at CAA. There is no runtime protection.

What it does is remove the easy path. An attacker who can pass one CA's validation is blocked if that CA is not on your list — and they cannot edit your list without already controlling your DNS.

The three tags

issue — who may issue ordinary certificates.

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

issuewild — who may issue wildcard certificates. Worth setting separately: a wildcard is a far more valuable thing to obtain improperly, and many domains never need one.

example.com.  IN  CAA  0 issuewild ";"

A lone semicolon means nobody. If you do not use wildcards, saying so explicitly closes a door.

iodef — where to report an attempted violation.

example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Not every CA sends these, but the ones that do give you a genuinely early warning that somebody tried.

How the lookup walks up

CAA is checked at the exact name first, then up the tree towards the apex — the first name with any CAA record wins, and the walk stops there.

This matters more than it sounds. A CAA record at the apex covers every subdomain that has none of its own. But a subdomain with any CAA record overrides the apex completely — including for tags it does not mention. Set issue on a subdomain and forget issuewild, and the apex's wildcard restriction no longer applies there.

If you set records at more than one level, set the full set at each.

How to add one without breaking renewals

The failure mode is specific and avoidable: you list one CA, and something else in your estate quietly renews through another. The next renewal fails, and the certificate expires while nobody is watching.

1. Find every issuer you actually use. Not just the obvious one — check your CDN, your load balancer, your managed hosting and your mail provider. Several issue certificates on your behalf through their own CA.
2. List them all. Multiple issue tags are fine and are the normal case.
3. Check your CA's required value. These are identifiers the CA publishes, not domain names you can guess: letsencrypt.org, digicert.com, sectigo.com, pki.goog, amazon.com, globalsign.com. Getting it wrong blocks the CA you meant to allow.
4. Set issuewild ";" if you do not use wildcards.
5. Verify before your next renewal, not after:

dig +short CAA example.com

If a renewal fails after you add CAA, the CA's error usually names the problem directly — it will say CAA prohibits issuance. That message is the answer, not a mystery.

Is it worth it?

For one record, yes. It is among the cheapest security measures in DNS: no performance cost, no ongoing maintenance beyond remembering it when you change CA, and it removes an entire category of mis-issuance from your exposure.

The one discipline it demands: when you change certificate provider, change the CAA record first. Otherwise you will discover it at the worst moment, which is a renewal you were not watching.

KumoDNS supports CAA on Business and Enterprise plans — see record types by plan.