Glossary

MTA-STS (Mail Transfer Agent Strict Transport Security)

Forces TLS encryption for email delivery to your domain

MTA-STS (Mail Transfer Agent Strict Transport Security) is an email security standard that allows domain owners to declare that inbound email must be delivered over authenticated TLS connections, preventing downgrade attacks and man-in-the-middle interception during transit.

What is MTA-STS?

MTA-STS, or Mail Transfer Agent Strict Transport Security, is defined in RFC 8461. It is an email security mechanism that allows domain operators to publish a policy stating that mail must only be delivered to their servers over encrypted TLS connections with valid certificates. Without MTA-STS, email is delivered using "opportunistic TLS," which means encryption is attempted but can be stripped by an attacker in a man-in-the-middle position.

The MTA-STS policy is published in two places: a DNS TXT record at "_mta-sts.yourdomain.com" that signals the existence of the policy, and a plain-text policy file hosted at "https://mta-sts.yourdomain.com/.well-known/mta-sts.txt." The HTTPS hosting of the policy file means the policy itself is protected from tampering by TLS, unlike a plain DNS record.

MTA-STS is most effective when combined with TLS-RPT (TLS Reporting), which provides feedback about delivery failures and policy application.

How Does MTA-STS Work?

When a sending mail server (MTA) is about to deliver an email to your domain, it first checks for an MTA-STS policy by querying the DNS TXT record at "_mta-sts.yourdomain.com." If a policy record is found with a valid "id" tag, the sender fetches the policy file over HTTPS from "https://mta-sts.yourdomain.com/.well-known/mta-sts.txt."

The policy file specifies the enforcement mode ("enforce" or "testing"), the maximum age for which it should be cached, and a list of allowed mail server hostnames (MX hosts). When delivering mail, the sending MTA verifies that the destination mail server's certificate is valid and that the server hostname matches one listed in the policy. If the connection cannot be established securely, the sender does not deliver the message, preventing silent downgrade to unencrypted delivery.

The "testing" mode allows domain owners to roll out MTA-STS gradually, receiving TLS-RPT reports about failures without actually blocking delivery.

How to Check Your MTA-STS Setup

You can validate your MTA-STS configuration using the MTA-STS Checker at nslookup.net/tools/mta-sts-checker. The tool checks for the required DNS TXT record, fetches and parses the policy file from your HTTPS endpoint, verifies that the listed MX hostnames match your actual MX records, and flags issues such as an invalid mode value or an unreachable policy URL.

Before switching from "testing" to "enforce" mode, monitor your TLS-RPT reports to ensure no legitimate sending servers are failing TLS negotiation to your mail servers.

Related Tool

MTA-STS Checker

Try the Tool →

Frequently Asked Questions

What is the difference between MTA-STS and STARTTLS?

STARTTLS is an extension that allows a mail connection to upgrade from unencrypted to encrypted, but it is opportunistic — if an attacker downgrades the connection, mail is still delivered in plaintext. MTA-STS is a policy that tells sending servers they must deliver using verified TLS or not at all, removing the possibility of a silent downgrade attack.

Does MTA-STS protect outbound email?

MTA-STS protects inbound email to the domain that publishes the policy. To benefit from MTA-STS on outbound email, the sending mail transfer agent must support MTA-STS policy lookups. Major providers such as Google Workspace and Microsoft 365 support MTA-STS lookups when sending, meaning they will enforce policies published by recipient domains.

What happens if a sending server does not support MTA-STS?

MTA-STS is only enforced by sending servers that actively look up and honour the policy. If a sending MTA does not support MTA-STS, it will simply fall back to opportunistic TLS or even plaintext delivery as it would have done before. The standard does not block non-compliant senders at a protocol level, but adoption among major providers is now widespread.

How often should the MTA-STS policy be refreshed?

The "max_age" value in the policy file controls how long sending MTAs should cache the policy. A typical value is 604800 seconds (7 days). Sending servers fetch a fresh copy when the cached policy expires. If you need to make urgent changes — such as updating your MX hostnames — update the "id" value in the DNS TXT record to signal that a new policy should be fetched immediately.