How to Fix Missing CAA Records
Use this page when the CAA Record Analyzer shows no effective issuance policy, or a policy that is broader than the certificate authorities you actually use.
What This Means
Without CAA records, any publicly trusted certificate authority is allowed to issue certificates for the domain. The fix is straightforward but must be sequenced carefully: inventory every CA that currently issues for the domain first, because publishing CAA records that omit a CA in active use will block its next renewal.
| Signal | What to verify | Why it matters |
|---|---|---|
| No CAA anywhere | Whether the domain or any parent publishes CAA | Any public CA may issue, enabling convincing mis-issuance. |
| Overly broad issue tags | Which CAs are authorized versus actually used | Stale authorizations widen the issuance attack surface. |
| No issuewild tag | Whether wildcard issuance policy is explicit | Wildcard certificates inherit issue tags unless restricted. |
| No iodef contact | Whether violation reports reach a monitored inbox | You never learn about blocked unauthorized issuance attempts. |
Common Causes
Patterns worth checking first
- Never configured: CAA is optional and most zones were created before it became common practice.
- Unknown CA inventory: Teams avoid publishing CAA because they are unsure which CAs their CDN or SaaS platforms use.
- Provider limitations: Some legacy DNS providers lacked CAA support, so the record was skipped.
How To Confirm It Safely
Confirmation steps
- List every active certificate for the domain and identify its issuing CA.
- Include certificates managed by CDNs, load balancers, and SaaS platforms.
- Check parent domains for existing CAA records that subdomains inherit.
- Confirm your DNS provider supports the CAA record type before planning the change.
Fix Workflow
- Inventory issuing CAs. Identify every CA that currently issues for the domain, including managed platforms.
- Publish issue tags. Authorize only the CAs from the inventory on the apex domain.
- Set wildcard policy. Add an explicit issuewild tag, authorizing a CA or denying with ";".
- Add iodef and validate. Publish a monitored reporting contact, then test a renewal and re-run the analyzer.
Implementation 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"Rollout Risks
Omitting a CA in active use blocks its next renewal
CAA is enforced at issuance time, so the failure appears later as a renewal error.
- Inventory managed-platform certificates before publishing.
- Test a renewal shortly after rollout instead of waiting for expiry.
- Add the missing CA rather than deleting the whole policy if a renewal fails.
Managed platforms can switch certificate authorities
CDNs and SaaS providers sometimes change their issuing CA without notice.
- Review provider documentation for their supported CAs.
- Authorize the provider's documented CA set, not only the one currently observed.
- Re-check the policy when changing certificate or CDN providers.
Validation Checklist
Post-fix validation
- The effective CAA policy lists only the certificate authorities in active use.
- Wildcard issuance policy is explicit via an issuewild tag.
- The iodef contact points to a monitored mailbox.
- A test issuance or renewal succeeds and the CAA Record Analyzer confirms the intended policy.
FAQ
Will publishing CAA break my existing certificates?
No. CAA is only checked when a certificate is issued, so existing certificates keep working.
- Renewals are the moment of risk, so authorize the renewing CA first.
- Test a renewal early instead of waiting for expiry pressure.
Should subdomains have their own CAA records?
Usually not. CAs walk up the DNS tree, so apex policy covers subdomains by default.
- Publish subdomain CAA only when a different policy is genuinely needed.
- Keep policy centralized at the apex for predictable inheritance.