From DNS Evidence to a Finding: AdminToolkit's DNS and Mail Security Methodology

Scope and explicit nonclaims

This document covers the current DNSSEC Validator, DANE Validator, SPF/DMARC/DKIM Checker, and SMTP TLS Handshake / Mail Domain Delivery Readiness. The tools are first-pass, read-only diagnostics. They do not replace an authoritative-zone view, registrar state, a full DNSSEC validator such as DNSViz, sending or receiving MTA logs, packet capture, or a complete mail-security audit.

Record presence is inventory, not validation. Syntactic validity is not cryptographic proof. A resolver’s authenticated-data indication is evidence from that resolver, not an independent signature calculation in the browser. A certificate name comparison is not PKIX chain validation. SPF, DMARC, and DKIM record inspection does not authenticate a particular message. These distinctions drive every result below.

Evidence collection and trust boundaries

Pasted DNSSEC, TLSA, SPF, DMARC, and DKIM values are parsed in the browser. They are not sent merely because they were pasted. A live DNS action first asks the fixed Cloudflare DNS-over-HTTPS JSON endpoint from the browser. If that request fails, the browser calls the same-origin DNS helper; that helper prefers server-side Cloudflare DNS-over-HTTPS for MX and TXT and can use the web server’s native resolver for supported record types. The result displays resolver/source notes where available. This means live DNS evidence is a view through those resolver paths, with their cache state and vantage point.

Live TLSA/certificate comparisons use a restricted same-origin endpoint. It accepts a normalized public DNS host, rejects private or non-public target addresses, uses a conservative port allowlist and short timeouts, and does not fetch arbitrary URLs. SMTP readiness resolves public MX hosts, probes only the first three ordered MX targets on TCP port 25, and attempts EHLO, STARTTLS, and certificate capture separately for every resolved public A and AAAA address of each selected target. Optional MTA-STS, TLS-RPT, DANE, and FCrDNS checks run only when selected.

The bounded SMTP diagnostic probe can retain per-address certificate evidence from broken servers without treating that path as PKIX proof. When MTA-STS is selected, a separate strict transport result for every resolved address requires SNI for the MX hostname, a trusted and current WebPKI chain, and a matching DNS-ID in the certificate SAN; CN fallback is not accepted. DANE-EE comparison instead hashes the certificate or SPKI captured from each address-specific STARTTLS session and compares it with DNSSEC-secure TLSA data at that MX owner name.

Normalization before a decision

DNS names are trimmed, lowercased, and stripped of a final dot. Browser validators reject URLs, user-info, ports, and private single-label names; labels must fit normal LDH syntax. The same-origin PHP helper also performs IDNA conversion when the runtime provides it, while preserving the normalized ASCII name used for the query. Empty lines are removed from pasted record sets.

DS, DNSKEY, and RRSIG values are tokenized into their presentation fields. TLSA accepts ordinary presentation format and generic \# length hex format without silently deleting characters. Its three numeric fields are octets; unknown values can be syntactically valid but remain unsupported and unusable. Known SHA-256 and SHA-512 associations must be exactly 32 and 64 bytes, while an exact match must contain complete non-empty octets.

SPF terms are whitespace-delimited. DKIM and DMARC tag names and their version values are case-sensitive; an exact duplicate DKIM or DMARC tag invalidates that tag list instead of selecting the last value. MTA-STS uses its own grammar: required non-mx fields use the first value and later duplicates are ignored with a warning. TLS-RPT likewise follows its own record grammar and may combine more than one rua field. Parser decisions are protocol-specific, never imported from a generic last-wins map.

DNSSEC decision logic: resolver verdict versus record inventory

The DNSSEC tool parses DS, DNSKEY, and RRSIG records, labels known algorithms and digest types, and reports malformed records, absent evidence, unknown algorithms, and SHA-1 DS digests. That is structural inventory only: DS plus DNSKEY plus RRSIG does not become a validated chain. A secure status or authenticated-data indication is accepted only as the named validating resolver’s verdict. Explicit bogus evidence, including Extended DNS Error code 6 where supplied, is blocking; bare SERVFAIL, timeout, or generic failure remains unavailable because many non-DNSSEC failures produce the same symptom.

