CAA Records Explained: Control Who Issues Your SSL Certificates

What are CAA records?

A CAA record (Certification Authority Authorization) is a type of DNS record that specifies which certificate authorities are allowed to issue SSL/TLS certificates for a given domain. The standard is defined in RFC 8659, which replaced the original RFC 6844.

Since September 2017, all publicly trusted certificate authorities have been required to check CAA records before issuing a certificate. This requirement was mandated by the CA/Browser Forum Ballot 187. If a CA finds a CAA record that does not list them as an authorised issuer, they must refuse to issue the certificate.

Without CAA records, any CA in the world can issue a certificate for your domain. That is hundreds of organisations, each of which could be compromised or tricked into misissuance. CAA records narrow that list down to only the CAs you actually use.

On 16 October 2026, 9 of the 192 UK MSPs in ShieldMarc's quarterly audit (5%) published CAA records, the rarest of the controls it checks, and none of the 60 whose DNS Cloudflare hosts did.

You can check whether your domain already has CAA records using our free CAA Checker.

CAA record syntax

A CAA record consists of three parts: a flag, a tag, and a value. The general format is:

example.com.  IN  CAA  <flag> <tag> "<value>"

The flag is usually set to 0. A flag value of 128 marks the record as “critical”, meaning a CA that does not understand the tag must refuse to issue rather than ignoring it.

There are three standard tags:

• issue: Authorises a CA to issue standard (non-wildcard) certificates for the domain.
• issuewild: Authorises a CA to issue wildcard certificates for the domain. If no issuewild record is present, the issue records apply to both standard and wildcard certificates.
• iodef: Specifies a URL or email address where CAs should send reports when a certificate request violates your CAA policy.

CAA record examples

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

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issue "digicert.com"
example.com.  IN  CAA  0 issuewild "letsencrypt.org"

parked.example.com.  IN  CAA  0 issue ";"
parked.example.com.  IN  CAA  0 issuewild ";"

Not sure which CA identifier to use? Our CAA Record Generator produces ready-to-paste records for the main certificate authorities.

How to create CAA records

The process varies slightly depending on your DNS provider, but the general steps are the same:

1. Identify which CAs you use. Check the issuer field on your existing certificates. You can do this quickly with our SSL Checker.
2. Look up the correct CA identifier. Each CA has a specific domain string that must appear in the CAA value. For example, Let's Encrypt uses letsencrypt.org, DigiCert uses digicert.com, and Sectigo uses sectigo.com.
3. Add the records in your DNS provider. In Cloudflare, go to DNS > Records > Add Record, select type CAA, and fill in the tag and value. In AWS Route 53, create a new record set with type CAA and enter the value in the format 0 issue "letsencrypt.org". Most other providers follow a similar pattern.
4. Add both issue and issuewild tags. If you only add issue records, they will also apply to wildcard certificates by default. If you want different rules for wildcards, add explicit issuewild records.
5. Verify your records. After saving, use the ShieldMarc CAA Checker to confirm your records are published and correctly formatted.

If you prefer a guided approach, our CAA Record Generator walks you through the process and outputs the exact DNS records you need.

CAA and wildcard certificates

The issuewild tag controls which CAs can issue wildcard certificates (for example, *.example.com). If you do not publish any issuewild records, CAs will fall back to your issue records when deciding whether to issue a wildcard.

This means that if you want to restrict wildcard issuance more tightly than standard issuance, you must add explicit issuewild records. For example, to allow DigiCert to issue standard certificates but block all wildcard issuance entirely:

example.com.  IN  CAA  0 issue "digicert.com"
example.com.  IN  CAA  0 issuewild ";"

When Cloudflare runs the DNS and these records are at the zone apex, as here, the issuewild records Cloudflare adds there still let its certificate authorities issue wildcards while Universal SSL is on.

Wildcard certificates are convenient but carry additional risk. If a wildcard certificate is compromised, it can be used to impersonate any subdomain. Restricting wildcard issuance through CAA is a sensible precaution for most organisations.

