CAA records explained

What CAA does, and what it deliberately does not do

CAA is specified in RFC 8659, a Standards Track document from November 2019 that obsoletes the original RFC 6844. It defines a DNS record type that lists the certificate authorities permitted to issue for a name, and a processing algorithm that every CA must run before issuance.

The limits are stated in the RFC itself, in plain terms, and they are worth reading before you decide how much protection you are buying. Section 1 says conformance with a published CAA record is a necessary but not sufficient condition for issuance, and that relying parties must not use CAA records as part of certificate validation. In other words: browsers do not check CAA. Nothing at connection time consults it.

Section 5.3 states the other limit: CAA does not prevent mis-issuance by an authorised CA. If you list an authority and that authority's domain validation is fooled, CAA has done its job and the certificate still exists. CAA reduces the number of parties who can make that mistake on your behalf; it does not make any of them more careful.

And it is not retroactive. The RFC notes that a certificate which does not conform to your current CAA records may have been perfectly conformant with the records published when it was issued. Publishing CAA today does nothing about a certificate issued yesterday.

What remains after those caveats is still worth having: the set of organisations capable of issuing a trusted certificate for your domain drops from every public CA to the ones you named, checked on every single issuance, at the cost of one DNS record.

The property tags

A CAA record has three parts: a flags byte, a property tag, and a value. RFC 8659 section 4 defines three tags.

• issue authorises a named authority to issue certificates for the exact name the record covers. The value is the authority's identifier, which is a domain name chosen by that authority, not necessarily its website.

• issuewild authorises a named authority to issue wildcard certificates. It is separate from issue on purpose: you can allow an authority to issue for www.example.com while allowing nobody to issue for star dot example.com.

• iodef gives an address where a CA should report a request it refused because of your policy. The value is a URL, and in practice a mailto: address is what CAs support most widely.

A value of a single semicolon means no authority is authorised. Published under issue, it says no certificate may be issued for this name at all; under issuewild, it says no wildcard may be issued while ordinary certificates remain allowed.

IANA's Certification Authority Restriction Properties registry holds more tags than RFC 8659 defines: issuemail, from RFC 9495, for S/MIME certificates issued to addresses in your domain; issuevmc, from the Verified Mark Certificate requirements, for the certificates BIMI uses; and contactemail and contactphone, from CA/Browser Forum ballots, which are a domain validation method rather than a restriction. Our scanner recognises issue, issuewild, issuemail and iodef; if you publish one of the others, publish it without the critical flag so that no authority is forced to refuse a request it could otherwise have handled.

The flags byte and the critical flag

The flags field is a single octet, and only one bit in it is defined. Bit 0, the issuer critical flag, is set by writing 128 in the flags position; anything else you will see in the wild is 0.

The semantics from RFC 8659 section 4.1 are strict: a CA must not issue for a name whose relevant record set contains a critical property with a tag the CA does not understand or support. This is a fail-closed rule and it is the point of the flag. It exists so that a future property with real security meaning cannot be silently ignored by an authority that has not implemented it.

The practical consequence is that a typo behind a critical flag blocks every certificate for the domain. A record reading 128 issuewilde followed by an authority name is a critical property with an unrecognised tag, and every CA in the world is required to refuse rather than guess what you meant. Our scanner reports exactly this case as a high-severity failure, because the symptom appears at the CA rather than in your DNS and is very hard to diagnose from your side.

Use 0 unless you have a specific reason not to. There is no security benefit to marking issue or issuewild as critical, because every CA already understands them.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
;             flags ^  ^ tag        ^ value

example.com.  3600  IN  CAA  128 issuewilde "letsencrypt.org"
; critical flag on a misspelt tag: no CA may issue for this domain at all

Parameters: account binding and validation methods

The value of an issue or issuewild property can carry parameters after the authority name, separated by a semicolon, in tag=value form. RFC 8657 defines the two that matter, and they turn CAA from a statement about which organisation may issue into a statement about which account at that organisation may issue.

accounturi names a specific account at the CA. Section 3 of RFC 8657 says the CA must only treat the property as authorising issuance when it recognises the URI as identifying the account making the request. With it set, an attacker who somehow passes domain validation from a different account at the same authority is still refused.

validationmethods restricts which challenge types the CA may accept, as a comma-separated list. If your issuance is always DNS based, restricting to dns-01 means an attacker who gains control of your web server cannot obtain a certificate through an HTTP challenge. Let's Encrypt documents the labels it accepts as http-01, dns-01 and tls-alpn-01.

On support: the Baseline Requirements make processing of accounturi and validationmethods mandatory for CAs from 2027-03-15. Before that date, support is per-authority. Let's Encrypt documents support for both today. Check your own authority's documentation before relying on either, because a CA that does not implement the parameter is permitted to ignore it, and a restriction that is ignored is not a restriction.

The account URI is not a secret and publishing it is not a disclosure risk, but note the operational cost: rebuild your ACME client's account and the URI changes, at which point issuance stops until you update the DNS record.

; only this ACME account at this CA may issue
example.com.  3600  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"

; and only through the DNS challenge
example.com.  3600  IN  CAA  0 issue "letsencrypt.org; validationmethods=dns-01"

How a CA finds your record: the tree climb

RFC 8659 section 3 defines the lookup. The CA starts at the exact name it is being asked to certify and climbs the DNS tree one label at a time, stopping at the first name that has a CAA record set. It does not continue to the root, and it does not merge records found at different levels: the first set it finds is the whole policy.

That has two consequences people trip over. First, a record at the apex governs every subdomain that does not publish its own, which is usually what you want. Second, a record at a subdomain completely replaces the apex policy for that subdomain rather than adding to it, so a record at api.example.com that names only one authority silently removes every authority the apex allowed.

Wildcards have their own rule, in section 4.3. When the request is for a wildcard name and the relevant record set contains at least one issuewild property, every issue property must be ignored. So if you publish issuewild for one authority and issue for another, the second authority cannot issue your wildcard even though it is named in the set. Conversely, issuewild is ignored entirely for requests that are not wildcards.

If you publish no issuewild at all, wildcard requests fall back to your issue records, which is the simplest arrangement and the right default unless you specifically want to restrict wildcards.

api.eu.example.com   no CAA set   ->  keep climbing
eu.example.com       no CAA set   ->  keep climbing
example.com          CAA found    ->  this set is the whole policy
                                       (com and the root are never consulted)

The values the common authorities publish, September 2026

Each authority chooses its own identifier and publishes it in its own documentation. The values below were read from each authority's own pages in September 2026; they change rarely but they do change, and a wrong identifier fails closed. Confirm against your authority's current documentation before you publish.

• Let's Encrypt: letsencrypt.org.

• Google Trust Services: pki.goog.

• DigiCert: digicert.com. DigiCert documents the same identifier for its issuemail records.

• Sectigo: sectigo.com. Sectigo's documentation notes that it also recognises trust-provider.com and usertrust.com as authorising it.

• AWS Certificate Manager: Amazon documents four identifiers, amazon.com, amazontrust.com, awstrust.com and amazonaws.com, and says a CAA record must name one of them before ACM can issue. Publishing all four is the documented safe choice, since which one applies depends on the issuing hierarchy.

A note on identifiers that look wrong: they are domain names but they are not necessarily resolvable service endpoints, and matching is on the string the authority publishes, not on anything the CA hosts there. Do not substitute a name you think is more correct.

If your certificates are issued by a platform rather than bought directly, the authority behind them is the one to list. Cloudflare's documentation, for example, shows partner records for pki.goog, letsencrypt.org, ssl.com and sectigo.com, because which authority signs a Cloudflare-managed certificate is Cloudflare's choice rather than yours. The reliable method is not to guess: read the issuer off the certificate your site is currently serving.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates

Publishing it: three fields or one string

DNS hosts split CAA records two ways, and knowing which one you are looking at prevents most publishing mistakes.

Separate fields. Route 53's console takes the three settings on one line as flags, then tag, then a quoted value, and Amazon's documentation is explicit that the value must always be enclosed in quotation marks. Cloudflare's dashboard, as of its April 2026 documentation, presents a type, a name, a tag chosen from a menu and a field for the CA domain name. Most managed DNS panels follow one of these two shapes.

One string. Zone files, and any host that takes raw record data, want the whole thing: flags, tag, and the value in double quotes, separated by spaces. If the panel gives you a single box and you are unsure which it expects, publish once and read the record back with dig; a value that comes back with the quotes inside it, or with the tag duplicated, tells you immediately.

Parameters go inside the quoted value, after the authority name and a semicolon. This is the part panels most often mangle, because a semicolon is a comment character in a zone file and some panels strip or escape it. Read the record back after publishing.

Publish at the apex unless you have a specific reason to publish lower. An apex record covers every subdomain through the tree climb, and a per-subdomain record is a replacement rather than an addition.

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

; and, in Route 53's console, the same three records entered as
; 0 issue "letsencrypt.org"
; 0 issuewild "letsencrypt.org"
; 0 iodef "mailto:security@example.com"

How to verify it

Query the record and read it back as a string. Old versions of dig print unknown types in the generic format, as TYPE257 followed by a byte count and hexadecimal, which is correct but unreadable; if you see that, the record is fine and your dig is old.

Then check the tree climb from the name that actually gets certified. If your certificate covers www.example.com, query that name, not the apex, and confirm the authority you expect appears in the set that a CA would find.

