CAA Lookup
Check which Certificate Authorities are authorized to issue TLS certificates for any domain. Look up CAA DNS records, verify wildcard certificate restrictions, and confirm iodef violation reporting is configured.
What is a CAA record?
A CAA (Certification Authority Authorization) record is a DNS record type that lets domain owners specify which Certificate Authorities are permitted to issue TLS certificates for their domain. Before issuing a certificate, a CA checks the domain's CAA records and refuses if it is not listed.
CAA records are defined in RFC 8659 and have been a mandatory baseline check for all publicly trusted CAs since September 2017 (required by the CA/Browser Forum). They provide an additional layer of defense against certificate mis-issuance — even if a CA is compromised or makes a validation error, your CAA policy acts as a final gate.
Who benefits most? Any organization that uses a specific CA (e.g. Let's Encrypt, DigiCert, Sectigo) and wants to prevent other CAs from issuing for their domain. This is particularly valuable for domains under active attack, high-value domains, or organizations subject to compliance requirements (PCI DSS, HIPAA, SOC 2).
CAA record format: flags, tags, and values
Each CAA record has three fields: flags, tag, and value. Understanding these fields helps you read and write CAA records correctly.
| Field | Common Values | What it means |
|---|---|---|
| flags | 0 or 128 |
0 = informational; 128 = issuer-critical (CAs must understand this tag or refuse to issue) |
| issue | "letsencrypt.org" |
Authorize a CA to issue standard TLS certificates. Multiple issue records = multiple authorized CAs. |
| issuewild | "sectigo.com" |
Authorize a CA specifically for wildcard (*.domain) certificates. Overrides issue for wildcards. |
| iodef | "mailto:[email protected]" |
Where CAs should send violation reports. Accepts mailto: or https: URIs. |
| ";" value | ";" |
Prohibition — no CA may issue for this tag. issue ";" = no standard certs allowed. |
Basic CAA configuration
example.com. IN CAA 0 issue "letsencrypt.org" example.com. IN CAA 0 iodef "mailto:[email protected]"
Only Let's Encrypt may issue. Violations reported by email.
Multi-CA with wildcard restriction
example.com. IN CAA 0 issue "letsencrypt.org" example.com. IN CAA 0 issue "digicert.com" example.com. IN CAA 0 issuewild "digicert.com" example.com. IN CAA 0 iodef "mailto:[email protected]"
LE + DigiCert for standard certs; DigiCert only for wildcards.
issue vs issuewild: standard vs wildcard certificates
The issue property
governs issuance of standard TLS certificates — covering specific hostnames like
example.com and
www.example.com.
The issuewild property
governs wildcard certificates that match any subdomain at one level
(*.example.com).
When issuewild is not
present, the issue records
apply to both standard and wildcard certificates. When
issuewild is present, it
overrides the issue
records specifically for wildcard issuance. This lets you allow wildcards only from a
specific CA while letting a different CA issue standard certificates.
Practical tip: If you use Let's Encrypt for automatic certificate renewal
but use a paid OV or EV certificate for your public-facing wildcard, you would set:
issue "letsencrypt.org",
issuewild "sectigo.com".
This prevents Let's Encrypt (which only issues DV certificates) from accidentally issuing
a wildcard that would override your paid OV wildcard.
iodef: getting notified of unauthorized certificate requests
The iodef record
specifies where CAs should send reports when they receive a certificate issuance request
that violates your CAA policy. The value is a URI — either a
mailto: address
for email delivery or an https:
endpoint for programmatic report delivery.
Not every CA sends iodef reports consistently, so you should not rely on iodef as your only detection mechanism. However, it is a zero-cost early-warning signal — configuring it takes one DNS record and provides a free alert channel that could catch a mis-issuance attempt before a certificate is deployed. You can monitor the inbox or endpoint and alert your security team automatically.
Email iodef endpoint
0 iodef "mailto:[email protected]"
Simple, requires no server. Route to a monitored security inbox.
HTTPS iodef endpoint
0 iodef "https://example.com/caa-report"
Programmatic ingestion. The CA sends IODEF JSON to the endpoint.
How CAA fits into your TLS certificate security posture
CAA records are one layer in a defense-in-depth certificate security strategy. They work alongside several other mechanisms:
Certificate Transparency (CT)
All publicly trusted CAs are required to log every issued certificate to Certificate Transparency logs. You can monitor CT logs (e.g. via crt.sh) to detect certificates issued for your domain — even if they should not exist. CT logging is retroactive detection; CAA records are pre-issuance prevention.
DNSSEC
CAA records are only effective if an attacker cannot tamper with your DNS. If your DNS is not signed with DNSSEC, a DNS cache poisoning attack could replace your CAA records with an attacker's records (or remove them entirely), bypassing CAA entirely. For maximum protection, combine CAA records with DNSSEC signing.
CAA + SSL/TLS checker
After adding CAA records, verify that your existing TLS certificate was issued by one of the CAs you listed. Use the SSL/TLS Certificate Checker to inspect the issuer of your current certificate and confirm it matches your CAA policy.
Multi-perspective validation
Some CAs perform domain validation from multiple network vantage points and require CAA checks to also pass from each. This prevents localized DNS hijacking attacks where an attacker manipulates DNS responses at one location. The CA/Browser Forum is moving towards requiring multi-perspective validation for all CAs.
Recommended security stack for your domain: CAA records (restrict issuance) + DNSSEC (prevent CAA tampering) + CT log monitoring (detect mis-issuance) + iodef reporting (alert on violations). Together, these layers dramatically reduce the risk of unauthorized certificate issuance for your domain.
Frequently asked questions
What is a CAA record?
A CAA (Certification Authority Authorization) record is a DNS record type (type 257) that specifies which Certificate Authorities are permitted to issue TLS certificates for a domain. CAs are required to check CAA records before issuing. If the domain has CAA records that exclude the CA, it must refuse. CAA records have been a mandatory baseline check since September 2017 per the CA/Browser Forum.
What happens if a domain has no CAA records?
If a domain has no CAA records, any publicly trusted CA may issue certificates for it. This is the default state for most domains — it is not a misconfiguration, but it gives you no additional control. Adding CAA records narrows certificate issuance to only the CA(s) you specify. Domains with strict security requirements should always have CAA records to limit their attack surface.
What is the difference between issue and issuewild?
The issue property controls standard TLS certificate issuance (covering specific hostnames). The issuewild property controls wildcard certificate issuance (*.example.com). If no issuewild record is present, the issue records also govern wildcards. If an issuewild record is present, it overrides issue specifically for wildcard issuance — so you can authorize different CAs for standard vs. wildcard certificates. Setting issuewild ";" prohibits all wildcard issuance regardless of issue records.
What is an iodef record?
An iodef record specifies where CAs should send violation reports when they detect a certificate request that violates your CAA policy. The value is a mailto: URI or an HTTPS endpoint. Not every CA sends iodef reports, but those that do give you an early warning of unauthorized issuance attempts. It requires only a single DNS record to configure and costs nothing to receive reports.
Does Let's Encrypt support CAA records?
Yes. Let's Encrypt checks CAA records before every issuance and every renewal. If your domain has a CAA policy that does not include letsencrypt.org, Let's Encrypt will refuse to issue or renew. To authorize Let's Encrypt, add: 0 issue "letsencrypt.org". This check happens at issuance time, so if you add a CAA restriction after previously using Let's Encrypt, it will take effect on the next renewal attempt.
Should I allow multiple CAs in my CAA records?
List only the CAs you actually use. If you use a single CA for all certificates, restrict to that CA only — this gives the tightest control. If you use multiple CAs for different services (e.g. Let's Encrypt for automated renewal on web servers, DigiCert for OV certificates on specific domains), list all of them. Listing CAs you do not use provides no protection benefit and slightly increases the window for mis-issuance if one of those extra CAs is compromised.
What does the issuer-critical flag do?
The issuer-critical flag (flags=128) means the CAA record uses a property tag that the CA must understand. If a CA does not recognize the tag, it must refuse to issue rather than ignoring the unknown record. For standard tags (issue, issuewild, iodef), all modern CAs recognize them and the critical flag makes no practical difference. The flag is relevant when using custom or experimental tags — it ensures forward compatibility: CAs that do not know the new tag must fail safe instead of silently issuing.
How do I add CAA records at my DNS provider?
Most major DNS providers support CAA records through their control panel. In Cloudflare: DNS → Add Record → Type: CAA, then fill in the tag and value fields. In AWS Route 53: create a CAA record set. In BIND zone files: @ 3600 IN CAA 0 issue "letsencrypt.org". Always test after adding records — use this tool to verify the records are resolving correctly. If you forget to list your current CA and your certificate expires, renewal will fail.