Home / Blog / MTA-STS: Enforcing TLS for Inbound Email

MTA-STS: Enforcing TLS for Inbound Email

Email Security By Taylor Reed 7 min read

STARTTLS is the standard mechanism for encrypting SMTP traffic between mail servers. The problem: it's opportunistic. If a sending server offers STARTTLS and the receiving server supports it, the connection is encrypted. If negotiation fails for any reason, most MTAs silently fall back to plaintext.

This makes STARTTLS vulnerable to downgrade attacks. An attacker who controls the network path can intercept the connection, strip the STARTTLS capability announcement, and force plaintext transmission. The sending server has no way to know the downgrade was malicious. It assumes the receiving server doesn't support TLS and delivers the message unencrypted.

MTA-STS (RFC 8461) solves this. It's a policy mechanism that lets you tell sending mail servers "TLS is required for delivery to my domain. If you can't negotiate TLS successfully, don't deliver the message."

How MTA-STS Works

MTA-STS uses two components: a DNS record and an HTTPS-hosted policy file.

DNS record: A TXT record at _mta-sts.yourdomain.com that announces MTA-STS support and includes a policy version identifier.

Policy file: A plaintext file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt that specifies the policy mode, MX hostnames, and cache duration.

The flow:

  1. A sending mail server prepares to deliver a message to recipient@example.com.
  2. It queries DNS for _mta-sts.example.com.
  3. If the record exists, the sender fetches the policy file via HTTPS from https://mta-sts.example.com/.well-known/mta-sts.txt.
  4. The policy file tells the sender which MX hosts are valid and whether TLS is required.
  5. The sender attempts delivery. If TLS negotiation fails and the policy is set to enforce, the sender defers delivery and retries later. If TLS succeeds, delivery proceeds.

MTA-STS shifts the default from "use TLS if available" to "use TLS or don't deliver."

Publishing an MTA-STS Policy

Step 1: DNS Record

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

_mta-sts.example.com. IN TXT "v=STSv1; id=20260602001"
  • v=STSv1: Protocol version.
  • id: Policy identifier. Change this value whenever you update your policy. The ID is arbitrary (timestamp, version number, etc.). Changing it tells senders to re-fetch the policy file.

Step 2: Policy File

Host a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup-mail.example.com
max_age: 604800
  • version: Must be STSv1.
  • mode: Policy enforcement level. Options: testing, enforce, none.
    • testing: Policy is published but not enforced. Senders report failures via TLS-RPT but don't defer delivery.
    • enforce: TLS is required. If negotiation fails, senders defer delivery.
    • none: Policy is disabled. Used to signal policy removal without deleting the DNS record.
  • mx: List of valid MX hostnames for your domain. Wildcards are supported (*.example.com). Only MX hosts matching this list are considered valid.
  • max_age: Cache duration in seconds. Senders cache the policy for this long before re-fetching. Common values: 86400 (1 day) to 31557600 (1 year).

The policy file must be served over HTTPS. The certificate must be valid, trusted, and match the hostname mta-sts.yourdomain.com. If the HTTPS fetch fails, senders treat the policy as non-existent.

Step 3: HTTPS Hosting

You need to host the policy file at a publicly accessible HTTPS endpoint. Options:

  • Static web server: Configure your web server (Nginx, Apache, etc.) to serve the file at /.well-known/mta-sts.txt.
  • CDN: Host the file on a CDN like Cloudflare or AWS CloudFront.
  • Object storage: Use S3, Google Cloud Storage, or similar with static website hosting enabled.

The subdomain mta-sts.yourdomain.com must resolve to the server hosting the policy file. This is typically a CNAME or A/AAAA record pointing to your web server or CDN.

Policy Modes: Testing vs. Enforce

