CAA Records Explained: Defining Which Certificate Authorities Can Issue for Your Domain

In the world of Public Key Infrastructure (PKI), trust matters more than anything. Organizations spend a lot of time and money securing their domains with SSL/TLS certificates, but many do not think about who is actually allowed to issue those certificates. That gap can cause serious problems. CAA records are a simple DNS tool that lets domain owners decide, clearly, which Certificate Authorities are allowed to issue certificates for their domain.

If your security program does not yet use DNS CAA records, this guide will walk you through what they are, how they work, and why every organization should be using them.

What Is a CAA Record?

A Certification Authority Authorization (CAA) record is a DNS resource record, standardized under RFC 6844 and updated by RFC 8659, that tells the world which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain or subdomain. You can think of it as a simple rule written into your DNS that tells any CA to check permission before issuing a certificate.

A basic CAA record looks like this:

This record tells every CA: only Let’s Encrypt is allowed to issue certificates for example.com. Any other CA that gets a certificate request for that domain is required by the CA/Browser Forum Baseline Requirements to check for CAA records and follow the rules or refuse to issue. CAA records also follow DNS hierarchy. If a subdomain does not have its own CAA record, the CA will look at the parent domain and apply those rules instead, making it easy to manage policy across a large number of domains.

How CAA Records Define Authorized Certificate Authorities

CAA records work by connecting specific CA identifiers to your domain in DNS. When a CA receives a request to issue a certificate, it looks up CAA records for that domain. If a CAA record exists and the CA is not listed, it must refuse. If no CAA record exists at all, any CA is free to issue certificates for your domain, which is the kind of open door that security teams need to close.

You can list more than one CA in your CAA records. This is useful for organizations that use different CAs for different purposes, such as a public CA for customer-facing services and a private CA for internal systems. Each authorized CA gets its own CAA entry, and the CA must match at least one entry to proceed with certificate issuance.

Understanding the issue, issuewild, and iodef Tags

CAA records use three main property tags to control certificate issuance. Each tag does something different, and understanding all three is important for setting up your records correctly.

Issue: This tag names which CA is allowed to issue standard certificates for your domain. For example, 0 issue “digicert.com” gives DigiCert permission to issue certificates for that domain.

Issuewild: This tag controls which CAs can issue wildcard certificates, such as *.example.com. This is separate from the issue tag, so you can have a more open policy for standard certificates but a stricter one for wildcard certificates, depending on your security needs.

Iodef: This tag tells CAs where to send a report if they receive a certificate request that violates your policy. You can point it to an email address or a URL, like this:

0 iodef "mailto:[email protected]"

One thing to watch out for: if you only set an issuewild tag without an issue tag, any CA can still issue standard certificates for your domain. The two tags are independent, so always configure both to make sure your policy is complete.

Why CAA Records Are Essential for Domain Security

Unauthorized certificate issuance is a real problem. Whether it happens through social engineering, a mistake at the CA, or a compromised system, certificates have been wrongly issued for well-known domains. When that happens, attackers can intercept encrypted traffic, run man-in-the-middle attacks, or pretend to be legitimate services.

CAA records do not prevent every possible attack, since they rely on CAs checking and following them, and compliance is governed by the CA/Browser Forum. But since September 2017, all publicly trusted CAs are required by the CA/Browser Forum Baseline Requirements to check CAA records before issuing. A CA that ignores this risks losing its trusted status, which is a serious consequence.

CAA records also support regulatory compliance. Under frameworks like SOC 2, ISO 27001, and PCI DSS, being able to show that you control which CAs issue certificates for your domain is a solid, documentable security control. It helps with audits and shows your organization is managing domain security properly.

How Certificate Authorities Validate CAA Records

When a CA receives a certificate request, it runs a DNS lookup for CAA records on the fully qualified domain name (FQDN) in the request. If records are found and the CA is not listed, it refuses to issue. If the DNS query fails due to a SERVFAIL, timeout, or misconfiguration, the CA must also refuse. This fail-secure approach means that a broken setup protects you rather than leaving you exposed.

