DNS CAA Record Explained — Certificate Authority Authorization

Every publicly trusted Certificate Authority (CA) is required to check CAA (Certificate Authority Authorization) records before issuing an SSL/TLS certificate. CAA records let domain owners publish which CAs are authorized to issue certificates for their domain, closing a significant security gap in the certificate ecosystem. That certificate is later presented and verified during the TLS handshake.

Without CAA records, any publicly trusted CA could issue a certificate for your domain after normal domain validation. With CAA records in place, compliant public CAs that are not authorized by your policy must refuse.

Why CAA Records Matter

The SSL/TLS certificate system relies on trust. Hundreds of Certificate Authorities worldwide are trusted by browsers and operating systems to issue certificates for any domain. This means that even if you only use Let's Encrypt, a compromised or misbehaving CA on the other side of the world could theoretically issue a valid certificate for your domain.

CAA records reduce this risk by publishing your certificate issuance policy directly in DNS. Since public CAs are required to check CAA records (per RFC 8659 and the CA/Browser Forum Baseline Requirements), issuance by non-authorized compliant CAs should be refused before it happens.

Tip: CAA records are one of the simplest certificate-security improvements you can make. If you use public SSL/TLS certificates, you should usually have CAA records.

CAA Record Syntax

A CAA record consists of three components:

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

The Flag Field

The flag is a single integer:

• 0 (non-critical) — If a CA does not understand this tag, it may proceed with issuance. This is the standard setting for the three well-known tags.
• 128 (critical) — If a CA encounters a tag it does not understand and the critical flag is set, it must not issue a certificate. This is used with future or extension tags to ensure strict enforcement.

For the standard issue, issuewild, and iodef tags, use flag 0. All CAs understand these tags.

The Three Tag Types

issue — Authorize Standard Certificate Issuance

The issue tag specifies which CAs may issue non-wildcard certificates for the domain:

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

This allows Let's Encrypt to issue certificates for example.com and any name within the zone (such as www.example.com), unless overridden by a more specific CAA record at the subdomain level.

To authorize multiple CAs, add multiple issue records:

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

To deny all certificate issuance entirely, use a semicolon:

example.com.    3600    CAA    0 issue ";"

This is useful for domains that should never have certificates issued — for example, internal-only domains or domains reserved for future use.

issuewild — Authorize Wildcard Certificate Issuance

The issuewild tag controls which CAs may issue wildcard certificates (e.g., *.example.com):

example.com.    3600    CAA    0 issuewild "digicert.com"

If no issuewild records exist, CAs fall back to checking issue records for wildcard authorization. Once you add any issuewild record, compliant public CAs not listed in issuewild must refuse wildcard requests — the issue records no longer apply to wildcard requests.

A common pattern is to allow one CA for standard certificates and a different (or no) CA for wildcards:

; Let's Encrypt for standard certificates
example.com.    3600    CAA    0 issue "letsencrypt.org"
 
; No wildcards allowed from any CA
example.com.    3600    CAA    0 issuewild ";"

Tip: If you do not use wildcard certificates, explicitly deny them with issuewild ";". This tells compliant public CAs not to issue a wildcard for your domain, even if your issue records would otherwise permit it.

iodef — Incident Reporting

The iodef tag tells CAs where to send reports when a certificate request violates your CAA policy:

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

Reports can be sent via email (mailto:) or HTTPS endpoint. While not all CAs support iodef reporting, adding it costs nothing and can provide valuable visibility when a supporting CA receives a certificate request that violates your policy.

How CAs Check CAA Records

When a CA receives a certificate signing request (CSR) for www.example.com, the lookup process follows this order:

1. Query CAA records at www.example.com
2. If none found, query CAA records at example.com
3. If none found, query CAA records at com
4. If no CAA records are found at any level, the CA may issue the certificate

This tree-climbing behavior means you typically only need CAA records at your zone apex. Records there protect the entire domain and all subdomains.

Subdomain Overrides

You can override the apex policy for specific subdomains. This is useful when different parts of your organization use different CAs:

; Default: Let's Encrypt for the whole domain
example.com.         3600    CAA    0 issue "letsencrypt.org"
 
; Exception: shop subdomain uses DigiCert
shop.example.com.    3600    CAA    0 issue "digicert.com"

In this configuration:

• example.com and www.example.com — only Let's Encrypt
• shop.example.com — only DigiCert (the subdomain CAA overrides the parent)

Setting Up CAA for Let's Encrypt

Let's Encrypt is the most widely used free CA. Here is a complete CAA configuration that authorizes Let's Encrypt for both standard and wildcard certificates, with reporting:

example.com.    3600    CAA    0 issue "letsencrypt.org"
example.com.    3600    CAA    0 issuewild "letsencrypt.org"
example.com.    3600    CAA    0 iodef "mailto:security@example.com"

If you also use Amazon Certificate Manager (ACM) for AWS services:

