{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}{{ badge.value }}
One public target only. Examples: example.com, mail.example.com, or https://www.example.com.
Use SMTP MX for inbound delivery; all other profiles validate the entered host directly.
Whole number from 1 to 65535; profile changes restore the service default.
Choose the transport used by the service endpoint.
Digest comparison is optional and does not fetch a live certificate.
Spaces, colons, and dashes are ignored. The normalized digest stays in this browser.
This is a recursive-resolver observation, not a direct authoritative query.
The neutral default is disabled.
{{ compareResolversEnabled ? 'Enabled' : 'Disabled' }}
Use only to diagnose resolver behavior; the neutral default is disabled.
{{ checkingDisabledEnabled ? 'Enabled' : 'Disabled' }}
CheckStateEvidenceNext stepCopy
{{ row.check }}{{ row.state }}{{ row.evidence }}{{ row.nextStep }}
EndpointOwner nameAddressesTLSA / DNSSECVerdictCopy
{{ row.endpoint }}
{{ row.routeSource }}
{{ row.ownerName }}{{ row.addresses }}{{ row.tlsaEvidence }}
{{ row.lookup }}
{{ row.verdict }}
{{ row.note }}
OwnerUsageSelectorMatchAssociationVerdictCopy
{{ row.ownerName }}{{ row.usage }}{{ row.selector }}{{ row.matching }}{{ row.association }}{{ row.verdict }}
{{ row.note }}
OwnerResolverRCODEADTLSA recordsObservationCopy
{{ row.ownerName }}{{ row.resolver }}{{ row.rcode }}{{ row.ad }}{{ row.answerCount }}{{ row.note }}
CAA Validation Report Check a hostname's CAA policy through its effective DNS record set and wildcard rules, with issuer findings and public resolver evidence.
DKIM DNS Record Generator Build a DKIM TXT record from a selector and public key with validation and DNS string splitting, plus rollout checks before publishing.
MTA-STS Validator Check an email domain's MTA-STS TXT and HTTPS policy, then review MX patterns and the policy-host certificate before enforcement.
SPF Record Generator Build an SPF TXT record from real sender paths with ordered mechanisms and lookup-budget planning plus DNS packaging and rollout checks.

Mail servers and other unattended TLS clients cannot ask a person whether an unexpected certificate should be trusted. DNS-Based Authentication of Named Entities (DANE) gives them another trust path: a DNSSEC-authenticated TLSA record states which certificate or public key belongs to a particular service. The decision therefore depends on three facts agreeing: the service name must be correct, DNSSEC must authenticate the answer, and the certificate association must match.

The DNS name is specific to an endpoint, not merely to a domain. It begins with the port and transport, followed by the service host. HTTPS on TCP port 443 at www.example.com, for example, uses _443._tcp.www.example.com. Inbound SMTP adds another step because the recipient domain's MX records identify the mail exchangers; each exchanger then has its own _25._tcp TLSA owner. Checking the recipient domain directly can miss the records that sending mail systems actually use.

Certificate usage
Selects PKIX trust, a DANE trust anchor, or the end-entity certificate. SMTP DANE relies on usages 2 and 3.
Selector
Chooses either the complete certificate or its SubjectPublicKeyInfo (SPKI) structure.
Matching type
Publishes the selected bytes directly or as a SHA-256 or SHA-512 digest.
Association data
Carries the exact bytes or digest that the client compares with the certificate it receives.

A visible TLSA answer is not automatically trustworthy. The Authenticated Data (AD) flag says that the recursive resolver claims to have validated the DNSSEC chain. A checking-disabled query can reveal data hidden behind a validation failure, but that reply is diagnostic only. It cannot establish an authenticated DANE result.

Certificate changes create a second operational risk. Exact matching can break at renewal because any changed certificate byte changes the association. SPKI digests often survive reissuance when the key stays the same, while a deliberate key rollover needs old and new associations published for a safe overlap. DANE readiness is therefore a point-in-time view of DNS routing and records, not proof of the certificate currently served by the endpoint.

Question Evidence Common mistake
Which host is protected? MX routing or the direct service host, plus port and transport Querying the base domain instead of the endpoint owner
Is the record authenticated? DNSSEC validation with AD present Treating an ordinary or checking-disabled answer as secure
Will the certificate match? Compatible usage, selector, matching type, and association Assuming publication alone proves the live certificate

How to Use This Tool:

