SaaSFort Most SaaS teams consider email security solved once SPF, DKIM and DMARC are green. Those three answer one question well: is this message really from you?
They answer a completely different question not at all: did the message travel encrypted?
The gap nobody checks
SMTP negotiates encryption with a plaintext command. A sending server connects, the receiving server advertises STARTTLS, and the session upgrades to TLS.
The advertisement itself is unauthenticated. An attacker positioned on the network path strips the STARTTLS capability from the receiving server’s reply. The sender, seeing no offer of encryption, delivers over plain TCP. Both sides believe they behaved correctly. Nothing in SPF, DKIM or DMARC fires, because all three validate the message, not the tunnel.
This is a downgrade attack, and it has been practical for as long as SMTP has existed.
What MTA-STS actually does
MTA-STS (RFC 8461) lets a receiving domain publish a commitment: mail to me must arrive over authenticated TLS, and here are the hosts allowed to receive it. A sender that supports MTA-STS fetches that policy, caches it, and refuses to deliver if the connection cannot be secured.
It has two parts, and both must exist.
A DNS record at _mta-sts.yourdomain.com:
v=STSv1; id=20260913120000
A policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.mail.protection.outlook.com
max_age: 604800
The HTTPS requirement is the point: the policy is authenticated by the certificate authority system, so an attacker who can tamper with DNS still cannot forge the policy.
The mode field is the whole story
Three values are legal, and only one protects anything.
| Mode | Behaviour | Protects mail? |
|---|---|---|
none | Policy exists but asserts nothing | No |
testing | Failures are reported, mail still delivered unencrypted | No |
enforce | Sender refuses to deliver over an unprotected connection | Yes |
A domain sitting in testing for a year has the appearance of a control and none of the effect. This is worth stating plainly because it is the most common outcome: teams deploy in testing mode, the reports look fine, and nobody schedules the switch.
TLS-RPT is what makes enforce safe
Switching straight to enforce risks silently blocking legitimate mail, for example if one MX host is missing from the policy or presents a certificate that does not validate.
TLS-RPT (RFC 8460) is the feedback channel. One TXT record:
_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Sending providers then deliver daily JSON summaries of successful and failed TLS negotiations toward your domain: certificate validation errors, handshake failures, hosts that offered no TLS at all.
The sequence that works:
- Publish TLS-RPT first.
- Publish MTA-STS in
mode: testing. - Read reports for two to four weeks. Fix every failure they surface.
- Switch to
mode: enforceonce the reports are clean. - Keep reading them, because an expiring certificate on one MX host will show up here before a customer notices.
Doing it in that order is the difference between a control and an outage.
Adoption is low, which is exactly why buyers notice
Published surveys of the top one million domains in 2026 put MTA-STS adoption below one percent. The practical consequence for a B2B SaaS vendor is asymmetric: almost nobody has it, so having it is a visible differentiator in a security questionnaire, and the cost is two DNS records plus a static file.
For vendors selling into Germany, this is not optional polish. BSI TR-03108 requires transport security for email, and treats DANE, MTA-STS and TLS-RPT as a set rather than alternatives. If you are answering a BSI-driven audit letter, missing MTA-STS is a finding you can close in an afternoon.
Where it maps for compliance
- NIS2 Article 21(2)(h), cryptography and encryption: transport encryption for a communication channel carrying business data.
- NIS2 Article 21(2)(e), network security.
- ISO/IEC 27001:2022 A.8.24 (use of cryptography) and A.5.14 (information transfer).
- DORA Article 9, protection of data in transit, for financial entities and their providers.
How to verify it from outside
The whole point of an external control is that anyone can check it without your cooperation, which is also how a buyer will check it.
# 1. Is a policy advertised?
dig +short TXT _mta-sts.yourdomain.com
# 2. Does the policy exist, and what mode is it in?
curl -s https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
# 3. Is there a reporting channel?
dig +short TXT _smtp._tls.yourdomain.com
A SaaSFort scan runs all three and reports the mode, not merely the presence of a record, because a policy in testing is not a passing control.
The short version
SPF, DKIM and DMARC protect your brand from being impersonated. MTA-STS protects your customers’ mail from being read in transit. They are different problems, and the second one is currently unaddressed at the overwhelming majority of SaaS vendors.
Two DNS records and one static file. Start in testing, read the reports, then enforce.
Ready to put this into practice?
Two ways to start — pick what fits. Free Scan if you want to see your security grade in 60s with no commitment. Free 14-day Growth trial if you're ready to monitor multiple domains, export NIS2 reports, and download Deal Reports — no credit card required.
No credit card · Cancel anytime · GDPR-ready · EU-hosted