CAA DNS records tell certificate authorities which CAs are allowed to issue TLS certs for your domain — blocking ro…
What are CAA records?
CAA (Certificate Authority Authorization) records are DNS records that explicitly define which Certificate Authorities (CAs) are permitted to issue SSL/TLS certificates for a domain.
A CAA record acts as a gatekeeper. By publishing a CAA policy in your DNS zone, you prevent unauthorized or compromised CAs from issuing rogue certificates for your domain. CAA Records sits close to the public DNS layer that resolvers, browsers, inbox providers, and attackers all see. That makes configuration quality and change control just as important as the underlying standard itself.
Frequently Asked Questions
If you are already working through SSL / TLS and Certificate Transparency, this topic gives you the missing layer between the raw signal and the decision you have to make.
Why CAA exists
Historically, the PKI (Public Key Infrastructure) trust model had a major flaw: any of the hundreds of trusted root CAs globally could issue a valid certificate for any domain. If a single CA was compromised—or simply had weak validation practices—an attacker could purchase a valid cert for google.com or yourbank.com.
Notable misissuance incidents (like the DigiNotar compromise) proved that relying purely on CA competence was insufficient. The industry needed a way for domain owners to restrict issuance authority, leading to the creation of the CAA standard.
CAA record syntax: issue, issuewild, iodef tags
CAA syntax is straightforward but strict. It consists of three main components: a flag field, a tag, and a value.
Syntax Breakdown
DNS Record / Config
example.com. IN CAA <flag> <tag> "<value>"
Flag: Usually 0. A value of 128 means the record is critical and a CA must not issue a cert if it doesn't understand the tag.
Tag: Specifies the property being set (e.g., issue, issuewild, iodef).
Value: The CA's domain name or a contact URI.
Tags with real examples
issue: Authorizes a specific CA to issue single-name or SAN certificates.
DNS Record / Config
example.com. IN CAA 0 issue "letsencrypt.org"
issuewild: Authorizes a specific CA to issue wildcard certificates (*.example.com).
DNS Record / Config
example.com. IN CAA 0 issuewild "digicert.com"
iodef: Specifies a URL or email address where CAs should report invalid issuance requests.
DNS Record / Config
example.com. IN CAA 0 iodef "mailto:security@example.com"
How CAs check CAA before issuance
As of 2017, the CA/Browser Forum (the governing body for public PKI) made CAA checking mandatory.
When you request a certificate from a CA, the CA must look up the CAA records for your domain (RFC 8659 requirement).
If no CAA records exist, the CA assumes it is permitted to issue the cert.
If CAA records exist, the CA scans them. If the CA's own domain (e.g., letsencrypt.org) is listed, it proceeds.
If CAA records exist but the CA is not listed, it must actively refuse the certificate request and halt the issuance process.
Setting up CAA for common scenarios
The implementation depends entirely on your operational footprint.
Single CA
If your entire infrastructure uses Let's Encrypt for all certificates:
DNS Record / Config
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
Multi-CA
If your load balancers use Amazon AWS certificates, but your internal servers use DigiCert:
DNS Record / Config
example.com. IN CAA 0 issue "amazon.com"
example.com. IN CAA 0 issue "digicert.com"
Wildcard Restrictions
To allow single-name certs but strictly forbid wildcard certs (using a semicolon to denote an empty value):
DNS Record / Config
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild ";"
iodef tag: getting notified of unauthorized issuance attempts
The iodef tag is highly valuable for security teams. If an attacker tries to trick a CA (e.g., Sectigo) into issuing a cert for your domain, but your CAA record only lists Let's Encrypt, Sectigo will block the request.
If you have an iodef tag configured, Sectigo will also send an automated Incident Object Description Exchange Format (IODEF) report to your specified endpoint, alerting you to the attack in real time.
DNS Record / Config
example.com. IN CAA 0 iodef "https://api.example.com/caa-reports"
Tip
CAA + CT logs together give full certificate issuance visibility. CAA blocks unauthorized CAs before issuance. Certificate Transparency (CT) logs allow you to monitor authorized CAs after issuance to ensure no rogue certs were generated by an approved vendor.
CAA and Let's Encrypt: specific syntax and ACME validation
Let's Encrypt heavily enforces CAA. Beyond the standard issue tag, Let's Encrypt supports Account URI binding. This advanced feature ensures that not only is Let's Encrypt authorized, but only your specific Let's Encrypt account can request the certs.
DNS Record / Config
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456"
If an attacker compromises your web server but uses their own ACME account, the issuance will fail.
Common CAA mistakes
Despite its simplicity, misconfigurations are frequent:
Missing issuewild: Teams authorize issue but forget issuewild, causing automated wildcard renewals to fail.
Wrong CA domain format: Using www.digicert.com instead of the canonical digicert.com.
Assuming CAA stops all rogue certs: CAA only stops compliant public CAs. It does not stop a state-sponsored actor from generating a cert using a rogue root CA that bypasses CAA checks entirely.
Verifying your CAA record with dig
You can verify your configuration instantly from the command line using the CAA query type:
Use the CyberFurl SSL and certificate checks to properly check tls certificate configurations when you want to see the live signal on a real domain. Running a routine tls certificate check or using a dedicated tls cert checker ensures your CAA records align with actual issuance. Step back to the See the DNS posture feature page when you need the wider workflow around posture, monitoring, or remediation. That combination is usually much more useful than reading the standard in isolation.
CF
How CyberFurl Helps
Automated monitoring. Zero manual work.
CyberFurl continuously monitors your CAA records and alerts when certificates are issued by CAs not listed in your CAA policy — indicating either a misconfigured CAA record or a rogue certificate issuance. By integrating with Certificate Transparency logs, CyberFurl cross-references every new certificate issued for your domains against your CAA policy and surfaces unauthorized issuances within minutes of them appearing in the CT log.
CAA Records is not always mandated by law or by the protocol, but mature teams usually treat it as a baseline once the domain matters for customers, partners, mail delivery, or public trust. The real question is not “must I have it?” but “what risk am I carrying if I leave it weak?”
What happens without CAA?
The right next step is usually evidence first: inspect the live public behavior, identify the dependency or exposure that matters, and then decide whether to implement, tighten, monitor, or clean up. CAA Records is most useful when the answer is anchored in what production is actually doing rather than in documentation alone.
Can I have multiple CAA records?
CAA Records can help, but only when the prerequisites and surrounding trust assumptions are also true. The safest answer is to validate the specific path you care about in production, because edge cases around forwarding, intermediaries, browser support, or vendor behavior are often where theory breaks down.
Does CAA work for wildcard certs?
Support depends on the exact receiver, browser, platform, or vendor on the other side. Many ecosystems implement part of CAA Records, but the reliable answer comes from testing the specific product path you care about in production rather than assuming support is universal.
What is CAA Records?
CAA DNS records tell certificate authorities which CAs are allowed to issue TLS certs for your domain — blocking rogue issuance. In practice, teams care about CAA Records because it changes a real trust boundary somewhere in the stack and gives them a concrete signal they can validate on the live domain or application.
Are CAA records checked automatically by CAs?
Yes, under the CA/Browser Forum Baseline Requirements, all public Certificate Authorities are mandated to check CAA records before issuing a certificate.
How long does a CAA record change take to propagate?
Like all DNS records, propagation depends on the TTL of your previous CAA record (if any) or the negative caching TTL if you had none. Typically, it takes a few hours.
