CAA Records: DNS Hardening and Monitoring Guide 2026

What a CAA Record Is and Why It Controls Certificate Issuance

A CAA record is a DNS resource record that defines, for a domain, which certificate authorities may issue TLS certificates. Before a CA issues a certificate, it queries the domain's CAA record. If it finds no authorization for itself, it refuses to issue. The entry consists of three parts: a flag, a tag (issue, issuewild, or iodef), and a value, such as the domain name of the permitted CA. This limits the mis-issuance of certificates at the root.

CAA matters more than ever because web infrastructure has changed: over 86% of all websites now load over HTTPS (as of January 2025), and certificates are issued within minutes thanks to ACME automation. This speed is convenient — but it also makes mis-issuance more dangerous, because an attacker with brief control over domain validation can quickly obtain a valid certificate. A CAA record reduces the number of CAs that could even be used for such an attack, significantly shrinking the attack surface.

A realistic assessment matters: a CAA record alone does not prevent mis-issuance with certainty. An attacker who takes over DNS management can change the CAA record itself. CAA therefore works best in combination with DNSSEC, which secures the integrity of DNS responses, and with continuous monitoring that reports any change to the record. Only this interplay turns a single entry into a resilient layer of protection.

CAA Tags and Syntax: issue, issuewild, and iodef

A CAA record follows the pattern <flags> <tag> <value>. The three available tags cover different tasks. The right combination determines how tightly you restrict issuance — and whether you are notified about violations.

your-domain.com.   IN  CAA  0 issue "letsencrypt.org"
your-domain.com.   IN  CAA  0 issuewild ";"
your-domain.com.   IN  CAA  0 iodef "mailto:security@your-domain.com"
; Optional, with DNSSEC: bind to a specific CA account
your-domain.com.   IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345"

The CAA standard was modernized in 2019 by RFC 8659 and RFC 8657 (IETF). RFC 8657 adds the accounturi and validationmethods parameters, which let you pin issuance not only to a CA but to a specific account and a particular validation method. Let's Encrypt has enabled support for this ACME CAA binding in production (Let's Encrypt), and other CAs are implementing the extension as well — industry reports describe it as increasingly becoming standard.

Why CAA Is So Rarely Used — and What It Costs

The adoption figures are sobering: only 15.4% of the 150,000 most popular TLS-capable websites had a CAA record in mid-2024 (Qualys SSL Labs); across all measured sites the figure is around 16.6% (SANS ISC). This stands in sharp contrast to the 86% HTTPS coverage (as of January 2025): transport encryption is standard, but control over certificate issuance is the exception. The reason is usually organizational rather than technical — CAA is treated as optional and gets forgotten.

The economic consequences of insufficient DNS hardening, by contrast, are measurable. According to IDC, 82% of organizations were victims of DNS attacks, averaging nine attacks per year — an increase of 34% year over year (IDC). The average cost of a DNS attack is around 1.1 million US dollars (IDC), with 73% of attacks causing application downtime and 29% causing data theft. A hardened DNS stack is therefore not a theoretical exercise but direct risk reduction.

DNSSEC: The Integrity Layer Beneath the CAA Record

CAA and DNSSEC belong together. DNSSEC (DNS Security Extensions) cryptographically signs DNS responses, ensuring that a resolver detects a manipulated or forged answer. For CAA, this is crucial: a CA that queries the CAA record over an unsecured DNS response could fall for a forged answer. With DNSSEC, the integrity of the CAA information is secured — which is why RFC 8657 explicitly recommends using the accounturi binding for DNSSEC-protected domains.

DNSSEC adoption, however, remains mixed. At the resolver level, validation capability reaches around 36% globally, but the actual secure delegation rate of signed zones is only about 7% (APNIC 2025). End-to-end validation of DNS queries grew from 0.323% in Q1 2025 to 0.469% in Q1 2026 — a relative increase of 45% year over year (Cloudflare Radar), but still at a low level. In Germany, according to the BSI, only 20% of companies deploy DNSSEC correctly (BSI 2025).

The Four Hardening Layers: CAA, DNSSEC, SPF, and DMARC

DNS hardening is not a single entry but a layered model. CAA and DNSSEC secure certificate and response integrity, while SPF and DMARC secure your domain's email identity. Only together do they close the most common attack vectors — from mis-issuance and cache poisoning to domain spoofing in emails.

• CAA: Restricts which CAs may issue certificates. Mandatory check by all CAs since September 2017 (CA/Browser Forum). Reduces the attack surface for mis-issuance.
• DNSSEC: Signs DNS responses and prevents manipulation and cache poisoning. Global secure delegation rate around 7% (APNIC 2025) — this holds the greatest untapped potential.
• SPF: Defines which servers may send email for your domain. 56.5% of around 12.8 million domains examined publish an SPF record, rising to 60.2% among the top 1M (Czybik et al., IMC 2023).
• DMARC: Enforces how recipients handle emails that fail SPF/DKIM. Among top domains, adoption rose from 27.2% to 47.7% between 2023 and 2025 (EasyDMARC) — but enforcement remains the exception.

