CAA Records Explained: Control Who Can Issue Your Certificates

Short answer: A CAA (Certification Authority Authorization) record is a DNS record that lists which certificate authorities are allowed to issue SSL/TLS certificates for your domain. Since 2017, every publicly trusted CA must check CAA before issuing, and must refuse if it is not listed. Adding a record such as example.com. CAA 0 issue "letsencrypt.org" reduces the risk of certificates being issued by the wrong authority. Before adding it, list every CA your website, CDN, mail and third-party services use, or renewals will start failing.

Most website owners never think about which certificate authorities can issue certificates for their domain. By default, any of the many publicly trusted CAs may do so, as long as the requester passes domain validation. CAA records let you narrow that list to the one or two authorities you actually use. It is a small, cheap control that makes mis-issuance harder – but, like any allow-list, it can also block legitimate renewals if you forget someone. This guide explains how CAA works and how to add it safely.

Why CAA exists

Certificate authorities validate that a requester controls a domain before issuing a certificate. That validation can occasionally be fooled or bypassed – through a compromised account at a CA, a DNS or routing attack, a mistake in a CA’s process, or an attacker who gains temporary control of a web server. With many CAs trusted by browsers, the weakest one determines the overall risk for your domain.

CAA reduces that surface. When a CA receives a request for your domain, it looks up your CAA records. If the CA is not listed, it must refuse, even if domain validation would succeed. The mechanism is defined in RFC 8659, and checking it is mandatory under the baseline requirements that all public CAs follow.

CAA is checked only at issuance. It does not affect certificates that already exist, and browsers do not look at it when visitors connect.

The record format

A CAA record has three parts: a flag (usually 0), a tag and a value.

Values are the CA’s domain identifier, published in each CA’s documentation – for example letsencrypt.org for Let’s Encrypt. Commercial CAs and resellers often issue under a parent brand, so check which identifier your provider tells you to use.

Special cases:

• 0 issue ";" means no CA may issue normal certificates.
• If issuewild is absent, the issue records also govern wildcards.
• Records on a subdomain override those on the parent domain for that subdomain. If a subdomain has no CAA records, the CA climbs the DNS tree and uses the parent’s.

How to add CAA records safely

Step 1: Inventory the CAs you use

This is the step that prevents outages. Collect the issuer of every certificate across your domain and subdomains:

• Your web hosting or control panel (often Let’s Encrypt, sometimes another free ACME CA or a commercial one).
• Your CDN or proxy, which may issue edge certificates from one or several CAs and may change between them.
• Mail services, helpdesks, landing page builders, shop platforms and other services that host custom domains or subdomains for you.
• Any commercial certificates you purchased directly.

Look at the issuer in each current certificate, check certificate transparency logs for certificates issued for your domain in the last year, and read the documentation of services that issue certificates on your behalf – many publish the exact CAA values they need.

Step 2: Create the records

A typical small business setup using Let’s Encrypt through the host and a CDN that uses two other CAs might look like this:

example.com.  CAA 0 issue "letsencrypt.org"
example.com.  CAA 0 issue "pki.goog"
example.com.  CAA 0 issue "digicert.com"
example.com.  CAA 0 iodef "mailto:[email protected]"

Treat this as an illustration only; use the values your providers specify. Most DNS providers have a CAA record type in their dashboard with separate fields for flag, tag and value. If you use wildcards, add issuewild records for the CAs that issue them, or rely on issue if the same CAs handle both.

Step 3: Handle subdomains delegated to others

If a subdomain such as help.example.com points to a vendor via CNAME, CAs follow the CNAME when looking up CAA. The vendor’s own domain may then determine which CAs are allowed, or your parent-domain records may apply – the exact behaviour depends on the setup. When a vendor-hosted subdomain uses a CA not listed in your records, renewal on that subdomain fails. The fix is either adding that CA to your records or setting specific CAA records for the subdomain.

Step 4: Test and monitor

1. Check the records with dig example.com CAA +short or an online DNS lookup tool.
2. Test issuance with each provider if possible – for example a staging or dry-run renewal – or wait for the next renewal and watch it closely.
3. Monitor certificate expiry on every hostname for the first few renewal cycles. A CAA mistake shows up as a failed renewal, often weeks after you added the record.

