Skip to content
AdminKit
Live Updated

CAA record generator: how do you build a DNS CAA record?

How does this check work, and what does the result tell you?

AdminKit's CAA record generator builds the exact zone-file CAA lines for the certificate authorities you authorize, any wildcard-specific authorization, the critical flag, and an iodef reporting address — entirely in your browser, with nothing sent to any server. You still need to publish the result in your DNS before it restricts anything, then confirm it with AdminKit's DNS lookup.

Part of the DNS cluster — more tools, guides and terms on dns.

The zone owner name these records are published under.

RFC 8659 §5.3: tells a CA that doesn't understand a property below to refuse issuance rather than ignore it.

Comma-separated CA domains allowed to issue any certificate, e.g. letsencrypt.org, pki.goog. Use ";" to disallow issuance entirely.

Comma-separated CA domains allowed to issue wildcard certificates. Leave blank to fall back to issue above.

Comma-separated mailto: or https: destinations for CAA violation reports.

  • Domain is required.
  • Enter at least one issue, issuewild or iodef value.

What the result means

This is the zone-file text built from the CAs, wildcard CAs and reporting address you entered — it says nothing about what your domain currently publishes, and building it does not restrict anything by itself. To see what is actually live in DNS today, run AdminKit's DNS lookup.

Next step

Publish the lines above as CAA records at the domain they name, then confirm they took effect with AdminKit's live DNS lookup once DNS has propagated.

Keep this result

Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.

Get alerted — early access

How it works and limits

Fill in the domain, the certificate authorities you want to authorize, any wildcard-specific authorization and a violation-report address below, and this tool assembles the exact CAA zone-file lines as you type, entirely in your browser — nothing you enter is sent to AdminKit or anywhere else. Building the lines changes nothing by itself: publish them as CAA records in your own DNS, then confirm they took effect with AdminKit’s live DNS lookup, which queries DNS for real and reports back what it actually found.

What does a CAA record actually restrict?

A CAA record, defined in RFC 8659 (the current standard, obsoleting the earlier RFC 6844), names which certificate authorities are allowed to issue a publicly trusted TLS certificate for a domain. The CA/Browser Forum’s TLS Baseline Requirements oblige every publicly trusted CA to check a domain’s CAA records before issuing — so a domain with no CAA record at all leaves the door open to any CA that passes its own validation, while a domain that publishes one narrows that down to the CAs actually named. Publishing a record is what restricts issuance; this tool only builds the text, and CAA never replaces the CA’s own domain validation — it is an additional, independent control, not a substitute for one.

The properties this tool builds

IANA’s CAA property tag registry defines several tags; this tool covers the three in everyday use:

  • issue — authorizes a CA, by its own domain name, to issue any certificate (including non-wildcard) for this domain. Enter ; instead of a domain to disallow issuance entirely.
  • issuewild — authorizes a CA to issue wildcard certificates specifically. RFC 8659 §4.2 falls back to issue for wildcard requests whenever no issuewild property is published, so leaving this blank is a deliberate choice, not an oversight.
  • iodef — a mailto: or https: destination a CA can send a report to when it declines to issue because of this record, or detects a policy violation. It arranges reporting; it authorizes no one by itself.

Every record also carries a flags byte: 0 normally, or 128 when the critical bit is set. RFC 8659 §5.3 requires a CA that doesn’t recognize a critical property to refuse issuance outright rather than ignore it — useful once you are certain every CA you use supports the properties here, risky before that.

Limits

  • This tool only builds the record text. It never queries DNS and never publishes anything — you still have to add the records to your own DNS and confirm them with a live check.
  • It validates the values you enter (domain syntax, the ; deny-all shorthand, and the mailto:/https: scheme on iodef), but it cannot see what your domain’s authoritative servers actually answer once published — for that, use AdminKit’s live DNS lookup.
  • It does not check DNSSEC status. CAA on its own doesn’t stop an attacker who can forge unsigned DNS responses from hiding a CAA record from a CA’s resolver; DNSSEC closes that separate gap.

Reference: CAA record for the plain-language definition this tool builds from. Once your CAA records are live, AdminKit’s SSL/TLS certificate check confirms what a browser actually sees on the certificate CAA was meant to help control.

Frequently asked questions

Does this tool send anything to AdminKit's servers?

No — every field you fill in is read directly by your browser, and the zone-file lines are built there with plain JavaScript. Nothing you type is sent to AdminKit or anywhere else. That also means it cannot check what your domain currently publishes; for that, use AdminKit's live DNS lookup, which does query DNS.

I built the lines here — does that already restrict who can issue a certificate?

No. This tool only builds the text of the record. Nothing changes until you publish it yourself as a CAA record in your DNS provider's control panel, then confirm it actually resolved correctly with AdminKit's DNS lookup, which queries DNS for real.

What does the critical flag actually do?

RFC 8659 §5.3 says a certificate authority that does not recognize a property marked critical (flags byte 128 instead of 0) must refuse to issue rather than silently ignore it. That is stricter, not safer by default — only set it once every CA you actually use is confirmed to understand the properties in the record.

What happens if I set issue but leave issuewild blank?

RFC 8659 §4.2 has wildcard certificate requests fall back to the issue property whenever no issuewild property exists, so authorized CAs can still issue wildcards unless you add an explicit, possibly different, issuewild list.

Does a CAA record replace the certificate authority's own domain validation?

No — CAA only narrows which CA is allowed to attempt issuance at all. The CA you did authorize still has to complete its own domain control validation before it issues anything; CAA is a second, independent control, not a substitute for the first one.