CAA Records Explained: Control Who Issues Your SSL Certificates

What are CAA records?

A CAA record (Certificate Authority Authorisation) 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.

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 every major CA.

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 ";"

Wildcard certificates are powerful 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:[email protected]"
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 you use a CDN like Cloudflare or a SaaS platform that provisions its own certificates, you need to include their CA in your records. Cloudflare, for example, uses DigiCert, Let's Encrypt, and Google Trust Services depending on the plan.

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.

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