MTA-STS (Mail Transfer Agent Strict Transport Security) tells sending servers that your domain only accepts email over encrypted TLS connections. Without it, the STARTTLS upgrade is optional — and attackers can force email to transmit in plaintext.
The protocol works through two components:
- A DNS record announcing MTA-STS support
- An HTTPS-hosted policy file specifying encryption requirements
When properly configured, sending servers must establish a verified TLS connection before delivering mail. If they can’t, the email doesn’t get delivered — protecting against interception and tampering.
MTA-STS is typically deployed alongside TLS-RPT (TLS Reporting), which sends you daily reports on connection failures. Together, they provide enforcement plus visibility into what’s actually happening between mail servers.
Why does MTA-STS exist?
SMTP was designed in an era when encryption wasn’t a concern. The STARTTLS extension added optional TLS later, but “optional” became the vulnerability.
The STARTTLS problem
If a sending server can’t establish TLS, it falls back to plaintext delivery. Attackers exploit this through downgrade attacks:
- Intercept the connection between the sending and receiving servers
- Read or modify email content undetected
- Block the STARTTLS negotiation
- Force plaintext transmission
STARTTLS also skips certificate validation. A sending server accepts any certificate — expired, self-signed, or belonging to an imposter. Man-in-the-middle attacks become trivial when nobody checks credentials.
| Vulnerability | What happens | MTA-STS solution |
| Opportunistic encryption | Falls back to plaintext if TLS fails | TLS required or delivery fails |
| Downgrade attacks | Attacker blocks TLS negotiation | No fallback permitted |
| No certificate validation | Any certificate accepted | Must be valid, trusted, hostname-matched |
| DNS spoofing | Attacker redirects MX to malicious server | Allowed MX hosts pinned in policy |
MTA-STS closes these gaps by making TLS mandatory rather than hopeful.
How does MTA-STS work?
The mechanism relies on a two-part discovery and enforcement process that sending servers follow before delivering mail.
Discovery process
When a sending server wants to deliver email to your domain:
- DNS lookup — checks for a TXT record at _mta-sts.yourdomain.com
- Policy fetch — if the record exists, retrieves the policy file over HTTPS
- Validation — verifies the receiving server’s certificate matches the policy
- Delivery decision — delivers if validation passes; behavior on failure depends on policy mode
The HTTPS requirement for the policy file is intentional. DNS can be spoofed (attackers redirect queries to malicious servers). HTTPS with certificate validation prevents fake policies from being served — the policy host itself must prove its identity.
Major email providers support MTA-STS, including Gmail, Microsoft 365, and Yahoo. When you implement MTA-STS, mail from these senders arrives encrypted and verified.
What are the MTA-STS components?
Three pieces work together: a DNS record announcing support, a policy file defining rules, and (optionally) a reporting record for failure notifications.
DNS TXT record
The first component signals MTA-STS support. Publish a TXT record at _mta-sts.yourdomain.com:
v=STSv1; id=20241227001
| Field | Purpose |
| v=STSv1 | Protocol version (always STSv1) |
| id= | Unique identifier — change when policy updates |
The id field matters more than it looks. Sending servers cache your policy (based on max_age). When you modify the policy file, increment the ID to force immediate re-fetch — otherwise, servers continue using stale cached versions.
Policy file
The second component defines enforcement rules. Host a plaintext file at:
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
Example policy:
version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: mail2.yourdomain.com
max_age: 604800
| Field | Example | Purpose |
| version | STSv1 | Protocol version |
| mode | testing | Enforcement level |
| mx | mail.yourdomain.com | Allowed MX host (one per line) |
| max_age | 604800 | Cache duration in seconds (604800 = 1 week) |
The web server hosting this file must present a valid TLS certificate for the mta-sts subdomain. Self-signed certificates won’t work — sending servers validate before trusting the policy.
TLS-RPT record
The third component (optional but strongly recommended) enables failure reporting. Publish a TXT record at _smtp._tls.yourdomain.com:
v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com
Reports arrive daily in JSON format, detailing connection successes and failures. Without TLS-RPT, you’re enforcing blindly — problems remain invisible until someone complains about missing email.
What are the policy modes?
MTA-STS offers three enforcement levels, designed for phased rollout from monitoring to full enforcement.
| Mode | Behavior | Use case |
| none | Disables MTA-STS | Decommissioning the policy |
| testing | Reports failures but delivers anyway | Initial rollout, troubleshooting |
| enforce | Rejects email if TLS validation fails | Production enforcement |
Testing mode
Start here. In testing mode, sending servers attempt TLS validation but deliver the email regardless of the outcome. Failures get reported via TLS-RPT.
The testing phase reveals misconfigurations you didn’t know existed:
- Expired certificates on backup MX servers
- MX hosts are missing from the policy file
- Third-party services sending without TLS support
Fix issues during testing. Verify clean reports before enabling enforcement.
Enforce mode
After reviewing 4-6 weeks of clean TLS-RPT data, upgrade to enforce mode. Now, sending servers must establish validated TLS. If they can’t, email isn’t delivered — it bounces back to the sender.
When switching modes, update the policy file and increment the DNS record ID. Otherwise, sending servers continue using their cached testing-mode policy until max_age expires.
How do you implement MTA-STS?
Implementation follows a phased approach — setup, monitoring, then enforcement. Rushing to enforce mode before resolving certificate issues causes legitimate emails to bounce.
Prerequisites
Before deploying, verify your mail servers meet requirements:
- Support TLS 1.2 or higher
- Use valid certificates from recognized certificate authorities
- Certificates match MX hostnames exactly
Run an email deliverability test to check the current authentication and encryption status before starting.
Setup steps
| Phase | Actions | Timeline |
| DNS setup | Publish _mta-sts and _smtp._tls TXT records | Day 1 |
| Policy hosting | Create mta-sts.txt with mode: testing | Day 1 |
| Monitoring | Review TLS-RPT reports for failures | 4-6 weeks |
| Resolution | Fix certificate and MX issues revealed in reports | As needed |
| Enforcement | Update policy to mode: enforce, increment ID | After clean reports |
The testing period matters. Four to six weeks provides enough data to catch intermittent issues — backup servers that only activate during outages, seasonal sending patterns, forgotten third-party integrations.
What is TLS-RPT and why does it matter?
TLS-RPT (SMTP TLS Reporting) provides visibility into what happens when servers try to deliver mail to your domain. Without it, MTA-STS operates as a black box.
Report contents
Sending servers that support TLS-RPT deliver daily JSON reports detailing:
- Failed connections with specific reasons
- Successful TLS connections (count and details)
- Policy information they retrieved from your domain
Common failure reasons reveal specific problems:
| Failure type | Meaning |
| starttls-not-supported | Sending server doesn’t support TLS |
| certificate-expired | Your mail server’s certificate expired |
| certificate-not-trusted | Certificate not from recognized CA |
| certificate-host-mismatch | Certificate doesn’t match MX hostname |
| validation-failure | MX host not listed in your policy |
These reports function similarly to DMARC reports — aggregated feedback about authentication and security outcomes. The difference is that DMARC covers sender authentication while TLS-RPT covers transport encryption.
Using reports
During testing mode, TLS-RPT catches problems before they cause mail loss:
- Typo in your policy file’s MX list
- Certificate expiring next week on a server you forgot about
- Partner organization sending from infrastructure without TLS
Fix issues while testing mode still delivers the mail. Switch to enforce only after reports show consistent success.
How does MTA-STS relate to SPF, DKIM, and DMARC?
SPF, DKIM, and DMARC handle authentication — proving who sent the email and whether it was modified in transit.
MTA-STS handles transport — encrypting the email while it moves between servers.
| Protocol | Layer | Function |
| SPF | Authentication | Authorizes sending IP addresses |
| DKIM | Authentication | Cryptographically signs message content |
| DMARC | Authentication | Aligns SPF/DKIM, sets policy for failures |
| MTA-STS | Transport | Enforces TLS encryption between servers |
A domain with DMARC but no MTA-STS proves sender identity, but transmits content where anyone between servers can read it. A domain with MTA-STS but no DMARC encrypts transit but can’t verify senders.
Authentication prevents spoofing and impersonation. Transport security prevents interception and eavesdropping. Implement both for complete protection — they address different attack vectors entirely.
For domains already running SPF, DKIM, and DMARC, adding MTA-STS completes the security stack. The protocols don’t conflict — they complement each other across different layers.
TLS is a must-have!
Combined with TLS-RPT, you get enforcement plus visibility into connection outcomes.
For help implementing transport security alongside SPF, DKIM, and DMARC, an email deliverability consultant can configure the full authentication and encryption stack.
Frequently asked questions
Here are some commonly asked questions about MTA-STS:
No. MTA-STS protects inbound email to your domain — it tells sending servers how to deliver mail to you securely. Outbound security depends on whether recipient domains have implemented MTA-STS. You can’t force encryption on domains that haven’t configured it.
Sending servers that don’t support MTA-STS ignore your policy entirely. They continue delivering via opportunistic STARTTLS (or plaintext if STARTTLS fails). MTA-STS only affects compliant senders — fortunately, major providers like Gmail, Microsoft, and Yahoo all support it.
Both enforce TLS for email transport, but they work differently. DANE (DNS-Based Authentication of Named Entities) requires DNSSEC for security. MTA-STS uses HTTPS and certificate authorities instead. Most organizations find MTA-STS easier to implement since DNSSEC adoption remains limited.
One to four weeks (604800 to 2419200 seconds) works for most domains. Longer values reduce DNS lookups but delay policy updates. Shorter values increase lookup frequency but allow faster changes. A week is a reasonable default for most situations.
