What this checks
A CAA record (RFC 8659) tells certificate authorities which of them may issue certificates for a name. Before issuing, a CA looks the record up for the exact host, then for each parent name, and uses the first set it finds. This page does the same walk through two public validating resolvers and shows what each name returned, whether the zone is DNSSEC-signed, and whether the resolvers agree.
It then reads Certificate Transparency: every CA that issued a certificate for any host under the domain in the last 90 days, with the CAA identifiers that CA recognizes (from the CCADB list CAs publish). A CA that issued but is not allowed by the CAA set is flagged — a stale record, a certificate issued through a CDN, or an issuance nobody asked for.
Why issue "letsencrypt.org" is not enough
A plain issue record restricts which CA may issue, not who may ask. Anyone able to complete a DNS-01 or HTTP-01 challenge for the name still gets a certificate from that CA. RFC 8657 adds two parameters: accounturi pins issuance to one ACME account, and validationmethods limits the challenge types. CA/Browser Forum ballot SC-098v2 (May 2026) makes both mandatory for every publicly trusted CA from 15 March 2027; some CAs honour them already.
What the lint looks for
Records that block the CA you actually use; two accounturi parameters on one record (unsatisfiable); mis-cased or unknown validationmethods labels; an unrestricted record next to a restricted one for the same CA (the unrestricted one wins); identifiers no public CA recognizes (typos); the critical flag on an unknown tag (blocks every CA); wildcard certificates with no issuewild record; a missing or malformed iodef; zones without DNSSEC, where a CA's resolver cannot detect a spoofed answer.
The generator
From the CAs seen in CT it builds a record set with accounturi, validationmethods, issuewild and iodef, and warns about the CAs the new set would block. It runs entirely in your browser: the account URI you paste never leaves the page.