CAA Records Explained What They Are and How to Set Them Up

If a rogue certificate authority issues an SSL certificate for your domain without your knowledge, your users could be silently intercepted by an attacker holding that fraudulent cert. CAA records exist specifically to stop that. They are a simple but powerful DNS record type that tells every compliant certificate authority which ones are allowed to issue certificates for your domain — and instructs all others to refuse. Since September 2017, every public CA is required by the CA/Browser Forum to check CAA records before issuing. That means setting up a CAA record is one of the fastest wins available in DNS-level security, and most domain owners have never touched one.

What a CAA Record Actually Does

A CAA (Certification Authority Authorization) record is a DNS record of type 257. It lives in your zone file alongside your A, MX, and CNAME records. When a CA like Let's Encrypt, DigiCert, or Sectigo wants to issue a certificate for yourdomain.com, it performs a DNS lookup for CAA records on that domain. If a CAA record exists and the CA's own domain name is not listed, it must refuse the request entirely. If no CAA records exist at all, any CA can issue — which is the default state for most domains on the internet today.

The protection is asymmetric: adding one record locks down issuance significantly, while adding none provides zero restriction. That asymmetry is why setting up CAA records is worth the fifteen minutes it takes.

The Structure of a CAA Record

A CAA record has three fields beyond the standard DNS name and TTL:

• Flag — An integer, almost always 0. Setting it to 128 marks the tag as critical, meaning a CA that does not understand the tag must refuse issuance. For most setups, keep this at 0.
• Tag — The property being defined. The three meaningful values are issue, issuewild, and iodef.
• Value — A quoted string, typically a CA domain name or a reporting URL.

The Three CAA Tags

Understanding what each tag does is essential before you write a single record:

• issue — Authorizes a CA to issue standard (non-wildcard) certificates. Example: 0 issue "letsencrypt.org" allows Let's Encrypt to issue a cert for yourdomain.com and www.yourdomain.com.
• issuewild — Authorizes a CA to issue wildcard certificates (*.yourdomain.com). This tag is evaluated separately from issue. If you have an issue record but no issuewild record, wildcards are blocked unless explicitly allowed.
• iodef — Stands for Incident Object Description Exchange Format. It gives CAs an address to report policy violations or failed issuance attempts. Accepts mailto: or https:// URLs. This is optional but highly recommended for visibility.

Which CA Domain Names to Use

Each certificate authority has its own CAA identity string. You must use the exact string they publish, not their brand name or website URL. Here are the most common ones:

• Let's Encrypt: letsencrypt.org
• DigiCert (including GeoTrust, Thawte, RapidSSL): digicert.com
• Sectigo (formerly Comodo): sectigo.com
• GlobalSign: globalsign.com
• Entrust: entrust.net
• Amazon Certificate Manager (ACM): amazon.com and also amazontrust.com
• Google Trust Services: pki.goog

When in doubt, check the CA's own documentation for their authoritative CAA domain. Some CAs operate under multiple domains, and you may need to add more than one issue record.

Step-by-Step: Setting Up CAA Records

The process differs slightly depending on your DNS provider, but the logic is identical everywhere: navigate to your zone, add a new record, select type CAA, fill in the three fields, and save.

Cloudflare

1. Log into the Cloudflare dashboard and select your domain.
2. Go to DNS > Records and click Add record.
3. Set Type to CAA.
4. Set Name to @ (for the root domain).
5. Set Flag to 0, Tag to issue, and CA domain name to your CA's string.
6. Leave TTL on Auto and click Save.
7. Repeat for issuewild and iodef as needed.

AWS Route 53

1. Open the Route 53 console and choose your hosted zone.
2. Click Create record.
3. Set Record name to blank (for root) or enter a subdomain.
4. Set Record type to CAA.
5. In the Value field, enter records in the format flag tag "value", one per line.
6. Set TTL to 3600 and click Create records.

