SMTP supports TLS for transport encryption, but it’s opportunistic by default. A sending server will use TLS if the receiving server offers it, but if TLS isn’t available, or if something strips the STARTTLS advertisement, delivery proceeds in plaintext. This is the SMTP downgrade attack, and it’s been exploited in practice.
MTA-STS (Mail Transfer Agent Strict Transport Security) solves this. It lets you publish a policy that instructs sending servers to require TLS when delivering to your domain and to validate your mail server’s certificate. A server that can’t establish a valid TLS connection will refuse to deliver rather than fall back to plaintext.
The setup involves three components: a DNS TXT record at _mta-sts., a policy file served over HTTPS at a well-known URL, and optionally a TLS-RPT record for receiving failure reports.
What MTA-STS protects against
The threat model is an attacker positioned between the sending server and your mail server, capable of intercepting or modifying the SMTP conversation. Without MTA-STS, that attacker can strip the 250-STARTTLS capability advertisement from the server’s greeting, causing the sender to deliver in plaintext. The sending server never negotiated TLS, so it never had a certificate to validate. The conversation looks normal from its perspective.
MTA-STS prevents this by giving the sending server a way to verify the policy out-of-band, over HTTPS, before the SMTP connection happens. If the policy says TLS is required and the server can’t establish valid TLS to your MX host, delivery fails. This is the correct outcome: a delivery failure is preferable to plaintext delivery of sensitive mail.
Component 1: the DNS TXT record
Publish a TXT record at _mta-sts.yourdomain.com:
v=STSv1; id=20260618001The id value is a version identifier for your policy. Any alphanumeric string up to 32 characters works. The convention is to use a date-based string (YYYYMMDDNNN) so it’s obvious when the policy was last updated. Change this value whenever you update your policy file. Sending servers cache your policy and use the id to detect when they need to fetch a fresh copy.
Component 2: the policy file
The policy file must be served over HTTPS at exactly this URL:
https://mta-sts.yourdomain.com/.well-known/mta-sts.txtThis requires a subdomain mta-sts.yourdomain.com with a valid TLS certificate. You’ll need to create this subdomain in DNS and either host it on a web server you control or use a static hosting service that supports custom domains.
The file contents follow a simple key-value format:
version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800version: always STSv1.
mode: testing or enforce. In testing mode, sending servers apply the policy but still deliver mail even if TLS fails. They should report failures via TLS-RPT. In enforce mode, mail is not delivered if TLS requirements cannot be met.
mx: the MX hostnames that are permitted for your domain. These must match your actual MX records exactly. If your MX records point to mail.yourdomain.com and mail2.yourdomain.com, both need to appear here. Wildcards are supported: *.yourdomain.com covers any subdomain. Sending servers verify that the MX host they connect to is listed in the policy, and that the TLS certificate presented is valid for that hostname.
max_age: how long sending servers should cache the policy, in seconds. 604800 is one week. 86400 (one day) is reasonable while you’re making changes. Increase to 31557600 (one year) once the policy is stable.
The HTTPS response must have a Content-Type of text/plain. The file is served as plain text, not JSON or any other format. Check this after deploying.
Component 3: TLS-RPT reporting
TLS-RPT (TLS Reporting) is the companion standard to MTA-STS. It works similarly to DMARC reporting: sending servers send aggregate reports about TLS failures to an address you specify. The reports tell you when and why TLS negotiation failed for mail destined to your domain.
Publish a TXT record at _smtp._tls.yourdomain.com:
v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.comYou can also use an HTTPS endpoint:
v=TLSRPTv1; rua=https://reporting.example.com/v1/tlsrptReports arrive as JSON, compressed with gzip. The format is defined in RFC 8460. Each report identifies the sending organisation, the policy type applied (MTA-STS or DANE), and any failure details including the failure type, the MX hostname, and the certificate that was presented.
In a new deployment, TLS-RPT reports are useful for catching configuration issues before you move to enforce mode. If sending servers are reporting TLS failures against your legitimate MX hosts, something is wrong: an expired certificate, a hostname mismatch, or an MX record not listed in your policy.
Moving from testing to enforce mode
Run in testing mode for at minimum two weeks before switching to enforce. During that time, watch TLS-RPT reports for failures. Common issues to resolve before enforcing:
MX hostname not in policy. If a sending server is connecting to an MX host that isn’t listed in your mx: entries, it will report failures in testing mode and refuse delivery in enforce mode. Audit your MX records and make sure every hostname is listed.
Certificate hostname mismatch. Your mail server’s TLS certificate must be valid for the MX hostname. A certificate issued to yourdomain.com that doesn’t include mail.yourdomain.com as a SAN will fail validation. Check each MX host’s certificate against the hostnames in your policy.
Certificate expiry. An expired certificate causes TLS validation failures regardless of MTA-STS. If your mail server’s certificate expires, sending servers in enforce mode will stop delivering. Set up certificate renewal monitoring before enforcing.
To move to enforce mode, update the policy file and increment the id in the DNS TXT record:
version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 86400Change the DNS TXT record id value to signal the update:
v=STSv1; id=20260618002Sending servers that have cached the old policy will see the new id, fetch the updated policy file, and switch to enforcing.
A note on DANE
DANE (DNS-based Authentication of Named Entities) is an alternative approach to the same problem. It publishes TLS certificate fingerprints in DNSSEC-signed DNS records, allowing senders to validate certificates without a separate policy file. DANE requires DNSSEC on both the sending and receiving side, which limits its adoption. MTA-STS achieves most of the same security benefit without that dependency, which is why it has broader deployment.
The two standards are not mutually exclusive. Domains can implement both.
Verification
After publishing both DNS records and deploying the policy file, verify before moving to enforce mode:
- Confirm the TXT record at
_mta-sts.yourdomain.comresolves correctly - Fetch
https://mta-sts.yourdomain.com/.well-known/mta-sts.txtdirectly and confirm the content and Content-Type - Check that the MX hostnames in the policy match your actual MX records
- Confirm the TLS certificate on each MX host is valid and covers the correct hostname
The Email Authentication Checker validates MTA-STS policy records alongside SPF, DKIM and DMARC records.
For context on TLS-RPT report formats and interpretation, the approach is similar to DMARC aggregate reports. Understanding DMARC aggregate reports covers the general pattern.