What Is MTA-STS?

The Problem: Email Encryption Is Optional by Default

When a mail server sends an email, it tries to establish an encrypted TLS connection with the receiving server. But this encryption is opportunistic — if the receiving server does not support TLS or the certificate is invalid, the sending server simply falls back to plaintext.

This makes email vulnerable to downgrade attacks: an attacker on the network path can strip the TLS advertisement from the receiving server, forcing the connection to happen unencrypted. The sending server has no way to know that encryption was supposed to be available.

MTA-STS solves this problem.

MTA-STS (Mail Transfer Agent Strict Transport Security), defined in RFC 8461, allows domain owners to declare that their inbound mail servers require TLS encryption. It prevents downgrade attacks by instructing sending servers to refuse unencrypted delivery, similar to how HSTS works for HTTPS.

MTA-STS (Mail Transfer Agent Strict Transport Security, defined in RFC 8461) is a standard that lets domain owners declare that their mail servers require TLS. Once published, sending servers know they must refuse to deliver email over an unencrypted connection — even if an attacker tries to interfere.

Think of it as HSTS (HTTP Strict Transport Security) but for email.

How It Works

MTA-STS has two components:

1. DNS TXT Record

You publish a TXT record at _mta-sts.yourdomain.com to signal that your domain supports MTA-STS:

_mta-sts.yourdomain.com  TXT  "v=STSv1; id=20260220"

The id field is a version identifier. Every time you update your policy, you must change the id so that sending servers know to re-fetch the policy file.

2. Policy File via HTTPS

You host a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt that specifies the rules:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

The key fields are:

mode — enforce (reject unencrypted delivery), testing (allow but report failures), or none (disable)
mx — which mail servers are authorized (wildcards supported)
max_age — how long sending servers should cache the policy (in seconds)

MTA-STS Policy Modes
Mode	Behavior	When to Use
testing	Deliver normally but report TLS failures	Initial rollout and validation
enforce	Reject delivery if TLS cannot be established	Production after successful testing
none	Disable MTA-STS policy	Decommissioning or troubleshooting

Setting It Up Step by Step

Step 1: Verify Your Mail Servers Support TLS

Before enabling MTA-STS, ensure all your MX hosts have valid TLS certificates. You can test this with:

openssl s_client -connect mail.yourdomain.com:25 -starttls smtp

The certificate must be valid, not expired, and match the MX hostname.

Step 2: Create the Policy File

Create a text file with your policy. Start with mode: testing to catch issues before enforcing:

version: STSv1
mode: testing
mx: mail.yourdomain.com
max_age: 86400

Step 3: Host the Policy File

The file must be accessible at exactly this URL:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

This requires:

A valid SSL certificate for mta-sts.yourdomain.com
An A/AAAA record pointing mta-sts.yourdomain.com to your web server
The file served with Content-Type: text/plain

Step 4: Publish the DNS Record

Add a TXT record to your domain’s DNS:

_mta-sts.yourdomain.com  TXT  "v=STSv1; id=20260220001"

Pick any unique value for id — a timestamp works well.

Step 5: Monitor and Switch to Enforce

Use TLS-RPT (see below) to receive reports about TLS failures. Once you are confident that all legitimate senders can connect via TLS, change your policy mode from testing to enforce.

MTA-STS and TLS-RPT: Better Together

MTA-STS tells senders to require TLS. TLS-RPT (RFC 8460) tells senders to report when TLS negotiation fails. Together, they give you visibility into encryption issues:

_smtp._tls.yourdomain.com  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

Without TLS-RPT, you are flying blind — you have no way to know if senders are experiencing TLS failures when delivering to your domain.

Common Pitfalls

Expired certificates — If your MX server’s TLS certificate expires while MTA-STS is in enforce mode, sending servers will refuse to deliver mail. Monitor certificate expiry closely.
Mismatched MX hosts — The mx entries in your policy must match your actual MX records. If you change mail providers, update the policy file and bump the DNS id.
Missing HTTPS — The policy file must be served over HTTPS with a valid certificate. Self-signed certificates will not work.
Caching — Sending servers cache your policy for max_age seconds. If you need to make urgent changes, keep max_age short during rollout.

Who Should Use MTA-STS?

MTA-STS is valuable for any domain that receives email and wants to guarantee encryption in transit. It is especially important for:

Organizations handling sensitive data (healthcare, finance, legal)
Domains already using DMARC with an enforcing policy
Businesses subject to compliance requirements (GDPR, HIPAA)

Conclusion

MTA-STS closes a critical gap in email security by ensuring that inbound email connections are always encrypted. Combined with TLS-RPT for monitoring, it gives domain owners control over how their email is delivered.

Setting it up requires a DNS record and a hosted policy file — no changes to your mail server configuration. Start in testing mode, monitor the reports, and switch to enforce when ready.

Key Takeaways

MTA-STS enforces TLS encryption for inbound email delivery
It consists of a DNS TXT record and an HTTPS-hosted policy file
Start with testing mode before switching to enforce
Pair MTA-STS with TLS-RPT for full visibility into delivery failures
DMARCPulse generates the policy file and DNS record for you

DMARCPulse takes the complexity out of MTA-STS and TLS-RPT setup. It generates copy-ready DNS records and policy file templates that you can paste directly into your DNS panel and web server configuration. If your DNS provider supports Domain Connect, DMARCPulse can create the required DNS records with one click — no manual editing needed. Beyond initial setup, DMARCPulse continuously monitors your MTA-STS configuration and alerts administrators by email when something is wrong — such as an expired certificate, a mismatched MX entry, or an unreachable policy file that could prevent incoming email delivery. It also notifies you when configuration changes are needed, for example when it is time to move from testing to enforce mode. Get started today.