TLS-RPT & MTA-STS: closing the last unencrypted mile of email
SPF, DKIM and DMARC authenticate who sent a message. None of them protect the message itself while it travels between mail servers. That job belongs to TLS — and SMTP's version of TLS has a forty-year-old politeness problem: it is optional, and an attacker on the network path can simply ask both sides not to use it. MTA-STS and TLS-RPT are the two small standards that fix this, and they take about an hour to deploy.
The problem: encryption that asks permission
When one mail server delivers to another, it opens a plain-text SMTP connection and asks whether the receiver supports encryption via the STARTTLS command. If yes, the connection upgrades to TLS; if no, the mail is sent in the clear. This "opportunistic TLS" was a pragmatic retrofit — it never breaks delivery — but it has a fundamental flaw: the negotiation itself is unencrypted.
An attacker positioned on the network path (a compromised router, a hostile network, a nation-state middlebox) can strip the STARTTLS capability from the receiver's response. Both servers, behaving correctly, then fall back to plain text, and every message — password resets, contracts, personal data — crosses the wire readable. Neither side logs anything unusual. This is not theoretical; STARTTLS stripping has been observed at ISP scale.
MTA-STS: turning "please" into policy
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets your domain declare: mail for us must be delivered over verified TLS, to these specific mail hosts, or not at all. Senders that support it (Google and Microsoft do, which covers most of the volume that matters) cache your policy and refuse to fall back to plain text — the stripping attack stops working.
Deployment has two parts. A DNS TXT record at _mta-sts.yourdomain.dk (v=STSv1; id=2026070501) signals that a policy exists; the id changes whenever the policy does. The policy itself is a small text file served over HTTPS at https://mta-sts.yourdomain.dk/.well-known/mta-sts.txt, listing version, mode, your permitted MX hosts, and a max_age for caching.
The mode field gives you a safe rollout path: mode: testing asks senders to evaluate the policy and report failures without enforcing anything; mode: enforce is the real thing. Start in testing, watch the reports for a couple of weeks, then flip to enforce. The only real operational rule afterwards: when you change mail providers, update the policy file and bump the DNS id before the old MX hosts go dark.
TLS-RPT: the feedback channel
MTA-STS without reporting is flying blind — if a big sender cannot establish verified TLS with you, mail silently queues and retries, and you would never know why. TLS-RPT (RFC 8460) fixes that with one TXT record at _smtp._tls.yourdomain.dk: v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.dk.
Participating senders then email you a daily JSON summary per sending platform: how many sessions succeeded, how many failed, and precisely why — certificate expired, hostname mismatch, STARTTLS unavailable, policy fetch failed. A sudden spike in failures is an early-warning signal for exactly two things you urgently want to know about: a broken certificate on your mail host, or someone actively interfering with your traffic.
TLS-RPT is free to deploy, has no failure mode of its own (it is only a reporting address), and is useful even before MTA-STS: reports will tell you whether anyone is currently failing to reach you over TLS — which is precisely the data you want before turning enforcement on.
How this fits the rest of your email security
Think of the standards as answering different questions. SPF/DKIM/DMARC: is this message really from who it claims? MTA-STS: was it encrypted and delivered to the right servers? TLS-RPT: is anyone failing — or being prevented — from doing so? A domain with DMARC at p=reject, MTA-STS in enforce mode and TLS-RPT reporting has closed both the authentication and the transport attack surfaces of email, which is more than most banks can say.
The checks are cheap to run and cheap to forget. MonitorBase's full audit verifies both records and the policy file's reachability and mode, and monitoring alerts you if the policy file goes unreachable — the one failure that, under enforce, can actually delay your inbound mail.