Inputs
Example
example.com -> issue letsencrypt.org; issuewild ; iodef mailto:hostmaster@example.com; validationmethods dns-01.
Check and generate CAA issue, issuewild, iodef, ACME account bindings, validation methods, and issuemail tags.
Use it before changing certificate-authority authorization policy for a domain.
example.com -> issue letsencrypt.org; issuewild ; iodef mailto:hostmaster@example.com; validationmethods dns-01.
Any publicly trusted certificate authority can, in principle, issue a certificate for your domain — unless you say otherwise. CAA is where you say otherwise: a DNS record the CA must check at issuance time, naming the authorities you authorize. It is the control that turns a mis-issuance from an open possibility into a policy violation with an audit trail, and it is the control that catches the well-meaning colleague ordering a certificate from a vendor your PKI strategy retired two years ago.
The record's grammar is small but exact. The issue tag authorizes a CA for host certificates, issuewild separately governs wildcards, and iodef names a reporting address for policy violations. RFC 8657 adds sharper pins for ACME: accounturi restricts issuance to one specific ACME account, and validationmethods restricts which challenge types are acceptable. This tool validates existing records — pasted or fetched live — and drafts a conservative policy when none exists yet.
For an audit, run the live lookup and read issue and issuewild first: they carry the actual authorization. Remember the lookup semantics — a CA starts at the requested name, follows aliases as required, and climbs parent by parent until it finds the first relevant CAA RRset. A CAA RRset on a child name therefore applies to that exact name and descendant names that do not publish a closer RRset; it does not universally replace the apex policy. An empty issuer value denies issuance.
When drafting, authorize exactly the CAs you use, and check the operational path before you publish: your certificate automation must still succeed after the record goes live, and adding a CA must become a documented step of any future vendor change — CAA-caused renewal failures surface weeks later, at the worst possible moment, as expired certificates. If you operate ACME at scale, accounturi is the strongest cheap upgrade, because a stolen domain validation no longer suffices without your account key.
Pasted records stay in the browser. Live lookups use DNS-over-HTTPS first with a same-origin fallback, and RFC 3597 generic wire-format answers are decoded before validation. The tool judges record syntax and policy coherence at lookup time. It cannot see what any CA actually logged at issuance, does not scan Certificate Transparency for certificates that predate or violate your policy, and cannot verify that a CA honors iodef reports. Pair a CAA policy with CT monitoring for the full picture.
No. CAA is evaluated only at issuance. Existing certificates run to their natural expiry regardless of policy changes — which also means CAA is not a revocation tool; it only shapes the future.
The first relevant RRset found by RFC 8659 discovery: start at the requested name, follow aliases where required, then climb parent by parent. A child RRset applies to that name and descendants without a closer RRset; sibling names and the apex keep their own discovery paths.
Wildcard issuance then follows the issue tags. Publish issuewild only when wildcard policy should differ — for instance, allowing host certificates broadly while forbidding wildcards entirely.
Issuance by the right CA but the wrong hands. With accounturi, the CA additionally requires the request to come from your named ACME account, so an attacker who can pass domain validation still fails without your account key.
Set it — an address that receives violation reports costs nothing and occasionally catches a misconfiguration early. But treat it as best-effort: reporting behavior varies between CAs, so it complements CT monitoring rather than replacing it.
Yes, and that is the most common self-inflicted CAA incident: switching CA vendors without updating the record. The old certificates keep working, the first renewal through the new CA fails, and the failure surfaces as an expiry alert weeks later.