CAA Records Explained: Control Which CAs Can Issue Your Certificates

A CAA (Certification Authority Authorization) record is a DNS record that tells the world which certificate authorities are allowed to issue TLS/SSL certificates for your domain. It is a short line of text published in your zone, yet it closes a surprisingly large gap in how public certificates are issued. You can inspect the CAA policy on any domain in seconds with the CAA Lookup tool.

There are hundreds of publicly trusted certificate authorities, and your browser trusts every one of them equally. By default, that means any of those CAs could issue a valid certificate for your domain, whether or not you have ever done business with them. If an attacker can trick or compromise any single CA into issuing a certificate for example.com, they hold a trusted certificate for your site, which enables convincing phishing and man-in-the-middle interception.

This is not theoretical. Several high-profile mis-issuance incidents, including the DigiNotar compromise that produced fraudulent Google certificates, showed that the weakest CA in the ecosystem effectively sets the security floor for everyone. CAA narrows that exposure: instead of trusting all CAs to behave, you explicitly name the one or two you actually use, and every other CA is contractually required to refuse issuance for your domain.

A CAA record has three parts after the record type: a flags byte, a property tag, and a value. The format looks like this: name CAA flags tag "value". The flags field is a number, almost always 0; setting it to 128 marks the record as critical, meaning a CA must refuse to issue if it does not understand the tag. In practice you will use 0 unless you have a specific reason not to.

There are three property tags. The issue tag names a CA permitted to issue regular (non-wildcard) certificates. The issuewild tag specifically controls wildcard certificates such as *.example.com. The iodef tag gives a URL or mailto address where a CA can report a request it was asked to refuse. The value is a quoted string: a CA's identifying domain for issue and issuewild, or a contact URI for iodef.

The most common record authorizes a single CA. To allow only Let's Encrypt to issue certificates for your domain, you publish: example.com. CAA 0 issue "letsencrypt.org". Any other CA reading this is now obliged to refuse. To authorize two providers, you simply publish two issue records, one per CA, for example one for "letsencrypt.org" and one for "digicert.com".

To forbid all issuance entirely, set the value to a semicolon: example.com. CAA 0 issue ";". This is useful for a parked or unused domain that should never have a certificate. A complete, typical policy might combine an issue record, a matching issuewild record, and an iodef record so you both restrict issuance and get notified about attempts that violate the policy. After publishing, confirm the records resolve as expected with the CAA Lookup checker or a raw DNS Lookup lookup.

CAA enforcement happens at the certificate authority, not in the browser. The CA/Browser Forum baseline requirements make checking CAA mandatory: at the moment of issuance, before signing a certificate, the CA performs a fresh DNS lookup for CAA records on the requested domain. If a CAA record set exists and does not list the requesting CA, the CA must refuse to issue. If no CAA record exists at all, issuance is permitted by any CA, which is the default open behavior.

Two consequences follow. First, CAA is checked at issuance time only, so it does not affect certificates already issued, nor does it interfere with TLS handshakes for existing certificates. Second, because the check happens against live DNS, a CAA record takes effect as soon as it propagates; there is no separate activation step. It is a control over future issuance, not a kill switch for current certificates.

Wildcard certificates get their own tag because they carry more risk: a single *.example.com certificate covers every subdomain. The rule is that issuewild, when present, overrides issue for wildcard requests. If you publish only issue records, those apply to both regular and wildcard issuance. But as soon as any issuewild record exists, wildcard requests are governed solely by issuewild, and the issue records no longer authorize wildcards.

This lets you set asymmetric policy. For instance, you might allow Let's Encrypt to issue normal certificates while blocking all wildcards with issuewild ";", or permit wildcards only from a single trusted commercial CA. If you rely on wildcard certificates, always check both tags after a change, because forgetting an issuewild entry is a common reason automated wildcard renewals suddenly start failing. The SSL / TLS Check tool helps you confirm what certificate is actually being served once issuance succeeds.

The iodef tag turns CAA from a silent gate into an alarm. When a CA receives a certificate request that its CAA policy requires it to refuse, and an iodef record is present, the CA may send an incident report to the address you specify. You publish it as a contact URI, for example: example.com. CAA 0 iodef "mailto:[email protected]". An https:// endpoint is also valid for CAs that support reporting to a web service.

Support for iodef reporting varies between CAs, so treat it as a useful early-warning signal rather than a guarantee. Still, an unexpected iodef report is a strong indication that something or someone tried to obtain a certificate for your domain from a CA you did not authorize, which is exactly the kind of event worth investigating immediately alongside your registrar and WHOIS Lookup contact records.

CAA records are inherited down the DNS tree using a process called tree-climbing. When a CA checks CAA for a hostname like shop.eu.example.com, it first looks for a CAA record at that exact name. If none exists, it climbs to the parent, eu.example.com, then to example.com, and stops at the first label that has any CAA record. That record set then governs issuance for the requested name; the climb halts as soon as records are found, even if a higher level would have said something different.

The practical takeaway is that a single CAA policy at your apex domain (example.com) automatically protects every subdomain that does not define its own. You only need a more specific record when a particular subdomain needs different rules, for example a CI environment that uses a different CA. Just remember that defining any CAA record on a subdomain stops the climb at that point, so it must be complete for that subdomain's needs.

To see your current policy, run the CAA Lookup tool against your domain; it will show the issue, issuewild, and iodef records (or tell you none exist, which means any CA can issue). To add one, log in to your DNS provider, create a new record of type CAA, and fill in the flags (0), tag (issue), and value (your CA's identifier, such as letsencrypt.org). Most providers offer a CAA option in their record-type dropdown; if yours does not, you may need to enter it as a generic record using the numeric type 257.

Before publishing, list every CA you actually use, including your CDN, load balancer, and any managed hosting that auto-provisions certificates, so you do not accidentally lock out a legitimate issuer and break renewals. After the record propagates, re-run the CAA Lookup check to confirm it parses correctly, then verify your live certificate still serves cleanly with the SSL / TLS Check tool. CAA is one of the lowest-effort, highest-leverage DNS hardening steps available, so it is well worth adding to every domain you own.