RedScore.ai

Fixes

DNS & Domain Security · Updated 2026-05-02

CAA Record Presence

Publish CAA records to control which Certificate Authorities can issue certificates for your domain. Examples and common pitfalls.

CAA (Certificate Authority Authorization) records list which CAs are allowed to issue certificates for your domain. Without one, anyone who briefly controls your DNS or your domain account can buy a cert from any public CA. With one, the CA is required to refuse issuance unless its name appears in your record.

Warn: no CAA records

Publish CAA records at your domain apex naming the CAs you actually use. Three properties matter:

  • issue: names a CA permitted to issue any certificate (including non-wildcard).
  • issuewild: names a CA permitted to issue wildcard certificates. If unset, issue applies to wildcards too.
  • iodef: a contact (email or URL) that CAs can notify when they receive a request that violates your policy.

Minimum viable record set

If you only use one CA, and you do not issue wildcards, this is the floor:

Example: Let's Encrypt only, no wildcards

yourdomain.tld.   IN  CAA  0 issue "letsencrypt.org"
yourdomain.tld.   IN  CAA  0 issuewild ";"
yourdomain.tld.   IN  CAA  0 iodef "mailto:security@yourdomain.tld"

issuewild ";" explicitly denies wildcard issuance from every CA. The iodef line is a tip-off channel; CAs do not all honour it, but the ones that do can warn you of attempted misissuance.

If you use multiple CAs

List every CA your stack actually uses. A single missing entry will silently break renewals.

Example: Let's Encrypt + AWS ACM + Google Trust Services

yourdomain.tld.   IN  CAA  0 issue "letsencrypt.org"
yourdomain.tld.   IN  CAA  0 issue "amazon.com"
yourdomain.tld.   IN  CAA  0 issue "amazontrust.com"
yourdomain.tld.   IN  CAA  0 issue "pki.goog"
yourdomain.tld.   IN  CAA  0 issuewild "letsencrypt.org"
yourdomain.tld.   IN  CAA  0 iodef "mailto:security@yourdomain.tld"

Common CA identifiers: letsencrypt.org, amazon.com and amazontrust.com (AWS ACM), pki.goog (Google Trust Services), digicert.com, sectigo.com, globalsign.com, certum.pl, ssl.com, buypass.com, zerossl.com.

Verify the fix

  • Run dig CAA yourdomain.tld @1.1.1.1. You should see one or more CAA answers in the response.
  • Check the next certificate renewal completes successfully. A misconfigured CAA shows up as a renewal failure on the CA side, not in DNS.
  • Re-run the RedScore lookup to confirm the verdict moves to pass.

Common pitfalls

  • Forgetting auto-issuing services. CDNs (Cloudflare, Fastly), load balancers (AWS ALB, GCP), mail providers, and observability platforms often request certs from a CA you would not have thought to list. Audit before publishing or you will block their renewals.
  • Setting CAA only on a subdomain. CAs walk up the tree from the requested name; the apex record applies to every subdomain that does not have its own CAA. Publish at the apex first, then override per subdomain only if needed.
  • Using issue ";" (deny all) without realising you do issue certs. This blocks every CA. Only use deny-all if the domain is parked and never serves TLS.
  • Omitting issuewild when you do issue wildcards. Without it, issue covers wildcards too, but if you ever add issue for a CA that should not issue wildcards, you must also add the explicit issuewild for the one that should.
  • Trailing dots, quoting, and case. CA names are case-insensitive but always lowercase by convention. The value is a quoted string. Some DNS UIs strip quotes; verify with dig after publishing.

Related check: RedScore also runs a CT-log compliance check that compares actual issuance history against your CAA policy. Once CAA is published, that check can detect after-the-fact policy violations.

What to do next

See how these recommendations apply to your site's current scan results.

Scan domain