AZ Tools

CAA Record Builder (DNS Certificate Authority Authorization)

Network

A CAA record (RFC 8659, formerly 6844) is a DNS TXT-style record that tells public certificate authorities which CAs are permitted to issue certificates for your domain. Every CA in the CA/Browser Forum Baseline Requirements must check CAA before issuing — if a CAA record exists and doesn't list them, they refuse. This is a small but powerful defense against rogue or misconfigured certificate issuance, and it's free. Three tags are defined: `issue` authorises a CA for regular certificates, `issuewild` authorises a CA for wildcard certificates (defaults to the same as `issue` if absent), and `iodef` gives a contact (mailto:/https:) for incident reports. Each record carries a flags byte; setting the critical bit (128) tells CAs to refuse if they don't understand any associated parameters. This tool builds the records and outputs them in two formats: full BIND zone-file syntax (paste into a master zone), and split tag/value rows (for control-panel UIs that ask for them separately). The common-CA list lets you add Let's Encrypt, DigiCert, Sectigo, Google, Amazon, and others with one click. Special value `;` means 'disallow all CAs' — a strong policy when you don't currently need to issue.

Records

Tag
Value
Tag
Value
Tag
Value

Add common CA (as issue record)

BIND zone format

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

Tag / value rows

For DNS control panels that ask for flags, tag, and value separately. Format: flags tag value

  0  issue      "letsencrypt.org"
  0  issuewild  "letsencrypt.org"
  0  iodef      "mailto:security@example.com"
About CAA records

CAA stands for Certificate Authority Authorization (RFC 8659). It's a DNS record that tells public CAs whether they may issue certificates for your domain. CAs must check CAA on every issuance and refuse when they're not listed. The tool emits two output formats: full BIND syntax with proper escaping for direct zone-file pasting, and a flags / tag / value table for control panels (Cloudflare, Route53, etc.). The special value `;` in an issue or issuewild record means 'disallow all CAs', which is a strong default if you're not currently using TLS. CAA is hierarchical: a record at the apex covers all subdomains unless a more specific CAA set exists below it. Records take up to 8 hours to fully propagate due to CA caching.

How to use

  1. Enter your apex or subdomain name (CAA records are checked from the leaf up; setting them on the apex usually covers everything).
  2. Click one of the common-CA buttons to add a starter `issue` record. Edit the tag, value, or critical flag as needed.
  3. Add an `issuewild` record if you intend to issue wildcard certs. If you don't, omit it — `issue` alone does NOT cover wildcards.
  4. Add an `iodef` record with a mailto: or https: address so CAs can notify you of policy violations.
  5. Paste the BIND output into your zone file (or use the row format if your DNS control panel asks for tag and value separately).

Frequently asked questions

Where do I host the CAA record?
On the same domain you want to protect. CAA lookup walks up from the requested name to the apex — a cert for `api.example.com` triggers lookups at `api.example.com`, then `example.com`, then root. Most people put one CAA set on the apex and let it cover all subdomains. Subdomain-specific CAA only matters if you want a different policy there.
Does `issue letsencrypt.org` block other CAs from issuing wildcards too?
Yes — if you have any `issue` records and no `issuewild` records, the `issue` records also restrict wildcards. But if you have any `issuewild` record at all, it overrides for wildcards. The safest pattern is to explicitly list both when you want both regular and wildcard issuance, or to add only `issue` if you never need wildcards. Adding `;` to `issuewild` while permitting regular certs is a common 'no wildcards from anyone' policy.
What does the critical flag do?
Bit 7 (value 128) is the issuer-critical flag. When set on an unknown tag, CAs must refuse to issue. Today only `issue`, `issuewild`, and `iodef` are defined, so critical mostly affects future-compatibility. Leave it off (flags = 0) for typical setups; only use 128 if you're deliberately specifying a tag you require all CAs to understand.
How quickly do CAs honour a new CAA record?
Per the Baseline Requirements, CAs check CAA at the moment of issuance, with a maximum lookup TTL of 8 hours from when they cached an earlier value. So a new record can take up to 8 hours to take full effect across all CAs. To prevent old cached negatives from blocking issuance, give your records a TTL of 5-60 minutes during initial setup and increase later.
Can DNSSEC affect CAA?
If your zone is DNSSEC-signed, CAs must verify the signatures and treat unsigned responses as missing. So a misconfigured DNSSEC can break CAA checking and stall cert renewals. Validate the zone with a tool like dnsviz.net before relying on CAA enforcement.

Related tools