CAA Records Explained: How to Restrict SSL Certificate Issuance for Your Domain

The Vulnerability of Universal Trust: Why SSL Certificates Need Restricting

To understand the value of a CAA Record, you must first understand the "Implicit Trust" of the internet's public keys. Your browser (Chrome, Firefox, Safari) maintain a "Root Store" of trusted Certificate Authorities. There are currently over 100 organizations on this list. By default, any single one of those 100+ organizations can issue a valid SSL certificate for yourdomain.com. They don't need your permission; they only need to verify that whoever is asking for the certificate has some level of control over the domain.

This "Universal Trust" is a significant attack vector. If a small, obscure Certificate Authority in a foreign country has a security breach, an attacker could force that CA to issue a "Rogue Certificate" for your domain. Because that CA is in the browser's root store, the rogue certificate would look perfectly legitimate to all your users. The attacker could then perform a "Man-in-the-Middle" attack, decrypting your users' traffic without triggering a single browser warning. This is not a theoretical threat; it has happened multiple times in the history of the web (e.g., the DigiNotar and Comodo breaches).

• Preventing Mis-issuance: CAA records act as a "Pre-check." They tell every CA in the world: "Unless your name is on this list, do not ever issue a certificate for me."
• Reducing Attack Surface: By restricting your domain to one or two trusted CAs (like Let's Encrypt or DigiCert), you eliminate the risk posed by the other 98+ CAs in the root store.
• Auditing and Compliance: Many security frameworks (like SOC2 or HIPAA) now look for CAA records as evidence of controlled infrastructure management.

CAA (Certification Authority Authorization, RFC 8659) became mandatory for all Certificate Authorities in September 2017. This was a landmark moment for web security. It meant that CAs were no longer "Optional" observers of your DNS; they were legally and technically required to check your CAA records before signing even a single bit of a certificate. If a CA ignores a restrictive CAA record and issues a certificate anyway, they are in violation of CA/Browser Forum rules and risk being removed from the browser root stores entirely.

In essence, CAA records move the "Ownership of Trust" from the CAs back to you, the domain owner. You are no longer at the mercy of the "weakest link" in the global CA ecosystem. Instead, you define your own "Perimeter of Trust" directly in your DNS. This makes CAA records one of the highest ROI (Return on Investment) security controls you can implement—they take five minutes to set up, cost nothing, and protect you from one of the most catastrophic types of web attacks.

CAA Logic and Issuance Handshakes: How the Check Works

The CAA check happens at the very beginning of the "Certificate Lifecycle." When you (or an automated bot like Certbot) request a certificate, the CA doesn't immediately start the validation process. Instead, their system performs a DNS query for your domain's CAA records. This happens before they verify your email or check for your webmaster validation files. If the query returns a list of authorized CAs and their name isn't on it, the CA's system is hard-wired to stop and reject the request.

This logic is "Fail-Closed" by default. If your CAA record says you only use Let's Encrypt, and an attacker tries to get a certificate from GoDaddy, GoDaddy's automated system will see the restriction and block the request immediately. The attacker never even gets the chance to try and bypass GoDaddy's domain validation checks. This prevents "Social Engineering" attacks against CA support staff as well; even a human agent at the CA cannot override a programmatic CAA rejection without triggering massive internal compliance alarms.

; The Automated CAA Workflow:
1. CA Receives Request for example.com
2. CA Queries DNS: "dig CAA example.com"
3. Result check:
   - No CAA Records -> ISSUANCE PERMITTED
   - CAA Records exist, CA is on list -> ISSUANCE PERMITTED
   - CAA Records exist, CA NOT on list -> ISSUANCE REJECTED

One critical nuance of the CAA logic is the "Parent Domain Walk-up." If the CA doesn't find a CAA record specifically at api.example.com, they don't stop there. They "Walk up" the DNS tree to check example.com. This ensures that a single record at your "Apex" domain (the main domain) can protect every single subdomain you own. This is a powerful feature for large enterprises with thousands of subdomains; you can set a global policy at the top level and be confident that it covers your entire digital footprint unless you explicitly decide to override it for a specific microservice.

This inheritance model also means that you must be careful when managing multi-tenant environments. If you are a SaaS provider hosting customers on customer1.yourdomain.com, your apex CAA record will protect them too. This is generally a good thing, but it means you must ensure you authorize the CAs that your automated SaaS platform uses. For more on how this interacts with your overall DNS strategy, see our DNS Infrastructure Guide.

Syntax and Structure: Configuring Issue, Issuewild, and Iodef

A CAA record is a single line of text with a very specific, though simple, syntax. It consists of a "Flag," a "Tag," and a "Value." Most DNS providers give you a dedicated UI for these, but it's important to understand the raw format in case you need to troubleshoot via the command line or set them up in a custom BIND zone file. The "Flag" is currently almost always 0. The only other value, 128, is the "Critical" flag, which tells the CA: "If you don't understand the tag in this record, you must refuse to issue."

The "Tag" is where the actual security logic lives. There are three primary tags used in 99% of deployments: issue, issuewild, and iodef. Understanding the difference between these is crucial for maintaining a flexible yet secure infrastructure. You can have multiple CAA records for the same domain, allowing you to authorize multiple CAs or set different rules for different types of certificates.

The issue tag is your primary control. It authorizes a CA to issue a standard certificate for your domain name (e.g., www.example.com). If you have no other records, the issue tag also covers wildcards. However, if you want to be more specific, you can use the issuewild tag. This allows you to say: "Any CA can issue a regular certificate, but ONLY DigiCert is allowed to issue a high-risk wildcard certificate (*.example.com)." This is a common strategy for enterprises that want to keep a tight lid on wildcards while allowing dev teams to use Let's Encrypt for individual services.

The iodef (Incident Object Description Exchange Format) tag is your "Alarm System." It tells a CA what to do if they see a "Rogue" request that they are forced to reject. Most major CAs will send an automated email to the address in your iodef record, including the IP address of the person who tried to get the certificate and the technical details of the request. This is your "Early Warning System" that someone is trying to attack your domain. For a deep dive into monitoring these alerts, see our Guide to Certificate Transparency and Auditing.

The Inheritance Model: Managing Domain-Wide and Subdomain Policies

The inheritance model of CAA is one of its most useful–yet most misunderstood–features. It follows a "Top-Down" logic. If you set a CAA record at example.com, that policy is inherited by every possible subdomain: www.example.com, mail.example.com, v1.api.example.com, and even deeply.nested.subdomain.example.com. This makes deployment easy because you only need to manage a single set of records at your apex domain to secure your entire infrastructure.

However, inheritance stops as soon as the CA finds an explicit record at a lower level. If you have a global "Issue Let's Encrypt" policy at the apex, but you create a specific "Issue DigiCert" record at payment.example.com, the Let's Encrypt policy for that specific subdomain is effectively deleted for the CA. It does not "Merge" the policies. This is a critical security consideration; if you create a blank or typo-ridden CAA record on a subdomain, you may accidentally disable the protection inherited from the parent domain.

• Apex Control: Set your most restrictive policy at the root (@) to ensure a secure default for the entire domain.
• Specific Overrides: Only use subdomain-level CAA records when a specific service (like a high-security backend) requires a different CA provider than the rest of the company.
• Empty Records: You can purposefully place an "Empty" CAA record on a subdomain to Block All Issuance for that specific host, regardless of what the parent domain says.

; Example of Overriding Inheritance:
example.com.     IN  CAA  0  issue  "letsencrypt.org"  ; Global Default
payment.host.    IN  CAA  0  issue  "digicert.com"     ; This OVERRIDES the apex for this host
blocked.host.    IN  CAA  0  issue  ""                ; This BLOCKS all issuance for this host

This "Last-In, First-Out" logic is designed to give technical teams maximum flexibility. A central security team can set a safe company-wide policy, but individual project teams can "Opt-out" or change their provider if they have a specific business need. It also allows you to handle complex "Zone Delegations." If you have delegated a subdomain to a third-party partner via NS Records, your apex CAA will still be checked by the CA unless that partner publishes their own CAA records in the delegated zone.

For webmasters, the best strategy is to maintain a "Single Source of Truth." Keep your CAA records at the apex whenever possible and only create subdomain records when absolutely necessary. This minimizes the risk of "Policy Drift," where different parts of your organization are following different security rules without a central audit trail. To check how your inheritance is currently behaving, use our DNS Security Audit Tool to scan your domain and its most active subdomains simultaneously.

Industry Standard Records for Leading Certificate Authorities

Every CA has a specific "ID String" that you must use in your CAA record. These strings are usually based on the CA's main website domain. For example, if you use Let's Encrypt, the tag value is "letsencrypt.org". If you use Amazon Certificate Manager (ACM), the value is "amazon.com". It is vital that you use the exact string provided by the CA in their documentation. If you make a typo (like "lets-encrypt.org"), the CA will be forced to reject your issuance request, causing your SSL renewal to fail.

The table above lists the most common values you will encounter. However, some CAs have multiple values depending on the "Brand" of certificate you are buying. For example, if you use a "PositiveSSL" certificate, the CA might be Sectigo, but you should always check the "Support" or "Documentation" section of your specific provider before publishing. Some managed providers like Cloudflare or Heroku manage these records for you automatically, but if you are managing your own DNS, the responsibility falls on you to keep this list accurate and up-to-date.

One "Advanced" feature used by major CAs is the "Account Binding" parameter. This allows you to restrict issuance not just to a CA, but to your Specific Account ID at that CA. This prevents an attacker from getting a certificate from Let's Encrypt for your domain, even if you have authorized Let's Encrypt in your CAA! You would use a value like issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678". This is the "Gold Standard" for enterprise security, as it pins your domain's trust to your specific contract and identity with the vendor.

If you are transitioning between CAs—for example, moving from DigiCert to Amazon ACM—you should have Both authorized in your DNS simultaneously. CAA records are an "Allow List," meaning you can have as many as you need. By keeping both CAs authorized during the transition period, you ensure that your old certificates can still renew if needed while your new certificates can be issued for the first time without any technical friction. Once the migration is 100% complete, you can then remove the old CA from your list of authorized providers.

Implementation, Verification, and Avoiding Outages

Adding a CAA record is non-destructive—it won't break your existing certificates. No browser will suddenly stop trusting your site because you added a CAA record today. The risk is Future Outages. If you add a CAA record and accidentally omit the CA that your automated renewal script uses, your certificate will expire, and your site will go "Dark" the next time the script tries (and fails) to renew. This makes the "Verification" phase of implementation just as important as the deployment phase itself.

Before you publish your records, you should perform an "SSL Audit" of your domain. Use a tool like SSL Certificate Checker to identify every active certificate on your domain and subdomains. Make a list of every Certificate Authority involved. If you see DigiCert on your main site but Let's Encrypt on your "Staging" site, you must include both in your apex CAA record. Once you have this list, you are ready to update your DNS.

• Check Current Records: Run dig CAA yourdomain.com to see if your DNS provider or a previous admin has already set any records.
• Simulate a Request: Some CAs (like Let's Encrypt) allow you to check your CAA status via their API before you request a certificate.
• Monitor IODEF Reports: Set up a dedicated email alias for your iodef reports so you are immediately notified if a rogue issuance is blocked.
• Low TTL for Rollout: When first adding records, set a low DNS TTL (e.g., 300 seconds) so you can quickly fix errors if you realize you've blocked a critical service.

# How to verify your CAA record from a Mac or Linux terminal:
dig CAA google.com +short

# Output: 0 issue "pki.goog"
# This confirms Google only allows their own trust service to issue certs for them.

If you manage your DNS through a third-party platform like Cloudflare, you may find that they have "Hidden" CAA records that they add automatically. Cloudflare authorizes themselves ("cloudflare.com") as part of their "Universal SSL" service. When you add your own CAA records to Cloudflare, they will typically "Merge" them with theirs. However, it is always best to manually verify the final output using a "Third-Party" resolver (like Google's 8.8.8.8) to ensure the internet sees exactly what you expect.

Finally, remember that CAA is a Preventative control, not a Detective one. Even with CAA, you should still use Certificate Transparency (CT) monitoring. While CAA blocks the issuance of rogue certificates, CT monitoring alerts you to certificates that have actually been issued. Together, they form a complete "Defense in Depth" strategy: CAA stops the attack before it happens, and CT catches anything that might have slipped through due to a CA's technical glitch. For more on this complete security stack, visit our Security Tools Dashboard.

Frequently Asked Questions

Next Steps

Perform a complete 5-minute audit of your domain's current CAA status using our DNS Security Audit Tool. This tool will simulate the exact "Check" that a Certificate Authority performs, highlighting any missing records or syntax errors that could endanger your domain.

Once you have verified your CAA records, ensure your overall "Chain of Trust" is secure by reading our guides on DNSSEC Validation and TLS Certificate Chain Integrity. If you're planning a migration to a new SSL provider, see our SSL Lifecycle Management guide for best practices on avoiding downtime.

Browse all Security Guides on DNSnexus for documentation on advanced topics like CAA Account-Binding and Certificate Transparency dashboards.

Related Guides

• SSL Certificate Expiry: How to Monitor It and Prevent Outages
• TLS Certificate Chain Validation: How to Fix Incomplete Chains
• DNSSEC Explained: How to Sign Your Zone for Maximum Security
• DNS TTL Explained: Why CAA Records Need Proper Time-to-Live
• Wildcard SSL Explained: Security Risks and Deployment Strategy