What is a CAA record, and how do you add one?

Published September 30, 2026 · about a 6-minute read

A scan flagged "no CAA record" and you're wondering whether it's worth five minutes of your time. Short version: yes, because it's a five-minute change that closes a real gap in how certificates get issued — and unlike some DNS security features, a correct CAA record can't take your site down. There's one gotcha that can bite you, though, so let's do it properly.

The gap it closes

Here's a fact that surprises people: by default, any trusted public certificate authority will issue a TLS certificate for your domain to whoever passes its validation checks. Dozens of CAs, any of them, for your domain. Normally that's fine — the validation is what stops abuse. But CAs are human systems, validation has been fooled before, and a single mis-issued certificate for your domain lets someone impersonate you with a padlock that looks perfectly valid.

A CAA — Certification Authority Authorization — record is how you say "only these CAs are allowed to issue for me." Since 2017, public CAs are required to check it before issuing. List Let's Encrypt, and a request to some other CA for your domain gets refused at issuance time. You've turned "any CA on Earth" into a short allowlist you control.

Certificate Transparency logs tell you after a rogue certificate has been issued. A CAA record stops it from being issued in the first place. Prevention beats a postmortem.

What it looks like

A CAA record is three parts: <flags> <tag> <value>. The tags you'll actually use:

The 0 is the flags field (128 marks a tag "critical"). The iodef line is worth adding — it's a free tripwire that emails you if someone tries to get a cert through a CA you didn't authorize.

How to add one

1. Open your DNS provider or registrar's dashboard and add a new record of type CAA.
2. Set flags 0, tag issue, value your CA's domain in quotes, e.g. "letsencrypt.org".
3. If you use wildcard certs, add a second record with tag issuewild.
4. Optionally add an iodef record pointing at an email you monitor.
5. Save and give it time to propagate.

Most dashboards give you separate fields for flags, tag and value so you don't hand-format the string.

The one gotcha that actually matters

This is the part that turns a safe change into a 2am incident: you have to list every CA you actually use — including the ones you don't realize you use. If you're behind Cloudflare, AWS, Fastly, or a managed host, they issue certificates on your behalf through specific CAs. Add a CAA record that names only Let's Encrypt, and the next time your CDN tries to renew through its own CA, the CAA check refuses it — and a cert quietly fails to renew.

So before you save: figure out who issues every certificate on your domain (your own ACME client, your CDN, your host, any subdomain services) and list all of them. When in doubt, check your providers' docs for the exact CAA values they require. Get this right and CAA is set-and-forget; get it wrong and you'll find out at renewal time — which is exactly the kind of silent, delayed failure that certificate monitoring exists to catch.

Keep it honest: what CAA doesn't do

CAA isn't a force field. It won't stop a CA on your allowlist from being compromised, it doesn't retroactively invalidate certificates already issued, and it's a lower-severity item than, say, a missing security header or an expired cert. It sits in the same "cheap, sensible, do it if it's easy" bucket as DNSSEC — with the nice difference that a correct CAA record has no downside. Add it, get the free tripwire, move on.

See whether your domain has one — and what else your DNS is missing — with our free site checker. It reports your CAA, DNSSEC, SPF and DMARC records alongside your TLS and headers, no signup.