Start with mode: testing. This tells sending servers "I have an MTA-STS policy, but don't enforce it yet." Senders attempt TLS, log failures, and report them via TLS-RPT (if you've published a TLS-RPT record). You can monitor the reports to identify misconfigurations before enforcing the policy.

Common issues caught during testing:

  • Missing MX hostnames in the policy. If you have a backup MX that's not listed in the mx field, legitimate delivery will fail when the policy is enforced.
  • Certificate errors. Expired certificates, hostname mismatches, or untrusted certificate chains cause TLS negotiation to fail. TLS-RPT reports show these failures.
  • STARTTLS not supported. If one of your MX hosts doesn't advertise STARTTLS, enforcement will break delivery.

Run in testing mode for at least a week. Review TLS-RPT reports, fix any issues, and then switch to mode: enforce. Update the id field in the DNS record when you change the policy so senders re-fetch it.

How MTA-STS Prevents Downgrade Attacks

Without MTA-STS, an attacker can perform a trivial downgrade attack:

  1. Intercept the SMTP connection.
  2. Strip the STARTTLS capability from the server's EHLO response.
  3. The sender thinks the receiver doesn't support TLS and sends plaintext.

With MTA-STS enforced:

  1. The sending server fetches your policy before attempting delivery.
  2. The policy says "TLS is required."
  3. The sender attempts STARTTLS. If the capability is missing (because the attacker stripped it), the sender knows this violates the policy.
  4. The sender defers delivery instead of falling back to plaintext.

MTA-STS also protects against rogue MX attacks. If an attacker modifies your DNS to point to their own MX server, the sending server checks the MX hostname against your MTA-STS policy. If the hostname doesn't match, delivery is rejected.

MTA-STS and TLS-RPT

MTA-STS and TLS-RPT are complementary.

MTA-STS tells senders what to do when TLS negotiation fails. TLS-RPT tells you when those failures happen.

Without TLS-RPT, you can enforce MTA-STS, but you have no visibility into what's breaking. You don't know if legitimate senders are failing to deliver because of a misconfiguration on your side.

With TLS-RPT, you get JSON reports detailing:

  • Which sending IPs failed TLS negotiation.
  • Why negotiation failed (certificate error, protocol mismatch, etc.).
  • How many delivery attempts were affected.

Deploy both. MTA-STS without TLS-RPT is enforcement without feedback. TLS-RPT without MTA-STS is visibility without teeth.

Validating Your MTA-STS Policy

Before enforcing MTA-STS, validate your setup:

  1. Check the DNS record. Query _mta-sts.yourdomain.com and verify the TXT record is published.
  2. Fetch the policy file. Use curl or a browser to verify https://mta-sts.yourdomain.com/.well-known/mta-sts.txt is accessible and returns the correct policy.
  3. Validate with the MTA-STS checker. Use the MTA-STS validator on mrdns.com to verify your DNS record, policy file reachability, mode, max_age, and MX coverage.
  4. Test with a sending server. Send a test message from an MTA that supports MTA-STS (Postfix 3.4+, Exim 4.94+, etc.) and verify TLS is enforced.
  5. Review TLS-RPT reports. Monitor for failures during the testing phase.

Adoption and Support

MTA-STS support is growing but not universal. Major providers support it:

  • Google (Gmail): Enforces MTA-STS for sending, honors policies on receiving.
  • Microsoft (Outlook/Office 365): Supports MTA-STS.
  • Cloudflare Email Routing: Supports MTA-STS.
  • Postfix 3.4+: Full support.
  • Exim 4.94+: Full support.

Smaller providers and legacy MTAs may not support it. If a sender doesn't support MTA-STS, they ignore the policy and attempt delivery normally (opportunistic STARTTLS). Your policy only affects senders that implement MTA-STS.

This means MTA-STS improves security incrementally. You're not breaking mail from old systems, but you are enforcing TLS for modern senders.

When to Use MTA-STS

MTA-STS is most valuable for organizations that:

  • Handle sensitive email (financial services, healthcare, legal, etc.).
  • Want to prevent eavesdropping on inbound mail.
  • Are already using STARTTLS and want to eliminate downgrade risk.
  • Have the infrastructure to host an HTTPS policy file.

If you're running email infrastructure and you care about encryption, MTA-STS should be on your roadmap. It's not difficult to deploy, and the security benefit is significant.

For mail server TLS configuration, goodtls.com provides expert-recommended settings for Postfix, Exim, Dovecot, and other MTAs, including cipher suites and protocol versions. For validation, the MTA-STS checker and DNS lookup tools on mrdns.com let you verify your configuration. If you're already monitoring your infrastructure with Blacklist Monitoring, adding MTA-STS and TLS-RPT to your security posture is a natural next step.

Start with mode: testing, watch for failures, fix misconfigurations, and move to mode: enforce. TLS becomes mandatory, downgrade attacks become detectable, and your email is more secure.

Back to Blog