Updated 2 hours ago
In the traditional model, any of the hundreds of trusted Certificate Authorities could issue a certificate for any domain. Your domain. Without asking you.
CAA (Certificate Authority Authorization) records change this. They're DNS records that declare which CAs are permitted to issue certificates for your domain. When a CA receives a certificate request, they must check your CAA records first. If they're not on the list, they must refuse.
This is a whitelist you control.
How CAA Records Work
A CAA record has three parts: flags, a tag, and a value.
The flags field is typically 0. A value of 128 marks the record as critical—CAs must understand the tag or refuse issuance.
The tag specifies what you're authorizing:
- issue: Authorizes a CA to issue standard certificates
- issuewild: Authorizes a CA to issue wildcard certificates (like
*.example.com) - issuemail: Authorizes a CA to issue S/MIME certificates for email addresses at your domain
- iodef: Specifies where CAs should report policy violations
The value contains the CA's domain name or a contact method.
Common Configurations
Authorize a single CA:
Let's Encrypt can issue certificates. Every other CA on Earth cannot.
Authorize multiple CAs:
Use different CAs for standard and wildcard certificates:
Let's Encrypt handles regular certificates. Only DigiCert can issue wildcards.
Block all certificate issuance:
A semicolon means "nobody." Useful for domains that don't host public services.
Get notified about violations:
Inheritance
CAA records cascade down the DNS hierarchy. When a CA checks for CAA records, they start at the requested domain and walk up until they find one.
If example.com has a CAA record but blog.example.com doesn't, the parent's policy applies to the subdomain. This lets you set a default policy at the root and override it only where needed:
Most subdomains use Let's Encrypt. The API subdomain uses DigiCert.
No CAA records anywhere means no restrictions—any CA can issue certificates.
The 2017 Mandate
CAA records existed before 2017, but checking them was optional. On September 8, 2017, the CA/Browser Forum made CAA checking mandatory for all publicly trusted CAs.
This transformed CAA from a suggestion into an enforcement mechanism. CAs that violate CAA policy can lose their trusted status—removal from browsers' trust stores, which effectively puts them out of business.
Domain owners gained real control. The risk of unauthorized certificates dropped significantly.
Expanding Scope
CAA continues to evolve. In 2024, the CA/Browser Forum extended CAA to S/MIME certificates through Ballot SMC051. A new issuemail property tag (defined in RFC 9495) lets you control which CAs can issue email certificates for your domain. CAs were recommended to check issuemail records starting September 15, 2024, and checking becomes mandatory on March 15, 2025.
Looking further ahead, Ballot SC-085 requires CAs to use DNSSEC validation when performing CAA lookups, effective March 15, 20262. This closes a gap where attackers could potentially manipulate DNS responses to bypass CAA restrictions.
What CAA Does and Doesn't Protect
CAA prevents unauthorized CAs from issuing certificates for your domain. If a CA is compromised or goes rogue, your CAA records stop them—unless they're on your whitelist.
CAA doesn't prevent:
- Certificates issued before you published CAA records
- Attacks against CAs you've authorized
- Social engineering against your authorized CAs
- DNS attacks that modify or remove your CAA records (until DNSSEC validation becomes mandatory in 2026)
CAA is one layer of defense. Combine it with Certificate Transparency monitoring (to detect unauthorized certificates), DNSSEC (to protect your DNS records now, ahead of the mandate), and regular audits of which CAs you've authorized.
Frequently Asked Questions About CAA Records
Sources
Sources
Was this page helpful?