Phisher Safe by SimpleDMARC

MTA-STS Setup: Encrypt Email in Transit in 2026

Gaurav Maniar -

MTA-STS Setup: Enforce TLS Encryption on Your Inbound Email

MTA-STS (Mail Transfer Agent Strict Transport Security) tells sending mail servers that email to your domain must be delivered over an encrypted TLS connection. If a sending server can't establish a valid TLS connection, it should refuse to deliver the message rather than fall back to unencrypted transmission.

DMARC protects your outbound email reputation — it tells receivers how to handle email that claims to be from you. MTA-STS protects your inbound email in transit — it tells senders how to connect to your mail server. They solve different problems. Both are worth implementing.

What Problem MTA-STS Solves

SMTP, the protocol email runs on, was designed before encryption. By default, mail servers negotiate encryption opportunistically — they try TLS, but if it fails for any reason, they fall back to unencrypted delivery. An attacker in a position to interfere with the connection (a TLS stripping attack, or a man-in-the-middle attack) can force this fallback.

RFC 8461 defines MTA-STS as the solution: a published policy that tells sending servers "do not deliver email to us unless you can establish a valid TLS connection with a certificate matching our mail server hostname." There's no fallback allowed. The sender either delivers encrypted or tries again later.

This matters for email containing sensitive content: financial communications, legal correspondence, healthcare-adjacent data, authentication tokens. It also matters for compliance frameworks that require encryption in transit.

How MTA-STS Works

When a mail server is about to deliver email to your domain, it checks two things:

  1. Does _mta-sts.yourdomain.com have a TXT record indicating MTA-STS is in use?
  2. Can it fetch an MTA-STS policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt?

If both are present and the mail server supports MTA-STS, it enforces the policy in that file. The policy file specifies your mail server hostnames (MX records) and the mode: enforce (strict, fail if TLS can't be established), testing (log failures but deliver anyway), or none (policy disabled).

The mail server then caches this policy for the validity period you specify. Subsequent deliveries use the cached policy without fetching it again, which is also what makes the protection stick against certain attacks.

Setting Up MTA-STS: Step by Step

Setting up MTA-STS has three parts: a DNS TXT record, a policy file served over HTTPS, and optionally TLS-RPT for reporting.

Step 1: Create the MTA-STS TXT record

Create a TXT record at _mta-sts.yourdomain.com:

_mta-sts.yourdomain.com.  300  IN  TXT  "v=STSv1; id=20260601T000000;"

The id= value is a version identifier — change it whenever you update your policy. Using a timestamp (date + time format) is conventional. The TTL of 300 seconds (5 minutes) allows quick policy updates during initial setup.

Step 2: Create and host the policy file

The policy file must be served at exactly: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

The subdomain mta-sts.yourdomain.com must have a valid TLS certificate (Let's Encrypt works). The file content:

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

Start with mode: testing. In testing mode, failures are reported but mail is still delivered. Once you've confirmed your setup is correct, switch to mode: enforce.

The mx: lines list your mail server hostnames. These must match your actual MX records. Check your MX records with:

dig MX yourdomain.com

The max_age value is in seconds. 604800 is one week. Once you're in enforce mode, you can extend this to 31557600 (one year) for caching efficiency.

Step 3: Hosting the policy file

The policy file needs to be served from a web server at mta-sts.yourdomain.com. Options:

Self-hosted: Configure a virtual host on your web server at mta-sts.yourdomain.com with a valid TLS certificate. Serve the static policy file from the .well-known/ path.

SimpleDMARC hosted: SimpleDMARC's MTA-STS hosting manages the subdomain, certificate, and file serving for you. You create the DNS TXT record; SimpleDMARC handles the HTTPS file serving. This removes the web server requirement entirely.

Static hosting services: GitHub Pages, Cloudflare Pages, Netlify, and similar services can host the policy file if configured with the correct subdomain and HTTPS.

Step 4: Add TLS-RPT reporting

TLS-RPT (TLS Reporting, RFC 8460) is the companion protocol to MTA-STS — it sends you reports about TLS connection failures when delivering email to your domain, similar to how DMARC rua= addresses receive aggregate authentication reports.

Add a TXT record at _smtp._tls.yourdomain.com:

_smtp._tls.yourdomain.com.  300  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com;"

Use SimpleDMARC's TLS-RPT reporting address to have these reports parsed automatically alongside your DMARC reports. Check simpledmarc.com/tools for the correct address.

Step 5: Switch to enforce mode

After running in testing mode for a week with no unexpected failures in your TLS-RPT reports, update the policy file to mode: enforce and update the id= value in the DNS TXT record:

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

Update the DNS TXT record id= at the same time:

"v=STSv1; id=20260615T000000;"

The updated id= tells mail servers that have cached your policy to fetch the new version.

MTA-STS and DMARC: How They Relate

MTA-STS and DMARC address different points in the email security stack. Start with DMARC if you haven't already — it's higher priority because it directly stops domain spoofing. See the DMARC setup guide for the foundational setup.

MTA-STS doesn't affect DMARC authentication. An email can pass DMARC (authenticated sender) and fail MTA-STS (sent over unencrypted connection) — these are independent checks. In practice, most modern mail servers support TLS; MTA-STS enforces what's already happening opportunistically.

FAQ

Does MTA-STS affect email deliverability?
In enforce mode, a sending server that can't establish a valid TLS connection to your mail server will defer delivery rather than fall back to unencrypted. This could affect delivery from very old or misconfigured sending servers, but modern mail infrastructure universally supports TLS. Testing mode first reveals any edge cases.

What's the difference between MTA-STS and STARTTLS?
STARTTLS is the mechanism by which mail servers upgrade an existing connection to TLS — it's been around for decades. The problem is that STARTTLS is opportunistic: if the upgrade fails, servers fall back to unencrypted delivery. MTA-STS is the policy layer that makes TLS mandatory and prevents that fallback.

Do I need a dedicated web server for MTA-STS?
You need to serve an HTTPS file at a specific path on mta-sts.yourdomain.com. This can be a dedicated server, a static hosting service, or a hosted solution like SimpleDMARC's MTA-STS hosting. The requirement is a valid TLS certificate and correct file path — not a full web server stack.

How do I verify MTA-STS is working correctly?
Check your TLS-RPT reports for connection failures. You can also test with third-party validators that attempt to fetch your policy file and validate the DNS record. SimpleDMARC's tools at simpledmarc.com/tools include an MTA-STS checker.

Is MTA-STS the same as DANE?
No. DANE (DNS-based Authentication of Named Entities) is an alternative approach that uses DNSSEC to validate TLS certificates rather than relying on certificate authorities. DANE requires DNSSEC-signed domains and DNSSEC-validating resolvers. MTA-STS works with standard DNS and the existing certificate authority infrastructure, making it simpler to deploy for most organizations.