# CAA record

A CAA (certification authority authorisation) record lists the certificate authorities allowed to issue TLS certificates for your domain. Every public CA must check it before issuing, so a CAA record stops anyone getting a certificate for your domain from a CA you don't use. With no CAA record, any CA may issue.

- Record type: CAA
- Type number: 257
- Used for: Certificates and keys
- How common: Common
- Defined in: RFC 8659, RFC 8657

## Format

```
<name> <ttl> IN CAA <flags> <tag> "<value>"
```

| Field | What it means | Accepted values |
| --- | --- | --- |
| Flags | 128 marks the record critical: a CA that doesn't understand the tag must refuse. | `0` (usual) or `128`. |
| Tag | What the record controls. | `issue` (any certificate), `issuewild` (wildcards), `iodef` (where to report refused requests), and the newer `issuemail`, `issuevmc`, `contactemail`, `contactphone`. |
| Value | For issue and issuewild: the CA's identifying domain, optionally with parameters. `;` alone means no CA. For iodef: a mailto: or https: address. | `"letsencrypt.org"`, `"pki.goog"`, `"digicert.com; cansignhttpexchanges=yes"`, `";"`, `"mailto:security@example.com"`. |

## Examples

### Let's Encrypt only

```
@ 3600 IN CAA 0 issue "letsencrypt.org"
```

Only Let's Encrypt may issue for example.com and every subdomain.

### Two CAs, no wildcards

```
@ 3600 IN CAA 0 issue "letsencrypt.org"
@ 3600 IN CAA 0 issue "pki.goog"
@ 3600 IN CAA 0 issuewild ";"
```

Let's Encrypt or Google Trust Services, and no wildcard certificates from anyone.

### Locked to one ACME account

```
@ 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456"
```

Only your own Let's Encrypt account can get certificates.

### Reports

```
@ 3600 IN CAA 0 iodef "mailto:security@example.com"
```

CAs that support it email you when they refuse a request.

## How CAs read CAA

To issue for shop.example.com, a CA looks for CAA at shop.example.com, then example.com, then com, stopping at the first name that has any CAA records. So a CAA at the root covers every subdomain unless a subdomain has its own. CAA is checked at issuance only: adding it never affects certificates that already exist.

If you use a CDN or hosting platform that gets certificates for you, include its CA. Cloudflare, for example, uses Let's Encrypt, Google Trust Services and others, and adds the CAA records it needs on domains it manages.

## TTL

3600. CAs cache CAA for at most 8 hours.

## Common mistakes

- Adding CAA for one CA while your host renews certificates with another, so the next renewal fails.
- Writing the CA's company name ("Let's Encrypt") instead of its CAA domain (letsencrypt.org).
- Adding issuewild ";" while you still use a wildcard certificate.
- Putting CAA on a name that is a CNAME. CAs follow the CNAME and read the target's CAA.

## At your DNS host

- Cloudflare: separate fields for flags, tag (shown as plain-English choices) and value.
- Route 53: one value: 0 issue "letsencrypt.org".
- GoDaddy, Namecheap and Porkbun all offer CAA in the type menu.

## Questions

### Do I need a CAA record?

No, but it's a cheap protection: it limits which CAs could be tricked into issuing a certificate for your domain. Add one listing the CAs your hosts use.

### What is the CAA value for Let's Encrypt?

letsencrypt.org. Google Trust Services is pki.goog, DigiCert is digicert.com, Sectigo is sectigo.com, and Amazon is amazon.com.

### Does CAA affect existing certificates?

No. It's only checked when a certificate is issued or renewed.

## Related

- [TLSA record](https://lemon.domains/dns-records/tlsa.md)
- [HTTPS record](https://lemon.domains/dns-records/https.md)
- [TXT record](https://lemon.domains/dns-records/txt.md)
- [BIMI record](https://lemon.domains/dns-records/bimi.md)

Interactive version with a record checker and live lookup: https://lemon.domains/dns-records/caa