CAA Record Analyzer Guide
Use this guide to understand how certificate authorities evaluate CAA records, why parent-domain inheritance matters, and how to publish a policy that authorizes only the CAs you actually use without blocking renewals.
Overview
CAA is the control certificate authorities are required to check before issuing. The analyzer resolves the effective policy, including inheritance from parent domains, because the record a CA honors is not always the one published on the exact host being requested.
Policy elements to review together
- issue: Authorize only the CAs that issue your standard certificates.
- issuewild: Decide explicitly whether wildcard issuance is allowed and by whom.
- iodef: Publish a reporting contact so violation attempts reach a monitored inbox.
CAA Signals and Meaning
| Signal | Healthy state | Common weakness |
|---|---|---|
| CAA presence | Records exist on the domain or a parent | No CAA anywhere, so any public CA may issue. |
| issue tags | Lists only the CAs in active use | Overly broad authorization left over from old providers. |
| issuewild | Explicit wildcard policy | Wildcard issuance implicitly allowed via issue tags. |
| iodef | Monitored reporting contact published | No visibility when an unauthorized CA is asked to issue. |
| Inheritance | Effective policy matches intent at every level | Subdomain policy unintentionally overridden or missing. |
Practical CAA Examples
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef "mailto:security@example.com"example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"Recommended Remediation Flow
- Inventory certificates in use List every CA that currently issues for the domain, including CDN and SaaS-managed certificates.
- Publish issue tags for those CAs Authorize only the CAs from the inventory; use ";" to explicitly deny if a tag should block issuance.
- Decide wildcard policy Add issuewild explicitly, either authorizing a CA or denying wildcard issuance with ";".
- Add iodef and retest Publish a monitored reporting contact, then re-run the analyzer and confirm renewals still succeed.
Troubleshooting Common Issues
Certificate renewal fails after publishing CAA
The renewing CA is usually missing from the issue tags, often because a CDN or load balancer manages the certificate.
- Check which CA the failing service actually uses.
- Add that CA to the issue tags rather than removing CAA entirely.
- Remember managed platforms can switch CAs; review their documentation.
Subdomain shows a different effective policy
CAs walk up the DNS tree, so the first CAA set found wins for that name.
- Publish CAA on the subdomain only when it needs a different policy.
- Otherwise keep policy at the apex so inheritance stays predictable.
- Re-run the analyzer on both the apex and key subdomains.
Validation Checklist
Post-fix validation
- Confirm the effective policy lists only the CAs in active use.
- Verify wildcard issuance policy is explicit via issuewild.
- Check that the iodef contact points to a monitored mailbox.
- Issue or renew a test certificate to confirm the policy does not block legitimate issuance.
FAQ
Does CAA stop attackers who control my DNS?
No. CAA protects against mis-issuance requests, not full DNS compromise.
- An attacker with DNS control can change CAA records too.
- Combine CAA with registrar locks and DNS provider MFA.
- Monitor Certificate Transparency logs for unexpected issuance.
Will adding CAA break existing certificates?
No. CAA is only checked at issuance time, so existing certificates keep working.
- Renewals are affected, so authorize the renewing CA before publishing.
- Roll out during a quiet period and test a renewal early.
- Keep the policy reviewed whenever you change certificate providers.