CAA records: control who can issue certificates for your domain

A CAA record tells certificate authorities which of them may issue certificates for your domain, shrinking the surface for unauthorized issuance. This guide covers CAA syntax, ACME account pinning, and the dangling _acme-challenge delegation that can hand an attacker a trusted certificate.

Anyone can ask a certificate authority for a certificate. Domain validation is supposed to be the gate - the CA confirms you control the domain before it issues - but that gate has a well-known weak spot. If an attacker can pass validation for your name, from any of the dozens of publicly trusted CAs, they walk away with a legitimate certificate for your domain and every browser on earth will trust it. CAA records narrow that gate: they let you name the handful of authorities allowed to issue for you, so a request to anyone else is refused before validation even starts. But the same automation that makes certificates effortless introduces a quieter risk - a stale DNS delegation that lets someone else pass validation in your place. This guide covers CAA records, how they work, and how SecRift audits your certificate issuance surface.

What is a CAA record?

CAA stands for Certification Authority Authorization, defined in RFC 8659. It is a DNS record that lists which certificate authorities are permitted to issue certificates for your domain. Before a CA issues, it is required to check for a CAA record and honor what it finds - if the record names only Let's Encrypt and someone asks a different CA, that CA must refuse.

A CAA record has three parts: a flags octet, a property tag, and a value. The tags that matter in practice are issue (which CAs may issue standard certificates), issuewild (which may issue wildcard certificates), iodef (where to report a policy violation), and issuemail (which CAs may issue S/MIME certificates for your email addresses, added in RFC 9495). A typical record looks like 0 issue "letsencrypt.org" - flags of zero, the issue tag, and the CA's identifying domain.

CAA is entirely optional. Publishing no record is a legitimate choice - it just means any publicly trusted CA may issue for you after standard validation. A CAA record does not make issuance more secure on its own; it removes CAs you do not use from the pool of authorities that could ever issue in your name.

How CAA works

When a CA processes a certificate request, it looks up the CAA record for the exact name being requested. If it finds none, it climbs the DNS tree - from shop.example.com up to example.com - and uses the first record set it hits, stopping at your zone apex. This tree-climbing means a CAA record at your apex covers every subdomain unless a subdomain publishes its own.

Once the CA has the record set, it reads the issue and issuewild properties. If any authorizing property names it, issuance proceeds; if none do, the CA refuses. An empty value - issue ";" - authorizes no one at all, which is a deliberate way to say "do not issue any certificates for this name."

Two extensions harden this further. RFC 8657 adds parameters to the issue value: accounturi pins issuance to one specific ACME account at the CA, and validationmethods limits which validation methods (like dns-01 or http-01) are accepted. Together they mean that even a trusted CA will only issue for your domain through the exact account and method you nominated.

Why it matters

The threat CAA addresses is mis-issuance - a trusted CA handing a certificate for your domain to someone who is not you. It has happened, through both attacks on validation and CA compromise. Without CAA, your exposure is the entire set of publicly trusted CAs: any one of them, or anyone who can trick any one of them, is a path to a certificate in your name. CAA collapses that set to the CAs you actually use.

But the sharpest risk on the certificate surface is not the CAA record itself - it is the DNS delegation that automated issuance leaves behind. Many setups point _acme-challenge.example.com at a provider's validation zone with a CNAME, so the provider can answer the ACME dns-01 challenge on your behalf (RFC 8555). That works fine until the target stops existing - the provider account is closed, the cloud resource is released, the delegated zone is abandoned. Now you have a dangling record: a CNAME pointing at a name anyone can claim. An attacker who registers that target publishes their own challenge response, passes validation, and obtains a genuine, trusted certificate for your domain. Your CAA record does not stop this, because the attacker is going through a CA you authorized, answering a challenge you delegated to a target you no longer control.

Common mistakes

• A malformed CAA record. Syntax errors do not fail safe. A CA that cannot parse your record may treat it as unsatisfiable and refuse to issue - or, if you set the issuer critical flag on a property the CA does not understand, RFC 8659 requires it to refuse outright. A typo can silently block all certificate issuance for your domain.
• Blocking a CA you actually use. If your record names only one authority and you later switch or add a provider, renewals from the new CA start failing. CAA is a policy you have to keep in sync with reality.
• A dangling _acme-challenge delegation. The highest-impact mistake, and easy to miss - the delegation was set up correctly and only became dangerous when its target quietly disappeared. Nothing in your zone looks broken.
• Assuming CAA covers S/MIME. The issue and issuewild tags govern only TLS certificates. They place no restriction on S/MIME certificates for your email addresses - that is a separate issuemail policy (RFC 9495), and without it any CA may issue S/MIME certificates in your name.
• A wildcard policy broader than the base policy. If issuewild names a CA that issue does not, you have widened the set of authorities that can mint wildcard certificates - often unintentionally, since the wildcard rules override the base issue policy for wildcard requests.

How SecRift checks your certificate issuance surface

SecRift reads your public DNS and evaluates the certificate issuance surface across six findings - it does not connect to your site or fetch a live certificate, so it sees exactly what a CA would consult before issuing:

• CAA presence - looks up your CAA record using the same tree-climbing walk a CA performs, and reports whether an effective policy exists. Because publishing no CAA is a valid choice, an absent record is reported as informational and does not count against your score.
• CAA syntax - parses every effective record against RFC 8659: flags, tags, issuer values, and parameters. A malformed value or an unrecognized property carrying the issuer critical flag is flagged as critical, because it can make CAs refuse to issue for you entirely.
• ACME challenge delegation - resolves _acme-challenge and, if it is a CNAME or NS delegation, checks that the target still resolves. A delegation pointing at a name that no longer exists is the dangling-takeover vector, and it is the heaviest-weighted finding in the check. A static challenge record in your own zone, or a target that resolves cleanly, passes.
• Issue pinning - checks whether your authorizing issue and issuewild properties pin issuance to a specific ACME account (accounturi) and validation method (validationmethods) per RFC 8657. Pinning is optional hardening, so its absence is a low-severity advisory; a malformed pinning parameter is flagged higher, since a CA cannot satisfy it.
• Wildcard policy - compares issuewild against issue and flags the case where the wildcard policy authorizes a CA the base policy does not, widening the wildcard issuance surface. A deliberately restrictive issuewild ";" passes.
• S/MIME policy - reports whether you publish an issuemail policy (RFC 9495) constraining S/MIME certificate issuance. Since issue and issuewild do not restrict S/MIME, an absent issuemail is a low-severity advisory; a malformed value is flagged as critical.

The dangling _acme-challenge finding is a close cousin of the abandoned delegations SecRift's DNS delegation and exposure check hunts for - both are stale pointers that turn into takeover paths. And because CAA records live in DNS, they are only as trustworthy as the zone that serves them: DNSSEC is what stops an attacker from forging a CAA answer on the wire in the first place.

Run a free scan on any domain at secrift.com and see your certificate issuance surface in seconds.