Your organization has likely implemented SPF, DKIM, and DMARC to protect your domain from spoofing and phishing. You’ve checked the boxes on email authentication. But there’s a critical vulnerability in your email infrastructure that these protocols don’t address: the encryption of messages in transit between mail servers. The dirty secret of email security is that STARTTLS, the mechanism most mail servers use for encryption, is entirely optional. An attacker performing a man-in-the-middle attack can simply strip the encryption, forcing servers to communicate in plaintext. This is where MTA-STS and TLS-RPT come in—two complementary email security protocols that transform opportunistic encryption into enforced protection.
Mail Transfer Agent Strict Transport Security (MTA-STS) is a security standard defined in RFC 8461 that enables domain owners to require TLS encryption for all incoming email connections. Think of it as HSTS (HTTP Strict Transport Security) for email—it tells sending mail servers that they must establish a secure, encrypted connection when delivering mail to your domain, or they should not deliver the message at all.
MTA-STS addresses two critical vulnerabilities in email delivery:
By publishing an MTA-STS policy, you’re declaring that your mail servers support TLS and that sending servers should refuse to deliver mail if they cannot establish a secure connection. This fundamentally changes the security posture of email encryption in transit.
Understanding the difference between opportunistic and enforced TLS is crucial to grasping why MTA-STS matters. The current standard for email encryption, STARTTLS, operates on an opportunistic basis. When a sending mail server connects to a receiving server, it checks whether TLS is available. If it is, great—the connection is encrypted. If it’s not, or if something interferes with the negotiation, the servers simply proceed with an unencrypted connection.
This opportunistic approach creates a significant vulnerability. An attacker positioned between two mail servers can perform a STARTTLS stripping attack by:
Because STARTTLS is opportunistic, the sending server has no way to know that encryption should have been available. It simply delivers the message unencrypted, assuming that’s the best option available. MTA-STS transforms this model by moving from opportunistic to enforced TLS. With an MTA-STS policy in place, the sending server knows that your domain requires encryption. If TLS cannot be negotiated, the sending server treats it as a delivery failure rather than falling back to plaintext.
MTA-STS uses a combination of DNS records and HTTPS-hosted policy files to communicate your TLS requirements. Here’s the technical flow:
Step 1: DNS TXT Record
The sending mail server first checks for an MTA-STS DNS TXT record at _mta-sts.yourdomain.com. This record indicates that a policy exists and provides a policy ID for caching purposes:
_mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20240115T120000;"Step 2: Policy File Retrieval
The sending server then retrieves the actual policy via HTTPS from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The use of HTTPS is critical—it prevents DNS spoofing attacks by requiring certificate validation through the web PKI infrastructure.
The policy file format looks like this:
version: STSv1
mode: enforce
mx: mail1.yourdomain.com
mx: mail2.yourdomain.com
mx: *.mail.yourdomain.com
max_age: 604800Policy Parameters:
Step 3: Policy Enforcement
When delivering mail, the sending server validates that:
If any validation fails and the mode is “enforce,” the sending server must not deliver the message over an insecure connection.
Step 1: Verify Your MX Records and TLS Support
Before implementing MTA-STS, ensure all your MX hosts support TLS 1.2 or higher with valid certificates. Test your configuration using tools like Hardenize or CheckTLS.
Step 2: Create the Policy File
Create a text file with your MTA-STS policy. Start with “testing” mode:
version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 86400Step 3: Host the Policy File
Upload this file to https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. You’ll need to:
mta-sts.yourdomain.comtext/plainStep 4: Publish the DNS TXT Record
Add the DNS TXT record with a unique policy ID:
_mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20240115T120000;"The ID should change whenever you update your policy file, forcing sending servers to refresh their cached copy.
Step 5: Monitor and Transition to Enforce Mode
Run in testing mode for at least a week while monitoring TLS-RPT reports. Once confident, update your policy file to mode: enforce and increment the ID in your DNS record.
TLS Reporting (TLS-RPT), defined in RFC 8460, is the companion protocol to MTA-STS. While MTA-STS enforces encryption requirements, TLS-RPT provides visibility into what’s actually happening with TLS connections to your mail servers. Without TLS-RPT, you’re flying blind—you won’t know if legitimate senders are experiencing TLS failures or if your MTA-STS policy is causing delivery issues.
TLS-RPT works by having sending mail servers generate reports about TLS connection successes and failures, then sending those reports to an address you specify. Implementation is straightforward—just publish a DNS TXT record:
_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"The rua parameter specifies where reports should be sent. You can specify multiple addresses separated by commas, and you can also use HTTPS endpoints for automated processing.
TLS-RPT reports arrive as JSON documents, typically sent daily by participating mail servers. A report contains:
Key failure types to watch for:
These reports are invaluable for troubleshooting delivery issues and identifying potential security incidents. A sudden spike in TLS failures could indicate a misconfiguration, certificate expiration, or an active attack.
Despite being published as RFCs in 2018, MTA-STS and TLS-RPT adoption remains relatively low compared to SPF, DKIM, and DMARC. Several factors contribute to this gap:
Complexity and Infrastructure Requirements: Unlike SPF and DKIM, which only require DNS changes, MTA-STS requires hosting a policy file on an HTTPS endpoint. This adds infrastructure complexity that many organizations aren’t prepared for.
Lack of Awareness: Email security discussions often focus on authentication (preventing spoofing) rather than encryption in transit. Many security teams don’t realize that email encryption in transit is opportunistic and vulnerable to downgrade attacks.
Incomplete Security Frameworks: Common email security checklists emphasize SPF, DKIM, and DMARC but often omit MTA-STS and TLS-RPT entirely. Organizations believe they’ve secured their email when they’ve only addressed authentication, not encryption.
The False Sense of Security: Because most modern mail servers do support STARTTLS, and most connections do get encrypted, there’s a false sense that email encryption is “good enough.” The vulnerability of TLS downgrade attacks isn’t immediately visible until it’s exploited.
However, for organizations handling sensitive communications—healthcare, financial services, legal, or any industry with compliance requirements—the encryption gap represents a significant risk. SPF, DKIM, and DMARC protect against sender spoofing, but they do nothing to prevent eavesdropping on messages in transit.
If your organization has already implemented SPF, DKIM, and DMARC, adding MTA-STS and TLS-RPT should be your next priority for email security. These protocols close a critical gap in your email security posture by ensuring that messages are encrypted in transit and providing visibility into encryption failures.
Start with TLS-RPT first—it’s simpler to implement (just a DNS record) and will give you immediate visibility into how TLS is performing for your domain. This baseline data is invaluable before implementing MTA-STS. Then implement MTA-STS in testing mode, monitor the TLS-RPT reports for issues, and transition to enforce mode once you’re confident in your configuration.
At Email Delivery Pro, we’ve seen organizations significantly improve their email security posture by implementing these protocols. The combination of enforced encryption (MTA-STS) and visibility (TLS-RPT) provides defense-in-depth against both passive eavesdropping and active man-in-the-middle attacks. Don’t let your email encryption remain opportunistic—make it mandatory with MTA-STS and gain visibility with TLS-RPT. Your sensitive communications deserve nothing less than enforced protection.