The page does not calculate the DS digest from each DNSKEY, verify RRSIG cryptography, validate signature inception/expiry, or build an independent chain from the root trust anchor. Consequently, DS/DNSKEY/RRSIG tables are inventory. The independent part is structural parsing and consistency of the supplied fields; the cryptographic verdict is delegated to the selected validating resolver. If a live subquery fails, its evidence can be empty. Missing records plus no secure verdict must therefore remain incomplete, not “unsigned” or “safe.”

DANE decision logic: three gates, then usage-specific trust

A complete implemented DANE result needs three separate gates: a syntactically valid and usable TLSA RRset at _port._protocol.host, a DNSSEC-secure resolver result for that RRset, and a certificate-association comparison. Records with the same usage, selector, and matching type form one parameter group. Any current association in a group may match, which permits old and new credentials to coexist during a same-parameter rollover; every supported published group must nevertheless contain a current match before this tool reports a clean result. Different parameter groups are not a universal logical OR: a SHA-256 match beside a SHA-512 mismatch, or the reverse, cannot prove that all clients will succeed because clients differ in digest support and RFC 7671 selection behavior.

For a credential rollover, prepublish the old and new association data at least two relevant TLSA TTLs before changing the credential, allow for publication and cache propagation, then switch and check every service endpoint. Remove the old association only after the old credential is no longer used anywhere. The current live path evaluates DANE-EE usage 3 for selectors 0 (full certificate) and 1 (SPKI), with matching types 0 (exact), 1 (SHA-256), and 2 (SHA-512), and compares each group with material captured from the same STARTTLS session. A usage-3 match does not require PKIX validation, hostname matching, or an unexpired WebPKI certificate; those facts remain separate operational or MTA-STS evidence. DANE-TA usage 2 is reported unsupported because a valid result would require the presented full chain, association to the selected trust anchor, and SMTP reference-identity validation. The current tool treats PKIX-TA (usage 0) and PKIX-EE (usage 1) as unusable in this opportunistic SMTP-DANE profile, consistent with RFC 7672 §3.1.3, where their SMTP-client treatment is undefined and clients may treat them as unusable.

A secure TLSA match authenticates only the checked service host and TLSA owner. Claiming DANE-authenticated routing for a mail domain additionally requires an authenticated MX RRset and authenticated handling of every alias step. The current SMTP readiness runtime does not independently validate that complete domain-routing chain, so its host-level DANE result must not be read as domain-wide DANE proof. A secure RRset with a mismatching supported group is blocking; unavailable DNSSEC, absent TLSA, or only unsupported records stays unavailable or unsupported.

Mail-authentication decision logic: syntax and policy, not message authentication

The mail-authentication checker finds SPF TXT records at the domain, DMARC at _dmarc.domain, and DKIM at a manual selector or the first match in a documented list of common selector names. Auto-selector search is convenience evidence, not exhaustive discovery; failure to find a selector is unknown, not proof that the domain does not sign mail.

SPF checks the v=spf1 marker, multiple SPF records, unsafe +all, terminal ordering, modifiers, address/CIDR syntax, the ptr mechanism that RFC 7208 says SHOULD NOT be used, and a static count of direct DNS-triggering terms. That count is an estimate, not a complete SPF evaluation: the tool does not recursively expand includes, redirects, A, or MX trees, and SMTP’s implicit-MX fallback must never be applied to the SPF mx mechanism. It therefore cannot award a complete ten-lookup-budget pass. DMARC checks the case-sensitive version marker, policies, alignment tags, report URIs, duplicate and historic tags, and monitoring-only p=none. The current checker does not implement complete RFC 9989 DMARC policy discovery through the DNS tree walk and Organizational Domain determination. No record at the exact owner _dmarc.<input> therefore proves only that no DMARC policy record was found at that owner; it does not prove that no inherited DMARC policy applies to the domain. The checker also does not simulate identifier alignment for a message. DKIM checks case-sensitive tag syntax, version position, duplicate tags, key presence/revocation, base64, recognizable RSA/Ed25519 key material, and key size where decodable; it does not verify a DKIM-Signature over message content.