cPanel / WHM (most shared hosting)

1. Log into cPanel and navigate to Zone Editor.
2. Click Manage next to your domain.
3. Click Add Record and choose CAA from the type dropdown.
4. Fill in Name (your domain), TTL (3600), Flag (0), Tag (issue), and Value (the CA domain).
5. Click Add Record to save.

Raw Zone File (BIND format)

If you manage your own authoritative nameserver, the records look like this:

If you use Let's Encrypt for standard certs but a different CA for wildcards (for example, DigiCert for a paid wildcard), you would write:

Blocking All Issuance Intentionally

There is a valid edge case: a domain that should never have a certificate issued at all — perhaps an internal-only zone or a parked domain. You can explicitly forbid all CAs by using an empty quoted string as the value:

Any CA that queries this record and finds an issue tag with an empty value must refuse issuance. This is cleaner than relying on the absence of a record.

How CAA Inheritance Works

CAA follows tree-climbing inheritance. If a CA looks up a CAA record for api.yourdomain.com and finds none, it climbs up to yourdomain.com and checks there. This means a single CAA record on the root domain covers all subdomains unless you override at the subdomain level. If you have a subdomain managed by a third party that uses a different CA, add a separate CAA record for that subdomain specifically.

This also means that setting a CAA record only on www.yourdomain.com does not protect yourdomain.com itself — you need to set it at the root.

How to Verify Your CAA Records

After adding your records, verify them with dig or nslookup. The dig command is the most reliable:

Expected output for a properly configured domain:

On Windows without dig installed, use PowerShell:

You can also use the DNS Lookup tool on this site — select CAA from the record type dropdown and enter your domain to see what any resolver around the world returns.

To simulate a CA's perspective and confirm the record is publicly visible, query against Google's public resolver:

Common Mistakes and How to Avoid Them

• Forgetting issuewild — Adding only an issue record blocks wildcards by default because there is no issuewild entry permitting them. If you use wildcard certs, add an issuewild record explicitly.
• Wrong CA domain string — Using letsencrypt.com instead of letsencrypt.org will cause issuance failures. Always copy the string from the CA's official CAA documentation.
• Only setting on www but not root — The root domain needs its own CAA record. Subdomains inherit from the root, but the root does not inherit from subdomains.
• Not updating after switching CAs — If you move from Sectigo to DigiCert, update your CAA records first, then request the new certificate. Requesting before updating will cause the new CA to refuse.
• Using flag 128 unnecessarily — The critical flag is for experimental or proprietary tags. Using it with standard tags causes problems with CAs that have strict parsers. Stick with flag 0.

What Happens When a CA Violates a CAA Record

Technically, a CA that ignores a CAA record and issues a certificate anyway is violating the CA/Browser Forum Baseline Requirements. That violation is grounds for browser vendors to distrust the CA entirely — a catastrophic outcome for the CA, which means compliant CAs take these records very seriously. In practice, all major browser-trusted CAs check CAA before issuance.

For additional assurance, enable Certificate Transparency monitoring. Services like crt.sh log every publicly issued certificate. You can search for your domain and set up alerts to catch any unexpected issuances even if a rogue CA somehow bypassed your CAA record.

Putting It All Together: A Recommended Baseline Setup

For a typical domain using Let's Encrypt for everything, this three-record setup is the recommended baseline:

For a domain using a paid CA for the primary cert and Let's Encrypt for automated subdomain certs:

Multiple issue records are perfectly valid — the CA just needs its own domain to appear in at least one of them. The TTL of 3600 (one hour) is appropriate for CAA records because they are security-sensitive; shorter TTLs increase query load without much benefit, and longer TTLs slow down your ability to respond if you need to make an emergency change.

CAA records take under fifteen minutes to configure and provide meaningful protection against misissuance for the lifetime of your domain. They belong in every domain's DNS setup alongside SPF, DKIM, and DMARC as a non-negotiable baseline for operational security.