MTA-STS is a standard that lets a domain say, in a published policy, that other mail servers must use verified TLS when delivering to it. Its companion, TLS-RPT, sends reports about connections that failed. Together they close a gap in how email encryption works by default. This guide explains the gap, how the two fit together, what to publish and how to move from testing to enforcement without losing mail.
The problem: opportunistic encryption
When two mail servers talk, the sending server asks whether the receiver offers STARTTLS. If it does, they upgrade to an encrypted connection. This is called opportunistic TLS, and it protects mail from passive eavesdropping. The weakness is that the offer travels in plain text before encryption starts. An attacker who can change traffic on the path can remove the offer, and the sender then falls back to sending in the clear. An attacker can also present a certificate that does not match, and many senders accept it anyway, because rejecting it would break delivery to servers with sloppy setups.
| Threat | Plain opportunistic TLS | With MTA-STS enforce |
|---|---|---|
| Passive eavesdropping | Protected if TLS is negotiated | Protected |
| STARTTLS stripped by an attacker | Falls back to plain text | Sender refuses to deliver |
| Certificate for the wrong name | Often accepted | Sender refuses to deliver |
| Visibility of failures | None | Reports through TLS-RPT |
How MTA-STS works
Three pieces make up MTA-STS.
- A DNS TXT record at
_mta-sts.example.comthat announces that you have a policy and carries an identifier. - A policy file served over HTTPS at
https://mta-sts.example.com/.well-known/mta-sts.txt, which lists your MX hosts and the mode. - A sending server that supports MTA-STS, looks up the record, fetches the policy, caches it and then requires a valid TLS connection to a listed MX host.
The policy is fetched over HTTPS, which relies on the public certificate system. That is what makes it harder to tamper with than plain DNS alone. The first fetch is trusted on first use, and later fetches are checked against the cached identifier.
Before you start
- Know your MX hosts. Run a lookup for the MX records of your domain.
- Each MX host must support TLS with a certificate that is valid, not expired, issued by a trusted authority and whose name matches the MX host name in your records.
- You need a web host or service that can serve a file over HTTPS at the mta-sts subdomain with a valid certificate.
- You need a mailbox or reporting service to receive TLS-RPT reports. These come as compressed JSON files, so many people use a tool that parses them.
This is for your inbound mail. MTA-STS protects mail sent to your domain. If a platform hosts your mailboxes, check with that provider first, since some manage MTA-STS for you and some need you to publish the records yourself. Mail you send through MigoSMTP is not changed by your policy.
Step 1: Write the policy file
version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 86400| Field | Meaning |
|---|---|
| version | Always STSv1 |
| mode | testing, enforce or none |
| mx | One line per allowed MX host; wildcards such as *.example.com are allowed for subdomain matching |
| max_age | How long senders may cache the policy, in seconds |
List every host that may receive your mail. If you leave one out, senders in enforce mode will refuse to deliver to it. The example uses placeholder names, so replace them with your own.
Step 2: Host the file
Create a host named mta-sts.example.com with a valid HTTPS certificate and serve the file at the path /.well-known/mta-sts.txt. The file must be returned with a plain-text type and no redirects. Check it from outside your network with a browser or a command-line fetch. A certificate problem here breaks the policy for every sender.
Step 3: Publish the DNS record
_mta-sts.example.com. IN TXT "v=STSv1; id=20261015T100000"The id is any string of letters and digits up to 32 characters. A timestamp is a convenient choice. Change it every time you change the policy file, otherwise senders keep the cached version.
Step 4: Add TLS-RPT
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"Senders that support the standard send summary reports, usually once a day, to the address in rua. The reports show how many connections succeeded and failed, and categorise failures such as an expired certificate, a name mismatch or no STARTTLS offer. This is the data that tells you when it is safe to enforce.
Step 5: Start in testing mode
In testing mode, senders do not refuse to deliver, but they report failures. Run for several weeks, long enough to include the senders that write to you only occasionally. Read the reports and fix every failure you can: renew certificates, correct names, remove MX hosts that do not support TLS and close gaps in your host list.
| Report finding | Likely cause | Fix |
|---|---|---|
| Certificate expired | Missed renewal on an MX host | Renew and automate renewal |
| Certificate host mismatch | Certificate name differs from the MX name | Issue a certificate for the correct name |
| STARTTLS not supported | An old or misconfigured MX host | Enable TLS or remove the host |
| Policy fetch failure | mta-sts host unreachable or certificate invalid | Fix the web host |
| Validation failure for an unlisted MX | MX missing from the policy | Add it to the file and update the id |
Step 6: Move to enforce
When reports are clean for a sustained period, change the mode to enforce, raise max_age to a longer value and update the id in the DNS record. From then on, supporting senders refuse to deliver if your servers cannot meet the policy. Plan the first days carefully: keep reports flowing, and have someone watching certificate expiry.
Keep it healthy
- Monitor certificate expiry on every MX host and on the mta-sts web host.
- Update the id whenever the policy changes.
- If you plan to change mail hosts, add the new MX to the policy and wait for the cache period before removing the old one.
- To switch off, set the mode to none, update the id, wait for the old max_age to pass and only then remove the records.
MTA-STS and DANE
DANE for SMTP, described in RFC 7672, solves the same problem differently. It publishes certificate information in DNS and relies on DNSSEC to protect it. It does not need a web host, but it needs DNSSEC support at your DNS provider and mail host. MTA-STS needs no DNSSEC but needs HTTPS hosting. Some domains publish both. Choose by what your infrastructure supports, and check which senders you want to protect.
A worked example: a small company with two MX hosts
A company with the domain example.org runs two mail hosts. It publishes a TLS-RPT record and an MTA-STS policy in testing mode, with both hosts listed and a one-day max_age. The first reports show a few failures from one sender: the certificate on the second host had expired. The team renews it and sets up automatic renewal. Two weeks later the reports are clean. They change the mode to enforce, raise max_age to several weeks and update the id.
Months later, they add a third mail host. They add it to the policy, change the id and wait before sending traffic to it, so that senders with cached policies learn the new list. Nothing breaks, because they followed the order of changes. The example is illustrative and uses placeholder names.
How this fits with the rest of your email security
MTA-STS protects transport. It does not prove who sent a message or stop spoofing, which is the job of SPF, DKIM and DMARC. Set those up first with our guide to authenticating your sending domain and, when ready, move DMARC to reject. For outgoing mail, applications should use encrypted submission as described in SMTP settings, ports and TLS.
Not sure whether your mail host manages MTA-STS? Ask us what to check on your side before you publish records.
Further reading and sources
Frequently asked questions
What problem does MTA-STS solve?
Mail servers often upgrade to encryption using STARTTLS, but an attacker on the network can remove that offer, and the sender then falls back to plain text. MTA-STS lets a domain publish a policy that says sending servers must use verified TLS to its MX hosts, so such downgrades fail instead.
Does MTA-STS affect the mail I send?
No. It protects mail coming in to your domain from servers that support MTA-STS. It does not change how your own outgoing mail is sent. Outgoing mail to domains that publish policies is checked by your sending platform.
What is TLS-RPT?
SMTP TLS Reporting, defined in RFC 8460. Senders that support it send you daily summary reports showing successes and failures when connecting to your servers over TLS. It is the main way to see problems before you enforce a policy.
Do I need DNSSEC?
Not for MTA-STS, which relies on HTTPS and the public certificate system. DANE for SMTP, defined in RFC 7672, is a different approach that does require DNSSEC. You can choose one or both depending on your DNS provider and mail host.
What modes does the policy support?
There are three: none, testing and enforce. In testing, senders report failures but still deliver. In enforce, they refuse to deliver if the TLS requirements are not met. None tells senders there is effectively no policy.
What is the id field in the DNS record?
It is a string that changes whenever the policy changes. Senders cache policies, and the id tells them to fetch a new copy. If you edit the policy file without changing the id, senders may keep using the old one.
What happens if my certificate expires after enforcing?
Sending servers that honour the policy will refuse to deliver mail to you, and it will be delayed or bounce. That is why certificate monitoring and renewal are essential before you move to enforce.
How long should max_age be?
It sets how long senders cache the policy, in seconds. Use a short period while testing, and a longer one such as several weeks when stable, as the standard suggests. A longer period protects against downgrade attacks for longer but slows changes.
Do mailbox providers support MTA-STS?
Several large providers support it on the sending side. Support changes, so check provider documentation. Even where support is partial, publishing a policy and reports costs little and provides useful visibility.