CAA record management is the job of publishing and checking the DNS CAA record that states which certificate authorities may issue TLS certificates for your domain, under RFC 8659. This article covers the record syntax, how a certificate authority's lookup climbs from a subdomain to its parent, checking your own domain, and what a well-run set of records looks like. A common mistake: assuming issue never covers wildcards, when it does unless issuewild overrides it.
Contents
What is a CAA record?
A CAA (Certification Authority Authorization) record is a DNS resource record, type 257, that names the certificate authorities allowed to issue TLS certificates for a domain (RFC 8659). With no CAA record anywhere up the domain's tree, any public CA may issue a certificate for it; that is the default state, not a misconfiguration.
CAA is not new. RFC 8659 (November 2019) is the current standard, obsoleting the original RFC 6844 from January 2013.
CAA is a rule a certificate authority checks before issuing, not something a browser or mail server enforces, and it has no effect on SPF, DKIM or DMARC, which govern email sending instead. Our guide to CAA records covers the full syntax and setup steps.
RFC 8657 adds two optional parameters, accounturi and validationmethods, for control tighter than a bare issuer domain. We cover both below.
How does a CAA record work?
A CAA record follows a fixed shape: name, record type, flags, tag, then a quoted value. A working example for example.com:
example.com. CAA 0 issue "letsencrypt.org"
RFC 8659 defines three tags. issue authorises one CA for the hostname, issuewild authorises one for wildcards only, and iodef gives a mailto: or https: address for policy-violation reports.
The wildcard interaction catches people out. issue also covers wildcard requests unless an issuewild tag exists, in which case it takes over for wildcards only.
Flags run from 0 to 255. Setting 128 turns on the issuer critical bit: a certificate authority must refuse to issue if it does not recognise that property.
A certificate authority checks the exact requested name, then climbs each parent label, stopping at the first with any CAA set, and never checks the root. It follows a CNAME to its target, as Let's Encrypt's CAA docs confirm, but RFC 8659 (sections 3 and 7) dropped RFC 6844's separate climbing from that target.
Why CAA record management matters
A domain with no CAA record goes without one extra control against mis-issuance and relies on every public CA's own validation. A certificate issued in error by any public CA, from a validation bug or compromised account, breaks no stated policy, because none exists (RFC 8659 section 1).
For an MSP this is concrete, not theoretical. A client domain with no CAA record trusts every public CA's validation process at once, not just the one or two it uses.
That means that if there's a bug in any one of the many public CAs' validation processes, every domain name is potentially affected. CAA provides a way for domain holders to reduce that risk. Source: Let's Encrypt
The iodef tag gives a channel to hear about blocked or violating requests. But the Baseline Requirements only say a CA should report them, not that it must.
CAA reduces mis-issuance risk under the domain's own name. It does not stop a lookalike domain getting its own, valid, certificate under a different name, a separate problem for lookalike domain monitoring.
Since 15 March 2026, CAs must also validate DNSSEC on CAA lookups. A DNSSEC validation error such as SERVFAIL cannot count as permission to issue, worth checking with our DNSSEC checker.
How to check your domain's CAA records
A simple way is to run the domain through ShieldMarc's free CAA checker. It climbs from the hostname through its parents to the registrable domain and flags a deny-all record, an unknown issuer or a broken iodef address.
To see it yourself, run dig CAA example.com; the nslookup built into Windows cannot look up CAA records. If nothing returns, repeat the query one label up.
An empty answer at the exact name queried is not an error. It means no record exists there, so the parent label decides, and the climb carries on until it finds a CAA set, stopping short of the root.
Watch for a real trap. Two CAA records left at the same name from different edits both apply, so check both rather than assume the newer replaced the old one.
Cross-check against reality. Compare the issuer list with the CA that actually issued the domain's current certificate, shown by ShieldMarc's free SSL checker.
Look up the record
Query the domain; if nothing returns, check one label up, not stop there.
List your real issuers
Note every certificate authority that actually issues for the domain today.
Publish issue records
Add one issue record per CA in use, plus issuewild only if wildcards are issued.
Add an iodef address
Publish a monitored mailbox so a CA can report a blocked or violating request.
Recheck before you rely on it
A CA mid-issuance may still finish within the TTL or 8 hours, whichever is longer.
What good CAA record management looks like
Good management is precise rather than broad, and leaves nothing to the default:
- One
issuerecord per certificate authority actually in use, not every major CA added out of caution. - An
iodefaddress on a monitored mailbox, costing nothing to publish and giving a channel for violation reports, without a guarantee of action. - A deliberate wildcard stance: add
issuewild ";"if wildcards are never issued, rather than leaving them covered byissueby default. - Pinning further where it matters:
accounturilimits issuance to one CA account,validationmethodsto listed methods such asdns-01(RFC 8657); under the Baseline Requirements, CAs should process both now and must from 15 March 2027. - Remembering the TTL nuance: a CA that already passed its check may still issue within the record's TTL or 8 hours, whichever is greater, so a change is not instant.
Pro Tip: If certificates are issued through ZeroSSL, authorise sectigo.com in the CAA record, not zerossl.com, because ZeroSSL issues through the Sectigo hierarchy and the wrong value blocks every renewal.
Common misunderstandings about CAA
Five misunderstandings recur often enough to correct directly:
- The wildcard myth:
issuerestricts wildcard certificates too, unlessissuewildoverrides it for wildcards only. - The iodef myth: publishing
iodefdoes not guarantee a report when a blocked request happens; the Baseline Requirements only encourage a CA to send one. - The inheritance myth: a subdomain with no CAA record of its own is not unrestricted, it inherits the nearest parent's record.
- The ZeroSSL trap: ZeroSSL's CAA value is
sectigo.com, notzerossl.com, because ZeroSSL issues through the Sectigo hierarchy; the wrong value blocks issuance outright. - The critical-flag number: the issuer critical bit is flag value 128, not 1.
Where ShieldMarc fits
ShieldMarc's free CAA checker climbs from the hostname through its parents to the registrable domain and flags a deny-all record, an unrecognised issuer or a broken iodef address. The free CAA generator builds a syntactically correct record from the major CAs' identifiers, including the sectigo.com value ZeroSSL needs.
The paid plans add monitoring: CAA is one of the 16 checks behind the Security Grade, A+ to F, and CAA monitoring emails an alert when a previously published record disappears. An added or changed record never raises an alert, only a disappearing one does; DKIM is not part of the grade, and no ShieldMarc tool or monitor checks BIMI or mail-server STARTTLS.
None of this needs a decision up front. Every checker tool works without an account, and signing up needs no card: it starts a 30-day trial, after which the organisation drops to the free Starter plan.
My own judgement: the free checker and generator cover most of what a one-off CAA fix needs. CAA monitoring earns its place once you would rather be emailed about a disappearing record than find it during an incident.
Start today
Check the domain now with the free CAA checker. Then add or correct one issue record for the certificate authority you actually use.
If you look after several domains, a 30-day trial needs no card. It shows CAA alongside DMARC, SSL and DNSSEC in one Security Grade.
A domain with CAA set but no DMARC record is still open to spoofed mail sent from its own name, a separate problem CAA does not touch. Our guide to DMARC covers that control on its own terms.
Frequently asked questions
Do I need a CAA record if I already use only one certificate authority?
Yes if you want the protection: without one, any public CA can still issue a certificate for the domain, even one never intended to be used. Adding it takes minutes and changes nothing about how the existing certificate is issued, provided the record names that CA. If the CA is ever changed, a record still naming only the old one will block the new one's renewal.
Will publishing a CAA record break my next certificate renewal?
Not if the record names the CA actually issuing the certificate; the check happens before issuance and adds no noticeable delay. It will block renewal if the issuer list is out of date, for example after switching providers or moving to a host using a different CA. Check the record whenever the provider changes, before the old certificate expires, not after a renewal fails.
What happens with no CAA record at all?
Any public CA may issue a certificate for the domain; this is the default behaviour, not an error or a warning sign. It removes one control against mis-issuance, but does not mean the domain is exposed or has a wrongly issued certificate. This differs from a record that denies everything: no record at all means unrestricted, not blocked.
Can a CAA record stop someone registering a lookalike domain and getting it a certificate?
No: a CAA record only restricts issuance for the domain that publishes it; a lookalike such as examp1e.com sets its own policy, or none at all. A valid certificate can still be issued to a lookalike domain, because CAA never looks at how similar a name is to another. That is a separate problem, covered by lookalike domain monitoring rather than CAA.
Does a CAA record have anything to do with SPF, DKIM or DMARC?
No: CAA governs which CAs may issue TLS certificates; SPF, DKIM and DMARC govern who may send email as the domain, a separate system. A domain can have a complete, correct CAA record and no DMARC record at all, or the reverse; neither implies anything about the other. See our guide to DMARC for the email side of domain security.
Sources
- RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record
- RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record (obsoleted by RFC 8659)
- RFC 8657: CAA Record Extensions for Account URI and ACME Method Binding
- Certificate Authority Authorization (CAA) - Let's Encrypt