SPF holds a common pitfall: in a study of around 12.8 million domains, 49,421 SPF records exceeded the limit of ten DNS lookups defined in RFC 7208 and risk a PermError on every send (Czybik et al., IMC 2023). Anyone using SPF should therefore monitor not just the existence but also the validity of the record. For how to turn report data into concrete action, see the article on analyzing DMARC reports.

Account Binding with RFC 8657: The Next Hardening Level

A simple issue entry generally allows a CA to issue — regardless of which account submits the request. RFC 8657 closes this gap with two parameters. The accounturi parameter binds issuance to a specific ACME account: even if an attacker uses the same CA, they fail because they do not control the authorized account. The validationmethods parameter additionally restricts which domain validation methods are accepted — for example, only dns-01, which relies on DNSSEC-secured information.

This binding is especially relevant for domains with high protection requirements. Since Let's Encrypt supports ACME CAA binding in production (Let's Encrypt) and RFC 8657 explicitly recommends using accounturi for DNSSEC-protected domains, certificate issuance can be pinned to exactly one account and one method. It is important that such fine-grained records remain correct after every change — an accidentally removed accounturi binding weakens protection unnoticed.

Detecting CAA and DNSSEC Drift: Why Monitoring Is Essential

DNS entries are not set-and-forget. They change with provider switches, CA migrations, automated deployments, or faulty configurations — and sometimes through attacks. "Drift" describes the unintended deviation of a DNS entry from its expected target state. Without monitoring, a removed CAA authorization, disabled DNSSEC, or a weakened DMARC policy only surfaces when a certificate fails or a spoofing attack gets through.

The risk is real: DNS attacks per organization rose by 34% year over year (IDC Global DNS Threat Report), and Europol reports a continued rise in domain abuse and data theft (Europol IOCTA 2025). A particularly underestimated variant is orphaned entries: SentinelOne identified over 1,250 subdomain takeover risks from deprovisioned cloud resources alone and, in one investigation, took over around 150 abandoned S3 buckets that received over 8 million requests within four months (SentinelOne 2025). How such takeovers arise is described in detail in the article on dangling CNAME records and subdomain takeover.

XICTRAQ's DNS and domain monitoring regularly checks your CAA records, DNSSEC status (DS, DNSKEY, AD bit), and your SPF and DMARC entries. If an entry deviates from its expected state — a CAA record disappears, DNSSEC fails, or a policy changes — you receive an alert via email, Slack, Discord, or Telegram before it becomes a security incident.

CAA records form part of an end-to-end monitoring chain: they control who may issue, while certificate, domain, and hijacking monitoring cover the remaining risks across the DNS and certificate layer.

Implement, Verify, and Secure DNS Hardening for the Long Term

The following checklist summarizes the most important steps — from the CAA tags through DNSSEC to email authentication. It serves as a starting point for auditing your DNS layer.

• Set a CAA record — use issue to allow only the CAs you actually use; otherwise any of the hundreds of CAs is permitted
• Set issuewild ";" if you do not need wildcard certificates — prevents unwanted wildcard issuance
• Add an iodef contact — so you receive a notification when a CA refuses issuance due to CAA
• Add accounturi and validationmethods (RFC 8657) — binds issuance to a specific account and method
• Enable DNSSEC — signs DNS responses; only around 7% of zones are securely delegated (APNIC 2025), so there is great potential here
• End SPF with -all and watch the 10-lookup limit — a study found 49,421 SPF records exceeding it (Czybik et al., IMC 2023)
• Raise DMARC to p=quarantine/p=reject — only 2.5% of domains enforce p=reject (DMARC Report 2025)
• Remove orphaned DNS entries — dangling records enable subdomain takeovers (SentinelOne 2025)
• Monitor everything continuously — records change; automated monitoring detects drift immediately

DNS hardening is increasingly becoming a compliance topic. In its technical guidelines for secure email communication (BSI TR-03108 and BSI TR-03182), the BSI recommends both DNSSEC and email authentication, and in 2025 — together with eco and Bitkom — declared a "Year of Email Security" (BSI 2025). In its inventory beginning in February 2025, the BSI found that only 20% of companies deploy DNSSEC correctly — so the gap between recommendation and practice is considerable.

The economic backdrop also argues for consistent hardening: in 2025, the FBI IC3 recorded over 20.877 billion US dollars in reported cybercrime losses for the first time, with 3.05 billion alone attributed to business email compromise (FBI IC3 2025) — an attack type that consistent SPF and DMARC enforcement counters. Combined with solid GDPR compliance, DNS hardening forms the technical foundation for demonstrable protective measures.

A CAA record is quickly set — the real challenge is keeping it consistent alongside DNSSEC, SPF, and DMARC over time. After a provider switch, a CA migration, or a careless deployment, a previously clean configuration can suddenly develop gaps without anyone noticing. This silent drift is the biggest risk.

Automated monitoring closes this gap. XICTRAQ's DNS and domain monitoring regularly checks CAA, DNSSEC, SPF, and DMARC and reports any unexpected change. Combined with SSL certificate monitoring and domain expiry monitoring, this creates complete oversight of the entire DNS and certificate layer of your online presence.

Frequently Asked Questions About CAA Records and DNS Hardening