The verification that counts, though, is a real issuance. A CAA record is only proved correct by a certificate being issued under it, so force a renewal rather than waiting for the scheduled one. Most ACME clients have a flag for this, and doing it the same day you publish turns a silent failure two months from now into an error message in front of you.

Our CAA checker reads the records as published, follows the same climb a CA would, and flags the specific faults that block issuance: a policy that authorises nobody, a critical flag on a tag no authority recognises, and an iodef value that is not a usable URL. It cannot tell you whether the authority you listed is the one your platform actually uses; only the certificate can tell you that.

dig +short CAA example.com
dig +short CAA www.example.com

# then force a renewal rather than waiting for the scheduled one
certbot renew --force-renewal --cert-name example.com

The failure mode: a CAA record that blocks your own renewal

This is the one genuine risk in publishing CAA, and it deserves to be stated plainly rather than buried. Nothing breaks when you publish the record. Your site keeps working, your certificate keeps validating, and every check you run looks clean. Then, at some point between two weeks and two months later, a renewal runs, the authority checks CAA, finds it is not listed, and refuses. The automation retries, is refused again, and usually reports the failure into a log nobody reads. The first visible symptom is an expired certificate and a browser warning.

Two things make this worse than it used to be. Certificate lifetimes are shortening on a published CA/Browser Forum schedule: the maximum is 200 days for certificates issued from 2026-03-15, 100 days from 2027-03-15, and 47 days from 2029-03-15. Shorter lifetimes mean renewals come round sooner, which shortens the fuse. And managed certificates, from a CDN or a hosting platform, are the usual casualty, because the authority behind them is not the one you would have guessed.

The defences are cheap. List every authority that issues for the domain today, including the one your platform uses on your behalf. Force a renewal immediately after publishing rather than waiting. Keep the record's TTL at an hour or less while you are still making changes, so that undoing a mistake takes an hour rather than a day.

And know the rollback: deleting the CAA records restores issuance for every authority, and takes effect once the old record falls out of resolver caches, which is bounded by the TTL you published. There is no lengthy recovery here, which is what makes the risk manageable.

The other half of this failure mode is a record that authorises nobody. A set where every issue property has the value of a single semicolon is a valid and sometimes deliberate configuration, for a domain that must never have a certificate. If the domain does serve HTTPS, it is a renewal outage waiting for a date. Our scanner reports it as a warning rather than a failure for exactly that reason: it cannot tell your intent, and it says so rather than guessing.

How we report a missing CAA record, and why

When a domain has no CAA record, our scan reports it as information and deducts nothing from the score. That is a deliberate decision and it is worth explaining, because a scoring page that marked it as a failure would rank better and be less honest.

No CAA record is the internet's default state. Nothing about the domain is broken, no visitor is affected, and the overwhelming majority of domains are in the same position. Scoring it as a fault would mean telling most of the internet it has a security problem it does not have, which devalues every real finding on the same page.

It is not, though, an outcome we present as fine. The absence of a control is the absence of a control: with no record, every publicly trusted authority in the world is authorised by default, and there is no mechanism that would stop a mis-issued certificate before it exists. The finding says so, and it comes with the record to publish and the steps to publish it safely. Information means we are not going to invent a penalty; it does not mean we recommend leaving it.

The findings that do cost you points are the ones where CAA is actively wrong: a critical flag on an unrecognised tag, which blocks every certificate for the domain; a policy authorising nobody on a domain that serves HTTPS; an iodef address that cannot receive the reports it is asking for. Those are faults you created, with consequences we can demonstrate.

What commonly goes wrong

• Omitting the authority your platform uses on your behalf. The site keeps working and the next managed renewal fails, weeks later, with the error at the CA rather than in anything you can see. Read the issuer off the live certificate instead of guessing.

• Publishing issuewild for one authority and issue for another. Once any issuewild property exists, every issue property is ignored for wildcard requests, so the second authority cannot issue your wildcard even though you named it.

• A typo behind the critical flag. A record such as 128 issuewilde blocks every certificate for the domain, because each CA is required to refuse rather than guess at a critical tag it does not recognise.

• Adding a CAA record at a subdomain and expecting it to add to the apex policy. The tree climb stops at the first set it finds, so a subdomain record replaces the apex policy entirely for that subdomain.

• Semicolons eaten by the control panel. Parameters after the authority name, and the semicolon that means authorise nobody, are both mangled by panels that treat the character specially. Always read the record back with dig rather than trusting the form.

• Publishing and not testing. A CAA mistake is invisible until a renewal runs. Forcing one the same day converts a silent outage in two months into an error message you can fix in ten minutes.

• Expecting CAA to do something at connection time. Browsers never look at it, and RFC 8659 explicitly forbids relying parties from using it in validation. It constrains issuance and nothing else.