← Back to Blog
security

DNS CAA Records: How to Restrict Which CAs Can Issue Your SSL Certificate (2026)

Imagine someone walked into a locksmith with a copy of your address and asked for a key to your house. Now imagine that was possible with SSL certificates too — any Certificate Authority could, in theory, issue a certificate for your domain without your knowledge. For years, this was an accepted risk of the CA system. DNS CAA records close that gap: they let you explicitly declare, in DNS, which CAs are allowed to issue certificates for your domain — and every publicly trusted CA is contractually required to check for one before issuing anything.

🌐

DNS Lookup Tool

Look up your CAA records to verify they restrict certificate issuance correctly.

Try It Free →

What Is a CAA Record?

A CAA (Certification Authority Authorization) record is a DNS resource record, defined in RFC 8659, that specifies which Certificate Authorities are permitted to issue certificates for a domain. Since September 2017, the CA/Browser Forum's Baseline Requirements have made CAA checking mandatory for all publicly trusted CAs — a CA that ignores a CAA record and issues anyway is in violation of the Baseline Requirements and can face distrust action from browsers.

CAA is an authorization control, not an encryption or trust mechanism. It doesn't make your certificate more secure once issued — it reduces the risk of a certificate being issued to the wrong party in the first place, whether through CA error, a compromised account at an unintended CA, or a targeted attack.

CAA Record Syntax

A CAA record has three parts: a flag, a tag, and a value.

# Basic syntax example.com. CAA <flag> <tag> "<value>" # Real examples example.com. CAA 0 issue "letsencrypt.org" example.com. CAA 0 issue "digicert.com" example.com. CAA 0 issuewild "letsencrypt.org" example.com. CAA 0 iodef "mailto:security@example.com"
TagPurpose
issueAuthorizes a CA to issue standard (non-wildcard) certificates for this domain.
issuewildAuthorizes a CA to issue wildcard certificates. If absent, CAs fall back to the issue tag for wildcard requests too.
iodefAn email or URL where CAs should report policy violations (e.g. a rejected issuance attempt from an unauthorized CA).

How Do I Know If My CAA Records Are Set Up Correctly?

Query your domain's CAA records directly with dig, or use the DNS Lookup tool above for a quicker check without a terminal:

# Check CAA records with dig dig CAA example.com +short # Expected output if configured: 0 issue "letsencrypt.org" 0 issue "digicert.com" # No output at all means no CAA record exists — # in that case, ANY publicly trusted CA can issue for this domain.

An empty result is the most common "misconfiguration" — not because it's wrong technically (no CAA record means no restriction, which is valid per the RFC), but because it means you haven't actually restricted anything. If you only ever issue certificates through one CA, an empty CAA record leaves the door open to any other CA issuing a certificate for your domain by mistake or through a compromised account elsewhere.

CAA Values for Common CAs

Certificate AuthorityCAA Value
Let's Encryptletsencrypt.org
DigiCertdigicert.com
Sectigosectigo.com
GlobalSignglobalsign.com
Google Trust Servicespki.goog
Amazon (ACM)amazon.com, amazontrust.com, awstrust.com, amazonaws.com

Restricting to a Specific Account (CA-Specific Parameters)

Some CAs support account-level restriction within the CAA record itself, so even a compromised or misused account at your authorized CA can't issue for your domain unless the account ID also matches:

# Let's Encrypt account-binding example example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678" # Validation-method restriction (limit to DNS-01 challenge only) example.com. CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

Common CAA Mistakes

  • Forgetting issuewild: if you request a wildcard certificate but only have an issue record for a different CA than the one issuing, the CA falls back to checking issue — but if it's absent entirely and only issuewild exists for another CA, wildcard issuance from your intended CA will fail.
  • Typos in the CA domain value: letsencrypt.org spelled or capitalized incorrectly is treated as "not authorized," not "assume typo and allow" — issuance will simply fail.
  • Setting CAA on a CDN-fronted domain without confirming the CDN's CA: if a CDN (e.g., Cloudflare) manages a certificate on your behalf, you need CAA to authorize the CDN's actual issuing CA, not just your own, or their automated renewal will fail.
  • Not adding iodef: without it, you won't be notified when a CA rejects an unauthorized issuance attempt against your domain — you lose visibility into attempted misuse.
CAA records are checked at issuance time only, not on every TLS handshake. Adding or changing a CAA record does not affect certificates already issued — it only controls what can be issued going forward.

CAA and Certificate Transparency

CAA works alongside Certificate Transparency (CT) logs as a second layer of defense. CAA is preventive — it stops unauthorized CAs from issuing in the first place. CT is detective — it gives you a public, auditable record of every certificate that was issued for your domain, so you can catch a CAA policy failure or a compromised authorized CA after the fact. Use both: a CAA record with an iodef reporting address, plus periodic monitoring of CT logs for your domain (our Certificate Search tool queries CT logs directly).


Check your CAA records right now

Look up your domain's CAA (and other DNS) records instantly with our free DNS Lookup tool.