Every day, certificate authorities issue millions of SSL certificates, and nothing in the traditional web PKI stops a rogue or compromised CA from issuing a perfectly valid certificate for your domain without your knowledge. That changed in 2017 when CAA records became a mandatory check for all publicly trusted certificate authorities. If you have not deployed CAA records yet, any of the 150+ trusted CAs in browsers can issue for your domain. A single CAA record changes that from an open door to a locked one with only the keys you hand out. This guide covers exactly what CAA records are, how to write them, how to deploy them, and how to verify they are actually doing their job.
What Is a CAA Record
A CAA (Certification Authority Authorization) record is a DNS record type, standardized in RFC 8659, that specifies which certificate authorities are permitted to issue SSL/TLS certificates for your domain. Before issuing a certificate, every compliant CA must perform a DNS lookup for CAA records on the domain in question. If the CA finds records and its own name is not listed, it must refuse to issue. If there are no CAA records, the CA is free to issue. The check is mandatory per the CA/Browser Forum Baseline Requirements, meaning any CA that skips the check risks losing its root trust.
CAA records sit in the DNS alongside your A, MX, and CNAME records. They are not visible to website visitors and have no impact on browsing speed or certificate validation at connection time. Their sole purpose is to constrain issuance before a certificate even gets created.
Why This Matters More Than You Think
Certificate misissuance has happened repeatedly in the real world. DigiNotar was compromised and issued fraudulent certificates for Google. Symantec was caught issuing test certificates for domains they did not control. Even legitimate CAs have had auditing failures. Without CAA records, any of those incidents could produce a valid-looking certificate for your domain that browsers would accept without complaint.
With a CAA record in place, a compromised CA still cannot issue for your domain if its name is not in your record set. The attacker would have to compromise your DNS too, which is a much harder bar to clear, especially if you have DNSSEC enabled. CAA is not a silver bullet, but it significantly narrows the attack surface.
There is also a compliance angle. PCI DSS, SOC 2, and ISO 27001 assessments increasingly flag the absence of CAA records as a gap in certificate lifecycle management. Getting them in place is a low-effort, high-value control.
Anatomy of a CAA Record
A CAA record has three fields after the standard DNS preamble: a flag, a tag, and a value.
Breaking down each part:
- Flag (0 or 128): Use 0 for all normal deployments. A flag of 128 marks the tag as critical, meaning a CA that does not understand the tag must refuse issuance. In practice, all compliant CAs understand the three standard tags, so 0 is correct here.
- Tag: One of three values. issue controls issuance of regular (non-wildcard) certificates. issuewild controls issuance of wildcard certificates. iodef specifies where the CA should send a report when a policy violation occurs.
- Value: For issue and issuewild, this is the domain name of the authorized CA. For iodef, this is either a mailto: address or an HTTPS URL that accepts IODEF reports.
Which CA Domain Names to Use
This is where most people get tripped up. The value in a CAA record must match exactly what the CA has registered with the CA/Browser Forum. Common ones:
- Let's Encrypt: letsencrypt.org
- DigiCert (including GeoTrust, RapidSSL, Thawte): digicert.com
- Sectigo (formerly Comodo CA): sectigo.com
- GlobalSign: globalsign.com
- Entrust: entrust.net
- Amazon Certificate Manager: amazon.com
- Google Trust Services: pki.goog
- ZeroSSL: zerossl.com
If you use a reseller or hosting panel that issues certificates through a third-party CA under the hood, check what CA actually signs the leaf certificate. Run the following against your live site to find out:
The output will show the issuing CA organization. Map that to the CAA domain name using the list above or the CCADB (Common CA Database) at ccadb.org.
Writing Your CAA Records Step by Step
Step 1: Identify Every CA You Currently Use
Audit all your domains and subdomains. A common mistake is blocking all CAs at the root domain level while forgetting that a subdomain managed by a different team uses a different CA. Check certificates for your main domain, any CDN-managed subdomains, and any SaaS platforms that issue certs on your behalf (Cloudflare, Fastly, AWS CloudFront, etc.).
Step 2: Decide on Wildcard Policy
If you want the same CA to issue both regular and wildcard certificates, you need both an issue and an issuewild record. An issue record alone does not authorize wildcard issuance. An issuewild record alone does not authorize non-wildcard issuance. If you deliberately want to block all wildcard issuance, add an issuewild record with an empty value:
Step 3: Add the Records in Your DNS Provider
Log into your DNS control panel. The field names vary by provider but the data is the same.
Cloudflare: DNS tab, Add record, Type = CAA. Enter the name (@ for root), flag (0), tag (issue/issuewild/iodef), and CA domain name.
AWS Route 53: Select your hosted zone, Create record, Record type = CAA. The value format in Route 53 is: 0 issue "letsencrypt.org" on a single line.
cPanel / WHM: Zone Editor, Add Record, select CAA from the type dropdown. Fill in Flag, Tag, and Value fields separately.
Using raw BIND zone syntax:
Step 4: Handle Subdomains
CAA records follow a specific inheritance model that is different from most DNS record types. If a subdomain has no CAA records, the CA walks up the DNS tree to the parent zone. So if sub.example.com has no CAA records, the CA checks example.com. If example.com has records, those apply. This means your root-level CAA records protect the entire domain tree by default. However, if you want a specific subdomain to have a different policy (for example, allowing a CDN provider to issue only for that subdomain), add explicit CAA records at the subdomain level.
Verifying Your CAA Records Are Working
Do not assume the records are correct just because your DNS panel shows them saved. Verify from the outside using command-line tools.
Using dig:
Expected output for a properly configured domain:
Using nslookup on Windows:
You can also use the DNS Lookup tool here on dnschecker.ca to query CAA records directly from your browser and see results across multiple geographic locations simultaneously.
To test that a specific CA would be authorized, there is no substitute for actually reading the records. If your CAA record says letsencrypt.org and you try to get a DigiCert certificate, DigiCert will refuse. You can simulate this by attempting a certificate request through that CA and watching it fail, but querying the records yourself is faster and does not require initiating an actual certificate order.
Common Mistakes and How to Avoid Them
Forgetting the CA That Issues for Your CDN
Cloudflare, Fastly, and similar providers issue certificates on behalf of your domain automatically. If you lock down your CAA records to only your primary CA and forget to add the CDN provider's CA, your CDN certificate renewal will fail silently and visitors will see certificate errors. Check your CDN's documentation. Cloudflare uses DigiCert and Let's Encrypt depending on plan tier. Fastly uses multiple CAs. Add all of them.
Using the Wrong CA Domain Name
Sectigo was formerly Comodo CA. If you put comodoca.com in your CAA record, it may work for legacy compatibility, but the current registered name is sectigo.com. Use the name the CA has registered with the CAB Forum. When in doubt, check the CA's own documentation on CAA configuration. Every major CA publishes this.
Locking Yourself Out During Renewal
If you switch CA providers, update your CAA records before the new CA attempts issuance, not after. The new CA will check records at issuance time. If your records still list the old CA only, the new CA will refuse and your renewal will fail. Plan the DNS change with enough lead time for propagation, typically 24 to 48 hours to be safe, though in practice most resolvers pick up changes within an hour.
Placing CAA Records on a CNAME Target
CAA records must live on the actual domain name in your zone, not on CNAME targets. If www.example.com is a CNAME to example.com, the CA checks for CAA records on www.example.com first, then walks up to example.com. It does not follow the CNAME chain. This is correct behavior and you do not need to do anything special, but it means you cannot put CAA records on an external CNAME target you do not control.
Using IODEF to Get Notified of Violations
The iodef tag is optional but highly recommended. When a CA encounters a violation (someone tried to get a cert your policy does not allow), it is supposed to send a report to the address in your iodef record. The report format is IODEF (Incident Object Description Exchange Format), defined in RFC 7970. Not all CAs send iodef reports in practice, but the compliant ones do, and it gives you an early warning signal that someone may be trying to get unauthorized certificates for your domain.
Set up a dedicated inbox or a ticketing system webhook for these reports rather than routing them to a personal inbox that might get ignored.
CAA Records and DNSSEC
CAA records are only as trustworthy as your DNS. An attacker with the ability to spoof DNS responses could return a forged CAA record authorizing any CA they choose. DNSSEC signs your zone records cryptographically, making forgery detectable. If you are deploying CAA records for serious security hardening, enabling DNSSEC on your zone at the same time is the right move. Most major DNS providers support DNSSEC: Cloudflare, Route 53, and Google Cloud DNS all make it straightforward to enable.
A Minimal Recommended Configuration
For most domains using a single CA, this is a solid baseline:
Add additional issue or issuewild lines for each additional CA you need to authorize. Keep the list as short as possible. Every CA you authorize is a CA whose compromise could affect you.
CAA records take about fifteen minutes to implement correctly and protect your domain for as long as they exist in your DNS. There is no good reason to skip them, and multiple good reasons to deploy them today.