SMTP transport decision logic

MX evidence is classified before any connection: ordinary MX, Null MX, implicit MX, mixed, malformed, or NXDOMAIN. An existing domain without an MX RRset uses the domain itself as an effective preference-0 SMTP target. Null MX separately means “no inbound mail.” Explicit MX records disable that implicit fallback even when their targets are broken. For each selected effective target, the tool attempts every resolved public IPv4 and IPv6 address and records STARTTLS advertisement, handshake evidence, certificate material, negotiated protocol, and the selected trust mode per address. A complete readiness pass requires coverage of every effective MX target and every resolved address in the selected top-three set. An unattempted address is incomplete, not an inferred STARTTLS, certificate, MTA-STS, DANE, or FCrDNS failure.

Selected policy layers keep their own trust and severity. For MTA-STS and TLS-RPT discovery, records beginning with the respective protocol-version marker are counted before the selected record is fully parsed; a second malformed protocol candidate therefore cannot disappear and leave an apparent single valid record. MTA-STS then requires exactly one candidate TXT record and a syntactically complete policy from the fixed HTTPS URL with HTTP status exactly 200 and no redirects, WebPKI authentication of the policy host, full policy-MX coverage, and strict STARTTLS/WebPKI/SAN-only audit evidence for each covered target. The runtime records the policy response Content-Type and warns when a returned media type is present but not text/plain, as recommended by RFC 8461; a missing Content-Type is not currently flagged. mode: none needs no mx field and is inactive. testing records failures but, unlike enforce, does not require a conforming sender to stop delivery. The tool audits the current observed endpoints against strict transport requirements; it does not reproduce a particular sender's cached policy or delivery decision.

TLS-RPT requires exactly one candidate v=TLSRPTv1 record and at least one syntactically valid mailto: or https: rua URI; this proves neither destination acceptance nor report delivery. A failed DANE check is not rescued by MTA-STS. FCrDNS requires, for each tested IP, a PTR name whose A or AAAA answer contains that original IP. PTR equality with the MX hostname is separate identity-consistency information, not part of the round-trip definition.

Severity semantics and unknown handling

An error means the supplied or observed evidence contains a blocking contradiction for that selected audit: malformed mandatory syntax, explicit DNSSEC bogus, a secure usable TLSA RRset with a mismatching supported parameter group, missing STARTTLS, a strict MTA-STS PKIX/SAN audit failure, prohibited legacy TLS, or an impossible MX state. It is not automatically a prediction of a sender's delivery action: in particular, MTA-STS testing reports failures while enforce can block delivery. The same fact can have different meaning under opportunistic SMTP, MTA-STS testing, MTA-STS enforce, and DANE; severities are not copied across trust modes. A warning means evidence is incomplete, not proven, operationally weak, optional-but-selected and absent, or based on a non-exhaustive heuristic. Info is inventory or context and does not improve validity by itself.

Pass means all gates implemented for that selected check were satisfied by the supplied and observed evidence. It is not a blanket security score. Network timeout, resolver failure, native DNS without a trustworthy DNSSEC status, unprobed MX hosts, missing certificate material, an unsearched DKIM selector, or unsupported DANE-TA must stay unavailable, incomplete, unsupported, or warning. The tool should never convert “could not check” into “no problem.”

Reproduce the evidence manually

Replace the documentation placeholders below with the same domain, MX host, and selector shown in the tool. Query at least one validating resolver and preserve the complete output, resolver address, and observation time.

# DNSSEC inventory and validating-resolver verdict
dig @1.1.1.1 +dnssec example.net DS
dig @1.1.1.1 +dnssec example.net DNSKEY
dig @1.1.1.1 +dnssec example.net A
# In the final response, inspect status, flags (including ad), Answer and Authority.

# Mail-routing and authentication-record inventory
dig @1.1.1.1 example.net MX
dig @1.1.1.1 example.net TXT
dig @1.1.1.1 _dmarc.example.net TXT
dig @1.1.1.1 selector1._domainkey.example.net TXT

