CyberFurl can load analytics only after you opt in. Core product features work without analytics consent.
What is MTA-STS? Mail Transfer Agent Strict Transport Security Guide (2025)
Email Security
MTA-STS Explained: Force TLS Encryption on All Inbound Email to Stop STARTTLS Attacks
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) forces sending mail servers to use TLS when delivering to your domain, stopping STARTTLS stripping and SMTP downgrade attacks. Learn how MTA-STS works, the difference between testing and enforce mode, how it compares to DANE, and how to deploy it safely without breaking inbound mail.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) forces sending mail servers to use TLS when deliv…
What is MTA-STS?
MTA-STS (Mail Transfer Agent Strict Transport Security) is a DNS and HTTPS-based security standard that forces sending mail servers to use authenticated TLS encryption when delivering email to your domain. It eliminates the STARTTLS downgrade vulnerability that has existed in SMTP since opportunistic encryption was introduced.
Without MTA-STS, SMTP email delivery uses opportunistic TLS — the sending server advertises TLS support during the SMTP handshake, but an attacker between the two servers can strip the STARTTLS command from the unencrypted greeting, forcing the sender to deliver mail in plaintext. MTA-STS blocks this attack by delivering the policy requirement over a separate, trusted HTTPS channel that the attacker cannot manipulate.
# id changes → remote fetches new policy
Published as an RFC 8461 standard, MTA-STS is supported by all major sending MTAs including Gmail, Microsoft 365, Yahoo, and most enterprise mail systems.
Why STARTTLS is not enough: the downgrade attack problem
When SMTP was designed, email was transmitted in plaintext. STARTTLS was added later as an opportunistic upgrade — the sending server proposes TLS, the receiving server accepts, and the connection upgrades. This works well in the absence of active attackers.
The vulnerability: the STARTTLS command itself is transmitted in the initial plaintext greeting, before any encryption is established. An attacker on the network path (malicious ISP, compromised router, BGP hijacker) can intercept the connection and silently remove 250-STARTTLS from the server's capability list. The sending MTA sees no TLS offered, assumes the receiving server does not support it, and delivers the email in plaintext to the attacker — who then forwards it along to the real mail server.
This is not a theoretical attack. STARTTLS stripping has been documented in state-actor-level network interception. MTA-STS eliminates the attack by providing TLS requirements through an out-of-band channel (HTTPS) that cannot be stripped from an SMTP session.
The three MTA-STS policy modes
| Mode | Sender Behavior | When to Use |
|------|----------------|-------------|
| mode: none | Policy is announced but not enforced — senders ignore it | Effectively disabled; not recommended |
| mode: testing | Senders report TLS failures but still deliver mail | Rollout phase — 30-60 days minimum |
| mode: enforce | Senders refuse to deliver if TLS validation fails | Production — after confirming zero TLS failures in reports |
The transition from testing to enforce is where most implementations go wrong. Teams rush to enforcement without monitoring TLS-RPT reports, resulting in inbound mail delivery failures from senders who correctly refuse to deliver to misconfigured MX hosts.
Required DNS TXT record + HTTPS policy file
MTA-STS requires two components working together:
DNS TXT record at _mta-sts.yourdomain.com:
DNS Record / Config
_mta-sts.example.com. IN TXT "v=STSv1; id=20260101T000000;"
This signals to senders that a policy exists and provides a version identifier for cache invalidation.
HTTPS policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:
The policy file lists the exact MX hostnames that senders should connect to and the TLS enforcement mode. The max_age value (in seconds) tells senders how long to cache the policy — longer cache periods provide protection even when the HTTPS server is temporarily unreachable, but also slow down policy updates.
How to deploy MTA-STS safely
step 1─────────>
step 2─────────>
step 3─────────>
step 4─────────>
step 5─────────>
step 6
1. Step 1:Before publishing any MTA-STS policy, confirm that every MX host listed in your DNS has a valid, publicly trusted TLS certificate that matches the MX hostname. Self-signed certificates, expired certificates, or hostname mismatches will cause delivery failures once you enforce MTA-STS. Use an SSL checker on each MX hostname to confirm certificate validity, expiry date, and hostname match.
2. Step 2:Publish a TLS-RPT DNS TXT record at _smtp._tls.yourdomain.com pointing to a reporting endpoint: v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com — This ensures that from day one of MTA-STS testing, you receive daily reports from major senders about any TLS failures. Without TLS-RPT, you are deploying blind.
3. Step 3:Create the policy file with mode: testing (never start with enforce), list all your MX hosts exactly as they appear in DNS, and set max_age to 86400 (1 day) during testing. Host it at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt — this subdomain must have a valid TLS certificate. Example file: version: STSv1 / mode: testing / mx: mail.example.com / max_age: 86400
4. Step 4:Add a TXT record at _mta-sts.yourdomain.com: v=STSv1; id=20260101T000000; — The id value is a version identifier (any unique string works). Senders use it to detect policy updates — when the id changes, they re-fetch the policy file. Publish this record and wait 48 hours for propagation.
5. Step 5:Review daily TLS-RPT reports for failure patterns. Common failures to watch for: certificate expired on an MX host, MX hostname not matching certificate SAN, policy file unreachable (web server down or TLS error on mta-sts subdomain), and MX host changes that are not reflected in the policy file. Address every failure category before advancing to enforce mode.
6. Step 6:Once 30-60 days of TLS-RPT reports show zero failures, update the policy file to mode: enforce and increase max_age to 604800 (1 week) or 2592000 (30 days). Increment the id value in the DNS TXT record so senders know to re-fetch the updated policy. Continue monitoring TLS-RPT reports — any certificate change or MX migration that is not reflected in the policy file will now cause delivery failures.
MTA-STS vs DANE: choosing the right approach
Both MTA-STS and DANE address SMTP downgrade attacks, but they operate differently:
| Feature | MTA-STS | DANE |
|---------|---------|------|
| Trust mechanism | Web PKI (CA certificates) + HTTPS | DNSSEC + TLSA records |
| DNSSEC required | No | Yes — mandatory |
| Sender adoption | High (Gmail, Microsoft, Yahoo) | Limited (Comcast, some European providers) |
| Certificate pinning | No — any valid CA cert works | Yes — pins specific cert or key |
| Operational complexity | Moderate — maintain HTTPS server + DNS | High — requires DNSSEC expertise |
| Best for | Most organizations | High-security environments with DNSSEC |
For most organizations, MTA-STS offers the better balance of security improvement and operational feasibility. DANE provides stronger cryptographic guarantees but demands DNSSEC on your domain and has less sender support outside of specialized environments (particularly required by BSI TR-03108 for German government communications).
Deploying both MTA-STS and DANE simultaneously is valid and recommended for the highest protection level — DANE enforces for senders that support it, MTA-STS enforces for the broader sender ecosystem.
Common MTA-STS errors
Stale policy file (MX mismatch): If you change your MX records but forget to update the policy file and increment the DNS id, senders in enforce mode will refuse delivery because your MX hosts no longer match the policy. Always update the policy file and increment id before changing MX records.
Expired certificate on mta-sts subdomain: The HTTPS web server hosting the policy file must have a valid TLS certificate. If it expires, senders cannot fetch the policy — behavior depends on their cache: senders with cached policy continue enforcing it; senders without cache may skip enforcement or treat the fetch failure conservatively.
MX hostname mismatch: The mx: values in the policy file must match your actual MX DNS records exactly. If DNS says aspmx.l.google.com and the policy file says smtp.gmail.com, enforcement fails.
Going direct to enforce: Never deploy mode: enforce without first running mode: testing for 30-60 days and reviewing TLS-RPT reports. Even a single misconfigured MX host with an expired certificate will cause inbound mail failures from enforce-compliant senders.
Technical Architecture
MTA-STS is defined in RFC 8461 and fundamentally changes the email trust model from opportunistic to strict:
Legacy model (vulnerable): Sending MTA trusts the initial plaintext SMTP greeting from the receiving server. Attacker strips 250-STARTTLS → sender delivers in plaintext.
MTA-STS model (secure): Sending MTA fetches TLS policy from a separate HTTPS endpoint (authenticated by Web PKI). Policy says enforce → sender must establish valid TLS to listed MX hosts with valid certificates or refuse delivery.
Compliance Failures: HIPAA, GDPR, and CJIS require encrypted email transit — relying on opportunistic TLS provides no enforceable guarantee
Compliance Impact
CISA Guidance: Strongly encourages MTA-STS for all federal .gov domains
HIPAA: Covered entities must protect ePHI in transit — opportunistic TLS is insufficient; MTA-STS provides the enforceable guarantee
GDPR Article 32: State-of-the-art technical measures for data security — STARTTLS stripping vulnerability makes opportunistic TLS increasingly non-compliant for sensitive communications
Best Practices for MTA-STS in 2025/2026
Always deploy TLS-RPT first — you need failure visibility before you can safely enforce
Never skip the testing phase — 30-60 days minimum before mode: enforce
Automate certificate renewal on mta-sts subdomain — an expired policy file certificate breaks policy delivery
Update id whenever you change the policy file — senders use this to invalidate their cache and re-fetch
Set high max_age in enforce mode — long cache duration (30 days) provides protection even during brief outages of your policy web server
Tools to check your MTA-STS
Use the CyberFurl MTA-STS checker to validate your full MTA-STS deployment — DNS record syntax, policy file reachability, HTTPS certificate validity, MX hostname accuracy, and mode. After any change to your MX records or TLS certificates, re-run the checker to confirm the policy file remains accurate. For deployment guidance and continuous posture monitoring, the checker pairs with TLS-RPT analysis.
CF
How CyberFurl Helps
Automated monitoring. Zero manual work.
CyberFurl validates your full MTA-STS deployment end-to-end: DNS record syntax, policy file reachability, TLS certificate validity on the mta-sts subdomain, MX hostname accuracy, and enforcement mode. Combined with TLS-RPT report analysis, CyberFurl provides continuous visibility into whether enforcement is causing delivery failures - giving teams the evidence to reach enforce mode safely.
MTA-STS is not universally mandated by law, but it is rapidly becoming a regulatory baseline. CISA's modernized email security guidance strongly encourages MTA-STS adoption for all federal .gov domains alongside DMARC and DKIM. HIPAA covered entities are increasingly expected to enforce TLS on email containing ePHI — relying on opportunistic STARTTLS (which is trivially bypassable) is viewed as insufficient protection. GDPR Article 32 requires appropriate technical measures for data in transit, making STARTTLS-stripping attacks a compliance gap. For any domain where email is used to communicate sensitive business, customer, or regulated data, MTA-STS is the appropriate baseline.
What's the difference between MTA-STS testing mode and enforce mode?
In testing mode (mode: testing), senders fetch and process your MTA-STS policy but continue delivering email even if TLS validation fails — they send failure reports to your TLS-RPT address instead of rejecting. This is the safe starting point that lets you observe real-world delivery behavior before committing to enforcement. In enforce mode (mode: enforce), senders must successfully establish a valid TLS connection to the MX hosts in your policy file. If TLS fails — expired certificate, missing STARTTLS, mismatched MX hostname — the sender refuses to deliver the message. Always run testing mode for at least 30-60 days and confirm zero TLS-RPT failures before switching to enforce.
Why do I need a .well-known HTTPS file for MTA-STS?
MTA-STS uses a two-component architecture: a DNS TXT record signals that a policy exists, and an HTTPS-hosted policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt contains the actual policy details (mode, authorized MX hosts, max-age). The HTTPS delivery is deliberate — it provides an out-of-band channel that attackers cannot easily manipulate compared to DNS, which is historically unauthenticated. The web server's TLS certificate itself serves as proof that the policy delivery is legitimate. A DNSSEC-unsigned DNS record alone would not provide the same level of trust, which is why MTA-STS requires both components working together.
MTA-STS vs DANE — which should I implement?
Both MTA-STS and DANE protect against SMTP downgrade attacks, but through different mechanisms and with different operational requirements. MTA-STS uses DNS + HTTPS-hosted policy and relies on the Web PKI (CA-based) trust model — widely supported by major senders (Gmail, Microsoft, Yahoo) and deployable without DNSSEC. DANE uses DNSSEC-signed TLSA records to pin certificates cryptographically, bypassing Web PKI entirely — more secure in theory but requires DNSSEC on your entire domain and has limited sender adoption. For most organizations: deploy MTA-STS first because it is easier and has broader sender support. Deploy DANE additionally if you need the strongest available protection and your DNS provider supports DNSSEC reliably. The two are complementary, not mutually exclusive.
How do I roll out MTA-STS safely?
Safe MTA-STS rollout: (1) Deploy TLS-RPT first — publish the DNS record pointing to a reporting endpoint before adding MTA-STS, so you can monitor transport failures throughout the process. (2) Confirm all your MX hosts have valid, publicly trusted TLS certificates (not self-signed, not expired, matching the MX hostname). (3) Publish the policy file with mode: testing and list all your MX hosts accurately. (4) Monitor TLS-RPT reports for 30-60 days — watch for certificate errors, hostname mismatches, and policy fetch failures. (5) Only switch to mode: enforce after confirming zero TLS failures in reports. (6) Increment the id tag in your DNS record whenever you change the policy file, so senders know to re-fetch the updated policy.
What happens if my MTA-STS policy file is temporarily unreachable?
Behavior depends on whether the sending MTA has a cached copy of your policy. If the sender cached your policy recently (within the max_age window), it continues enforcing the cached policy even if the policy file endpoint is temporarily unreachable — this resilience is by design. If the sender has no cached policy and cannot fetch one, it falls back to opportunistic TLS without enforcement. This is one reason to set a high max_age in enforce mode (604800 seconds or higher) — a longer cache TTL means most senders continue enforcing even during brief policy server outages. Monitor your mta-sts subdomain TLS certificate expiry and server uptime as carefully as your MX host certificates.
Does MTA-STS work with Gmail, Microsoft 365, and Yahoo?
Yes — all three major email platforms fully support MTA-STS as senders. Gmail and Google Workspace support MTA-STS enforcement and send TLS-RPT failure reports. Microsoft 365 and Exchange Online support both MTA-STS enforcement and TLS-RPT reporting. Yahoo Mail also supports MTA-STS. This broad adoption among the highest-volume senders is what makes MTA-STS operationally valuable — the senders delivering the most email to your domain all respect your enforce policy. TLS-RPT reports from Google and Microsoft confirm that enforcement is working correctly for the senders that matter most to your deliverability.
