SMTP started life in 1982 as a plaintext protocol. Forty years later, most mail is still carried by it — with TLS bolted on as an afterthought called STARTTLS.
STARTTLS is opportunistic: the client asks, the server agrees, and if a middlebox or attacker silently removes the "STARTTLS" advertisement from the server's banner, both sides happily continue in plaintext. That's a downgrade attack, and it's the reason your bank's email could theoretically cross the internet unencrypted without anyone's software complaining.
Two complementary standards close this hole: MTA-STS (RFC 8461) and DANE (RFC 7672). The MTA-STS & TLS-RPT and DANE/TLSA tools in yas.sh check both sides of the equation.
MTA-STS: HTTPS-published policy
MTA-STS tells other mail servers: "when you connect to my MX hosts, TLS is not optional." It has two parts:
Part 1 — a TXT record at mta-sts.yourdomain.com:
mta-sts.yourdomain.com. TXT "v=STSv1; id=20260808"
The id is a version string — it must change every time the policy changes, or receivers won't re-fetch it.
Part 2 — the policy file served over HTTPS at:
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
max_age: 604800
mx: mx1.yourdomain.com
mx: mx2.yourdomain.com
| Directive | Meaning |
|---|---|
version |
Always STSv1 |
mode |
enforce (mandatory TLS), testing (report only), none |
max_age |
How long receivers cache the policy |
mx |
Hostnames that may receive mail — the policy is invalid if these don't match real MX records |
The MTA-STS tool fetches the policy over HTTPS, parses every directive, and cross-checks each mx: entry against the domain's live MX records — a mismatch means receivers will reject the policy.
TLS-RPT: seeing the failures
A policy you can't observe is a guess. TLS-RPT (RFC 8460) is the reporting side: a TXT record at _smtp._tls.yourdomain.com that tells senders where to deliver transport-security reports:
_smtp._tls.yourdomain.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"
When Gmail tries to send you mail and the TLS connection fails, it emails a JSON report to that address. If you enforce MTA-STS without TLS-RPT, you're enforcing blind.
DANE: pin the certificate in DNS
DANE does for SMTP what HSTS does for HTTPS — but stronger, because the trust anchor is DNSSEC-signed DNS rather than a policy served by the very server you're connecting to.
A TLSA record at _25._tcp.yourdomain.com publishes a hash of the expected certificate or its public key:
_25._tcp.yourdomain.com. TXT "3 1 1 0d0f0a3d8f2c1d4b..."
The four fields are:
| Field | Meaning |
|---|---|
| Usage | 3 domain-issued (typical), 2 trust anchor, 1/0 for CA-based schemes |
| Selector | 0 = hash of the SPKI (public key), 1 = hash of the full certificate |
| Matching type | 1 = SHA-256, 2 = SHA-512, 0 = full data |
| Data | The hex hash |
Because selector 0 hashes the public key, rotating certificates without changing keys doesn't break DANE — that's why it's the recommended choice.
The DANE/TLSA tool connects to your host with TLS, extracts the certificate and its SPKI, computes the SHA-256/512 hashes, and compares them against every published record — a per-record ✅/❌ verdict.
Practical deployment note: DANE only works if your domain is DNSSEC-signed, and it must be tested carefully first — a mismatched TLSA record on an enforcing receiver means your mail stops arriving entirely. Publish, validate with the tool, then enforce.
The checklist
v=STSv1TXT atmta-sts.subdomain with a changingid.- Policy file at
/.well-known/mta-sts.txt— modeenforce,mx:matching your MX records. v=TLSRPTv1TXT at_smtp._tls.so you see failures.- If you run DNSSEC: TLSA records at
_25._tcp., SPKI-based (usage 3, selector 0). - Re-run the MTA-STS tool after every change — the policy's
idmust bump or nothing updates.
Transport security for email is a two-sided agreement. Publishing the records is half; the other half is other people honoring them. The standards are mature, the tooling is free, and the failure mode of not doing it is your mail silently traveling in plaintext — or worse, being quietly redirected. That's not a risk worth taking for a four-field TXT record.
What these mechanisms actually protect
SPF, DKIM, and DMARC protect the content of email — who is allowed to send as your domain and whether the message is authentic. MTA-STS and DANE protect the transport — the connection between mail servers themselves. A message can be fully authenticated yet still be intercepted or tampered with in transit if the connection between the sending and receiving servers is not secured. MTA-STS and DANE address exactly that gap by forcing mail servers to use TLS on the connection, so authentication and transport security work together to keep email safe end to end.
MTA-STS: how it works
MTA-STS (Strict Transport Security) is a policy that tells receiving mail servers to require an encrypted connection to your domain. It works by publishing a policy at a well-known HTTPS URL that declares how strictly TLS should be enforced, plus a reporting mechanism that tells you about failures. When a sender sees the policy, it refuses to fall back to plaintext for your domain, closing the downgrade window where an attacker could intercept or read mail on the wire. MTA-STS is a strong, broadly deployable control that does not depend on DNS-specific features.
DANE: the DNS-rooted alternative
DANE (DNS-based Authentication of Named Entities) achieves a similar goal through a different root: instead of a policy over HTTPS, it publishes the expected TLS certificate or a hash of it in the DNSSEC-protected DNS records (TLSA records). A mail server with valid TLSA records signals "here is the certificate you should trust for me," and senders can verify it. Because DANE's assurance is rooted in DNSSEC rather than the CA system, it provides strong protection — but it requires DNSSEC to be deployed, which is why it is not universally available. Understanding this dependency tells you when DANE is an option and when MTA-STS is the practical choice.
Deploying transport security safely
Like DMARC, transport security should be rolled out without breaking legitimate mail. Start by publishing the policy in monitoring or a lenient mode and reading the reports to confirm that legitimate senders can still deliver. Then tighten enforcement only once you are confident the connection is secure for all the servers that talk to your domain. Monitoring the failure reports during the rollout is what lets you strengthen without accidentally cutting off legitimate mail. Used together with email authentication, transport security completes the picture of trustworthy email delivery.