Every website you visit relies on an SSL/TLS certificate to keep your connection secure. But who decides which companies are allowed to issue those certificates for a given website? That is exactly the job of a CAA record.
A Certification Authority Authorization (CAA) record is a small entry in your domain’s DNS. It tells certificate-issuing companies, known as Certificate Authorities or CAs, which of them are allowed to issue certificates for your domain. Without it, any trusted CA in the world could issue a certificate for your site, and you might not find out until something goes wrong.
CAA records matter more than they used to because they now decide whether a certificate is issued at all, not just which CA may issue it. In 2025 and 2026, two important changes made CAA records far more powerful. A rule called Multi-Perspective Issuance Corroboration (MPIC) means CAs now check your records from several locations at once, and from March 2026 they must also check Domain Name System Security Extensions (DNSSEC) signatures for any domain that uses DNSSEC.
The result is simple. A misconfigured CAA record no longer just weakens your security policy, it can stop your certificate from being issued at all. That now covers two distinct failures: a policy mistake that blocks your own CA, and a DNS or DNSSEC mistake that breaks the lookup.
This blog explains what CAA records are, how the new rules work, and what you need to get right to avoid certificate failures. Let us start with the basics.
What Is a CAA Record and Why It Matters
A CAA record lives in your domain’s DNS; the same system that maps your domain name to its server’s IP address and stores other policy records. Instead of pointing to a server address, it points to a policy: which CAs are allowed to issue certificates for your domain.
Before CAA became mandatory for all public CAs in 2017, any CA could issue a certificate for any domain as long as the request passed a basic ownership check. That was risky. A CA that made a mistake, or a bad actor, could obtain a valid certificate for your domain without your knowledge, and browsers would trust it just like the real one.
CAA fixes this by adding a gatekeeper at the DNS level. When a CA receives a request to issue a certificate for your domain, it first checks your CAA records. If that CA is not on your approved list, it has to refuse, no matter what else the request includes.
This makes CAA one of the cheapest security controls you can add. A CAA record is just a DNS entry, so it costs nothing, yet it decides who can issue certificates for you. Even so, adoption stays low. As of mid-2024, only about 15 percent of the top TLS websites had CAA records in place, which means most organizations are not using this protection at all.
To use CAA well, it helps to understand the few simple tags that make up a record.
The Main CAA Tags You Need to Know
A CAA record has three parts: a flag, a tag, and a value. The flag is almost always zero, meaning the CA may proceed even if it does not recognise the tag. The only standardized non-zero value currently in use is 128, the issuer-critical flag, which forces the CA to refuse issuance if it cannot understand the tag. The tag says what kind of rule the record sets, and the value is the actual instruction. There are four tags you will use most often.
The issue tag says which CA is allowed to issue normal certificates for your domain. You enter the CA’s official domain name as the value. The moment you name one CA with an issue record, every other CA is automatically blocked, so there is no separate deny rule to add. If you work with more than one CA, you add one issue record for each, and they all stay authorized.
The issuewild tag controls authorization for wildcard certificates. If an issuewild record exists, it overrides the issue tag for wildcard certificates only. If no issuewild record is present, the issue tag applies to both regular and wildcard certificates.The iodef tag tells CAs where to send an alert when someone’s certificate request is blocked by your policy. You can give an email address or a web address.
Think of it as an early warning system. Without it, a blocked attempt simply disappears, and you never learn it happened. It is free, takes less than a minute to set up, and most major CAs support it. Note that iodef support varies. Not all CAs send these reports reliably, so treat it as a supplementary signal rather than your primary alerting mechanism.
There is also a fourth tag, issuemail, added in 2023. It works just like issue but applies to S/MIME certificates used for secure email. If your organization uses S/MIME, it is worth adding too.
These tags give you control over who can issue certificates and how you are warned when your policy is enforced. That control matters even more now, because of how CAs recently changed the way they check these records.
What Changed in 2025 and 2026: MPIC and DNSSEC
Until 2025, a CA checked your CAA records from a single location. That sounds fine, but it left a gap. DNS responses can be faked, for example through BGP hijacking, where the internet’s routing is manipulated to send a CA’s lookups to attacker-controlled servers that return false answers. From one location, a CA cannot easily tell a real response from a forged one. This is not just theory. In 2018, a BGP hijack at an upstream provider rerouted traffic destined for Amazon Route 53’s DNS servers (Amazon’s own systems were not compromised), redirecting a cryptocurrency platform’s users to a fraudulent site and causing losses of more than 150,000 dollars.
MPIC was created to close this gap. Its enforcement began industry-wide on 15 September 2025, and the minimum number of remote perspectives it requires rises in phases through 2026, rising to four on 15 June 2026. Instead of checking from one place, CAs now check your CAA records from several network locations around the world at the same time. If all of them agree, the check passes. If any location returns a different answer, the check fails and no certificate is issued.
Faking one DNS response is possible, but faking the same response from four or more independent locations at once is far harder. As of March 2026, CAs must confirm your records from at least three remote network perspectives plus one primary perspective, all spread across at least two distinct Regional Internet Registry (RIR) regions, before issuing a certificate.
The second change adds DNSSEC. MPIC confirms that answers are consistent, but it does not prove they are genuine. DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that DNS responses are authentic and have not been tampered with. It protects against attacks such as DNS spoofing and cache poisoning.
From 15 March 2026, a CA/Browser Forum rule (Ballot SC-085v2) requires CAs to validate DNSSEC signatures whenever they perform CAA or domain-control lookups for a DNSSEC-enabled domain. If your DNSSEC setup is broken, with expired signatures or an incomplete key change, your CAA check will fail and your certificate will not be issued. If you do not use DNSSEC, this particular change does not affect you, though it is still worth considering as part of your wider DNS security.
Because of these changes, the steps a CA now follows before issuing a certificate look like this:
- The CA receives a certificate request for your domain.
- Using MPIC, it looks up your CAA records from several independent locations worldwide, and if those locations disagree, issuance is blocked.
- As part of that same lookup, it validates DNSSEC signatures on any DNSSEC-enabled domain, and if a signature is broken or missing, issuance is blocked.
- It checks whether it appears in your CAA record as an approved issuer, and if it does not appear, it must refuse.
- It checks any extra rules, such as account or validation-method restrictions.
- Finally, it confirms that you actually control the domain before proceeding.
- The certificate is issued.
Most issuance problems come down to a few avoidable mistakes somewhere in this process. Here are the ones to watch for.
Avoiding Mistakes and Following CAA Best Practices
A handful of recurring mistakes cause most CAA failures, and all of them are easy to prevent once you know about them.
The first is missing issuewild when you issue wildcard certificates. If you only have an issue record and then try to get a wildcard certificate, it will be blocked. Many teams set up issue records early, then add wildcard certificates later without updating their policy.
The second is using the wrong CA name. The value in your record must be the CA’s official domain name, not a reseller or partner. If you buy certificates through a reseller, you still need the underlying CA’s identifier, so check their documentation for the exact text to use.
The third is DNS that is not reachable from the public internet. Because MPIC checks from several outside locations, your authoritative name servers must be reachable externally. This often causes problems for hybrid cloud setups where part of the DNS is kept internal.
The fourth is broken DNSSEC, which now blocks issuance outright from March 2026. The usual causes are expired signatures and incomplete key changes. Monitor your DNSSEC health and set alerts well before signatures expire.
That covers the mistakes to avoid. Beyond them, a few good habits keep CAA working as you grow. Before writing any records, check Certificate Transparency logs to see which CAs already issue for your domains, so you do not accidentally lock one out. Add CAA records automatically whenever a new domain or subdomain is created, so issuance never fails because a record was forgotten. This matters more every year, because certificate lifetimes already down to 200 days as of March 2026, heading to 100 days in March 2027 and just 47 days by March 2029, which means far more frequent renewals and far less room for a quiet misconfiguration.
Getting all of this right across many domains takes the right tools and experience, which is where we can help.
How Encryption Consulting Can Help
CAA records are simple in idea but harder to manage at scale. Choosing the correct CA identifiers, handling many subdomains, coordinating with DNSSEC, and building CAA into automated certificate workflows all take a solid grasp of how PKI, DNS, and the latest industry rules fit together.
Encryption Consulting helps organizations design and manage their PKI, including full certificate lifecycle management that covers both issuance and the DNS controls around it. Our CertSecure Manager platform discovers certificates across your environment, monitors Certificate Transparency logs, and automates renewals, so it can flag certificates from unexpected CAs before they turn into incidents. We also offer a PKI Services that reviews your readiness for requirements and finds gaps before they cause outages.
Conclusion
CAA records have been around since 2017, but 2025 and 2026 raised the stakes. With MPIC now checking from multiple locations and DNSSEC validation now required, a misconfigured record is no longer a minor weakness. It can stop your certificates from being issued. As certificate lifetimes get shorter and renewals happen more often, the cost of getting this wrong only grows.
The good news is that the steps are straightforward. Authorize every CA that currently issues for your domain. Add an issuewild record for wildcard certificates and an iodef record so you hear about blocked attempts. Keep your DNS publicly reachable and consistent, watch your DNSSEC health if you use it, and build CAA into your automation so every new domain is protected from day one.
If you would like help reviewing your current CAA setup or building a stronger DNS and certificate management strategy, Encryption Consulting’s team can help you close the gaps before they cause problems.
