Run a lookup
How it works
Paste the domains
CAA is normally published at the zone apex and inherited by subdomains.
Query CAA over DoH
One lookup per domain, run in your browser against public resolvers.
Read the tags
issue controls normal certificates, issuewild controls wildcards, and iodef sets where violation reports are sent.
Check before you migrate
A CAA record naming your old CA will block your new one from issuing, which stalls a migration at the worst moment.
What CAA does, and what it does not
A CAA record is an instruction to certificate authorities: only these named CAs may issue certificates for this domain. Every publicly trusted CA is required to check it before issuing, so it is a genuine control rather than an advisory one. It closes off a specific attack — an adversary who obtains a certificate for your domain from some CA you have never used, and uses it to serve traffic that browsers trust completely.
What it does not do is protect against a CA you have authorised behaving badly, and it does nothing about certificates that were issued before the record was published. It is a narrow control that is cheap to apply, not a broad defence.
The failure people actually hit
CAA causes far more self-inflicted outages than it prevents attacks, and always in the same way: a domain publishes a CAA record naming one CA, and eighteen months later somebody moves the site to a platform that issues through a different one. Issuance fails, the error message points at a DNS record nobody remembers creating, and a migration stalls. If you are about to move a domain to a new host or CDN, check CAA first — this takes ten seconds and saves an afternoon.
The empty-value form is worth understanding too. A record of issuewild ";" means no CA may issue wildcard certificates for the domain, which is a deliberate and often sensible restriction. A bare semicolon in the issue tag means no CA may issue anything at all, which is very rarely what someone intended to publish.
Should a sending domain publish CAA?
It is optional and it has no effect on deliverability. Receivers do not check CAA, and no filter cares whether it exists. Where it earns its place is on domains that matter — your main site, your tracking domain, anything carrying a certificate that a user or a mail client will validate. On a fleet of throwaway sending domains it is administrative overhead for no security gain, and one more record to fix when you migrate.
Frequently asked questions
Do I need a CAA record?
No, and most domains do not have one. Without CAA, any publicly trusted CA may issue for your domain, which is the default the web ran on for decades. Add it on domains where you want to constrain issuance, and skip it on disposable sending domains where it only creates future friction.
Why is my certificate issuance failing with a CAA error?
Your CAA record does not name the CA your new host is using. Add an issue tag for that CA, wait for the TTL to expire, then retry. This is the single most common CAA problem and it usually surfaces mid-migration.
Does CAA affect email deliverability?
Not at all. No receiver or spam filter consults CAA. It governs certificate issuance only.
What does a semicolon on its own mean?
It denies everything for that tag. issuewild ";" blocks all wildcard certificates, which is a reasonable restriction. issue ";" blocks all issuance for the domain, which is almost always a mistake unless the domain is deliberately parked.
Do subdomains inherit CAA from the parent?
Yes. A CA checks the exact name first, then walks up the tree until it finds a record. A record at the apex therefore applies to every subdomain unless one publishes its own, which is what makes an overlooked apex record capable of blocking issuance for a subdomain nobody associated with it.
What is the iodef tag for?
It gives CAs an address to report policy violations to — an attempted issuance that CAA blocked. Support is inconsistent across CAs, so treat anything arriving there as a bonus rather than as monitoring you can rely on.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.