CAA Validation Report
Check a hostname's CAA policy with CNAME and parent-DNS lookup evidence, wildcard rules, issuer findings, and resolver comparison notes.{{ caaSummaryHeading }}
| Flags | Tag | Value | Applies now | Notes | Copy |
|---|---|---|---|---|---|
| {{ row.flags }} | {{ row.tag }} | {{ row.value }} | {{ row.applies ? 'Yes' : 'No' }} | {{ row.note }} |
| Check | Status | Notes | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.status }} | {{ row.note }} |
| Step | Hostname | Outcome | Notes | Copy |
|---|---|---|---|---|
| {{ row.step }} | {{ row.host }} | {{ row.outcome }} | {{ row.note }} |
A certificate request can fail even when the hostname resolves correctly and the applicant controls the domain. Public certificate authorities (CAs) also check DNS Certification Authority Authorization (CAA), a DNS policy record that tells them which CAs are allowed to issue for a name. CAA is checked before issuance. It does not change how browsers validate an already issued certificate.
CAA becomes important whenever certificate authority changes, automation, aliases, or delegated DNS names are involved. A team might move from one CA to another, add a hosted service under www, request a wildcard certificate, or let a vendor manage a subdomain. The effective policy may come from the exact hostname, a CNAME target, or a parent domain, so checking only the label someone typed can miss the record set that a CA will use.
The main terms are small, but they decide very different outcomes:
issue- Allows one or more CAs to issue ordinary domain-name certificates. For wildcard requests, it is used only when no
issuewildproperty is present. issuewild- Controls wildcard certificates such as
*.example.com. When present, it takes precedence overissuefor wildcard issuance. iodef- Publishes a destination for certificate issuance incident reports. It is reporting metadata, not an issuer allowlist.
- Critical flag
- Tells a CA not to ignore an unknown property. Unknown critical properties can block issuance for CAs that do not understand them.
CAA is easy to overread. It is not a list of current certificates, and it does not prove that a future ACME order will pass. A certificate issued yesterday can remain valid after the domain changes CAA today. A matching issuer row also leaves other checks untouched, including account authorization, domain-control validation, certificate contents, CA policy, rate limits, and multi-perspective DNS behavior.
Wildcard certificates deserve a separate check because the same base domain can express one policy for api.example.com and another for *.api.example.com. A domain can authorize a CA for ordinary names, authorize a different CA for wildcards, or publish an empty issuer value that requests a deny-all result for the selected issuance class. The distinction comes from the CAA properties in the relevant record set, not from the visible shape of the hostname alone.
Resolver freshness also matters. Public resolver caches, recent DNS edits, delegated zones, CNAME targets, DNSSEC handling, and CA-specific processing can produce a different answer from what an administrator sees in one quick lookup. CAA evidence is therefore best treated as a current DNS-policy snapshot to compare with the certificate request, CA account, and validation method that will actually be used.
How to Use This Tool:
Use the certificate name you plan to request, then choose the scope that matches the order.
- Enter
Hostname. A bare hostname or a full URL is accepted, and only the hostname is used for lookup. The hostname must include a dot and must not contain spaces. - Choose
Certificate scope. SelectExact hostnamefor names such aswww.example.com. SelectWildcard requestfor certificate names such as*.example.com. - Open
Advancedwhen propagation or alias behavior is part of the question. You can compareResolver, keep or disableFollow CNAME, and setParent hopsfrom 1 to 10 levels. - Click
Validate CAA. If the form reports an invalid hostname, remove spaces, unsupported characters, or pasted path text that is not part of the host. - Read the summary badge first.
CAA policy looks consistent,CAA has review notes, andCAA needs attentiondescribe the strongest finding for the selected scope. - Open
CAA Policy Evidenceto see returned flags, property tags, values, whether each row applies now, and the row note. - Use
Validation Findingsfor the rule checks, then inspectCAA Lookup Chainwhen you need to show whether the effective record came from the requested hostname, a CNAME target, or a parent domain. - Use
CAA Finding Mixfor a compact status chart andJSONwhen a ticket or audit note needs a structured copy of the same evidence.
Advanced Tips:
- Run exact-host and wildcard checks separately before changing records for a certificate renewal that includes both ordinary and wildcard names.
- Compare Cloudflare DNS and Google Public DNS when a record was edited recently. A resolver mismatch is often propagation or cache timing, not necessarily a policy error.
- Keep
Follow CNAMEenabled for hosted services and vanity names unless you specifically need to prove the policy at the alias name itself. - Increase
Parent hopsonly when the hostname has deep labels or delegated subdomains that may inherit policy from a higher name. - Preserve the issuer value exactly when CAA parameters such as account or validation-method constraints are involved. Those parameters can matter to the CA even when the issuer domain looks correct.
- For change records, pair one
CAA Policy Evidencerow with the matchingValidation Findingsnote and theCAA Lookup Chainrow that names the effective DNS point.
Interpreting Results:
CAA policy looks consistent means the current resolver answer did not trigger a review or needs-attention finding. Treat it as useful DNS-policy evidence, not as an issuance promise. The CA still checks account rights, domain-control validation, certificate contents, rate limits, CA policy, and current resolver views.
CAA has review notes usually means the policy may be valid but needs a human decision. Typical review notes include no explicit CAA record set, no issuewild property for a wildcard request, no iodef destination, or a noncritical property outside the recognized CAA tag list.
CAA needs attention marks a stronger risk for the selected certificate scope. An empty issuer value can request no issuance for that class. An unknown property with the critical flag can require a CA that does not understand it to refuse issuance. An unsupported iodef URI scheme should be fixed before relying on incident reporting.
Applies now is the main column when exact and wildcard policy differ. Exact-host mode applies ordinary issue rows and treats issuewild as context. Wildcard mode applies issuewild when present; if it is absent, wildcard authorization falls back to issue.
No RRset found does not mean DNS is broken. It means no explicit CAA policy was found in the searched chain from the selected resolver's view, so CAA itself is not restricting issuance there. If the record was added recently, compare resolvers and wait for DNS caches to expire before treating that absence as settled.
Technical Details:
CAA validation is a rule check over the relevant resource record set, often called the Relevant RRset. The search starts at the fully qualified domain name under review and climbs toward the DNS root until it finds a CAA record set or runs out of names. Alias handling can shift the starting point to a CNAME target before the parent search, which is why hosted services and vanity names sometimes inherit policy from a DNS name that is not visible in the certificate request.
Each CAA record carries a numeric flags value, a property tag, and a property value. The tag identifies the kind of rule, and the value usually contains an issuer domain, a reporting URI, or CA-specific parameters. The high bit of the flags field is the critical flag, normally shown as 128. A CA that cannot understand a critical property must not silently ignore it.
Lookup Core
| Step | What is checked | Why it matters |
|---|---|---|
| Host normalization | A URL or host input is reduced to a lower-case hostname without a trailing dot. | Paths, schemes, and trailing dots should not change the DNS name being tested. |
| Alias check | When enabled, the selected resolver is queried for a CNAME at the normalized hostname. | Alias-heavy services can have their effective CAA policy attached to the target name. |
| Parent search | The report queries CAA at the working hostname, then removes one leftmost label at a time up to the configured hop limit. | The first CAA RRset found becomes the effective policy for the rest of the validation. |
| No CAA answer | If every searched name returns no CAA records, the result is recorded as no explicit RRset. | Issuance is not restricted by CAA in that resolver view, though other CA checks still apply. |
Rule Core
| Check | Healthy condition | Review or attention condition |
|---|---|---|
| Effective RRset | At least one CAA record is found in the searched chain. | No CAA record set is found, so the policy is unconstrained by CAA from this lookup. |
| Wildcard precedence | Exact-host checks do not require issuewild; wildcard checks are clearest when issuewild is present. |
A wildcard request without issuewild falls back to issue and is marked for review. |
| Issuance controls | At least one applicable issue or issuewild row applies to the selected certificate scope. |
An applicable empty value, including ;, is treated as a block for that issuance class. |
| Recognized tags | All returned tags are in the report's recognition list. | Unknown noncritical tags are review notes; unknown critical tags need attention. |
| IODEF destinations | Published reporting destinations use mailto:, http:, or https:. |
No destination is a review note; unsupported schemes need attention. |
CAA Finding Mix counts finding statuses after the DNS policy rules have been applied. It is not a numeric risk score, and it does not weight one finding against another. One needs-attention finding can matter more than several healthy rows when it affects the requested issuance class.
| Tag | Applies to | Interpretation |
|---|---|---|
issue |
Exact-host certificates and wildcard fallback. | Names an authorized issuer when non-empty; an empty value requests no issuance for that class. |
issuewild |
Wildcard certificates. | Takes precedence over issue for wildcard names and is ignored for ordinary exact-host requests. |
iodef |
Reporting only. | Provides a policy-violation reporting destination and does not authorize issuance by itself. |
issuemail |
Email-address certificate context. | Recognized as a CAA property for email-address certificates, separate from ordinary TLS server certificate issuance. |
contactemail and contactphone |
Domain-validation contact metadata. | Useful for operator contact and validation workflows, but not an issuer allowlist. |
| Issuer parameters | Issuer-specific constraints on issue or issuewild. |
May restrict authorization to a particular CA account or validation method when the CA processes those parameters. |
| Unknown tag | Depends on the tag and CA support. | Noncritical unknown tags are review notes; critical unknown tags are treated as blocking concerns. |
CAA issue-family values may include parameters after the issuer domain. Standards define parameters such as accounturi and validationmethods, and CAs may document additional handling in their certificate policy or certification practice statement. Preserve those values when troubleshooting because a correct issuer domain can still fail if the request uses the wrong account or validation method.
Accuracy and Privacy Notes:
The lookup uses the selected public DNS-over-HTTPS resolver. That resolver receives the normalized hostname and the queried DNS names. Do not enter private, internal, or sensitive hostnames unless you are comfortable sending those names to Cloudflare DNS or Google Public DNS.
The result is a live resolver view, not an authoritative CA decision. Public resolver caches, recent DNS changes, DNSSEC validation behavior, split-horizon DNS, and CA multi-perspective checks can produce a different answer from what a CA records during issuance.
Alias handling follows the visible CNAME option and then searches parents from the working hostname. If a certificate failure involves a long CNAME chain, delegated DNS, or a CA-specific interpretation of issuer parameters, compare the report with authoritative DNS output and the CA's own validation log before changing production records.
Worked Examples:
CA migration check
A team moving www.example.com to a new issuer selects Exact hostname. The effective RRset contains 0 issue "ca.example.net", and CAA Policy Evidence shows that the issuer row applies now. The next check is whether the pending certificate order is really using the CA named in that value.
Wildcard intent is missing
A domain publishes 0 issue "ca.example.net" but no issuewild row. Exact-host mode can look consistent, while Wildcard request adds a review note because wildcard issuance is falling back to ordinary issue. Publishing an intentional issuewild row makes the wildcard decision explicit.
Inherited deny-all policy
A subdomain has no CAA rows, but the parent publishes 0 issue ";". CAA Lookup Chain identifies the parent as the effective RRset, and Validation Findings marks issuance controls as needs attention because the applicable issuer value is empty. If the DNS design allows it, a more specific subdomain CAA row can override that inherited block.
Critical property surprise
A record set includes 128 experimental "value". The critical flag plus unknown property produces a needs-attention finding. Before submitting another certificate order, confirm that the intended CA supports that property or remove the critical flag from unsupported policy experiments.
FAQ:
Does a consistent CAA result mean my certificate will issue?
No. The result checks DNS CAA policy for the selected hostname and scope. The CA still evaluates account permissions, domain-control validation, certificate contents, rate limits, and its own issuance policy.
Why is no CAA record a review note?
No explicit RRset means the searched DNS names did not publish a CAA policy from the selected resolver's view. That usually leaves issuance unrestricted by CAA, which may be intentional or may mean a new record has not propagated.
Can I paste a full URL?
Yes. The hostname field accepts a full URL and uses only the hostname for lookup. If validation fails, remove spaces, paths that are not part of the host, or malformed text and use a name such as www.example.com.
Why does wildcard mode ignore an issue row?
When a relevant RRset includes issuewild, wildcard requests use that policy and ignore ordinary issue rows. If no issuewild row exists, wildcard mode falls back to issue.
Why did the answer come from another hostname?
If Follow CNAME is on and the hostname aliases to another DNS name, the report checks the alias target before walking parent names. The lookup chain records the step that led to the effective RRset.
Are private hostnames safe to enter?
Only enter hostnames you are willing to send to the selected public DNS resolver. The lookup uses Cloudflare DNS or Google Public DNS, so internal names can be exposed to that resolver.
Glossary:
- CAA
- Certification Authority Authorization, the DNS record type that expresses which CAs may issue certificates for a domain name.
- CA
- A certificate authority that can issue public TLS certificates under its certificate policy and browser-trust requirements.
- Relevant RRset
- The CAA record set that applies after the DNS search checks the requested name, any alias target, and parent names.
- CNAME
- A DNS alias that points one hostname to another hostname before other DNS data is interpreted.
issue- The CAA property tag that authorizes CAs for exact-host issuance and wildcard fallback.
issuewild- The CAA property tag that authorizes wildcard certificate issuance and overrides
issuefor wildcard names. iodef- The CAA property tag that publishes a reporting destination for certificate issuance policy events.
- Critical flag
- The CAA flag bit that tells a CA not to ignore an unknown property tag.
References:
- DNS Certification Authority Authorization (CAA) Resource Record, IETF, November 2019.
- CAA Record Extensions for Account URI and ACME Method Binding, IETF, November 2019.
- Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, CA/Browser Forum, May 19, 2026.
- Public Key Infrastructure using X.509 (PKIX) Parameters, IANA, October 16, 2023.
- Certification Authority Authorization (CAA) Processing for Email Addresses, IETF, October 2023.