What a blocked renewal looks like

When a CA refuses to issue because of CAA, the error appears in the renewal log or the provider’s dashboard, not on your website – at least not until the old certificate expires. Typical messages mention “CAA record prevents issuance” or “CAA check failed” and name the domain involved. With Certbot, the output of certbot renew or certbot renew --dry-run shows it clearly. Hosting panels usually display a failed renewal notice, and CDNs mark the certificate as pending or failed in their SSL settings.

The fix is straightforward: add the CA’s identifier to your records, wait for the DNS change to propagate (CAs may cache records for up to the record’s time to live), and trigger the renewal again. The important thing is noticing the failure while the old certificate still has weeks of validity left, which is why expiry monitoring and CAA belong together.

Common mistakes and how to avoid them

• Forgetting the CDN’s CAs. CDNs may use several authorities and switch between them for resilience. Add all the ones they document.
• Using the wrong identifier. A reseller’s brand name is not always the CA’s CAA identifier.
• Restricting wildcards unintentionally. An issuewild ";" record blocks wildcard renewals you may rely on.
• Adding CAA during an urgent certificate problem. Change one thing at a time; add CAA when certificates are healthy.
• Not telling the team. The next person who switches hosting or CDN needs to know CAA exists, or their first renewal will fail mysteriously.

Is CAA worth it for a small business?

CAA is not the first thing to fix – a valid certificate, automatic renewal, HTTPS redirects and security headers matter more for most sites. But once those basics are in place, CAA is a quick additional layer, especially for businesses whose domain is used for customer logins, payments or e-mail that customers trust. The main cost is maintenance: whenever you add a provider that issues certificates for your domain, update the record. If you are not confident you know every issuer, start with a record that includes all providers you find and review it after a few renewal cycles.

How CAA fits with other DNS protections

CAA is one of several DNS-based controls that strengthen a domain. DNSSEC protects DNS answers themselves from being forged, which makes CAA lookups harder to manipulate. A registrar lock and two-factor authentication on the registrar and DNS accounts prevent attackers from changing your records in the first place – including removing your CAA restrictions. On the e-mail side, SPF, DKIM and DMARC records protect your domain name from being abused in forged messages. None of these depends on the others, but together they make it considerably harder to impersonate your domain, whether on the web or in inboxes.

How Site AI Audit helps

Site AI Audit checks the certificate your visitors actually receive – validity, expiry and the HTTPS redirect – together with security headers and e-mail authentication records for your domain. Monitoring on paid plans alerts you when a certificate is close to expiry, which is exactly how a renewal blocked by a CAA mistake becomes visible in time. See the plans.

Related reading

• SSL Certificate Monitoring: How to Never Miss an Expiry Again
• Wildcard vs Multi-Domain (SAN) SSL: Which Should You Choose?
• Free vs Paid SSL Certificates: Which Does Your Site Need?

The bottom line

CAA records let you decide which certificate authorities may issue certificates for your domain, and every public CA must respect them. They are easy to add and reduce the risk of mis-issued certificates. The only real danger is forgetting a legitimate issuer, so inventory every CA used by your host, CDN and third-party services first, test renewals, and keep the record up to date whenever providers change.

FAQ

Do browsers check CAA records?

No. CAA is checked by certificate authorities at the moment of issuance. Browsers only verify the certificate itself when visitors connect.

What happens if I have no CAA record?

Any publicly trusted certificate authority may issue certificates for your domain after successful domain validation. This is the default for most domains and is not an error.

Can a CAA record break my website?

Not immediately, because existing certificates keep working. It can cause the next renewal to fail if the issuing CA is not listed, which becomes an outage when the current certificate expires.

Do I need separate CAA records for subdomains?

Not usually. Subdomains inherit the parent’s records unless they have their own. Add subdomain-specific records only when a subdomain uses a different CA from the rest of the domain.

What is the iodef tag for?

It gives certificate authorities an address, usually e-mail, where they may report refused certificate requests. Support for sending such reports varies, so treat it as optional.