MTA-STS (Mail Transfer Agent Strict Transport Security) is an email security standard (RFC 8461) that allows domain owners to declare that their mail servers require TLS encryption. It prevents downgrade attacks where an attacker strips the STARTTLS offer and forces email to be sent in plain text.

What is a STARTTLS downgrade attack?

A STARTTLS downgrade attack occurs when an attacker intercepts the connection between mail servers and removes the STARTTLS offer. This forces the sending server to deliver the email unencrypted, allowing the attacker to read the message contents. MTA-STS prevents this by telling senders to require TLS.

Do I need to host my own MTA-STS policy file?

Not necessarily. While MTA-STS requires a policy file served over HTTPS at mta-sts.yourdomain.com, services like MailShield can host this for you. You just add two DNS records (a CNAME and a TXT record) and the hosting is handled automatically.

What is the difference between MTA-STS testing and enforce mode?

In testing mode, sending servers attempt TLS but still deliver email if TLS negotiation fails — they just report the failure. In enforce mode, senders refuse to deliver if TLS can't be established. Start with testing mode and switch to enforce after confirming all senders can connect over TLS.

All posts

Technical

Why MTA-STS Matters More Than You Think

January 20, 20265 min

When you send an email, it travels between mail servers using SMTP. Here's the problem: SMTP was designed in the 1980s, before encryption was a concern. By default, email travels in plain text.

Most modern mail servers support STARTTLS, which upgrades the connection to TLS encryption. But STARTTLS is opportunistic. If an attacker intercepts the connection and strips the STARTTLS offer (a "downgrade attack"), the email is sent in plain text and neither the sender nor recipient knows.

MTA-STS (Mail Transfer Agent Strict Transport Security) fixes this. It tells sending servers: "Only deliver email to my domain over encrypted connections. If you can't establish TLS, don't deliver the email at all."

Why this matters for your business

If your organization handles sensitive information like customer data, financial records, contracts, or internal communications, you need to know that email is encrypted in transit. Without MTA-STS, there's no guarantee.

TLS downgrade attacks are not theoretical. They've been documented in the wild, particularly in regions with state-level surveillance capabilities. Even without active attacks, misconfigured mail servers sometimes fail to negotiate TLS and silently fall back to plain text.

MTA-STS is also increasingly expected by compliance frameworks and enterprise customers. If a prospect asks "how do you secure email in transit?" and you don't have MTA-STS, that's a gap in your security posture.

How MTA-STS works

MTA-STS requires two things:

A DNS record: a TXT record at _mta-sts.yourdomain.com that signals MTA-STS is enabled and includes a policy ID.
A policy file: a plain text file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt that specifies your MX servers and policy mode (testing or enforce).

When a sending server wants to deliver email to your domain, it checks for the MTA-STS DNS record, downloads your policy file over HTTPS, and then only delivers email to the MX servers listed in your policy, and only over a valid TLS connection.

The HTTPS requirement is key: it prevents the same kind of interception that STARTTLS is vulnerable to. An attacker can't forge your policy file without also compromising your HTTPS certificate.

Testing vs. enforce mode

Like DMARC, MTA-STS has a testing mode. In testing mode, sending servers will attempt TLS but still deliver email if TLS fails. They just report the failure. In enforce mode, they refuse to deliver if TLS can't be established.

Start with testing mode. Monitor the TLS-RPT reports (see below) for a few weeks to make sure all legitimate senders can connect over TLS. Then switch to enforce when you're confident.

TLS-RPT: The reporting companion

TLS-RPT (TLS Reporting) works alongside MTA-STS. It tells sending servers where to send reports about TLS connection issues: failed handshakes, certificate problems, or policy fetch failures.

Without TLS-RPT, you're deploying MTA-STS blind. You won't know if legitimate senders are having TLS issues until emails stop arriving. TLS-RPT gives you that visibility.

Always deploy TLS-RPT alongside MTA-STS. The reporting data is essential for catching issues before they affect delivery.

The hosting challenge

The biggest practical barrier to MTA-STS adoption is the hosting requirement. You need to serve a policy file over HTTPS at a specific subdomain (mta-sts.yourdomain.com), which means setting up a web server, managing a TLS certificate, and keeping it all running.

This is why MailShield includes hosted MTA-STS. We handle the HTTPS hosting, certificate management, and policy serving. You just add two DNS records. This makes MTA-STS accessible even if you don't run your own web infrastructure.

Getting started

Check whether your domain has MTA-STS today (most don't). Add your domain to MailShield and we'll show you the current status, help you set up hosted MTA-STS with minimal effort, and process your TLS-RPT reports automatically so you can see exactly what's happening with your inbound email encryption.