domain. CAA <flag> <tag> "value", that names which certificate authorities may issue TLS/SSL certificates for a domain. Setting one is optional for domain owners, but every publicly trusted certificate authority has had to check for one before issuing a certificate since September 8, 2017, under CA/Browser Forum Ballot 187. Despite that mandate, only 15.4% of the top 150,000 TLS-supporting sites carried a CAA record as of June 2024, according to Qualys SSL Labs’ SSL Pulse survey. From March 15, 2027, certificate authorities must also process two further CAA parameters, accounturi and validationmethods, defined in RFC 8657, which bind issuance to one named automation account and one named validation method. What a CAA record controls
A CAA record limits certificate issuance at the DNS level: it tells every certificate authority, before it issues anything, whether it is authorized to.
The record type is defined in RFC 8659, published by the IETF in November 2019, which formally obsoletes the original 2013 specification, RFC 6844, still cited by some older guides without noting the replacement. A domain owner uses it to name one or more certificate authorities allowed to issue for the domain, and separately, for wildcard certificates. When an authorized CA issues outside its own stated policy, the record becomes evidence of a violation rather than a technical block that prevented it.
What a CAA record does not protect against
Nothing about encryption changes when a CAA record is added, and nothing about it strengthens the certificate once issued. It does not replace domain control validation: a certificate authority named as authorized still has to confirm the applicant controls the domain before issuing. It cannot stop a certificate authority that ignores its own published policy, and it does nothing against an attacker who has already compromised an authorized CA’s issuance system.
Do you need one
Without a CAA record, any publicly trusted certificate authority can issue a certificate for the domain, because the default behavior when no record is found is open. Publishing one closes that gap for every CA not named in it.
The distinction that trips up most first-time readers: the record itself is optional for the domain holder, and the check against it is mandatory for the certificate authority. CA/Browser Forum Ballot 187 made CAA checking a required step in the Baseline Requirements for all publicly trusted certificate issuance starting September 8, 2017. A domain with no record still gets certificates issued normally; a domain with a record that excludes a given CA gets its requests to that CA rejected.
Is a CAA record required to get an SSL certificate?No. Publishing one is optional for the domain holder. Only the certificate authority’s side of the check is mandatory, and has been since September 8, 2017.
Anatomy of a CAA record: flags, tags, and values
Every CAA record carries three parts: a flag, a tag, and a value. The flag is either 0 (non-critical, the default) or 1 (critical), telling a CA whether it must understand the tag before proceeding; a CA that does not recognize a critical tag must refuse issuance rather than skip the record. The tag names the property being set, and the value carries its content, typically a CA’s domain name or a contact address.
issue, issuewild, and iodef
The three original tags still cover most deployments. issue authorizes standard, non-wildcard certificate issuance. issuewild authorizes wildcard issuance and takes precedence over issue for wildcard requests specifically. iodef names an email address or URL a CA should notify when it receives a request that fails the CAA check, functioning as an incident report rather than an issuance control.
Two newer property types extend this list well beyond what most setup guides still describe.
| Tag / parameter | Function | Defined in | Status |
|---|---|---|---|
| issue | Authorizes standard certificate issuance by the named CA | RFC 8659 | Core, in active use |
| issuewild | Authorizes wildcard certificate issuance by the named CA | RFC 8659 | Core, in active use |
| iodef | Names a contact for CA-side violation reports | RFC 8659 | Core, in active use |
| issuemail | Restricts which CAs may issue S/MIME (email) certificates | RFC 9495 | In force since October 2023 |
| contactemail / contactphone | Publishes a contact a CA may use for domain-control validation | CA/Browser Forum Ballots SC013, SC018, SC019 | Being retired: discouraged from March 15, 2026; phone-based use sunsets March 15, 2027; email-based use sunsets March 15, 2028, under Ballot SC-090 |
| accounturi | Restricts an issue or issuewild authorization to one named automation account | RFC 8657 | Mandatory for CAs to support from March 15, 2027, under Ballot SC-098v2 |
| validationmethods | Restricts which domain-control validation method a CA may use for that account | RFC 8657 | Mandatory for CAs to support from March 15, 2027, under Ballot SC-098v2 |
Two of these seven controls are new enough that the three-tag description still common in setup guides is already incomplete: accounturi and validationmethods move CAA from a CA-level allowlist to an account-level one, with about six months left before support becomes mandatory.
Can more than one certificate authority be authorized at once?Yes. Publish one issue property per authorized CA. Authorizing DigiCert and Sectigo takes two separate CAA records.
Setting up a CAA record
Adding a CAA record follows the same handful of steps regardless of which DNS provider hosts the zone: identify the authorized CAs, choose the tags needed, and publish the record with a workable TTL.
- Confirm the current state first. Query the domain’s existing CAA records before changing anything; an old record from a previous provider can silently block a new CA.
- Pick the tags that match the goal. A single CA needs only issue; a domain issuing both standard and wildcard certificates from different CAs needs both issue and issuewild; an automated ACME setup benefits from adding accounturi.
- Publish the record in the zone. Most DNS management consoles offer a CAA record type directly; the fields map to name, flag, tag, and value.
- Set a workable TTL. A short TTL speeds up any future change; a longer one reduces query load. Either works for CAA, since the check happens at issuance time, not on every page load.
- Re-query after publishing. A fresh DNS lookup for the CAA record type confirms the change propagated before the next certificate request.
Subdomains, wildcards, and multiple CAs
A certificate authority checking CAA for a specific hostname starts at that exact name and, if nothing is published there, walks up the domain tree one label at a time until it finds a record or runs out of labels, per the search algorithm in RFC 8659. A record published at the root domain therefore reaches every subdomain that has not published its own.
| Domain / subdomain | CAA record present | Effective policy |
|---|---|---|
| example.com | issue “digicert.com” | Only DigiCert may issue for example.com |
| shop.example.com | none | Inherits example.com’s policy: only DigiCert |
| shop.example.com | issue “sectigo.com” | Only Sectigo may issue for shop.example.com; example.com’s record no longer applies here |
| test.shop.example.com | none | Inherits from shop.example.com (Sectigo), skipping past example.com entirely |
A record at the root reaches a subdomain only until that subdomain publishes one of its own. The moment it does, the search stops there, and the root policy plays no further part in that name or anything beneath it.
Does a CAA record on the root domain protect subdomains too?Yes, until a subdomain publishes its own record. At that point the subdomain’s record takes over completely for that name and everything below it.
Common CAA errors and how to fix them
| Symptom | Likely cause | Fix |
|---|---|---|
| Certificate request rejected right after adding a record | DNS propagation delay, or a cached negative answer still active | Wait out the previous TTL, then re-query the CAA record directly before retrying issuance |
| SERVFAIL on a CAA lookup | DNSSEC validation failure, or an authoritative server answering something other than NOERROR for the CAA query type | Check DNSSEC signing status first; if DNSSEC is unused, confirm the name server returns NOERROR for unrecognized query types |
| CAA check times out | A firewall or resolver drops the CAA query type, or an authoritative server is unreachable | Confirm the name server answers CAA queries specifically, and check every NS record for an outage |
| Two domains loop through CNAME records | A CNAME chain points from one domain to a second whose CNAME points back to the first, so the CAA search never reaches a terminating record | Point the chain at a domain that holds a CAA record directly, or publish one on one of the looping names |
| A correctly named CA is still rejected | A typo in the value field, most often a wrong top-level domain | Match the value field to the CA’s registered domain name, for example digicert.com, which sometimes differs from the brand name shown at checkout |
Propagation timing, DNSSEC state, and CNAME structure cause most of these failures, all of them before the certificate authority is ever involved.
Why would a certificate request fail right after adding a CAA record?Usually caching. Resolvers and CAs can hold the previous, no-record answer for as long as the old TTL specified, so a request submitted before that TTL expires may still see the old state.
Binding certificate issuance to one ACME account
RFC 8657 defines two parameters that attach to an issue or issuewild property: accounturi names a specific account URI at the authorized CA, and validationmethods restricts which domain-control validation method that account may use. Together they narrow a CAA record from “this CA may issue” to “this CA may issue, only for this account, only using this method.”
A record using both looks like this: example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1726001367; validationmethods=dns-01". Let’s Encrypt’s production ACME endpoint, acme-v02.api.letsencrypt.org, is the account server most published accounturi values point to today.
Support for these two parameters becomes mandatory for every publicly trusted CA on March 15, 2027, under CA/Browser Forum Ballot SC-098v2, passed in May 2026. The requirement lands alongside a separate schedule cutting maximum certificate lifespans to 100 days by that same date and to 47 days by March 2029, under Ballot SC-081v3, which is pushing more domains toward automated renewal and makes account-level binding correspondingly more useful.
Does setting up accounturi break certificates from other providers?It can if configured carelessly. An accounturi value locks issuance to one named account at one CA, so a domain still needing certificates from a second CA needs a second issue record for that CA, either without an accounturi value or with one naming that account instead.
Verifying your CAA record works
The fastest check is a direct DNS lookup for the CAA record type against the domain, which returns exactly what a certificate authority would see during issuance.
A correctly configured record returns the exact flag, tag, and value fields published, and nothing else.
