In our encryption article we wrote one line: "TLS protects the road; S/MIME/PGP seal the envelope." That article covered sealing the envelope. This one completes the half we left behind: the road itself. Because TLS has an insidious problem — in the email world, TLS is usually "opportunistic." That is, two servers may try to talk encrypted, but if an attacker in the middle plays the "I don't speak TLS" trick, the servers often silently fall back to unencrypted communication. No one sees an error, no one is warned — and the email travels like an open postcard.
In this third article of our Mail Technologies Series, we cover the two standards that take TLS from "attemptable" to mandatory: MTA-STS (which requires TLS) and TLS-RPT (which reports to you when TLS fails). Together they move the transport security of your inbound email from "hopefully encrypted" to "must be encrypted."
1. First, the Problem: "Opportunistic TLS" and the Downgrade Attack
When two mail servers connect, the sending server asks "do you support TLS?" (the STARTTLS command). If the other side says "yes," they continue encrypted. The problem: this handshake can be the target of an attack.
- Downgrade attack: An active man-in-the-middle corrupts the STARTTLS response; the sending server thinks "the other side doesn't speak TLS" and sends unencrypted. The content is exposed.
- No certificate validation: Opportunistic TLS often doesn't strictly validate the certificate; a rogue server can interpose and read the traffic.
- Silence: The worst part — none of this is reported to you. You don't even know a downgrade happened.
MTA-STS prevents the downgrade; TLS-RPT breaks the silence.
2. MTA-STS — Requiring TLS
MTA-STS (Mail Transfer Agent Strict Transport Security) lets you publish a policy for email coming to your domain: "if you're going to talk to me, TLS is mandatory and my certificate must be valid; otherwise don't deliver the email." Even if an attacker tries to downgrade STARTTLS, the sending server sees your policy and refuses unencrypted delivery.
How to set it up (three parts)
- Policy file: You publish a text file at
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It contains the mode (testingorenforce), your valid mail servers (mx), and a lifetime (max_age). - DNS TXT record: A TXT record at
_mta-sts.yourdomain.com:v=STSv1; id=...— this record tells sending servers the policy has been updated. - HTTPS and certificate: The
mta-stssubdomain serving the policy file must be reachable over HTTPS with a valid TLS certificate.
Common mistakes → the right way
- Mistake: starting straight in
enforce. If an MX is missing from the policy or there's a certificate issue, your inbound email starts being silently rejected. The right way: start withmode: testing, watch the TLS-RPT reports, and move toenforceonly once it's clean. - Mistake: an incomplete/incorrect MX list. The
mxlines in the policy must match your real mail servers exactly (e.g.*.mail.protection.outlook.comfor Microsoft 365). The right way: keep your MX records in sync with the policy file; when you change providers, update both together. - Mistake: not updating the
idwhen the policy changes. Sending servers detect a change via theidfield; if you don't update it, the old policy stays cached. The right way: refresh theidon every policy change (e.g. a timestamp).
3. TLS-RPT — Breaking the Silence
MTA-STS requires TLS but by itself doesn't answer "did something go wrong?" TLS-RPT (SMTP TLS Reporting) does exactly that: servers trying to send email to your domain send you daily summary reports of the successes/failures they experienced in the TLS handshake. So you see a fact like "12 emails were downgraded last week because TLS couldn't be established" instead of staying blind.
How to set it up
A single DNS TXT record suffices: at _smtp._tls.yourdomain.com, v=TLSRPTv1; rua=mailto:... (or an HTTPS endpoint). Reports flow there.
Common mistake → the right way (sound familiar?)
The same DMARC mistake from our first article applies here too: writing the rua address to a personal mailbox or an admin account on your own domain. TLS-RPT reports also arrive in JSON and aren't reviewed one by one; no one looks. The right way: collect the reports in the same management panel as your DMARC reports — the reporting service of the security vendor you work with (e.g. the email security management on the Check Point side) visualizes TLS-RPT under the same roof as DMARC. The rule is the same again: have a system read the report, not a human.
4. MTA-STS and DANE: A Short Note
Another way to make TLS mandatory is DANE (built on DNSSEC). The two solve the same problem via different routes: DANE requires a DNSSEC-signed infrastructure and is stricter; MTA-STS works without DNSSEC and is easier to deploy — which is why large providers like Microsoft 365 and Google widely support MTA-STS. For most organizations in Türkiye the practical starting point is MTA-STS + TLS-RPT; if your DNSSEC infrastructure is mature you can also consider DANE. The two can be used together.
5. This Layer Protects Confidentiality, Not Identity
Let's be clear: MTA-STS/TLS-RPT make it harder for email to be read/altered in transit (transport confidentiality). SPF/DKIM/DMARC answer "is the sender really you" (identity). They're different layers and complement each other — MTA-STS doesn't stop phishing, and DMARC doesn't stop a downgrade attack. For full protection you set up both. An organization's email security maturity is measured precisely by having all these layers at once.
Frequently Asked Questions
I use Microsoft 365 / Google Workspace — don't they already do TLS?
Yes, they support TLS — but in opportunistic mode. Without your MTA-STS policy, a server sending you email that gets hit by a downgrade attack can still deliver unencrypted. MTA-STS is the layer, on top of these providers, that makes TLS mandatory for email coming to your domain. Both Microsoft 365 and Google support MTA-STS.
Does MTA-STS protect my inbound or outbound email?
The MTA-STS policy you publish binds servers sending you email — i.e. it protects email coming to your domain. Protecting your outbound email depends on the other party publishing an MTA-STS policy. So the more widespread the standard, the more everyone benefits; by publishing your policy you both protect yourself and contribute to the ecosystem.
Can a misconfiguration lose my email?
If you jump straight to enforce and leave an MX out of the policy, yes — that route can be rejected. That's why you always start in testing mode and stay there until the TLS-RPT reports look clean. Set up in the right order, the risk is negligible.
How do I check my status?
MXToolbox and similar tools can query your MTA-STS policy and TLS-RPT record; many "email health" tests cover both records. If you like, our free field audit reports your MTA-STS/TLS-RPT status alongside your SPF/DKIM/DMARC report card.
What Should You Do Now?
If you've set up your identity layer (SPF/DKIM/DMARC), the transport layer is the next logical step. Start with two questions: (1) Does your domain have an MTA-STS policy? (2) Do you have a TLS-RPT record reporting TLS failures?
- Free Field Audit: Your MTA-STS/TLS-RPT status is reported alongside your SPF/DKIM/DMARC report card.
- Managed setup: We deploy MTA-STS with a safe transition from
testingtoenforce, and collect TLS-RPT reports in the same panel as DMARC.
About this article: The third article of our Mail Technologies Series; the continuation of the "TLS protects the road" line from our encryption article. The next will cover how identity is preserved through forwarding (ARC). Kinetik Bilişim is the Türkiye partner of Check Point Software Technologies at the Advanced Partner 2026 level, holding Email, Endpoint & Browser, Mobile, and SASE Solution Specialization accreditations. The author, Kemal Özleyen, is a cybersecurity engineer certified as a Check Point Workspace Security Expert.
