Reference

MTA-STS explained: the TXT record, the policy file and the three modes

What MTA-STS protects, the _mta-sts TXT record and HTTPS policy file you publish, what testing, enforce and none do, and how TLS-RPT reports fit in.

By Updated Last verified

On this page
  1. What MTA-STS protects against
  2. The two parts: a TXT record and a policy file
  3. The three modes
  4. What a real setup looks like
  5. TLS-RPT: get reports about failures
  6. When mail actually fails
  7. Roll it out safely
  8. Sources

MTA-STS (opens in a new tab) (SMTP MTA Strict Transport Security) lets a domain that receives email publish a policy, through DNS and HTTPS (opens in a new tab), that tells sending servers what to do when TLS cannot be negotiated. In Microsoft's summary: TLS is always used between email servers, and the sender can validate the receiving server's certificate. You publish two things: a TXT record (opens in a new tab) at _mta-sts.example.com and a policy file (opens in a new tab) at mta-sts.example.com/.well-known/mta-sts.txt, served over HTTPS. Start in testing mode with TLS reporting, then switch to enforce.

What MTA-STS protects against

RFC 8461 (opens in a new tab) explains that an attacker who can delete parts of the SMTP session, such as the "250 STARTTLS" response, or redirect the session by overwriting the MX record can perform downgrade or interception attacks. MTA-STS lets the receiving domain say what senders should do with messages when TLS cannot be negotiated.

Microsoft's MTA-STS guide (opens in a new tab) puts it plainly: the standard ensures TLS is used between email servers and lets sending servers validate that the receiving server has a trusted certificate. If TLS isn't offered or the certificate isn't valid, the sender refuses to deliver; under RFC 8461 (opens in a new tab) that refusal applies in enforce mode.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

The two parts: a TXT record and a policy file

The TXT record (opens in a new tab) sits at _mta-sts under your domain. It has two required fields: v, where only STSv1 is supported, and id, a short string that tracks policy updates. The RFC's example:

_mta-sts.example.com.  IN TXT "v=STSv1; id=20160831085700Z;"

The policy file (opens in a new tab) for example.com is served over HTTPS at mta-sts.example.com/.well-known/mta-sts.txt. It sets the mode, one or more allowed mx patterns for your mail servers, and max_age, the policy lifetime in seconds (at most 31557600).

The three modes

The mode (opens in a new tab) decides what a sending server does when policy validation fails:

Mode What senders do on a validation failure
enforce Must not deliver to hosts that fail MX matching or certificate validation, or that do not support STARTTLS
testing May deliver as if nothing failed; senders that implement TLS reporting send a report, if your domain also publishes TLS reporting
none Treat the domain as if it had no active policy

What a real setup looks like

Here is gmail.com. Its MTA-STS record at _mta-sts.gmail.com, checked against live DNS:

v=STSv1; id=20190429T010101;

Gmail's policy file (opens in a new tab) reads:

version: STSv1
mode: enforce
mx: smtp.google.com
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

TLS-RPT: get reports about failures

RFC 8460 (opens in a new tab) has a domain publish a DNS record saying it wants reports, at _smtp._tls.example.com. Gmail's TLS-RPT record at _smtp._tls.gmail.com, checked against live DNS:

v=TLSRPTv1;rua=mailto:sts-reports@google.com

When mail actually fails

Microsoft's guide (opens in a new tab) spells out the risk. If a sender doesn't support MTA-STS, mail is still delivered without the extra protection. The only case where messages aren't delivered is when both sides use MTA-STS and validation fails.

Exchange Online checks MTA-STS on all outbound mail to protected domains, with nothing for administrators to switch on. Its MTA-STS errors include:

  • 5.4.8: MX hosts failed MTA-STS validation; the destination MX host wasn't the one expected by the domain's policy.
  • 5.7.5: the remote certificate failed MTA-STS validation.

Roll it out safely

Microsoft (opens in a new tab) notes you can publish in testing mode to check the policy is valid before switching to enforce. The policy file needs HTTPS with a certificate for mta-sts.example.com, and Exchange Online doesn't host it for you. If your MX records point directly to Exchange Online, your policy can use the same mx value as Microsoft's: *.mail.protection.outlook.com.

Every time you change the policy, change the id in the TXT record too. Otherwise senders keep using the cached policy until its max_age runs out.

For SPF, DKIM and DMARC, see SPF vs DKIM vs DMARC. The check is a free one-off check of a domain's SPF, DKIM and DMARC records; it only reads public DNS and sends no email.

Sources

Tools for this

Frequently asked questions

Does MTA-STS stop my mail being delivered?

Only when both sides use MTA-STS and validation fails in enforce mode. Senders that don't support MTA-STS still deliver without the extra protection.

Where does the MTA-STS policy file go?

At https://mta-sts.example.com/.well-known/mta-sts.txt for the domain example.com, served over HTTPS with a certificate for the mta-sts subdomain.

What is the difference between testing and enforce mode?

In testing mode senders may still deliver when validation fails and send TLS reports if both sides support TLS-RPT; in enforce mode they must not deliver to hosts that fail validation or lack STARTTLS.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account