The iodef tag: incident reporting

The iodef tag tells CAs where to send notifications when someone attempts to request a certificate that violates your CAA policy. The value can be a mailto: address or an HTTPS endpoint:

example.com.  IN  CAA  0 iodef "mailto:security@example.com"
example.com.  IN  CAA  0 iodef "https://example.com/caa-report"

Not all CAs support iodef reporting, but adding it costs nothing and gives you an additional layer of visibility. If a CA does honour it, you will receive early warning of any unauthorised certificate requests targeting your domain.

CAA and DNSSEC: why signing matters

CAA records are only as trustworthy as the DNS responses that carry them. Without DNSSEC, an attacker who can perform a DNS spoofing attack could forge a response that removes or modifies your CAA records, tricking a CA into issuing a certificate it should have refused.

When DNSSEC is enabled, every DNS response is cryptographically signed. A CA checking your CAA records can verify that the response is authentic and has not been tampered with. This makes DNSSEC and CAA a strong combination: CAA defines who is authorised to issue certificates, and DNSSEC ensures that definition cannot be forged.

Check whether your domain has DNSSEC enabled using our DNSSEC Checker.

Common CAA mistakes

• Forgetting issuewild: If you add issue records but no issuewild records, the issue records will also control wildcard issuance. If you want to restrict wildcards differently (or block them entirely), you must add explicit issuewild records.
• Using the wrong CA identifier: Each CA has a specific identifier string. Using "letsencrypt.com" instead of "letsencrypt.org" will silently block issuance. Always verify the correct string from the CA's documentation, or use our CAA Record Generator to avoid typos.
• Misunderstanding subdomain inheritance: CAA records are inherited by subdomains. If you set CAA on example.com, it applies to app.example.com and every other subdomain unless they have their own CAA records. This is usually desirable, but be aware of it when different subdomains use different CAs.
• Blocking your own renewal: If you add CAA records but forget to include the CA that your automated renewal process uses (such as Let's Encrypt via certbot), your next renewal will fail silently. Always test by verifying your records with the CAA Checker after making changes.
• Overlooking CDN and SaaS providers: If a CDN or a SaaS platform provisions certificates for you, your records must allow its CAs. Cloudflare is a special case. When it runs your DNS, it adds records for its own CAs at the zone apex while Universal SSL is on, so you do not need to add those there. If Universal SSL is off, allow the CA of your advanced certificate (letsencrypt.org, pki.goog or ssl.com). Cloudflare adds nothing to a name below the apex that has CAA records of its own, to a CNAME setup or to a subdomain zone whose parent is hosted elsewhere: there, if Cloudflare manages your certificate, allow Let's Encrypt (letsencrypt.org), Google Trust Services (pki.goog) and SSL.com (ssl.com) yourself, or the CA that issues a certificate you upload. A zone with no CAA records at all is unrestricted, on Cloudflare or anywhere else.

How to check your CAA records

The quickest way to inspect your current CAA setup is with our CAA Checker. Enter your domain and you will see all published CAA records, along with a summary of which CAs are authorised for standard and wildcard issuance.

You can also check from the command line using dig:

dig CAA example.com

If the response is empty, no CAA records are published and any CA can issue certificates for your domain. For a broader view of your domain's security posture, including SSL, DMARC, SPF, and DNSSEC alongside CAA, run a Security Grade Check.

Next steps

CAA records are one of the simplest and most effective controls you can add to your domain. They take minutes to set up and immediately reduce the risk of unauthorised certificate issuance. Here is what to do next:

1. Check your existing CAA records to see your current state.
2. Inspect your SSL certificate to identify which CA issued it.
3. Use the CAA Record Generator to create your records.
4. Publish the records in your DNS and verify them.
5. Enable DNSSEC to protect your CAA records from spoofing.

Our blog post on CAA record management covers checks and fixes for a domain that already has records.

For more on securing your domain's email alongside its certificates, read our guides on What is DMARC? and SSL Certificate Monitoring.

Frequently asked questions