DNSSEC adds another layer of protection here. Without DNSSEC, CAA records can be spoofed through DNS cache poisoning, where an attacker inserts false records that allow their chosen CA to issue a certificate. When your DNS zones are signed with DNSSEC, the accuracy and integrity of your CAA records are guaranteed at the cryptographic level.

If no CAA record exists for a specific FQDN, the CA walks up the DNS tree to the parent domain, then the grandparent, until it finds one. This means a single CAA record at your apex domain can cover your entire domain namespace, which is a very efficient way to enforce policy at scale.

Best Practices for Configuring and Managing CAA Records

Setting up CAA records is straightforward but doing it well takes some planning. Here are the key practices to follow:

• Audit your certificate inventory first: Before adding CAA records, find out which CAs are already issuing certificates for your domains. Tools like crt.sh can help you do this. If you restrict issuance to a CA, you are not actually using, certificate renewals will fail.
• Set both issue and issuewild tags explicitly: Do not assume that one covers the other. Be clear about which CAs can issue standard and wildcard certificates and keep a record of why each CA is authorized.
• Add an iodef tag and actually monitor it: Reports only help if someone reads them. Connect your iodef endpoint to your security team’s ticketing system or SIEM, and treat any violation alerts seriously.
• Use CAA records alongside DNSSEC: DNSSEC makes sure your CAA policy cannot be faked at the DNS level. If your zones are not yet DNSSEC signed, this is a good reason to get started.
• Test your CAA records after publishing: Use tools like dig, the SSLMate CAA Record Generator, or MX Toolbox to check that your records are resolving correctly from multiple locations.
• Update CAA records whenever your CA relationships change: Any time you switch CAs, sign a new vendor, or go through a merger, update your CAA records to match. Outdated records can be just as risky as missing ones.

How Encryption Consulting Can Help

Setting up CAA records correctly starts with knowing exactly which Certificate Authorities are already issuing certificates for your domains. Without that inventory, you risk locking out a CA that is actively renewing certificates, which causes outages the moment a renewal fails. That audit is where most organizations get stuck, and it is where CertSecure Manager makes the biggest difference.

CertSecure Manager is Encryption Consulting’s Certificate Lifecycle Management platform. It gives your team a complete, continuously updated inventory of every SSL/TLS certificate across your environment, including which CA issued each one, when it expires, and where it is deployed. That visibility is exactly what you need before writing a single CAA record.

Here is how CertSecure Manager addresses each of these challenges:

Certificate Discovery and Inventory: Our CertSecure Manager scans your network and cloud environments to surface every certificate in use, no matter which CA issued it. Before you restrict issuance through CAA records, you need to know what is already out there. It handles that step automatically.

CA Relationship Tracking: As your CAA policy is only as accurate as your knowledge of which CAs you actually use, CertSecure Manager keeps your certificate inventory current so your CAA records stay aligned with reality, even as your environment grows or your CA relationships change.

Renewal Automation: Once your CAA records are in place, any certificate renewal that goes to an unauthorized CA will fail. CertSecure Manager automates renewals through your authorized CAs, so there are no last-minute surprises when a certificate is about to expire.

Audit Trail for Compliance: For frameworks like SOC 2, ISO 27001, and PCI DSS, being able to demonstrate control over certificate issuance is a documentable security control. CertSecure Manager logs every certificate event, giving your compliance team the evidence they need.

CAA records give you policy. CertSecure Manager gives you the visibility and automation to make that policy work consistently across your entire certificate environment.

Conclusion

CAA records are easy to miss because they work quietly in the background but leaving them out creates a real security gap. As certificate misissuance continues to be a risk across the internet, domain owners need to take control of who can issue certificates on their behalf. CAA records give you that control in a simple, standardized way.

When CAA records are set up correctly and paired with DNSSEC, a monitored iodef endpoint, and a solid certificate management process, they become a meaningful part of your PKI strategy. They are not hard to implement, but they do need to be kept up to date as your environment changes.