Choose the route that a real client uses before checking TLSA data. The profile determines whether MX discovery happens first or the entered host is checked directly.

  1. Enter one domain, hostname, URL, or email-style address in Target. Extra non-blank lines are ignored.
  2. Select the Service profile. Use SMTP MX route for inbound mail; the other profiles use the entered host directly. Confirm the resulting Port and Transport, because either change creates a different TLSA owner.
  3. Leave Observed digest at No digest comparison unless a separate live-certificate inspection supplied the digest. For a comparison, choose the matching selector and hash, then paste its hexadecimal value.
  4. Choose a Resolver vantage and run validation. Enable Compare resolvers only when cache or resolver disagreement matters; it compares Cloudflare and Google rather than measuring global propagation.
  5. Read Checks first, then use Route and TLSA to locate the owner or record that caused a warning. A checking-disabled diagnostic is advisory even when it returns records.

Interpreting Results:

Pass means the route has addresses, TLSA publication, authenticated DNSSEC evidence, and at least one usable record. Review preserves a usable but qualified route, such as checking-disabled DNS data, PKIX-bound usage outside strict SMTP, or an exact match that may be brittle at renewal. Stop marks a missing address, missing TLSA record, missing authenticated data, or no usable TLSA association.

The readiness percentage summarizes those checks; it is not an Internet standard and it cannot confirm what certificate the endpoint serves. A digest mismatch forces the overall state to a break. Not comparable means the selected digest method and the TLSA selector or matching type differ, so it forces review rather than proving a mismatch.

Resolver agreement strengthens a point-in-time observation but does not establish authoritative state or global consistency. For a consequential mail or TLS change, query authoritative DNS and inspect the live certificate separately.

Technical Details:

TLSA owner construction follows the service endpoint selected by routing. Direct profiles use the entered host. SMTP MX mode sorts returned MX records by preference, checks up to 20 exchangers, and falls back to the domain's address records only when no MX record exists. A Null MX means that the domain does not accept inbound mail.

Transformation Core

The service question becomes a TLSA lookup through this sequence:

  1. Normalize the input to one lowercase hostname.
  2. For SMTP MX, resolve the exchanger set; otherwise retain the direct host.
  3. Build _port._transport.host for each endpoint.
  4. Resolve A, AAAA, and TLSA data, then classify DNSSEC and every TLSA record.
  5. Combine route evidence into a route verdict and readiness score.

Rule Core

The four TLSA fields are checked before any optional digest comparison. The following rules are exact for this report.

Rule Pass or review condition Stop condition
Usage 0 to 3; strict SMTP accepts only 2 or 3 Outside 0 to 3, or usage 0/1 in an SMTP profile
Selector 0 for full certificate or 1 for SPKI Any other value
Matching type 0 exact, 1 SHA-256, or 2 SHA-512; exact matching is reviewed Any other value
Association Even-length hexadecimal; SHA-256 uses 64 hex characters and SHA-512 uses 128 Invalid hex, odd length, or wrong digest length
DNSSEC AD=true passes; checking-disabled data is review-only AD is absent during an ordinary validating query

Formula Core

Each route receives points for addressability, TLSA publication, DNSSEC state, and record usability.

Sroute = Paddress + PTLSA + PDNSSEC + Precord
  • Address ready contributes 20 points; TLSA present contributes 25.
  • Secure DNSSEC contributes 25 points, advisory checking-disabled data contributes 10, and missing authentication contributes 0.
  • A passing record set contributes 30 points, a review set contributes 20, and an unusable set contributes 0.

A Pass route is clamped to at least 85%. A Review route is clamped to 50% through 84%. A Stop route cannot exceed 45%. The overall percentage is the arithmetic mean of all route scores, rounded to the nearest whole percent.

Soverall = round ( ∑i=1nSi n )

The most severe route controls the overall state: severity 0 is Clear, severity 2 is Review, and severity 3 is Break. A comparable digest mismatch also sets severity 3, while a non-comparable digest sets at least severity 2.

Accuracy and Privacy Notes:

Public DNS names are sent to the selected recursive resolver. An entered certificate digest is normalized and compared in the browser, and no live certificate is fetched. Results describe one recursive-resolver view at one time; caches, propagation, split DNS, filtering, and DNSSEC policy can produce a different view elsewhere.

Do not publish a digest copied from an unverified connection. Confirm the endpoint, certificate chain, selected certificate bytes, and rollover plan with independent TLS and authoritative DNS checks before changing production TLSA records.

Worked Examples:

Inbound mail with one incomplete exchanger

An MX domain resolves to two mail exchangers. Both have addresses and TLSA records, but one TLSA reply lacks AD. The authenticated route can pass, while the second route stops and the overall state becomes Break. The corrective step is to repair or confirm that exchanger's DNSSEC chain rather than averaging the route away.

Digest method does not match

A certificate SHA-256 digest is supplied, but the record uses selector 1 for SPKI with SHA-256. The two values describe different byte sequences, so the result is Not comparable and requires review. Recompute the digest from SPKI or choose the certificate selector that matches the published record.

References: