CAA records let a domain operator express which certificate authorities may issue certificates for its names. An incomplete policy can block a legitimate hosting or CDN renewal. Build the policy from the authorities your actual services use, including wildcard issuance where relevant.
IN THIS ARTICLE
What you need before you begin
Inventory certificates for the website, CDN, mail endpoints and other managed services. Ask each provider for its current CAA issuer identifier. Keep access to the authoritative DNS service and record the existing CAA set before changing it.
01 Use CAA records to authorise the certificate authorities your services need
- Query CAA at the affected hostname and relevant parent names. A provider or certificate authority evaluates applicable policy according to CAA processing rules; an empty local result alone does not prove there is no inherited policy.
- Add issue entries for the required certificate authorities using their documented identifiers. Do not use a company marketing name or an invented certificate hostname.
- Review issuewild if wildcard certificates are used. An explicit wildcard policy can differ from the ordinary issuance policy, so confirm both paths.
- Preserve other intentional CAA properties and understand any critical flag before copying it. Do not create a restrictive policy from an unrelated website's example.
- Query the published set, then retry issuance through the actual service. Use its staging or test workflow where available to avoid repeated production requests.
02 Example: authorise the certificate authority you actually use
If your certificate workflow uses Let's Encrypt, its documented CAA issuer identifier is letsencrypt.org. The following is an illustrative record, not a recommendation to replace an existing policy. First inventory every certificate service used by the domain and its subdomains.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
dig example.com CAA +noall +answer
Read the result: The issue tag authorises the specified issuer for the applicable policy. An existing issuewild record controls wildcard issuance separately. Review inherited and alias-related CAA behaviour when a certificate name is a subdomain or follows a CNAME. A typo can block renewal even while the current certificate still works.
Include every certificate authority your reviewed design requires, then test the actual issuance workflow. CAA does not issue or install a certificate and cannot repair an expired certificate by itself. Keep the previous record set for a controlled reversal.
Confirm the expected result
Confirm the authority's current validation result and the issued certificate's names. Check upcoming renewals for other services affected by an inherited apex policy.
Troubleshoot unexpected results
CAA lookup failures can arise from DNSSEC, delegation or network issues rather than a deliberately denied issuer. Resolve the DNS failure first and keep the exact certificate-provider error for support.
A common question
Does adding a CAA record immediately revoke a certificate that already exists?
No. CAA governs issuance checks; it is not a revocation mechanism or a replacement for protecting private keys. If a key is compromised, request replacement and revocation through the certificate provider and fix the exposed credential path.