CAA Records Explained: How to Restrict Which Certificate Authorities Can Issue SSL/TLS Certificates for Your Domain

Every HTTPS connection on the internet depends on a chain of trust: a Certificate Authority (CA) signs an SSL/TLS certificate proving your domain belongs to you. But what if you could publish a DNS record that says, "Only these specific CAs are allowed to sign certificates for this domain"? That is exactly what a CAA record (Certificate Authority Authorization) does — and it is one of the most underused security controls in DNS.

What Are CAA Records?

A CAA record is a DNS record type (numeric value 257) defined in RFC 6844 and later updated by RFC 8659. It lets a domain owner declare which certificate authorities are authorized to issue certificates for the domain and its subdomains.

Here is the key part that makes CAA powerful: since September 2017, CAA checking is mandatory for all CAs under the CA/Browser Forum Baseline Requirements. That means if you publish a CAA record, every legitimate CA must check it before issuing a certificate. If they aren't on the list, they have to refuse the request.

If you don't publish any CAA records, the default rule applies: any CA can issue for your domain. That's fine in most cases, but it also means your domain is exposed to the risk of a compromised or badly-vetted CA issuing a rogue certificate.

How CAA Record Syntax Works

A CAA record is built from three components: flags, tag, and value.

example.com.  CAA  0  issue  "letsencrypt.org"

• Flags: An integer (usually 0). The value 128 marks the record as "critical," meaning a CA that doesn't understand the tag must refuse issuance. Use 0 unless you have a specific reason not to.
• Tag: The property type. The three main ones are issue, issuewild, and iodef.
• Value: The value depends on the tag. For issue, it's the domain name of an allowed CA.

The Three Important Tags

• issue — Restricts which CAs can issue certificates for the domain.
• issuewild — Restricts which CAs can issue wildcard certificates (*.example.com).
• iodef — Specifies a URL or email address where CAs should send reports about policy violations and failed issuance attempts.

Real-World Examples

Example 1: You Only Use Let's Encrypt

Suppose you manage your certificates with ACME and Let's Encrypt exclusively. You could publish:

example.com.  CAA  0  issue  "letsencrypt.org"

This tells all other CAs to stay away. Simple and effective.

Example 2: Multiple Allowed CAs

Most production setups use more than one CA, either for redundancy or because different teams use different providers:

example.com.  CAA  0  issue  "letsencrypt.org"
example.com.  CAA  0  issue  "digicert.com"
example.com.  CAA  0  issue  "sectigo.com"

Example 3: Block Wildcard Issuance Entirely

If you never use wildcard certificates, you can block them outright with a semicolon value:

example.com.  CAA  0  issuewild  ";"

The semicolon means "no CA is authorized for wildcard issuance." This is a great hardening step because wildcard certificates are a prime target for attackers — a leaked wildcard private key compromises every subdomain.

Example 4: Add Reporting

example.com.  CAA  0  iodef  "mailto:[email protected]"

Now, if a CA attempts to issue and gets rejected (or sees a policy violation), they'll send a report to that inbox. It's a free piece of monitoring for your certificate ecosystem.

How CAA Records Are Looked Up

When a CA receives a certificate request, it performs a CAA lookup by walking up the DNS tree from the requested name to the parent zone. The first record set it finds is the one that applies. This means:

• A CAA record on example.com applies to sub.example.com unless that subdomain has its own CAA record.
• A CAA record on sub.example.com overrides the parent for that subdomain.

Common Pitfalls (and How to Avoid Them)

1. Forgetting the CA You Already Use

The most common real-world incident is simple: a sysadmin adds a CAA record allowing only DigiCert, forgetting that automatic renewal for their Let's Encrypt certificates runs on the 30th of the month. When renewal day arrives, Let's Encrypt refuses to issue, and the certificate expires publicly. Actionable advice: before publishing any CAA record, list every CA currently used in your organization — including ones used by other teams, contractors, or SaaS products that provision certs on your behalf.

2. Not Including a Backup CA

What happens if your primary CA has an outage? If it's your only authorized CA, you're stuck. Best practice: always allow at least two CAs, ideally on different infrastructures.

3. Putting CAA Records on the Wrong Zone

CAA records only take effect if placed in the authoritative zone for the domain. Verify you're editing the parent DNS zone, not a subdomain zone, unless you're deliberately scoping to that subdomain.

4. Testing Without Verifying

After changing CAA records, always verify the change propagated. You can use dig from your terminal:

dig CAA example.com +short

Or, if you prefer a browser-based approach, use the DNS Analyzer on Whose.Domains to check your CAA records alongside your full DNS configuration. Then re-run your certificate renewal or request a test certificate to confirm nothing broke. If your HTTPS is already live, you can also check the final result with the SSL Checker to confirm your certificate chain is still clean.

Best Practices Summary

• Start small: publish CAA records for a staging domain first, then roll out to production.
• Use issuewild ";" to block wildcard certs if you don't need them.
• Add an iodef record so you're alerted to unauthorized issuance attempts.
• Keep a backup CA in your list to avoid availability problems.
• Revisit quarterly: CAs change, teams change, and certificate strategies change. Make CAA review part of your regular DNS hygiene.

Final Thoughts

CAA records are a rare win in security: they take five minutes to implement, require no software changes, and meaningfully reduce your attack surface. With CA checking now mandatory across the industry, the only thing standing between you and a stronger certificate posture is a single DNS record.

Check your current DNS configuration, decide which CAs you genuinely trust, and publish your first CAA record today. Your future self — and your security team — will thank you.