A CAA record (Certification Authority Authorization) is a type of entry among DNS records that lets a domain holder declare which certificate authorities are permitted to issue certificates for that domain. Before a publicly trusted authority signs a TLS certificate, it must look up the CAA records of the requested name and refuse issuance if it is not listed.
The record is defined in RFC 8659, which replaced the original RFC 6844, and checking it has been mandatory for publicly trusted authorities since September 2017 under the CA/Browser Forum Baseline Requirements. It does not encrypt anything and does not affect browsers directly; it is a preventive control on the issuance side that narrows the set of authorities able to mint a certificate for a name.
How a CAA record controls certificate issuance
A CAA record works as a policy statement read by the certificate authority, not by the client. When an authority receives an order for shop.example.com, it queries the CAA resource record set for that exact name. If none exists, it climbs toward the root one label at a time: example.com, then com. The first non-empty set found is the relevant one, and the search stops there.
If no CAA records exist anywhere along the path, any authority may issue, which is the default state of most domains. If a relevant set exists, the authority may issue only when its own identifying domain appears in a matching property. CNAME records are followed during the lookup, so a name delegated to a third-party service can inherit the CAA policy of the target.
Each record contains three fields: a flags byte, a property tag and a value. The following table summarizes the fields as they appear in a typical zone file entry such as example.com. 3600 IN CAA 0 issue "letsencrypt.org".
| Field | Typical content | Meaning |
|---|---|---|
| Flags | 0 or 128 | 128 sets the critical bit for unknown tags |
| Tag | issue, issuewild, iodef | Which policy the record expresses |
| Value | Authority domain or URL | Who is allowed, or where to report |
| TTL | 300 to 86400 seconds | How long resolvers cache the policy |
Property tags and their effect
The property tag decides what the record governs. Three tags are standardized in the base specification, and further tags have been added for account binding and validation methods in later documents.
| Tag | Purpose | Example value |
|---|---|---|
| issue | Authorizes any certificate type for the name | pki.goog |
| issuewild | Authorizes wildcard certificates only | sectigo.com |
| iodef | Reporting address for refused requests | mailto:security@example.com |
| issuemail | Authorizes S/MIME email certificates | Authority domain |
| accounturi parameter | Limits issuance to one account | Account URL at the authority |
| validationmethods parameter | Limits allowed validation methods | dns-01 |
When an issuewild set is present, it overrides issue for wildcard requests, so a domain can allow ordinary certificates from two authorities while permitting wildcards from only one. An empty value, written as issue ";", means no authority may issue for that name, which is a useful lock for domains that never serve HTTPS.
The critical flag (value 128) tells an authority that it must refuse issuance if it does not understand the tag. It is rarely needed today, and setting it on a tag that some authority does not recognize blocks issuance entirely from that authority.
CAA compared with related trust records
CAA is often confused with other mechanisms that also tie certificates to domains. The difference lies in who checks the data and when: CAA is evaluated once, at issuance, by the authority, while other mechanisms act at connection time or after the fact.
| Mechanism | Checked by | Moment of effect |
|---|---|---|
| CAA record | Certificate authority | Before issuance |
| TLSA record (DANE) | Connecting client | During each connection |
| Certificate transparency | Monitors and browsers | After issuance, through public logs |
| HTTPS record | Connecting client | Connection setup hints |
| TXT record | Authority, for DNS validation | During domain control validation |
In practice these controls complement each other. CAA reduces the number of authorities that could mistakenly issue, certificate transparency reveals any certificate that was issued anyway, and DNSSEC, through the DS and DNSKEY records, protects the CAA answer itself from forgery.
Configuring CAA records in practice
A sound CAA policy begins with an inventory of every authority in use, including those hidden inside hosting platforms, content delivery networks and email security gateways. Each one publishes the exact issuer domain name it checks, and a mismatch in spelling causes refused orders.
| Situation | Recommended records | Reason |
|---|---|---|
| Single automated authority | One issue record | Simplest, smallest attack surface |
| Primary plus backup authority | Two issue records | Allows fast switching during an outage |
| Wildcards from one vendor only | issue plus issuewild | Restricts the most powerful certificates |
| Parked or mail-only domain | issue “;” | Prevents any certificate issuance |
| Subdomain run by a partner | Separate set on the subdomain | Overrides the parent policy locally |
A TTL of about one hour is a practical balance: short enough to change authorities quickly, long enough to avoid excessive queries. Adding an iodef record gives the security team a signal when someone tries to obtain a certificate from an authority outside the policy.
Limitations and common mistakes
CAA is a control on honest authorities, not a cryptographic barrier. A compromised or careless authority can ignore it, and existing certificates remain valid after the record changes, because the check happens only at issuance. Authorities may also reuse a recent check for up to eight hours.
- Forgetting a platform authority, so automatic renewals silently fail weeks later.
- Placing records on the wrong name, for example only on
wwwwhile the apex stays open. - DNS servers that answer CAA queries with errors; a SERVFAIL can make authorities refuse issuance.
- Assuming CNAME targets are ignored, when in fact the target zone policy may apply.
- Omitting DNSSEC, which leaves the CAA answer open to spoofing on the path to the authority.
The simple explanation
Think of a CAA record as a guest list posted on the front door of a website’s address. Companies that issue security certificates must read the list before they hand out a certificate for that address. If their name is not on it, they must say no.
This does not make a website faster or encrypt its traffic. It simply reduces the number of companies that could ever be tricked into vouching for an address that does not belong to the requester.
How it is used in practice
A mid-sized online retailer obtains all of its certificates automatically from one authority, while its email security gateway uses a second vendor. The operations team publishes two issue records, one for each authority, an issuewild record that permits wildcards only from the automated authority, and an iodef address pointing to the security mailbox.
Three months later, an attacker who has compromised a developer account at a third authority tries to order a certificate for checkout.example.com. The authority performs its mandatory lookup, finds that it is not listed, refuses the order and sends a report to the iodef address. The security team learns of the attempt the same day, without any certificate ever being issued.