DNS Records & Concepts
What is a CAA record?
A CAA record, Certification Authority Authorization record, is a DNS record that specifies which certificate authorities are permitted to issue SSL certificates for a domain. It is a security mechanism that allows domain owners to restrict certificate issuance to a specific set of trusted certificate authorities, preventing any other CA from issuing a certificate for the domain even if an attacker somehow convinces them to try.
Before CAA records existed any of the hundreds of publicly trusted certificate authorities could issue a certificate for any domain as long as they could verify domain control. This created a systemic risk, if any single CA was compromised or made an error in its validation process, fraudulent certificates could be issued for domains the attacker did not legitimately control. A fraudulent certificate for example.com allows an attacker to impersonate that domain to anyone who trusts that certificate.
CAA records address this by giving domain owners explicit control over which CAs are authorised to issue certificates for their domain. A CA that is not listed in the CAA records must refuse to issue a certificate, even if the requester passes all other validation checks. Since September 2017 all publicly trusted certificate authorities are required to check CAA records before issuing a certificate and must refuse issuance if their CA is not listed as authorised.
How a CAA record works
When a certificate authority receives a request to issue a certificate for example.com it performs a DNS lookup for CAA records at example.com as part of its pre-issuance checks.
If no CAA records exist for the domain the CA may proceed with issuance, the absence of CAA records is treated as unrestricted permission for any CA to issue. This is the default state for most domains that have not explicitly configured CAA records.
If CAA records exist the CA checks whether its own CA name appears in the records. If the CA is listed it may proceed with issuance subject to passing all other validation requirements. If the CA is not listed it must refuse to issue the certificate, even if the requester passes domain control validation.
The CA also checks parent domains if no CAA records exist at the queried domain level. shop.example.com inherits CAA records from example.com if no CAA records are configured specifically for shop.example.com. This inheritance means a single CAA record at the root domain protects all subdomains simultaneously unless overridden by subdomain-specific records.
CAA record format and tags
CAA records have a more structured format than most DNS record types. Each record contains three components, a flag, a tag, and a value.
Flag: a number between 0 and 255. Currently only one flag value is defined in practice, 0 for non-critical and 128 for critical. The critical flag (128) instructs the CA that if it does not understand the tag it must refuse issuance. The non-critical flag (0) instructs the CA that if it does not understand the tag it may ignore the record and proceed. For standard CAA records the flag is almost always 0.
Tag: specifies the type of constraint the record imposes. Three tags are defined in the standard.
issue: authorises the named CA to issue standard single-domain and multi-domain certificates for the domain.
issuewild: authorises the named CA to issue wildcard SSL certificates for the domain. A wildcard certificate covers *.example.com: any subdomain. Without an issuewild record a CA listed in an issue record is not permitted to issue wildcard certificates even though it can issue standard certificates.
iodef: specifies a URL or email address where the CA should report any certificate issuance requests that violate the CAA policy. This is a reporting mechanism, the CA does not refuse issuance based on iodef records, it notifies the contact when a policy violation occurs.
Value: for issue and issuewild tags the value is the domain name of the authorised certificate authority. letsencrypt.org for Let’s Encrypt, digicert.com for DigiCert, comodoca.com for Comodo, pki.goog for Google Trust Services. For iodef the value is a mailto: URI or https: URL.
A complete set of CAA records allowing both standard and wildcard certificate issuance by Let’s Encrypt with violation reporting:
An empty value in an issue or issuewild record, 0 issue "": explicitly prohibits all certificate issuance for the domain or for wildcards respectively. This is used when a domain should never have certificates issued, such as infrastructure domains that only communicate internally and should never receive a publicly trusted certificate.
CAA records and SSL certificates for redirect management
CAA records are directly relevant to redirect management because connecting a domain to redirect infrastructure requires provisioning an SSL certificate for that domain, ensuring that HTTPS visitors can reach the redirect service without certificate errors.
Dedicated redirect management platforms like Redirect Supply automatically provision SSL certificates for connected domains using Let’s Encrypt or another certificate authority. If the connected domain has CAA records that do not include the CA the platform uses the certificate provisioning will fail, the CA will check the CAA records, find it is not listed, and refuse to issue the certificate.
Domain owners who have configured CAA records must ensure the CA used by their redirect management platform is listed before connecting the domain. The platform’s documentation should specify which CA it uses for certificate issuance.
For domains using Let’s Encrypt, the most common CA for automated certificate issuance, the required CAA record is:
If wildcard certificates are needed:
Most domains that have not explicitly configured CAA records do not need to add any, the absence of CAA records permits issuance by any CA including Let’s Encrypt. CAA records only need to be added or modified when they already exist and exclude the required CA.
CAA records and multiple certificate authorities
Organisations that use multiple certificate authorities, perhaps one for standard certificates and another for extended validation certificates, or one for web certificates and another for email certificates, can list multiple CAs in their CAA records.
Multiple issue records for different CAs are simply additive, each listed CA is authorised to issue certificates:
This configuration authorises both Let’s Encrypt and DigiCert to issue standard certificates but only DigiCert to issue wildcard certificates.
When multiple CAs are listed each CA checks whether its own name is present in any of the issue or issuewild records before issuing. The CA does not need all records to list it, only at least one.
CAA inheritance and subdomain overrides
CAA records use a specific inheritance model that determines how records at the root domain affect subdomains.
When a CA checks CAA records for shop.example.com it first looks for CAA records specifically at shop.example.com. If records exist there they apply exclusively to that subdomain, the root domain records are not consulted. If no records exist at shop.example.com the CA moves up to example.com and checks there. If records exist at example.com they apply to all subdomains that have no more specific records.
This means a single set of CAA records at the root domain provides broad protection across all subdomains by default. Subdomain-specific overrides can be configured when different CAs should be authorised for specific subdomains.
A common use case for subdomain overrides is wildcard certificate management. The root domain might allow both Let’s Encrypt and DigiCert for standard certificates but only DigiCert for wildcards. A specific subdomain might need Let’s Encrypt for wildcard issuance because an automated deployment system uses it. The subdomain-level CAA records override the root domain for that specific subdomain.
CAA records and account binding
An optional extension to CAA records called account binding allows domain owners to restrict certificate issuance not just to a specific CA but to a specific account at that CA. This provides an additional layer of protection, even if an attacker can access the same CA the domain owner uses they cannot issue certificates unless they also control the specific account bound to the domain.
Account binding uses additional parameters in the CAA record value:
This specifies that only the Let’s Encrypt account with the given URI can issue certificates for the domain. Any other Let’s Encrypt account, even a legitimately registered one, would be refused.
Account binding is supported by Let’s Encrypt and some other CAs. Not all CAs or ACME clients support it yet. For most domains the standard CA-level restriction without account binding provides sufficient protection.
Checking CAA records
CAA records are queried using the same DNS tools as other record types.
dig command: on Linux and macOS:
Returns all CAA records for example.com showing the flag, tag, and value for each record. Adding +short returns a condensed view:
Checking subdomain inheritance: to verify what CAA policy applies to a subdomain check both the subdomain and parent domain:
If the subdomain has its own records they apply. If not the parent domain records apply.
Online CAA checking tools: several online tools specifically check CAA records and validate them against known CA names. They flag common issues like typos in CA names, missing issuewild records when wildcards are needed, and conflicting records. SSL Labs’ certificate checker and SSLMate’s CAA Record Helper are useful tools for validating CAA configuration.
Certificate issuance testing: the most definitive test of CAA configuration is attempting to issue a certificate from the relevant CA. A successful issuance confirms the CAA records are correctly configured for that CA. A failure with a CAA-related error message confirms the records are blocking issuance and need to be updated.
Common CAA record mistakes
Missing issuewild record for wildcard certificates: having an issue record for a CA but no issuewild record prevents that CA from issuing wildcard certificates. If the redirect management platform or any other service needs a wildcard certificate an issuewild record must be added alongside the issue record.
Typo in CA domain name: the CA domain name in the CAA record value must be exactly correct. letsencrypt.org not lets-encrypt.org or letsencrypt.com. A typo prevents the correct CA from issuing certificates while providing no protection. Always verify CA domain names against the CA’s own documentation.
Blocking the CA used by redirect management: configuring CAA records that list only certain CAs and excluding the CA used by the redirect management platform. Certificate provisioning for the connected domain fails. Always check which CA a platform uses and ensure it is listed before connecting a domain with existing CAA records.
Using critical flag unnecessarily: setting the critical flag (128) on standard CAA records. If a CA encounters a critical-flagged record with a tag it does not understand it must refuse issuance entirely. Standard CAA records should use flag 0, non-critical, unless there is a specific reason to use the critical flag.
Empty issue record blocking all issuance unintentionally: accidentally including 0 issue "": the record that prohibits all certificate issuance, alongside records for specific CAs. Some implementations interpret the empty record as a prohibition on all issuance. Remove empty issue records unless explicitly intending to block all certificate issuance.
Not adding CAA records at all: while the absence of CAA records is permissive rather than restrictive, not configuring them means any CA can issue certificates for the domain. For security-conscious organisations and high-value domains adding CAA records restricting issuance to the CAs actually in use is a worthwhile security measure.