Keep DNS trust and certificate association separate
A DANE checker should show whether DNSSEC authenticated the relevant DNS evidence and whether a usable TLSA association matched the observed TLS endpoint. Those are different findings. A TLSA record can be visible in DNS without a validated chain of trust, and a securely retrieved TLSA record can fail to match the server's presented certificate material. A single green label hides the distinction that an operator needs to diagnose the problem.
RFC 7672 defines DANE for SMTP, building on the TLSA association format in RFC 6698. This article proposes checker acceptance requirements, not implemented EmailAuth behavior. No domain was scanned, TLS connection opened or record changed. The required original test cases remain open rather than being replaced by imagined successful output.
Identify the mail route and exact endpoint
Start with the receiving domain and the relevant MX route under the supported SMTP procedure. Record the MX hostname, port, TLSA owner name and any aliases or discovery steps used. A TLSA association for a website is not evidence for the SMTP endpoint, and a successful connection to one MX host does not establish the behavior of every host serving the domain. Preserve the route and observation scope before interpreting a certificate match.
RFC 7672 describes the DNSSEC-sensitive discovery and TLSA lookup process for SMTP. The checker should state which procedure it implements and retain the exact queries used in an authorized test. Do not infer a secure route from an unsigned name merely because a later lookup returns a TLSA-like string. Dependencies and trust state at the relevant discovery steps matter to the overall result.
Explain DNSSEC states accurately
DNSSEC validation requires a trust context, not simply a visible signature. Under RFC 4035 section 4.3, secure data has an authenticated chain from a trusted starting point. An insecure RRset lacks that authenticated chain and may or may not be signed. A signed island without an applicable trust anchor must therefore not be labeled unsigned merely because it is insecure. Bogus means the expected authentication could not be established, rather than an ordinary absence of a trust chain.
The SMTP profile makes the remaining distinction explicit. RFC 7672 section 2.1.1 uses indeterminate for failure to obtain the DNSSEC data required to determine the validation state, following RFC 4035, and treats that as a lookup failure. Absence of an applicable ancestor trust anchor is handled as insecure. A checker must preserve these SMTP-specific categories instead of applying a generic state label without its cause.
A checker should not describe unsigned evidence as a valid DANE association merely because the DNS lookup succeeded. It should also avoid calling every DNS error bogus without the necessary validation evidence. Retain resolver configuration, trust-anchor context and the reported state where the supported interface exposes it. RFC 4035 describes validation and resolver behavior; an arbitrary response flag without a trusted resolver context is not a substitute for that process.
Parse TLSA fields before matching
RFC 6698 defines certificate usage, selector, matching type and association data. The selector determines whether the association concerns the full certificate or its SubjectPublicKeyInfo. The matching type determines whether the association is exact data or a supported digest representation. The checker must identify these fields and the actual bytes selected for comparison rather than compare every TLSA value with a generic certificate fingerprint.
The certificate-usage value changes the authentication model. In the SMTP profile, RFC 7672 explains DANE-TA(2) and DANE-EE(3) and their respective processing. It says SMTP servers should not publish PKIX-TA(0) or PKIX-EE(1) associations for this purpose, and client treatment of those usages is undefined; clients may treat them as unusable. Do not generalize generic TLSA usage definitions into a promise that every SMTP client supports every usage.
Distinguish absence, unusability and mismatch
An absent TLSA record, an insecure answer, a securely obtained but entirely unusable TLSA set and a usable association that fails to match are not interchangeable. RFC 7672 gives different handling for these conditions. A checker should retain the exact category and the reason, including unsupported fields or malformed association data, rather than compress them into “DANE failed.”
For a usable association, record the endpoint's observed certificate material and the matching calculation under the selected fields. A public-web certificate chain result is not automatically the DANE result because the usage determines the trust model. Conversely, a matching digest from an unvalidated DNS source is not a secure DANE success. Both the DNS evidence and the association evaluation need their own retained observations.
Preserve connection and timing evidence
The TLS connection evidence should identify the hostname, address, port, observation time, negotiated context relevant to the check and certificate material or safe fingerprints needed for review. Keep sensitive connection details out of public summaries where unnecessary. A failed connection is a different result from a connected server presenting mismatching material. The output should explain which stage prevented a conclusion.
DNS and TLS observations can change during certificate rotation or route changes. Retain the timing and TTL context without claiming that a single observation proves permanent readiness. A checker should not automatically “repair” a mismatch by publishing the currently observed certificate association; that would bypass ownership, approval and rotation planning. This manuscript makes no such change and contains no live connection evidence.
A two-part evidence worksheet
Create a DNS section with receiving domain, MX path, TLSA owner, resolver, trust context, response code, validation state, complete RRset and timestamp. Create a TLS section with endpoint, connection outcome, certificate selection, matching method, association result and scope limitations. Link the sections only when they describe the same intended route and observation context.
The required fixtures should cover unsigned DNS, validation failure, missing association, mismatching material and a valid association. Add explicit expected behavior for unsupported usage or matching fields where the evaluated implementation needs it. Use authorized isolated fixtures, not third-party infrastructure. A fixture labeled valid should contain retained validation and matching evidence, not a manually assigned pass field. No fixtures were executed for this article.
Fictional diagnosis: a matching hash from unsigned DNS
A fictional operator sees a TLSA value that matches the server's observed public key and assumes DANE is working. The proposed review asks how the TLSA answer was authenticated. If the answer is insecure rather than securely validated, the apparent byte match does not establish the DANE trust chain. The TLS match and DNS trust finding must remain separate.
The team would collect authorized resolver and endpoint evidence and review the intended DNSSEC deployment before deciding on remediation. It would not publish keys, alter delegation or bypass validation to obtain a green result. This is a fictional exercise, not an observed domain or successful TLS connection. Its purpose is to demonstrate why the checker's explanation matters more than a single status color.
State the demonstrated result only
A useful conclusion names the tested route, DNSSEC state, TLSA usability and observed association result. It does not certify every MX host, every resolver or future certificate rotation. The output should also identify stages that were not reached and evidence that remains unavailable.
The catalogue requires unsigned, validation-failed, missing, mismatching and valid association cases. Those original tests remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies an acceptance design and fictional diagnosis, not executed DANE scans or verified platform capabilities.