MTA-STS: Encrypt Mail Sent to Your Domain

Set up MTA-STS to require encrypted delivery to your domain: publish the DNS record and policy, add TLS reporting, test first and then enforce safely.

Most companies have spent time on SPF, DKIM and DMARC, which deal with who is allowed to send as your domain. MTA-STS deals with a different risk: whether mail sent to your domain is protected in transit. Without it, a sending server that cannot set up an encrypted connection to your mail servers may fall back to sending in plain text, and an attacker in the middle can try to force that fallback. MTA-STS lets you publish a policy that tells sending servers to require encryption and a valid certificate when they deliver to you. This guide explains how MTA-STS works, how to roll it out safely with TLS reporting and how to maintain it.

The problem MTA-STS solves

Email servers usually encrypt connections with STARTTLS, but in classic SMTP that encryption is opportunistic. If it fails, many servers deliver anyway without encryption. Google's Workspace help page on the topic notes that SMTP alone does not provide security and is vulnerable to man-in-the-middle attacks, where communication between two servers is intercepted and possibly changed without detection (Google Workspace Admin Help: About MTA-STS and TLS reporting).

RFC 8461, the standard that defines MTA-STS, describes it as a mechanism that lets mail service providers declare their ability to receive TLS-secured SMTP connections and specify whether sending servers should refuse to deliver to mail hosts that do not offer TLS with a trusted certificate (RFC 8461).

How MTA-STS works

An MTA-STS setup has two parts:

A DNS TXT record named _mta-sts at your domain. RFC 8461 gives an example of the form v=STSv1; id=20160831085700Z;. The id field lets sending servers tell whether a cached policy is still current without fetching it again.
A policy file served over HTTPS at a fixed path, .well-known/mta-sts.txt, on a host named mta-sts followed by your domain.

The policy file contains a few key/value lines. According to the RFC, these include a version (currently STSv1), a mode (enforce, testing or none), one or more mx lines listing the mail hosts allowed for your domain and a max_age, which is how long, in seconds, senders may cache the policy. The RFC sets the maximum max_age at 31557600 seconds.

The three modes

The mode decides what a sending server does when it cannot validate your policy:

none: tells senders you have no active policy, which is useful when withdrawing one.
testing: senders still deliver even if checks fail, but those that support TLS reporting send reports about the failures.
enforce: the RFC says senders must not deliver to hosts that fail MX matching or certificate validation or that do not support STARTTLS.

Starting in testing mode is the safe path. It lets you find problems, such as a backup mail host with an expired certificate, before any mail is refused.

Add TLS reporting first

TLS reporting, defined in RFC 8460, gives you visibility. You publish a TXT record named _smtp._tls at your domain containing an rua value, which is where reports should be sent (RFC 8460). Sending servers that support it then send aggregate reports about successful and failed TLS connections to your domain.

Set up TLS reporting before or alongside MTA-STS in testing mode. Without reports, testing mode tells you little.

Prepare your mail hosts

Before publishing any policy, check every server that receives mail for your domain:

List every MX record, including backups.
Confirm each one supports STARTTLS.
Confirm each one presents a certificate that is valid, trusted and matches the hostname senders connect to.
Note certificate renewal dates and who owns them.

If you use a hosted mail service, its documentation will usually list the MX hostnames to include in your policy.

Worked example: a phased MTA-STS rollout

The table below is a hypothetical rollout plan for a company that uses a hosted mail service plus one on-premises relay as a backup MX. It shows the order of work, not fixed timings.

PhaseChangeWhat to check before moving onInventoryList MX hosts and certificate ownersEvery MX supports STARTTLS with a valid certificateReportingPublish _smtp._tls record with a reporting addressReports arriving and readablePolicy hostServe policy file over HTTPS at the mta-sts hostFile reachable with a valid certificateTesting modePublish _mta-sts record and policy in testing modeReports show no failures for legitimate hostsFix issuesRenew the backup relay certificateFailures disappear from reportsEnforceChange mode to enforce and update the idReports remain cleanMaintainAdd certificate renewals to the operations calendarOwnership recorded

Each time the policy changes, update the id in the TXT record so that senders know to fetch the new version.

Common mistakes

Most failures come from small gaps in ownership rather than from the standard itself. Watch for these:

Forgetting a backup MX host in the policy, so senders refuse to deliver to it under enforce mode.
Letting the certificate on the policy host or an MX host expire.
Changing the policy file without updating the id, so senders keep using the cached old version.
Moving to enforce mode without reading the testing reports.
Changing mail providers and leaving the old MX names in the policy.

Where MTA-STS fits with other email security

MTA-STS complements authentication rather than replacing it. Google's page recommends also setting up DKIM, SPF and DMARC. Those protect against spoofing of your domain; MTA-STS protects mail on its way to your servers. Our DMARC setup guide covers the authentication side, and our guide to BIMI explains a further step that builds on DMARC enforcement.

Keep it working

MTA-STS needs light but steady upkeep, and the effort is small compared with the cost of mail being refused because a certificate lapsed unnoticed. Monitor TLS reports for new failures, keep certificates renewed and review the policy whenever you change mail providers or add a receiving host. Assign an owner so that a change to mail routing always includes a check of the policy.

Frequently Asked Questions

What does MTA-STS protect against?

It helps prevent mail sent to your domain from being delivered without encryption or to an impostor server, by telling sending servers to require TLS with a valid certificate.

Do I need TLS reporting for MTA-STS?

It is optional but strongly advisable. TLS reports show where delivery to your domain fails TLS checks, which is essential before you switch to enforce mode.

What is the difference between testing and enforce mode?

In testing mode, senders still deliver when checks fail but can report the failures. In enforce mode, compliant senders refuse to deliver to hosts that fail the checks.

Does MTA-STS replace SPF, DKIM or DMARC?

No. Those deal with who can send as your domain. MTA-STS deals with encryption of mail delivered to your domain. Use them together.

Secure mail in transit

We help teams inventory mail hosts, roll out MTA-STS with TLS reporting and keep policies current as systems change. See our cold outreach and deliverability service, or talk to us about MTA-STS.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.