MTA-STS: enforcing TLS for email delivered to your domain

What problem MTA-STS solves

Mail servers talk to each other over SMTP, which was designed to accept plain-text connections. Most servers try to upgrade to TLS, but if that fails they usually send the message anyway, unencrypted. That leaves room for a person-in-the-middle to block the upgrade, or to redirect mail to a server they control, and read messages in transit.

The NCSC describes the objectives of MTA-STS as making it harder for an attacker to get your mail sent somewhere else, and making sure TLS encryption is used rather than downgraded to clear text. It does this in two ways: your mail server names are published on a separate HTTPS web page, so an attacker cannot simply subvert your MX record, and an enforce policy tells sending servers not to deliver if a secure connection cannot be made.

Three limits are worth knowing:

• It protects inbound mail only. Your MTA-STS policy protects mail sent to you; other domains' policies protect mail you send to them.
• It needs the sender to support it. Servers that do not support MTA-STS carry on delivering as before, so it adds protection without breaking them.
• It is not end-to-end encryption. Messages are encrypted between servers, not inside the mailbox. For sensitive content, see send secure email.

The three parts: TXT record, policy file and TLS-RPT

MTA-STS itself is a DNS record plus a policy file. The third piece, TLS reporting (TLS-RPT, RFC 8460), is a separate standard but the one that tells you whether MTA-STS is working. Shown for example.co.uk:

The policy file is a short text file, one key and value per line, with the version line first:

The id in the TXT record can be any value of 1 to 32 letters and numbers, and it must change every time you change the policy, or senders keep using the cached version until max_age runs out. Google and Microsoft both suggest a date and time stamp so you can see when the policy last changed. Google says the policy file can be up to 64 KB, and each domain needs its own policy file hosted separately.

Testing, enforce and none modes

The mode line controls what sending servers do when a secure connection fails:

How long to test depends on whose advice you follow. Google recommends two weeks in testing mode and a max_age of one to two weeks (604800 to 1209600 seconds) while testing. The NCSC is more cautious: it suggests a max_age of 24 hours (86400 seconds) in testing, at least a month of monitoring before you enforce, and a max_age of at least two weeks (1209600 seconds) once you do. The maximum is 31557600 seconds, about a year. A longer max_age in enforce mode protects you against attacks on DNS or on the policy hosting, which is the point of the standard.

How to set up MTA-STS

The steps are the same whichever mail platform you use:

1. List every domain and subdomain that receives mail (every one with an MX record). Each needs its own configuration.
2. Check each receiving mail server supports TLS 1.2 or later with a valid certificate that matches its MX name. Cloud services such as Exchange Online and Gmail handle this for you; your own servers need a reliable certificate renewal process.
3. Set up TLS reporting first. Create a mailbox or reporting tool for TLS-RPT and publish the _smtp._tls record. Google recommends adding TLS reporting before turning on MTA-STS.
4. Host the policy file in testing mode at https://mta-sts.yourdomain/.well-known/mta-sts.txt, with a valid certificate for the mta-sts subdomain.
5. Publish the _mta-sts TXT record with a new id.
6. Read the reports for failed connections, missing MX entries and certificate problems, and fix each one.
7. Switch the policy to enforce, raise max_age and change the id in the TXT record.

Raw TLS-RPT reports arrive as JSON, so a reporting tool makes them far easier to read. If a mail server's certificate ever expires while you are in enforce mode, MTA-STS-aware senders will stop delivering to it, so certificate monitoring is part of the job for anything you host yourself.

MTA-STS in Exchange Online

Microsoft supports MTA-STS in Exchange Online in both directions:

• Outbound: Exchange Online checks the MTA-STS policy of every domain it sends to, with nothing for you to configure. If a recipient domain's enforce policy fails, the sender gets a non-delivery report with error 5.4.8 (the MX host is not in the policy) or 5.7.5 (the certificate failed validation). Mail sent through an outbound connector to a smart host is validated against the smart host's domain.
• Inbound: if your MX record points directly at Exchange Online, Microsoft's own policy shows the values to use, with mx: *.mail.protection.outlook.com. Microsoft says the shared certificate and the rule that only one organisation can receive mail for a domain mean the wildcard does not weaken security, but warns that this wildcard is specific to Exchange Online: if other providers also receive mail for your domain, list their MX hosts too.
• Hosting: Exchange Online cannot host the policy file for you. Microsoft documents hosting it with Azure Static Web Apps, its recommended method because a TLS certificate is provided automatically, or with Azure Functions.

If your MX record points at a secure email gateway in front of Microsoft 365, the policy must list the gateway's MX hosts, and Microsoft advises checking the gateway provider's requirements. Exchange Online also supports inbound SMTP DANE with DNSSEC, a separate standard that protects mail in transit using signed DNS records; our sister site explains DNSSEC if you are weighing it up.

MTA-STS with Google Workspace and Gmail

When Gmail sends to a domain with an enforce policy, Google says its messages comply with that policy. For mail sent to your Google Workspace domain, you set MTA-STS up yourself:

• MX hosts: list the MX values in your DNS. Google's current single MX record is smtp.google.com; organisations that started before 2023 may still use the older aspmx values, which Google still supports.
• DNS records: Google says to add the _mta-sts and _smtp._tls records at your domain host, not in the Admin console, and to turn on TLS reporting before MTA-STS.
• Policy hosting: you host the mta-sts.txt file on your own HTTPS web server, or use a hosted service.
• Checking: the Admin console's Security Health page shows whether MTA-STS and TLS reporting are set up correctly.
• Reports: TLS reports can be emailed to a mailbox you create; delivery to a web server needs an API that Google Workspace does not provide.

Separately, Gmail's secure transport (TLS) compliance setting lets you require TLS for mail to or from specific domains, such as a key supplier. Our Gmail security settings guide covers it, and our Google Workspace email security hub covers the wider picture.

Managed MTA-STS

The DNS records are simple; hosting the policy file on a web server with a valid certificate, keeping it in step with your MX records and reading TLS reports is the part that takes effort. Two of the products we supply include it:

• Valimail Pro includes MTA-STS alongside automated SPF, DKIM, DMARC, BIMI and continuous protection reporting, licensed per domain.
• IRONSCALES DMARC includes hosted MTA-STS and TLS-RPT with its hosted DMARC, SPF and DKIM; which features sit in DMARC and which in DMARC Pro is confirmed at quote.

Both make sense if you are also working towards DMARC enforcement, which the NCSC puts in the same implementation plan. Our email authentication hub compares them with the other DMARC tools we supply.

How we help

Forever Systems can check every domain that receives mail, set up TLS reporting, arrange hosting for the policy file (for example through a hosted MTA-STS option), run testing mode while we review the reports with you, and move each domain to enforce when the reports are clean. We can do this alongside SPF, DKIM and DMARC work so the whole NCSC plan is covered. Pricing for any hosted option is confirmed at quote. Contact us to protect mail in transit to your domains.