MTA-STS for email
MTA-STS is a standard that lets domain owners tell supporting mail senders to require valid TLS when delivering mail to their domain. It protects inbound mail transport against downgrade attacks and complements the authentication and trust signals already provided by SPF, DKIM, and DMARC.
What is MTA-STS?
MTA-STS stands for Mail Transfer Agent Strict Transport Security. It is a DNS and HTTPS-based mechanism that allows a domain to publish a policy instructing supporting sending mail servers to require authenticated, encrypted TLS when delivering mail to that domain.
Before MTA-STS, SMTP TLS was opportunistic — a sending server would attempt TLS but fall back to plain text if TLS was unavailable or if an attacker stripped the STARTTLS advertisement. MTA-STS closes this gap for senders that support the standard.
MTA-STS is defined in RFC 8461 and is supported by major sending providers including Gmail and Microsoft. It applies to inbound mail delivery to your domain, not to the reputation of outbound mail you send.
Why MTA-STS matters for email security
Without MTA-STS, an attacker with access to the network path between two mail servers can strip the STARTTLS offer, forcing the connection to fall back to plain text. This is a STARTTLS downgrade attack. Mail content, including authentication tokens and sensitive information, can be intercepted.
MTA-STS prevents this by publishing a policy that supporting senders fetch and cache. When delivering mail to your domain, a supporting sender that has cached your MTA-STS policy will refuse to fall back to plain text or accept an invalid TLS certificate — even if the network tries to interfere.
MTA-STS does not improve spam filtering, inbox placement, or sender reputation. It is an inbound transport security mechanism for your domain, not a direct deliverability ranking factor.
How MTA-STS works
When a supporting sender is about to deliver mail to your domain, it looks up whether you have an MTA-STS policy by checking for a DNS TXT record at _mta-sts.yourdomain.com. If the record exists, the sender fetches your policy file from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over HTTPS.
The sender caches the policy for the duration specified in the max_age field. On subsequent deliveries within the cache window, it uses the cached policy without re-fetching.
When delivering mail, the sender enforces the policy: it requires STARTTLS, validates the TLS certificate against your published MX hostnames, and refuses to deliver over plain text or with an untrusted or mismatched certificate. If delivery fails, it retries until the message expires rather than falling back to plain text.
The MTA-STS DNS TXT record
The DNS record that signals MTA-STS support is a TXT record at the subdomain _mta-sts.yourdomain.com. A valid record looks like:
v=STSv1; id=20240101T000000
The v field must be STSv1. The id field is an arbitrary string that acts as a version identifier for the policy. When you update your policy file, you must also update the id field — this signals to senders that have cached the old policy that they should re-fetch it.
The id string is typically a timestamp but can be any alphanumeric string. It does not encode any semantic meaning; its only purpose is to change when the policy changes.
The MTA-STS policy file
The policy file is a plain-text file served at a specific HTTPS URL: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
A minimal enforce-mode policy looks like:
version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 86400
The version field must be STSv1. The mode field specifies the enforcement level. The mx field lists the hostnames of your MX servers — you can have multiple mx lines, one per hostname. The max_age field specifies how long senders should cache the policy in seconds.
The policy file must be served over HTTPS with a valid certificate. Senders will not fetch it over HTTP or with an invalid certificate. The Content-Type should be text/plain.
MX patterns and TLS certificate requirements
Each mx entry in your MTA-STS policy file must match the hostnames of your actual MX records. MTA-STS supports wildcard patterns using a leading dot — for example, .mail.protection.outlook.com matches any subdomain of that host.
When a supporting sender connects to deliver mail, it validates the TLS certificate presented by your MX server against the MX patterns in your policy. The certificate must be signed by a trusted certificate authority, must not be expired, and its Common Name or Subject Alternative Names must match one of the MX patterns.
If your MX server presents an expired, self-signed, or hostname-mismatched certificate, delivery will fail under enforce mode. Senders will not fall back to plain text — they will retry until the message expires. This is the intended behaviour, but it means TLS certificate maintenance on your MX servers is critical once you publish an enforce mode policy.
Testing mode vs enforce mode
MTA-STS supports three policy modes:
testing mode: senders apply the policy but do not refuse delivery on failure. Instead, failures are reported via TLS-RPT if you have a TLS-RPT policy. This is the recommended starting point — it lets you gather data on TLS failures without risking mail loss.
enforce mode: senders refuse to deliver mail if TLS cannot be established with a valid, matching certificate. Delivery failures are retried rather than falling back to plain text.
none mode: the policy is explicitly disabled. Senders treat delivery as if no MTA-STS policy exists, but they should stop caching a previously fetched policy.
The recommended deployment sequence is to start with testing mode, monitor TLS-RPT reports for failures, resolve any certificate or hostname issues, and then switch to enforce mode once you are confident all MX servers have valid TLS.
Common MTA-STS mistakes
Policy file not served over HTTPS. The file must be accessible at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with a valid certificate. An HTTP redirect or self-signed certificate will cause senders to ignore the policy.
MX pattern does not match real MX records. If your policy lists mail.example.com but your MX record points to mx1.example.com, supporting senders will fail certificate validation and not deliver.
Forgot to update id after changing the policy. Senders cache the policy using the id as a freshness indicator. If you change the policy file but not the id, cached senders will continue using the old policy.
Switching to enforce mode before verifying TLS. Moving to enforce mode with an expired or mismatched certificate on your MX server causes supporting senders to fail delivery. Always verify TLS in testing mode first.
Missing TLS-RPT policy. Without TLS-RPT, you have no visibility into TLS failures that supporting senders encounter when delivering to your domain.
How to fix MTA-STS problems
Ensure the policy file is accessible over HTTPS. The subdomain mta-sts.yourdomain.com must have a valid TLS certificate, and the file must be served at the exact path /.well-known/mta-sts.txt.
Verify that your mx patterns match your actual MX records. Use an MTA-STS checker to compare the policy file mx entries against your live MX DNS records.
Check TLS certificates on your MX servers. Each MX server must present a valid, trusted certificate whose Common Name or Subject Alternative Names match the hostnames listed in your policy.
Update the id field whenever you change the policy. Even a small change to the policy file requires an id update to signal cache invalidation.
Start with testing mode and add TLS-RPT. Use testing mode first and configure a _smtp._tls TXT record so you receive reports on any TLS failures before switching to enforce.
Once all checks pass, switch to enforce mode and monitor TLS-RPT reports periodically to catch certificate expiry or infrastructure changes before they cause delivery failures.
How MXFend can help
MTA-STS Checker — fetches your _mta-sts DNS TXT record and your policy file, validates the policy syntax, checks mode and mx patterns, and compares them against your live MX records. The most direct tool for verifying your MTA-STS configuration.
TLS-RPT Checker — checks whether your domain has a valid _smtp._tls TXT record for receiving TLS delivery failure reports. TLS-RPT works alongside MTA-STS to give you visibility into TLS errors at your inbound servers.
SMTP TLS Checker — connects to your MX servers and checks STARTTLS support, TLS certificate validity, hostname match, and cipher details. Use this to verify that your MX servers will pass MTA-STS validation before switching to enforce mode.
Email Security Score — combines MTA-STS, TLS-RPT, SMTP TLS, blacklist, SPF, DKIM, and DMARC into a single weighted audit.
Frequently asked questions
What is MTA-STS?
MTA-STS stands for Mail Transfer Agent Strict Transport Security. It is a standard that allows a domain to publish a policy requiring supporting senders to use validated TLS when delivering mail to that domain. It protects against STARTTLS downgrade attacks on inbound mail delivery.
Does MTA-STS improve email deliverability?
MTA-STS is an inbound transport security mechanism — it protects mail delivered to your domain against TLS downgrade attacks. It does not directly improve inbox placement or sender reputation for outbound mail you send. It is a security best practice, not a spam filter signal.
What DNS record does MTA-STS require?
MTA-STS requires a TXT record at _mta-sts.yourdomain.com. The record must contain v=STSv1 and an id field — for example: v=STSv1; id=20240101T000000. The id must be updated whenever the policy file changes, so that senders know to re-fetch the policy.
Where is the MTA-STS policy file hosted?
The policy file must be served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over HTTPS with a valid certificate. It is a plain-text file containing the version, mode, mx hostnames, and max_age fields. Senders will not fetch it over HTTP or with an invalid certificate.
What is the difference between MTA-STS and TLS-RPT?
MTA-STS is a policy mechanism: it tells supporting senders to require TLS when delivering to your domain. TLS-RPT is a reporting mechanism: it tells senders where to send reports about TLS failures they encounter when delivering to your domain. They are complementary — MTA-STS enforces the policy, TLS-RPT gives you visibility into failures.