Domains & DNS

CAA record planning: control which certificate authorities may issue for a domain

CAA records tell certificate authorities which CAs are authorized to issue certificates for a domain. They are a policy signal, not a replacement for domain validation. A restrictive CAA set can also break automated renewal if the issuing CA or account-specific requirement is not represented.

Inventory who issues certificates today

Find the CA used by the web host, CDN, reverse proxy, mail server, control panel, API gateway, and any external service that terminates TLS for your domain. A domain can legitimately have certificates from more than one CA.

Do this before publishing a restrictive CAA policy so renewal does not fail weeks later.

Understand issue, issuewild and reporting tags

The issue property controls ordinary certificate issuance; issuewild can apply separately to wildcard certificates. Some CAs support account binding or incident-reporting parameters, but syntax and support should be verified against current CA documentation.

An empty authorization value can intentionally prohibit a class of issuance, so copy examples carefully.

Remember inheritance

CAA lookup can inherit policy from a parent label when a subdomain has no CAA record of its own. Delegated or third-party subdomains therefore deserve explicit review when their TLS service is managed elsewhere.

A CNAME can also affect where CAA processing looks, depending on the issuance scenario.

Test renewal before relying on the policy

After publishing CAA, trigger or stage certificate issuance for the services you depend on, verify public DNS from authoritative servers, and monitor renewal logs.

  • List every legitimate certificate issuer.
  • Separate wildcard policy where needed.
  • Review inheritance and delegated services.
  • Test automated renewal after changes.
Related DotMoose serviceSee the DotMoose security approach

Keep reading

Related guides.

More domains & dns →