A TLSA record associates a TLS service with certificate or public-key data. It is not a TXT record, a replacement for an MX record or evidence that every sender uses DANE. For SMTP, the relevant discovery and enforcement behavior is defined by RFC 7672.
Start with the MX service hostname
References: RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
For a service on TCP port 25 at mx.example.com, the conventional TLSA owner is _25._tcp.mx.example.com. Derive the name from the actual SMTP exchange hostname, not automatically from the visible From domain or zone apex. Check every MX endpoint that the deployment intends to protect and the DNSSEC status along the discovery path.
The TLSA data fields are certificate usage, selector, matching type and association data. For this simple non-aliased route, the owner shown is sufficient; aliases require the authenticated TLSA base-domain handling in RFC 7672 §2.2. A commonly recommended SMTP DANE profile is 3 1 1: DANE-EE usage, SubjectPublicKeyInfo selection and SHA-256 matching. These numbers are meaningful protocol choices, not a generic prefix for arbitrary certificate text. RFC 7672 and RFC 7671 describe supported usages and operational considerations; keep unsupported combinations out of a deployment recipe.
Derive the exact bytes
References: RFC 6698 §2.1.2, RFC 6698 §2.1.3.
For a local PEM certificate file cert.pem, in a Bash shell first enable set -o pipefail; a reproducible SPKI digest pipeline is then openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256. Require every stage to succeed. Hash the DER public-key representation, not the PEM text, the displayed fingerprint or the whole certificate when selector 1 is intended.
Construct _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST, replacing HEXDIGEST with the actual digest. This is a template, not a publishable record. Obtain the certificate presented by the intended SMTP endpoint through a controlled STARTTLS inspection and compare its selected bytes. A local file may differ from the certificate the server really serves.
Test a key change before retiring the old association
References: RFC 7672 §4, RFC 7671 §8.
Synthetic fixture A uses a test certificate with key A and a TLSA association derived from A. Expected byte comparison is a match. Fixture B serves a certificate with key B while retaining only A's association; expected comparison is a mismatch. Fixture C publishes both acceptable associations for a planned transition and verifies the intended endpoint against B before retiring A.
The timing must account for cached TLSA data and all active server instances. A certificate renewed with the same public key can keep the same 3 1 1 association, whereas a new key changes it. A successful digest comparison is a local cryptographic check, not an SMTP DANE interoperability result. Live DNSSEC and SMTP testing remain separate evidence requirements.
Verify transport rather than a dashboard label
References: RFC 7672 §2.2, RFC 7672 §3.
Use a DNSSEC-validating path to establish usable TLSA data, then test the actual SMTP handshake and association with a DANE-capable implementation. Preserve DNS answers, validation trace, certificate chain, selected association and the sender's result. A supporting sender should not silently treat a failed required DANE authentication as a successful secure delivery. Do not claim universal transport protection: sender support and the exact authenticated discovery result matter.
Observed association and discovery checks
References: RFC 4035 §5.
The retained 7 November 2026 signed fixture, inspected but not rerun for this review, validates a TLSA RRset through a pinned parent, authenticated DS and child DNSKEY. A separate loopback TLS service actually presented test certificate A and then B. Extracting SPKI from each received handshake certificate produced a match for A against A, a mismatch for B against A alone, a match for B during an A/B overlap and a match for B after retiring A. The transcript records timestamps, loopback endpoints, TLS protocol and digests. This validates the separate cryptographic ingredients; the service was ordinary TLS, not SMTP STARTTLS, and no integrated DANE mail client or live DNS resolver test is claimed.