Check Certification Authority Authorization records for any domain
Querying CAA records for ...
CAA Records for
No CAA records found
Any CA is authorized to issue certificates for this domain.
Flags
Tag
Value
CA Authorization Status
Let's Encrypt
ZeroSSL
About CAA Record Checker
A CAA lookup reads the Certificate Authority Authorization record to see which certificate authorities are allowed to issue for a domain. Our free CAA Record Checker verifies Certificate Authority Authorization (CAA) DNS records for any domain. CAA records specify which Certificate Authorities are allowed to issue certificates for your domain, preventing unauthorized certificate issuance.
How to Use
1Enter the domain name to check.
2Click "Check CAA" to query CAA DNS records.
3Review which CAs are authorized and their issue/issuewild flags.
Each line is 0 <tag> "<value>". The first number is the flags octet, where 128 means critical.
issue and issuewild name the CAs allowed to issue for the domain and for its wildcards. iodef is a reporting address.
CAA only ever restricts. A CA missing from the list is refused; listing a CA grants nothing if it will not sign for you anyway.
A domain with no CAA record is unrestricted — absence is not a deny.
Issuers check CAA at issuance time, not at handshake time, so a change affects certificates issued from then on. Validating resolvers must re-check within 8 hours, and propagation follows your zone TTL.
How the Check Works
CAA is a DNS record that says which certificate authorities are allowed to issue for a domain. It is only consulted at issuance time, so a broken record rarely affects existing certificates — it blocks the next one, usually at the worst moment.
1The domain is sanitised to a bare hostname and a CAA query is sent for it.
2Every record returned is broken into its three parts — the numeric flag byte, the tag, and the value — and all of them are shown, including records that grant nothing.
3Only issue and issuewild tags are treated as permissions. This is the distinction that matters: iodef is a contact address for violation reports and grants an authority no right to issue.
4Two common authorities are reported individually, so you can see at a glance whether Let's Encrypt and ZeroSSL are still permitted after an edit.
The query targets the exact name you entered. Public resolvers walk up the tree when a name has no CAA record of its own, so a domain can be governed by a record on a parent zone — check the parent too before assuming an empty result means unrestricted.
Tips & Best Practices
•Add CAA records before ordering certificates to avoid issuance failures
•Include your primary CA and a backup CA in CAA records
•Use the iodef flag to receive reports of unauthorized issuance attempts
Frequently Asked Questions
It means any publicly trusted certificate authority may issue for your domain. That is the default state for almost every domain, and it is why misissuance is possible at all: without a CAA record, a CA that an attacker convinces to issue will do so. Adding one is a genuine improvement, because it means only the authorities you chose can act on your behalf. Do it after your current certificate is in place, and test an issuance afterwards, since a record that lists the wrong authority blocks renewals without any obvious error.
Yes, and you should allow exactly the authorities you actually use plus one you might migrate to. Multiple CAA records at the same name are treated as a set: an authority is permitted if any record names it. A record with no parameters, meaning just the domain, permits every certificate authority, so a record you intended as restrictive but wrote without parameters permits everyone instead. Check the record list itself after editing rather than trusting that multiple records means restrictive.
It governs wildcard certificates specifically, separately from the issue flag which governs ordinary certificates. This matters because a wildcard covers an unlimited number of hostnames, so authorities often want a stricter policy for it. The two flags are independent: you can allow an authority for ordinary certificates while refusing it wildcard ones, and the resolution is that issuewild applies to wildcards and issue applies to everything else. An iodef record is neither of these and grants no permission at all.
They report whether any issue or issuewild record for that domain names the authority, matched case-insensitively anywhere in the value. They are a convenience for the two authorities that cause most failed issuances, not a complete permission model. A record naming a third-party authority, a reseller's own CA name, or a bare "none" will permit issuance without flipping either flag. Read the record list itself when you care about correctness rather than these two answers.
It queries the exact name you entered. Real resolvers do walk up the tree: if a hostname has no CAA record of its own, the parent zone's record is consulted, and if that has none either, the grandparent's is, up to the top-level domain. That means a subdomain can be governed entirely by a record you set on the apex, which is exactly what most people intend and also exactly what surprises people. If the result here is empty and the domain still refuses to issue, look for a CAA record on the parent.
Yes. Every issuance asks the same question, regardless of whether a person or an automated client is making the request. So an automated renewal that starts failing days after you tightened your CAA record is not a renewal failure — it is the record doing its job. This is the most common cause of a certificate that renewed fine for months and then suddenly stopped, and the reason changes to CAA should be followed by a test issuance rather than a change to the renewal schedule.
No. The iodef tag carries an email address for reporting policy violations and confers no permission whatsoever. A domain whose only CAA record is an iodef entry has, in practice, restricted issuance to no one — public resolvers treat that as a deny. If you added iodef expecting it to sit alongside an issue rule, check that the issue rule is still present, because the two tags do different jobs and one does not imply the other.
Three causes, in order of likelihood. A record was added but has not propagated, since a new record is invisible until resolvers refresh. The record exists on a parent zone rather than on the name you queried, and this tool only asks for the exact name. Or the lookup failed and the error was swallowed rather than reported — a transient resolver failure is returned as an empty set, which looks identical to having no policy. Confirm with a second lookup after a minute before changing anything.
