CAA records: the DNS line that decides who can issue your SSL certificate

Most domains have no CAA record. That means any certificate authority trusted by default in browsers and operating systems, and there are well over a hundred roots in those trust stores, is permitted to issue a valid SSL certificate for your domain to anyone who can convince that CA they control it.

That is the default. Nothing is misconfigured, nothing throws a warning, and your padlock looks exactly the same. A CAA record is the one DNS line that narrows the list from "any CA" to "the CAs you actually use." It takes about two minutes to add and it is the kind of record that either sits there doing quiet work for years or breaks a renewal at 4am, depending on how carefully you write it.

What a CAA record actually does

CAA stands for Certification Authority Authorization. The record is a public statement in your DNS zone naming which certificate authorities may issue certificates for your domain.

Before a CA issues a certificate, it queries your DNS for CAA records on the name being certified. If it finds a record set and its own identifier is not in it, it must refuse to issue. This is not a suggestion. The CA/Browser Forum baseline requirements have mandated the check since September 2017, so every publicly trusted CA performs it. The record format is specified in RFC 8659.

Two things CAA does not do, both worth being clear about:

It is not checked by browsers. CAA is enforced at issuance time, by the CA. A visitor's browser never looks at it. If a certificate already exists, a CAA record added afterward does not invalidate it.

It is not a replacement for anything. CAA does not encrypt, does not affect your TLS configuration, and does not fix a cert that browsers already reject. It closes a different gap: mis-issuance. Historical incidents where a CA issued certificates for domains it should never have touched are exactly the scenario CAA was designed to make harder.

Reading the record

A CAA record has three parts after the name and type:

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

The flag (0 above) is a byte where only one bit currently matters: the critical flag, value 128. With 0, a CA that does not understand the tag ignores the record. With 128, a CA that does not understand the tag must refuse to issue. Use 0 unless you have a specific reason not to.

The tag is the instruction. Three are in common use:

• issue authorizes a CA to issue standard certificates for this name.
• issuewild authorizes a CA to issue wildcard certificates (*.example.com).
• iodef gives a contact address for reporting attempted violations.

The value is the CA's identifier domain, in quotes. Not their marketing domain, their documented CAA identifier. Let's Encrypt is letsencrypt.org. Google Trust Services is pki.goog. Look yours up rather than guessing.

One special value does a lot of work: a semicolon on its own forbids all issuance.

example.com.  IN  CAA  0 issue ";"

That is the right record for a parked domain, an internal-only hostname, or anything that should never have a public certificate. It is a deny-by-default posture for a name nobody is watching.

Writing one for your setup

Start by listing every system that gets a certificate for your domain. Not just the obvious one. Your web host, your CDN, your load balancer, your email hostname, your status page, and any managed platform that terminates TLS all obtain certificates, often from different CAs and often without telling you which.

A typical zone using Let's Encrypt for the site and a second CA for a managed service looks like this:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issue "pki.goog"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Multiple issue tags are additive. Each one adds a permitted CA. If you want wildcards restricted separately, add issuewild explicitly, and note the ordering rule that catches people: if any issuewild tag is present, wildcard requests are governed by issuewild alone and the issue tags are ignored for those requests. Omit issuewild entirely and your issue tags cover wildcards too.

You can go tighter. RFC 8657 defines parameters that bind issuance to a specific ACME account and validation method:

example.com.  IN  CAA  0 issue "letsencrypt.org; validationmethods=dns-01"

That says Let's Encrypt may issue, but only via DNS-01 validation. An attacker who briefly controls your web root cannot get a certificate through HTTP-01. Add accounturi= to pin issuance to one ACME account and the restriction gets tighter still. Support varies by CA, so verify before relying on it.

If your DNS provider's panel has no CAA record type, you are not stuck. The record can be published in the generic format from RFC 3597 as TYPE257 with a hex-encoded value, which many older panels accept. Moving to a provider with native CAA support is the better long-term answer.

The renewal failure a wrong record causes

Here is how CAA goes wrong in practice, and it is almost never at the moment you add the record.

A CA checks CAA on the exact name in the request. If that name has no CAA record set, the CA walks up the parent domains until it finds one. So a record on example.com governs shop.example.com and mail.example.com unless those names publish their own. That inheritance is the feature, and it is also the trap. The record you wrote in March for your main site quietly governs the subdomain a different team stands up in October, on a different platform, with a different CA.

Nothing fails at that moment either, because the existing certificates are already issued. It fails 60 or 90 days later when something tries to renew, gets refused by its CA, and the first symptom your visitors see is a browser interstitial on an expired certificate.

Three rules that prevent it:

1. Inventory before you write. Every TLS-terminating system, every subdomain, every CA. A record that reflects only what you remember will break what you forgot.
2. Add, then watch a full renewal cycle. Adding a CA to your record takes effect on the next issuance request. Removing one has no visible effect until a renewal attempt fails, which can be months out.
3. Treat CAA as part of any platform migration. Changing hosts, adding a CDN, or moving email hostnames can change which CA needs authorization. Update the record during the cutover, not after the outage.

Keep a modest TTL on these records as well. CAs may reuse a CAA check result for up to eight hours, so a correction is not always instant.

Checking what you have

The check is quick and the answer is usually either "nothing" or "something written a long time ago for a stack that has since changed." AcuityScan's DNS lookup tool returns your CAA records alongside the rest of your zone, queried against 20 global DNS resolvers so you see what CAs see rather than what your local cache remembers. Pair it with the SSL check to confirm which CA actually issued the certificate you are serving today, since that is the identifier your record has to contain.

For the wider view, the free scan at acuityscan.com runs 350+ checks across 8 modules, and the DNS health module reports CAA status next to nameserver redundancy, DNSSEC, and TTL problems. Certificate mis-issuance is a low-probability event with a high ceiling on damage, and this is a one-line, one-time defense against it.

TL;DR

• With no CAA record, any publicly trusted CA may issue certificates for your domain.
• Format: 0 issue "letsencrypt.org". Use flag 0, the CA's documented identifier, and one record per CA.
• 0 issue ";" blocks all issuance. Correct for parked and internal-only names.
• CAA inherits down to subdomains that have no record of their own, which is the usual source of surprise renewal failures.
• Inventory every TLS-terminating system first, then add the record, then watch one renewal cycle.
• Check yours with the DNS lookup tool, and confirm your current issuer with the SSL check.