BRev CAA record — certificate authority authorization
A CAA record is an instruction to certificate authorities: only these CAs may issue certificates for this domain. Since September 2017 the CA/Browser Forum has required every publicly trusted CA to check CAA before issuance and to refuse if it is not listed — which makes this one of the few DNS records that another organisation is contractually obliged to obey.
Checking walks up the tree. For shop.example.com a CA looks at shop.example.com, then example.com, then com, and uses the first CAA record set it finds. So a CAA at the apex governs every subdomain unless a subdomain publishes its own — and no CAA record anywhere means no restriction, which is the default state of most domains.
The three tags: issue authorises a CA for normal certificates, issuewild specifically for wildcards (and if only issue is present, wildcards are governed by it), and iodef gives a contact URL for reports of refused issuance. A value of ";" means “no CA may issue”, which is the correct setting for a domain that should never have a certificate at all.
What a CAA record looks like
Type 257 · Which CAs may issue certificates. Zone-file form below — owner name, TTL, then the record and its RDATA.
| Name | TTL | Record | What it means |
|---|---|---|---|
| example.com. | 3600 | CAA 0 issue "letsencrypt.org" | Only Let’s Encrypt may issue. Covers subdomains too, unless one publishes its own CAA set. |
| example.com. | 3600 | CAA 0 issuewild ";" | No CA may issue a wildcard — useful when you deliberately want only named hosts. |
| example.com. | 3600 | CAA 0 iodef "mailto:security@example.com" | Where a CA should report a refused or suspicious issuance request. |
| legacy.example.com. | 3600 | CAA 0 issue "digicert.com" | A subdomain overriding the apex policy — the CA stops walking at the first set it finds. |
The mistakes that break production
Certificate renewal starts failing after a CAA change
The CA you use is no longer authorised. It is easy to add a CAA for your primary provider and forget a second one used by a CDN, a load balancer or a mail platform — each of those issues its own certificates. List every CA that issues for you, including managed ones, before publishing.
Assuming CAA stops mis-issuance completely
It is a check the CA performs, not a cryptographic control. A CA that ignores the requirement, or an attacker who can alter your DNS, is not stopped by it. Pair CAA with DNSSEC (so the record cannot be forged in transit) and Certificate Transparency monitoring (so you see anything issued regardless).
Query a CAA record now
The box below is seeded with example.com. Choose CAA as the type and press Look up — the query goes from your browser straight to Cloudflare or Google over DNS-over-HTTPS, with no server of ours in the path.
DNS is the internet's address book: it turns a name like example.com into the addresses and service endpoints machines actually connect to. Every record has a type (what kind of fact it states) and a TTL (how long resolvers may cache it).
Record types
| Type | What it stores |
|---|---|
| A | IPv4 address |
| AAAA | IPv6 address |
| CNAME | Canonical name (alias) |
| MX | Mail exchanger (priority target) |
| TXT | Text — SPF, verifications, DKIM, arbitrary data |
| NS | Authoritative nameservers |
| SOA | Start of authority (serial, refresh, retry, expire, minimum) |
| SRV | Service locator (priority weight port target) |
| CAA | Which CAs may issue certificates |
| PTR | Reverse DNS (IP → name) |
| DNSKEY | DNSSEC public key |
| DS | Delegation signer (DNSSEC chain of trust) |
| HTTPS | HTTPS service binding (ALPN, ECH, hints) |
| SVCB | General service binding |
| TLSA | DANE — pin certificates in DNS |
| NAPTR | Name authority pointer (SIP/ENUM) |
TTL & “propagation”
DNS changes don't “push” anywhere — resolvers simply keep the old answer until its TTL runs out, then fetch the new one. So a change “propagates” in at most the old record's TTL. Planning a change? Lower the TTL (e.g. to 300s) a day in advance, make the change, then raise it back. The compare card above shows whether major public caches have picked your change up yet.
FAQ
Do I need a CAA record?
Not required — no record means any CA may issue. It is a cheap, high-value restriction: it stops an attacker who tricks a different CA into issuing for your domain, and it costs one record.
Does a CAA record on my domain cover subdomains?
Yes. The CA walks up from the name being issued and uses the first CAA set it finds, so an apex record governs everything below it unless a subdomain publishes its own.
How do I allow wildcards?
issue alone permits wildcards from that CA. Publishing issuewild lets you control them separately — issuewild ";" forbids wildcards entirely while normal certificates still issue.