# TLSA evidence and a 3 1 1 value for one concrete MX address.
# Repeat with each A and AAAA address; the digest comes from this saved leaf.
set -euo pipefail
mx=mail.example.net
ip=192.0.2.10
case "$ip" in *:*) connect="[$ip]:25" ;; *) connect="$ip:25" ;; esac
work=$(mktemp -d)
trap 'rm -rf "$work"' EXIT

dig @1.1.1.1 +dnssec "_25._tcp.$mx" TLSA >"$work/tlsa.txt"
timeout 15s openssl s_client -starttls smtp -connect "$connect" \
  -servername "$mx" -showcerts </dev/null 2>&1 | tee "$work/session.txt" >/dev/null
awk '/-----BEGIN CERTIFICATE-----/{copy=1} copy{print} \
  /-----END CERTIFICATE-----/{exit}' "$work/session.txt" >"$work/leaf.pem"
test -s "$work/leaf.pem"
openssl x509 -in "$work/leaf.pem" -noout >/dev/null
openssl x509 -in "$work/leaf.pem" -pubkey -noout >"$work/spki.pem"
openssl pkey -pubin -in "$work/spki.pem" -outform DER -out "$work/spki.der"
test -s "$work/spki.der"
openssl dgst -sha256 -binary "$work/spki.der" | xxd -p -c 256

# Separate strict WebPKI/SAN diagnostic; do not use this second session as digest input.
timeout 15s openssl s_client -starttls smtp -connect "$connect" \
  -servername "$mx" -verify_hostname "$mx" -verify_return_error </dev/null

Run the DNS and SMTP observations close together. A TLSA mismatch across a certificate rollover may simply be two cache/vantage snapshots taken at different times. Compare the exact owner name, usage, selector, matching type, and digest—not only the final hexadecimal string.

Limits and common false positives

DNS caches can show different rollover stages. Split-horizon DNS, ECS, anycast, and provider steering can make the web-server and operator vantage points differ. A browser DoH failure can switch the source to the same-origin helper. Native DNS fallback can return records without a verifiable DNSSEC state. The DNSSEC page’s secure state relies on resolver evidence and is not an independent cryptographic validator.

SMTP tests are bounded to the first three MX hosts but attempt every public address returned for those hosts. Greylisting, connection limits, tarpits, regional ACLs, transient packet loss, SNI behavior, and different certificates across addresses can change the result. Unprobed MX hosts or addresses keep full coverage incomplete; an attempted address with a real connection or protocol failure is reported as that failure. SPF lookup estimates exclude recursive expansion. Common-selector DKIM discovery is incomplete. TLS-RPT syntax cannot prove report delivery. The MTA-STS view is an audit snapshot, not evidence of every sender's cached policy. DANE-TA remains unsupported without real chain and identity validation, and the DANE-EE live comparison authenticates the checked host rather than the domain's complete MX/alias routing chain. A record that parses can still be operationally wrong for the organization’s actual senders, recipients, or rollover state.

Standards references and methodology version

Primary references: RFC 4033, RFC 4034, and RFC 4035 for DNSSEC; RFC 8914 for Extended DNS Errors; RFC 6698, RFC 7671, and RFC 7672 for DANE/TLSA and SMTP; RFC 5321 and RFC 3207 for SMTP routing and STARTTLS; RFC 7208 for SPF; RFC 6376, RFC 8301, and RFC 8463 for DKIM, including Ed25519; RFC 9989, RFC 9990, and RFC 9991 for DMARC and reporting; RFC 8461 for MTA-STS; RFC 8460 for TLS-RPT; and RFC 7505 for Null MX. RFC 8624 is historical and was obsoleted by RFC 9904; live DNSSEC algorithm recommendations come from the current IANA DNS Security Algorithm Numbers and DS Digest Algorithms registries. RFC 9325 and RFC 9525 provide current TLS and identity guidance.

Methodology version 1.4, dated 2026-09-07. The version describes the behavior documented on this page; changes to evidence sources, resolver paths, trust gates, or severity rules require a methodology update.