There is one DNS record that sits between your domain and every certificate authority on the internet, deciding which of them is allowed to issue a certificate for you. It is the CAA record, and the striking thing about it is how invisible it is. Most domains that have one set it a single time — often years ago, often by a tool or a hosting provider — and then never look at it again. It produces no padlock, no dashboard tile, no warning. And when it eventually causes an outage, the outage does not say "CAA." It says "certificate expired."
That gap between cause and symptom is the whole reason CAA deserves to be watched rather than set and forgotten.
What a CAA Record Actually Does
CAA — Certification Authority Authorization, defined in RFC 8659 — lets a domain publish, in DNS, the list of certificate authorities permitted to issue certificates for it. Before a public CA issues a certificate, it is required by the CA/Browser Forum baseline requirements to check your CAA record and refuse issuance if it is not on the list. It is a preventive control: it doesn't detect a bad certificate, it stops one from being issued in the first place.
A CAA record has three parts — a flags byte, a tag, and a value:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "digicert.com"
example.com. CAA 0 iodef "mailto:security@example.com"
-
issuenames a CA allowed to issue non-wildcard certificates. -
issuewildnames a CA allowed to issue wildcard certificates. Ifissuewildis absent, wildcard issuance falls back to theissueset (RFC 8659 §4.3) — so anissue-only record still governs your wildcards. -
iodefis a reporting address where a CA can tell you about a policy violation. Almost nobody sets it, and of those who do, almost nobody reads the mailbox.
The flags byte carries the issuer-critical bit (value 128). When it is set, a CA that doesn't understand the record's tag must refuse to issue rather than proceed — a fail-closed switch inside a fail-closed record.
The Inheritance Trap: The Failure Nobody Sees Coming
Here is the part that turns CAA from a checkbox into a genuine operational hazard. CAA inherits down the DNS tree. When a CA evaluates api.eu.example.com, it doesn't just look for a CAA record on that exact name — it walks up the tree per RFC 8659 §3: api.eu.example.com, then eu.example.com, then example.com, stopping at the first name that has any CAA record set. That record set governs issuance for the whole subtree beneath it.
So consider the common setup: someone, years ago, put issue "digicert.com" on the apex because that's who issued the corporate wildcard. Today a team spins up status.example.com and points it at a host that renews via Let's Encrypt. There is no CAA record on status.example.com, so the CA walks up, finds the apex issue "digicert.com", and — correctly, obediently — refuses to issue the Let's Encrypt certificate. Not because anything is broken. Because the policy says so, and the policy was written for a different CA by a person who has since left.
The first request works or fails depending on cache and timing, but the killer is renewal. An existing certificate keeps working until it expires. The automated renewal, weeks later, hits the CAA wall and fails silently in a cron log nobody reads. Then the certificate expires, the browser throws ERR_CERT_DATE_INVALID, and you begin debugging an "expired certificate" that is actually a CAA policy three labels up the tree, set by someone else, for a CA you no longer use.
"Missing" Is Not "Permits Any" — and a Lone Semicolon Is the Opposite
CAA has two edge cases that are easy to get backwards, and getting them backwards is how a checker lies to you.
No CAA record at all means every CA may issue. An absent record is maximally permissive — the default internet behavior. That is not the same as a record that permits everyone; it's the absence of a policy.
A record with an empty issue value — a lone ; — means the opposite: no CA may issue at all. Per RFC 8659 §4.2, issue ";" is a deliberate lockdown. A domain that sets it and then tries to get a certificate will be refused by every compliant CA, on purpose.
And there is a third state that a naive check collapses into one of the above: unknown. If the DNS lookup times out, or a validating resolver returns SERVFAIL on a broken DNSSEC chain, you didn't learn "permits any" — you learned nothing. Treating an unanswered query as "no policy, all CAs allowed" is exactly the misread that lets a real, restrictive policy hide behind a resolver hiccup. Present-and-permissive, present-and-locked-down, absent, and unknown are four different answers, and only three of them are safe to act on.
Why It Drifts
Even a correct CAA record doesn't stay correct on its own:
- A CA migration that updates the cert but not the record. You move from DigiCert to Let's Encrypt, reissue everything, and forget the CAA still names DigiCert — arming the inheritance trap above for the next subdomain.
- A record loosened "to make issuance work" during an incident and never tightened again, quietly widening who can mint certificates for you.
- A record added at a subdomain that shadows the apex policy for that branch — sometimes intended, sometimes a copy-paste that no longer matches.
- A registrar or DNS-provider migration that drops the CAA records entirely, silently returning you to "any CA may issue" with no signal that your issuance policy just evaporated.
None of these break the site today. Every one of them changes who can obtain a certificate for you, or whether your own renewals will succeed — and the only way to know is to be reading the policy, not the uptime.
How to Check It Yourself
The fast check is one dig:
dig CAA example.com +short
But because of inheritance, checking the exact name isn't enough — the record that governs status.example.com might live on example.com. Walk up the tree the way a CA does: query the name, and if it returns nothing, query its parent, and its parent, until you find the first name with a CAA RRset. Read the issue and issuewild sets and ask the real question: does this list include the CA that actually renews the certificate for this host? If it doesn't, that host's next renewal is already scheduled to fail.
How to Watch It
CAA is a preventive control whose failure mode is a future event — a renewal weeks out, an issuance you didn't authorize. That makes it a monitoring problem, not a one-time-audit problem:
- Evaluate the policy the way a CA does — walk the inheritance chain from the name upward, don't just look at the exact host — so you catch the apex record that silently governs a subdomain.
- Distinguish the four states — permissive, locked-down, absent, and unknown — and never let a resolver failure read as "all CAs allowed."
- Alert on the change, not just the state: a CAA set that was tight going loose, or a policy that dropped entirely, is a security regression that no uptime or SSL-expiry check will ever surface.
I work on Merlonix, which reads your domain's CAA policy on every check by walking the RFC 8659 §3 inheritance chain from the hostname upward, parsing the issue, issuewild, and iodef sets into a comparable policy, and — because a monitor must not cry wolf on a resolver hiccup — recording an authoritative reading only when the resolver actually answers, so it can alert specifically on CAA drift: a policy that loosened, tightened, or disappeared since the last check. It carefully separates "no record" (any CA may issue) from an empty issue set (no CA may issue) from an unresolved query, because those are three different answers.
You can check any domain's live CAA, DNSSEC, SSL, and DNS posture right now without signing up, and the free tools hub has the rest. CAA is the preventive half of certificate security: it decides who may issue. Its natural companion is Certificate Transparency monitoring — the detective half that tells you when a certificate was issued anyway — and both sit on the same DNS-security surface as DNSSEC, which fails closed when it breaks. Set correctly and left unwatched, a CAA record doesn't protect you; it waits, and the next renewal it blocks is the one you didn't know it governed.
