Email encryption in transit: TLS, MTA-STS and DANE

Mail between mailbox providers is encrypted in transit by default, using opportunistic TLS: the sending server upgrades the session if the receiver offers it, and continues in plaintext if it does not. That is a good default and a weak guarantee. Because it fails open, an attacker who can remove the STARTTLS advertisement from a server's capability list gets plaintext delivery, and neither side is told.

MTA-STS and DANE close that gap. TLS-RPT tells you when something tried.

The three layers, separated

None of these is end-to-end encryption. The receiving provider can read the message; so can yours. If the requirement is that only the recipient can read it, that is S/MIME or PGP, which are a different conversation with different operational costs.

Ports and modes

• 587 — submission with STARTTLS. The client connects in the clear and issues STARTTLS.
• 465 — implicit TLS. The TLS handshake happens immediately; issuing STARTTLS here is an error.
• 25 — server to server, opportunistic. This is the hop MTA-STS and DANE govern.

Confusing 587 and 465 is the most common cause of handshake failures at submission time, and it has nothing to do with the policy layers above.

MTA-STS, concretely

MTA-STS is published as a DNS TXT record plus an HTTPS-hosted policy file. The record:

_mta-sts.yourdomain.com.  TXT  "v=STSv1; id=20261015000000"

The policy, served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.mail.protection.outlook.com
max_age: 604800

Deploy in mode: testing first. In testing, senders that support MTA-STS report failures but still deliver. Only move to mode: enforce once reports are clean, because enforce means a sender that cannot validate your certificate will not deliver the mail. That is the point of the mechanism, and it is also how an expired MX certificate becomes an outage.

Note the mx lines must list every host in your MX records, wildcards included, and the id must change whenever you edit the policy.

TLS-RPT: the part people skip

_smtp._tls.yourdomain.com.  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"

Supporting senders then mail you a daily JSON summary of successful and failed TLS sessions to your domain. This is how you discover a misconfigured MX, an expiring certificate, or a genuine interception attempt before enforcement turns it into bounced mail. Publishing TLS-RPT costs nothing and should precede MTA-STS, not follow it.

DANE, briefly

DANE publishes TLSA records that pin the certificate your MX hosts present, validated through DNSSEC. It is a stronger guarantee than MTA-STS because it does not depend on the web PKI or an HTTPS fetch — and it is only available if your zone is DNSSEC-signed, which is a larger commitment. Several large European providers enforce DANE; adoption elsewhere is patchier. If DNSSEC is already in place, DANE is worth doing. If it is not, MTA-STS gets you most of the practical benefit sooner.

What this means for deliverability

TLS is a published sender requirement — Google's bulk-sender requirements include transmitting over a TLS connection — so a sender that habitually falls back to plaintext is failing a gate, not just leaking. The policy layers mostly affect inbound mail to your domain, which matters for a different reason: MTA-STS and TLS-RPT are the sort of domain hygiene that security reviews ask about, and getting them wrong causes outages that look like deliverability problems.

Keep the distinction clear. Encryption protects content on the wire. Placement is decided by domain reputation, complaint rate, list quality and engagement, and measured by seed testing rather than by a TLS report.

Deploy in this order

1. Fix submission: correct port and mode, valid certificate, no verification disabled.
2. Publish TLS-RPT and read reports for a few weeks.
3. Publish MTA-STS in mode: testing.
4. Confirm reports are clean, certificates auto-renew, and every MX host is listed.
5. Move to mode: enforce, and set a calendar reminder for certificate expiry regardless of automation.
6. Add DANE only if your zone is DNSSEC-signed.

What not to do

• Do not disable certificate verification to make an error go away. You have removed the only check that matters.
• Do not publish `mode: enforce` first. A mistake becomes undelivered mail from every supporting sender.
• Do not forget to bump the policy `id` when you change the file; caching senders will keep the old one.
• Do not let the policy host's certificate lapse. The policy is fetched over HTTPS; a failed fetch is a failed policy.
• Do not confuse transport encryption with end-to-end encryption in anything you tell customers.
• Do not expect MTA-STS to improve inbox placement. It governs encryption, not filtering.

How MailPilot helps

MailPilot validates the submission path when a mailbox is connected — port, encryption mode and credentials over OAuth or SMTP/IMAP — so a silently downgraded or misconfigured sender is caught at setup. For the parts that decide placement rather than privacy, it checks SPF, DKIM and DMARC alignment, warms mailboxes with real conversations, and measures inbox placement per provider with a seed-inbox network.