MTA-STS: Enforcing Encrypted Delivery
MTA-STS is a standard that lets you require TLS encryption for inbound mail to your domain. Without it, a man-in-the-middle attack could strip TLS and intercept mail in transit. Here's how it works and how to publish a policy.
The problem MTA-STS solves
Most modern mail servers support STARTTLS — they'll use TLS encryption if the receiving server offers it. But "opportunistic TLS" means it's optional. A network attacker positioned between two mail servers can perform a downgrade attack, stripping the TLS offer so the connection falls back to plaintext. The mail is delivered, but unencrypted and potentially readable or altered in transit.
MTA-STS (Mail Transfer Agent Strict Transport Security) changes this from opt-in to required. Once you publish an MTA-STS policy, sending mail servers that support the standard are required to use TLS with a valid certificate to deliver to your domain, or fail the delivery rather than fall back to plaintext.
How MTA-STS works
MTA-STS uses two components: a DNS record that signals a policy exists, and a policy file hosted on your domain over HTTPS.
When a sending server looks up your MX records to deliver mail, it also checks for an MTA-STS DNS record. If found, it fetches your policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The policy file specifies which mail servers are covered and what mode is in effect.
The MTA-STS DNS record
A TXT record at _mta-sts.yourdomain.com:
_mta-sts.yourdomain.com TXT "v=STSv1; id=20260603T000000Z"The id= value is a version identifier. Change it any time you update your policy file. Sending servers use it to know when to re-fetch the policy. A timestamp in the format above works well.
The policy file
The policy file must be served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. It requires a valid TLS certificate on the mta-sts subdomain. The content looks like this:
version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 86400Breaking it down:
| Field | Meaning |
|---|---|
version: STSv1 | Required. Identifies this as an MTA-STS policy file. |
mode: enforce | Require TLS. Reject delivery if TLS can't be established. |
mode: testing | Report failures but don't reject. Use this while validating. |
mode: none | Policy is disabled. Used to signal you've stopped enforcing. |
mx: | Which MX hostnames are covered. List each one explicitly, or use a wildcard. |
max_age: | How long (in seconds) sending servers should cache this policy. 86400 = 1 day. |
Deploying in testing mode first
Like DMARC, MTA-STS supports a testing mode before full enforcement. Start with mode: testing. Sending servers will check your policy and report failures to your TLS-RPT reporting address, but they won't block delivery. Once you've confirmed there are no TLS issues with your inbound mail setup, switch to mode: enforce and update the id= in the DNS record.
TLS-RPT: receiving reports
TLS-RPT (TLS Reporting) is the companion standard to MTA-STS. It lets receiving domains publish a reporting address where sending servers send reports about TLS failures during delivery. The DNS record:
_smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"This is analogous to the rua= in your DMARC record. Reports arrive as JSON files describing delivery attempts, TLS negotiation results, and any failures. dmarcdemon parses TLS-RPT reports alongside DMARC reports so you can monitor both in one place.
Prerequisites
- Your MX servers must support TLS with valid, unexpired certificates from a trusted CA.
- You need a valid TLS certificate for
mta-sts.yourdomain.com. - The policy file must be served with Content-Type: text/plain.
- Your MX hostnames in the policy file must match your actual MX records exactly.