Most email security effort goes outbound: tighten SPF, configure DKIM, move DMARC to enforcement. These controls protect your domain from impersonation and improve deliverability. They’re worth doing.
But there’s a parallel gap in inbound mail security that fewer organisations address: without MTA-STS, an attacker who controls network infrastructure between a sending mail server and yours can intercept SMTP connections and force them to deliver email without encryption. The mail arrives. It just wasn’t private in transit.
MTA-STS closes that gap. It’s a one-time configuration that requires no ongoing maintenance and takes about 30 minutes to deploy. Here’s how it works and how to implement it.
The problem: SMTP TLS is opportunistic by default
When one mail server sends email to another, it uses SMTP. Modern SMTP implementations support STARTTLS — an extension that upgrades the connection to encrypted TLS if both sides support it. This is the mechanism that keeps most email traffic encrypted in transit today.
The problem is that STARTTLS is opportunistic. If TLS negotiation fails for any reason — including because an attacker intercepts the connection and tells the sending server that STARTTLS isn’t available — most sending servers will fall back to delivering email in plaintext rather than refusing to deliver at all. The email gets through. It’s just unencrypted.
This attack is called SMTP TLS stripping or STARTTLS stripping. It requires the attacker to be in a position to intercept SMTP traffic — a BGP hijack, a rogue DNS response, or control of network infrastructure between two mail servers. These aren’t everyday attacks, but they happen, particularly in espionage and targeted interception scenarios. The 2014 Yahoo disclosure referenced by the Snowden documents described exactly this mechanism at scale.
For most Australian businesses, the realistic threat isn’t state-level interception. It’s that you have no visibility into whether your inbound email is actually being delivered over encrypted connections, and no mechanism to enforce it.
How MTA-STS fixes this
MTA-STS (Mail Transfer Agent Strict Transport Security) is defined in RFC 8461. It gives domain owners a way to publish a policy telling sending mail servers:
- My domain supports TLS on inbound connections.
- You must verify my server’s TLS certificate.
- If TLS isn’t available or the certificate doesn’t validate, do not deliver — return an error and try again later.
A sending mail server that supports MTA-STS will fetch your policy before attempting delivery and honour those requirements. If it can’t establish a valid TLS connection to your mail server, it defers delivery and logs the failure rather than delivering in plaintext.
MTA-STS doesn’t protect you against all SMTP interception scenarios, but it closes the STARTTLS stripping attack entirely. An attacker who intercepts the connection and claims TLS is unavailable will cause the sending server to defer delivery and potentially trigger a TLSRPT report (covered below) rather than delivering in plaintext.
The two components: policy file and DNS record
MTA-STS requires two things to be in place.
1. The policy file
The policy is a text file served over HTTPS at a specific URL:
https://mta-sts.yourdomain.com/.well-known/mta-sts.txtThe file has a simple format:
version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800The key fields:
- version: Always
STSv1. - mode: Either
testing(report failures but don’t block),enforce(block non-TLS delivery), ornone(policy withdrawn). Start withtestinguntil you’ve confirmed your mail server’s TLS certificate is valid and your MX records match themx:entries. - mx: The hostnames of your MX records. Must match the
mx:values for the certificate validation to pass. For Microsoft 365, these will be yourtenant.mail.protection.outlook.comMX record. - max_age: How long sending servers should cache the policy, in seconds. 604800 is seven days. Use 86400 (one day) while testing so you can update quickly.
The policy file must be served over HTTPS with a valid certificate for mta-sts.yourdomain.com. The subdomain itself needs to exist as a DNS entry pointing to a web server. The file must be accessible without redirect loops and with Content-Type: text/plain.
2. The DNS TXT record
Publish a TXT record at _mta-sts.yourdomain.com that advertises your policy:
_mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20260528"The id field is a version identifier you choose. It can be any alphanumeric string up to 32 characters. Sending servers use it to detect when your policy has changed and re-fetch it. Change the id whenever you update the policy file — a timestamp in YYYYMMDD format works well.
Deploying MTA-STS for Microsoft 365
For a Microsoft 365 environment, your MX record looks something like:
your-domain-com.mail.protection.outlook.comThe policy file should reference this as the mx: value:
version: STSv1
mode: enforce
mx: your-domain-com.mail.protection.outlook.com
max_age: 604800You need an mta-sts subdomain in DNS pointing to a web server that serves this file. If you’re already running a web server for your domain, the simplest approach is:
- Add a DNS A or CNAME record for
mta-sts.yourdomain.compointing to your web server. - Add an HTTPS virtual host (or equivalent in your hosting control panel) for
mta-sts.yourdomain.com. - Create the
.well-known/mta-sts.txtfile under that virtual host’s document root. - Obtain a TLS certificate for
mta-sts.yourdomain.com(Let’s Encrypt covers this for free).
If you’re not running your own web server, you can host the policy file on any static hosting service that supports custom subdomains over HTTPS — Netlify, Cloudflare Pages, or even a simple S3 bucket with CloudFront in front of it.
Once the subdomain and policy file are live, publish the DNS TXT record at _mta-sts.yourdomain.com.
Start with testing mode
Before switching to mode: enforce, run mode: testing for one to two weeks. In testing mode, sending servers fetch your policy and attempt TLS delivery as normal — but if TLS fails, they deliver in plaintext and send you a TLSRPT report rather than bouncing the message.
This gives you visibility into any delivery paths that are failing TLS validation before you enforce the requirement. Problems to look for during testing:
- Sending servers that don’t support TLS at all (rare but possible with older on-premises mail infrastructure)
- TLS certificate mismatches (if your
mx:entries don’t exactly match your MX record hostnames) - Intermediate CAs not trusted by all sending servers
Once you’ve run through a week or two of testing reports and confirmed no unexpected failures, change mode: testing to mode: enforce in the policy file and update the id in your DNS TXT record.
TLSRPT: monitoring TLS delivery
RFC 8460 defines TLSRPT (TLS Reporting), which lets you receive reports when sending servers encounter TLS failures delivering to your domain. It’s the MTA-STS equivalent of DMARC aggregate reports.
Publish a TXT record at _smtp._tls.yourdomain.com:
_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"Replace tlsrpt@yourdomain.com with an address where you want to receive the JSON reports. Google, Microsoft, and most major sending platforms send these reports once they see the record.
The reports show which sending servers are successfully establishing TLS to your domain, which are failing, and what the failure reason is. During your testing phase, this data tells you exactly what to fix before you enforce.
Verifying your setup
You can verify MTA-STS configuration manually:
# Check the DNS record
dig TXT _mta-sts.yourdomain.com
# Fetch the policy file
curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
# Check the TLSRPT record
dig TXT _smtp._tls.yourdomain.comThe Email Authentication Checker at edos.com.au will also check for an MTA-STS record as part of its domain scan — enter your domain to see whether the policy file and DNS record are present and correctly formatted.
How it interacts with your other email controls
MTA-STS is complementary to SPF, DKIM, and DMARC — not a replacement. The four controls protect different things:
- SPF prevents unauthorised sending sources from passing receiver-side authentication checks.
- DKIM provides cryptographic proof that email content wasn’t modified in transit and was authorised by the signing domain.
- DMARC ties SPF and DKIM together and tells receiving servers what to do when they fail.
- MTA-STS prevents inbound email to your domain from being delivered over unencrypted connections.
A fully hardened inbound mail configuration has all four. SPF, DKIM, and DMARC protect you from impersonation and delivery failures. MTA-STS protects the confidentiality of mail in transit to your server.
What it doesn’t cover
MTA-STS only applies to SMTP connections between mail servers (MTA-to-MTA traffic). It doesn’t protect:
- The connection between your users and Microsoft 365 over IMAP/SMTP submission or HTTPS — those are protected by standard TLS certificate validation.
- Email content stored at rest — that’s a separate question about encryption at rest in your mail platform.
- Outbound mail from your domain to external recipients — MTA-STS is a receiver-side control; your recipients need to publish their own policies for you to enforce TLS on outbound delivery.
The bottom line
MTA-STS is a low-effort, no-maintenance control that closes a specific inbound mail confidentiality gap. The deployment process — subdomain, policy file, two DNS records — takes about 30 minutes once you have a web server to host the policy file. After that it runs itself.
If you’ve already hardened SPF, DKIM, and DMARC, MTA-STS is the logical next step. If you haven’t gotten to those yet, start there — but put MTA-STS on the list.
Run a free check of your current email authentication setup at edos.com.au/tools/email-auth-check.