Certificate Authority Authorisation records (CAA) are a DNS record type standardised in RFC 6844 and made mandatory for CAs to check in 2017. A CAA record on your domain tells CAs which of them are permitted to issue certificates for that domain. Any CA that checks CAA records — which all publicly trusted CAs are now required to do — must refuse to issue a certificate if the domain's CAA records do not authorise them.

Without a CAA record, there is no restriction. Any CA can issue. With a CAA record listing your approved CAs, every other CA is prohibited from issuing for your domain.

What a CAA record looks like

CAA records have a straightforward format. A typical configuration authorising Let's Encrypt and DigiCert:

yourdomain.com.  IN  CAA  0  issue  "letsencrypt.org"
yourdomain.com.  IN  CAA  0  issue  "digicert.com"
yourdomain.com.  IN  CAA  0  issuewild  "letsencrypt.org"
yourdomain.com.  IN  CAA  0  iodef  "mailto:security@yourdomain.com"

The key fields:

  • issue — specifies a CA authorised to issue regular (non-wildcard) certificates
  • issuewild — specifies a CA authorised to issue wildcard certificates. If absent, the issue tag applies to both. If present, it overrides issue for wildcards.
  • iodef — an email address or URL where CAs should report failed issuance attempts due to CAA policy. This gives you visibility when someone tries to get a certificate for your domain from an unauthorised CA — an indicator of reconnaissance or attempted mis-issuance.

CAA records are inherited down the DNS tree. A CAA record on yourdomain.com applies to all subdomains unless overridden by a CAA record on the subdomain itself. This means a single CAA record at the apex covers your entire domain.

What CAA protects against

Rogue CA issuance. If a CA is compromised or coerced into issuing fraudulent certificates, CAA limits the impact to CAs you have already authorised. A compromised CA not on your CAA list cannot issue for your domain.

Social engineering attacks on CAs. Attackers have successfully impersonated domain owners to obtain certificates from CAs by exploiting lax domain validation processes. CAA adds a layer of restriction — even if an attacker convinces a CA to issue, the CA must first be authorised in your CAA records.

Unauthorised internal issuance. When developers or teams within your organisation go to a non-standard CA to get certificates without going through official channels, CAA provides visibility via iodef reports and limits which CAs can comply with such requests.

Mis-issuance detection through CT monitoring. CAA and Certificate Transparency are complementary controls. CAA prevents unauthorised issuance. CT logs detect it if prevention fails. If a certificate appears in CT logs from a CA not on your CAA list, it is either a CA that ignored the check (a compliance failure to report) or a mis-issuance that warrants investigation.

What CAA does not protect against

CAA is not a complete solution. Important limitations:

  • CAs you have authorised can still mis-issue. CAA limits which CAs can issue, but it does not prevent mis-issuance by authorised CAs. If Let's Encrypt mis-issues a certificate for your domain due to a domain validation failure, your CAA record authorising Let's Encrypt does not prevent it.
  • CAA is checked at issuance time, not continuously. A CA checks CAA at the moment of issuance. If you add a CA to your CAA records, that CA can issue. If you remove a CA, certificates already issued by that CA remain valid until they expire — the change is not retroactive.
  • DNS compromise undermines CAA. If an attacker can modify your DNS records, they can modify your CAA records. CAA's effectiveness depends on your DNS infrastructure being secure.
  • Not all clients check CAA. CAA is enforced by CAs, not by browsers. A browser connecting to a site does not independently verify that the certificate was issued by a CA on the domain's CAA list. The enforcement is entirely on the issuance side.

How to implement CAA records

Adding CAA records is straightforward if you have access to your DNS management interface:

  1. Identify which CAs you use. Check your certificate inventory for the issuing CAs of all certificates currently in use across your domains. Ensure all of them are included in your CAA records before adding the restriction — a CAA record that excludes a CA you are currently using will prevent renewal of those certificates.
  2. Add records for your primary domain. The apex CAA record covers all subdomains by inheritance, so you typically only need records at yourdomain.com unless specific subdomains need different CA policies.
  3. Add an iodef record. Configure a security email or webhook endpoint as the iodef target. This gives you visibility when CAs decline issuance requests due to your CAA policy — a useful signal that is often overlooked.
  4. Verify using a CAA checker. Several online tools allow you to verify that your CAA records are correctly configured and will be interpreted as intended by CAs.
  5. Monitor CT logs for violations. After adding CAA records, monitor CT logs for certificates from CAs not on your list. Any such certificate warrants investigation and potentially a report to the CA/Browser Forum.

CAA records in CertControl

CertControl's external scanner checks for CAA records on all monitored domains and flags domains that lack them as a security finding. For domains that have CAA records, the platform cross-references certificates found in CT logs against the authorised CAs in the CAA configuration — surfacing any certificates from unauthorised CAs immediately as high-priority findings.

The combination of CAA record presence monitoring and CT log cross-referencing gives you both sides of the control: verification that the policy is in place, and detection when it is violated.

See the platform Book a demo