What does it do?
When one mail server connects to another to deliver mail, it usually offers to upgrade the connection to TLS using a command called STARTTLS. That handshake is friendly but unsigned: an attacker who can see the connection can strip the STARTTLS offer, and the sending server cheerfully falls back to plain text. MTA-STS removes the choice. It publishes a policy file over HTTPS at a well-known location, saying "TLS is required, here are the MX hosts you should see, refuse to deliver if any of that does not match".
The policy file lives at https://mta-sts.yourdomain.com.au/.well-known/mta-sts.txt and is announced by a small DNS record at _mta-sts.yourdomain.com.au. Receivers cache the policy for the lifetime you specify, then refetch. Because the policy is fetched over HTTPS with certificate validation, an attacker on the path cannot forge it the way they can strip STARTTLS.
Why it matters
Picture a Perth physiotherapy clinic that handles patient referrals over email. Their mail provider supports TLS but the clinic has not published MTA-STS. A GP practice down the road sits behind a misbehaving firewall that strips STARTTLS from every outbound connection. Patient referral letters travel between the two practices in plain text, across a hotel wifi network, on a regional ISP, anywhere along the path. Nobody notices because both mail providers accept the fallback. With MTA-STS in enforce mode the connection would refuse to downgrade, the GP's misconfigured firewall would surface a clear bounce, and the leak would be visible the same day.
MTA-STS pairs with DNSSEC: an attacker who can spoof your DNS can also spoof the announce record and pretend MTA-STS does not exist. DNSSEC closes that gap by cryptographically signing the announce record itself, so resolvers can detect tampering before the policy fetch happens.
How to set it up
Three pieces in the right order: an HTTPS policy file, a DNS record pointing to it, and a TLS-RPT record so you can see what is happening. If you are on Google Workspace or Microsoft 365 the provider can do most of this for you in a single toggle; if you self-host, you will need a small static HTTPS host (a S3 bucket behind CloudFront works fine) for the policy file.
- Host the policy file. Most providers like Google Workspace, Microsoft 365, Fastmail and Zoho generate one for you; otherwise serve it yourself.
# https://mta-sts.yourdomain.com.au/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800- Publish the announce record. The id changes whenever you update the policy file.
_mta-sts.yourdomain.com.au. TXT "v=STSv1; id=2026051201"- Publish a TLS-RPT record so you receive daily reports of any TLS failures.
_smtp._tls.yourdomain.com.au. TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com.au"Run the policy in mode: testing for at least seven days. Read the reports. If nothing fails, flip the policy file to mode: enforce and bump the id.
Common mistakes
- Going straight to enforce without a testing phase. A wrong MX entry will silently bounce every inbound message.
- Forgetting to update the id when the policy file changes. Receivers will keep using the cached old version, and your fix never reaches them.
- Skipping TLS-RPT. Enforce mode without reporting is a black box: messages disappear and you have no idea who is failing.
- Listing MX hosts that do not match what your provider actually serves on the connection. Inspect the live MX with a lookup tool before publishing.
- Using a free wildcard TLS cert that does not include the
mta-stssubdomain. The policy file fetch fails its TLS handshake, the policy is treated as missing, and the whole mechanism quietly does nothing.
How AttackEdge checks it
The AttackEdge scan looks for both the announce record and the policy file, verifies the file parses, checks the MX list matches your live DNS, and confirms TLS-RPT is in place. Findings explain what is missing and how to fix it in your provider's console. Full methodology on /what-we-check.