CAA Records: Control Who Can Issue Your SSL Certificates

Dozens of certificate authorities (CAs) around the world are trusted by browsers to issue SSL/TLS certificates, and by default any of them may issue one for your domain if it can verify control. A CAA record lets you narrow that list down to the authorities you actually use. It is a single DNS record, it costs nothing, and it closes off a whole category of mistakes and attacks. It also has one sharp edge, which this article will help you avoid.

What a CAA record does

CAA stands for Certification Authority Authorization. It is a DNS record type, defined in RFC 8659, that names which CAs are permitted to issue certificates for a domain. Since 2017, the industry rules that publicly trusted CAs must follow (the CA/Browser Forum Baseline Requirements) oblige every such CA to check CAA before issuing. If your domain has CAA records and the CA is not listed, it must refuse.

CAA does not affect certificates that already exist, and browsers do not check it when visitors connect. It is purely a rule for CAs at the moment of issuance.

CAA record syntax

Each CAA record has three parts: a flag, a tag and a value.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

• Flag: almost always 0. A value of 128 marks the record "critical", meaning a CA that does not understand the tag must not issue. You will rarely need it.
• Tag: one of the following.
  • issue: CAs allowed to issue any certificate for this name, including wildcards unless issuewild says otherwise.
  • issuewild: CAs allowed to issue wildcard certificates (*.example.com). If present, it overrides issue for wildcards.
  • iodef: where a CA may report a refused request, as a mailto: or https: URL. Not every CA sends reports.
• Value: the CA's identifying domain, in quotes. A value of ";" means "nobody".

In the example, only Let's Encrypt may issue ordinary certificates, nobody may issue wildcards, and refused requests may be reported to the security mailbox.

Common CA identifiers

Each CA publishes the value it looks for. Some common ones:

Always confirm the value in your CA's own documentation, because some CAs accept several identifiers and brands under the same company can differ.

Step 1: Find out who issues your certificates today

This is the step that prevents outages. Before you publish a CAA record, list every certificate in use across your domain and subdomains, and note the issuer of each. Our SSL checker shows the issuing CA for any host name. Look beyond the main website:

• Your CDN or hosting platform may issue certificates automatically for your custom domain, often from a different CA than you expect.
• Email services, helpdesks, status pages and marketing tools on subdomains may each have their own certificates.
• Load balancers in cloud platforms frequently use the provider's own CA.

Every CA you find needs an issue record, or its next automatic renewal will fail. Renewals typically fail quietly until a certificate actually expires, which is why this inventory matters.

Step 2: Publish the records

Add CAA records at your domain apex in your DNS provider's control panel. Most modern panels have a CAA type with separate fields for flag, tag and value. For a site using Let's Encrypt on its own servers and a CDN that uses Google Trust Services, you might publish:

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issue "pki.goog"
example.com.  CAA  0 iodef "mailto:security@example.com"

Multiple issue records are combined: any listed CA may issue.

How CAs look up CAA: climbing the tree

When asked for a certificate for shop.eu.example.com, a CA checks for CAA records at that exact name. If there are none, it checks eu.example.com, then example.com, stopping at the first name that has any CAA records. That has two consequences:

• A CAA record set at your apex protects every subdomain beneath it.
• A subdomain can have its own CAA records that replace (not add to) the parent's. If a subdomain points via CNAME to a third-party platform, the CA follows the alias and may find the platform's CAA policy instead.

Optional: tighter controls

RFC 8657 adds parameters to the issue value that some CAs support, such as Let's Encrypt. accounturi restricts issuance to one specific ACME account, and validationmethods restricts which validation methods may be used:

example.com.  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456; validationmethods=dns-01"

This is powerful, but it also means a server rebuild with a new ACME account will be refused until you update DNS. Use it when you have tight change control.

Checking your CAA records

Query CAA directly:

dig example.com CAA +short
nslookup -type=CAA example.com

Or use the DNS lookup tool with the CAA type selected. If a certificate request fails with an error mentioning CAA, the CA's message usually tells you which name it checked and what it found.

Key takeaways

• A CAA record lists the certificate authorities allowed to issue certificates for your domain, and CAs must obey it.
• Inventory every certificate and its issuer, including CDNs and SaaS subdomains, before publishing.
• Use issue for normal certificates, issuewild for wildcards and iodef for reports.
• Records at the apex cover all subdomains unless a subdomain has its own CAA set.