example.com.    3600    CAA    0 issue "letsencrypt.org"
example.com.    3600    CAA    0 issue "amazon.com"
example.com.    3600    CAA    0 issuewild "letsencrypt.org"
example.com.    3600    CAA    0 iodef "mailto:security@example.com"

Popular CA Identifiers

Querying CAA Records with dig

Use dig to verify your CAA records are published correctly. The dig command is the standard tool for DNS lookups:

# Query CAA records for a domain
dig CAA example.com
 
# Expected output includes:
# example.com.    3600    IN    CAA    0 issue "letsencrypt.org"
# example.com.    3600    IN    CAA    0 issuewild "letsencrypt.org"
# example.com.    3600    IN    CAA    0 iodef "mailto:security@example.com"

Query against a specific nameserver to verify the authoritative response:

# Check directly against DNScale nameservers
dig CAA example.com @ns1.dnscale.eu
 
# Check against public resolvers to confirm propagation
dig CAA example.com @8.8.8.8
dig CAA example.com @1.1.1.1

To check what a subdomain inherits:

# If no CAA at www, it inherits from example.com
dig CAA www.example.com
 
# Check a subdomain with its own override
dig CAA shop.example.com

Tip: If dig CAA returns no records for a subdomain, that is expected — the CA will walk up the tree to the parent domain. You only need to worry if no CAA records exist at any level.

CAA and DNSSEC Together

CAA records tell CAs which issuers are authorized. DNSSEC cryptographically signs your DNS responses so validators can authenticate that they have not been tampered with. Together, they provide defense in depth:

• CAA without DNSSEC — A CA checks your CAA records, but an attacker who can tamper with DNS responses (via cache poisoning) could strip or modify the CAA records before the CA sees them.
• CAA with DNSSEC — The CA can verify the authenticity of the CAA response. If DNSSEC validation fails, the CA must treat the policy as unverified and refuse to issue.

For maximum protection, enable both CAA records and DNSSEC on your zones. DNScale supports DNSSEC signing and makes it straightforward to enable on any zone.

Common Mistakes

Forgetting to add your actual CA

Before adding CAA records, verify which CA issues your current certificates. If you add issue "letsencrypt.org" but your hosting provider uses DigiCert, your next certificate renewal will fail.

# Check which CA issued your current certificate
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer

Missing issuewild when using wildcards

If you use wildcard certificates and add issue records without issuewild, the issue records will apply to wildcards too (by fallback). But if you later add an issuewild ";" to block wildcards from one CA, you might accidentally block your own wildcard renewals from another.

Not updating CAA when changing CAs

When migrating from one CA to another, add the new CA to your CAA records before requesting the first certificate from them. The recommended workflow:

1. Add the new CA to your CAA issue (and issuewild if needed)
2. Request and install the new certificate
3. Remove the old CA from your CAA records after confirming the switch

Setting overly long TTLs

CAA records with very long TTLs can delay the effect of changes. A TTL of 3600 seconds (1 hour) is a good balance between caching efficiency and flexibility. If you need to make urgent changes, lower the TTL in advance following TTL best practices.

Why Most Domains Should Have CAA Records

Even if you think your domain is low-risk, CAA records are worth adding:

• Domains with websites — Reduce the chance that a non-authorized public CA issues a certificate that could be used for phishing or man-in-the-middle attacks against your users.
• Domains without websites — A domain that does not serve web traffic can use issue ";" to tell compliant public CAs to deny certificate issuance. This reduces the risk of attackers obtaining a publicly trusted certificate and setting up a convincing fake site using your domain.
• Parked or inactive domains — These are frequent targets. An attacker with a valid certificate for your parked domain can create a phishing site that browsers will show as secure.

CAA records, combined with DNSSEC and monitoring through iodef reporting, form a stronger certificate issuance policy for domains that use public certificates or should explicitly deny them.

Adding CAA Records in DNScale

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Select type CAA
4. Set the Flag (typically 0), Tag (issue, issuewild, or iodef), and Value (your CA identifier)
5. Click Create Record

Using the API

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "CAA",
    "content": "0 issue \"letsencrypt.org\"",
    "ttl": 3600
  }'

Related Record Types

• TXT records — Used for domain verification during certificate issuance (DNS-01 challenge)
• TLSA records — DANE certificate pinning, another layer of certificate security
• SSL/TLS Handshake — where issued certificates are presented and verified
• A records — The address records your certificates ultimately protect
• AAAA records — IPv6 address records, also covered by your certificates
• All DNS record types — Overview of every record type and when to use each one

Conclusion

CAA records are a straightforward security mechanism that most domain owners should deploy. By declaring which Certificate Authorities are permitted to issue certificates for your domain, you reduce the risk of certificate mis-issuance and may gain visibility through violation reporting. Combined with DNSSEC, CAA records let validating resolvers authenticate the certificate issuance policy published in your DNS zone. DNScale makes it easy to add and manage CAA records through its dashboard and API.