STARTTLS can encrypt an SMTP connection after both mail servers negotiate TLS, but opportunistic STARTTLS alone does not guarantee that a message stays encrypted or reaches the intended server. To make SMTP transport security more resilient, domain operators can publish delivery policies with MTA-STS or DNSSEC-backed DANE, then use SMTP TLS Reporting (TLS-RPT) to monitor outcomes.
What STARTTLS protects—and what it does not
SMTP STARTTLS upgrades an existing SMTP connection to TLS. RFC 3207 defines the extension: after a server advertises STARTTLS and the client requests it, the parties negotiate TLS before continuing the SMTP exchange. When negotiation succeeds, TLS protects that network hop against passive reading and modification in transit.
Baseline STARTTLS is opportunistic, however. A sending server may be configured to deliver even when TLS is unavailable, to preserve compatibility with mail systems that do not support it. An active attacker who can alter the SMTP exchange may remove the server’s 250 STARTTLS advertisement; an attacker who can influence routing may also try to redirect delivery. Without an additional policy requiring TLS and checking the receiving server’s identity, the sender may not know that encryption was suppressed or that the destination changed. RFC 8460 describes these risks in its discussion of SMTP TLS reporting: RFC 8460.
The key distinction is between encryption when TLS is negotiated and a policy that requires TLS and validates the receiving server. STARTTLS provides the mechanism for encrypting a connection; MTA-STS and DANE can add policy for mail delivery.
Recommended Free Tools
#1 Best Overall
How MTA-STS adds a delivery policy
SMTP MTA Strict Transport Security (MTA-STS) lets a recipient domain publish the MX hosts senders should use, whether TLS is required, and how senders should handle failures. Policy discovery starts with DNS; the policy document is hosted over HTTPS. A sender must support MTA-STS and obtain the domain’s policy for it to affect delivery. The protocol is specified in RFC 8461.
Testing mode
In testing mode, a sender that honors the policy can continue delivery when a policy check fails, while reporting failures if it also implements TLS-RPT. This lets operators observe problems such as an MX host missing from the policy or a certificate that does not validate before making delivery contingent on the policy.
Rank #2
- The latest SonicWall TZ370 series, are the first desktop form factor nextgeneration firewalls (NGFW) with 10 or 5 Gigabit Ethernet interfaces. The series consist of a wide range of products to suit a variety of use cases.
- Reduce complexity and get the business running without relying on IT personnel with easy onboarding using SonicExpress App and Zero-Touch Deployment, and easy management through a single pane of glass
- Drive business growth by investing in next-gen appliances with multi-gigabit and advanced security features, to future-proof against the changing network and security landscape.
- SonicWall 24x7 support provides chat, email, web, and telephone support for technical assistance | Dynamic Support is designed for customers who need continued protection through ongoing firmware updates and advanced technical support
- Hardware: Operating system: SonicOS 7.0 | Interfaces: 8x1GbE, 2 USB 3.0, 1 Console | Management: Network Security Manager, CLI, SSH, Web UI, GMS, REST APIs | VLAN Interfaces: 128 | Access points supported (maximum): 16
Enforce mode
In enforce mode, a sender honoring the policy must not deliver to an MX host that does not match the policy, does not support STARTTLS, or fails the policy’s certificate validation requirements. Messages may be delayed rather than sent over an unverified or unencrypted connection. That protects against specified downgrade and identity failures, but makes accurate MX names, valid certificates, and dependable policy hosting operationally important.
MTA-STS therefore depends on DNS policy discovery, an HTTPS-hosted policy, and certificate validation at the receiving MX. Operators need to keep the policy aligned with their live MX records and maintain the certificates and HTTPS endpoint used by the policy.
Rank #3
- The TZ570 is designed for mid-sized organizations and distributed enterprise with SD-Branch locations, the TZ570 delivers industry-validated security effectiveness with best-in-class price performance. TZ570 NGFWs address the growing trends in web encryption, connected devices and high-speed mobility by delivering a solution that meets the need for automated, realtime breach detection and prevention.
- Deployment of TZ570 is further simplified by Zero-Touch Deployment, with the ability to simultaneously roll out these devices across multiple locations with minimal IT support.
- The SonicOS architecture is at the core of TZ NGFWs. TZ570 is powered by the feature rich SonicOS 7.0 operating system with new modern looking UX/UI, advanced security, networking and management capabilities. TZ570 features integrated SD-WAN, TLS 1.3 support, realtime visualization, high-speed virtual private networking (VPN) and other robust security features.
- SonicWall 24x7 support provides chat, email, web, and telephone support for technical assistance | Dynamic Support is designed for customers who need continued protection through ongoing firmware updates and advanced technical support
- Hardware: Interfaces: 8x1GbE, 2x5GbE, 2 USB 3.0, 1 Console | VLAN interfaces: 256 | Firewall Inspection Throughput: 4.00 Gbps | Threat Prevention Throughput: 4.00 Gbps | IPS Throughput: 2.5 Gbps | IPSec VPN Throughput: 1.80 Gbps
How DANE for SMTP differs from MTA-STS
DANE for SMTP publishes TLSA records that describe TLS and certificate-validation criteria for mail servers. DNSSEC authenticates those records so a sender that validates DNSSEC can rely on the TLSA information. The SMTP-specific mechanism is defined in RFC 7672.
| Mechanism | Trust foundation | Operational dependencies | Role and failure implications |
|---|---|---|---|
| MTA-STS | Policy discovery through DNS and policy delivery over HTTPS, relying on Web PKI for HTTPS and certificate validation. | DNS policy discovery, HTTPS policy hosting, accurate MX names, and maintained mail-server certificates. | In enforce mode, a sender honoring the policy must not deliver when the MX match, STARTTLS, or certificate checks required by policy fail. Testing mode supports observation while delivery may continue. |
| DANE for SMTP | DNSSEC-authenticated TLSA records. | DNSSEC deployment and validation, plus correct TLSA publication and maintenance. | Provides TLS and certificate-validation criteria authenticated through DNSSEC; its trust and operational model differs from MTA-STS. |
| SMTP TLS Reporting (TLS-RPT) | Not an encryption policy; it uses a DNS TXT record to identify report destinations. | Publishing the reporting policy and handling incoming aggregate reports. | Reports delivery-security outcomes and failures; it complements MTA-STS or DANE rather than enforcing TLS itself. |
Neither mechanism is a universal best choice on the evidence available here: they depend on different infrastructure and trust foundations, and the cited standards do not establish comparative deployment prevalence or protection rates. A domain’s operational ability to maintain DNSSEC and TLSA records, or HTTPS-hosted MTA-STS policy, is therefore central to the decision.
What TLS-RPT reports—and why it matters
SMTP TLS Reporting allows a recipient domain to request aggregate reports about the security of mail delivery to its MX hosts. A domain publishes a TXT reporting policy at _smtp._tls.<domain> indicating where reports should be sent. The report schema covers issues with routing, DNS resolution, STARTTLS negotiation, and MTA-STS or DANE policy validation. See RFC 8460.
Reports can help distinguish routine configuration faults from failures that may indicate interception or tampering. For example, unexpected reports about an MX mismatch or failed TLS validation can give operators a signal to investigate. Reporting is not a prevention mechanism: it does not require senders to use TLS or stop delivery. MTA-STS or DANE supplies policy; TLS-RPT provides visibility into how delivery systems apply it.
Best Value
- The latest SonicWall TZ370 series, are the first desktop form factor nextgeneration firewalls (NGFW) with 10 or 5 Gigabit Ethernet interfaces. The series consist of a wide range of products to suit a variety of use cases.
- Reduce complexity and get the business running without relying on IT personnel with easy onboarding using SonicExpress App and Zero-Touch Deployment, and easy management through a single pane of glass
- Drive business growth by investing in next-gen appliances with multi-gigabit and advanced security features, to future-proof against the changing network and security landscape.
- SonicWall 8x5 Support provides chat, email, web, and telephone support for technical assistance | Dynamic Support is designed for customers who need continued protection through ongoing firmware updates and advanced technical support
- Hardware: Operating system: SonicOS 7.0 | Interfaces: 8x1GbE, 2 USB 3.0, 1 Console | Management: Network Security Manager, CLI, SSH, Web UI, GMS, REST APIs | VLAN Interfaces: 128 | Access points supported (maximum): 20
Reporting endpoints also need safeguards. RFC 8460 identifies risks including endpoint flooding, malicious report content, and report snooping. Operators should treat reports as untrusted inbound data, manage the reporting endpoint’s capacity, and limit access to sensitive operational details.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Operational checklist for domain owners
- Inventory the mail path. Identify the recipient domain’s MX hosts, certificate arrangements, DNS control, and who is responsible for HTTPS policy hosting or DNSSEC and TLSA records.
- Choose a policy mechanism your team can maintain. MTA-STS requires DNS discovery and an HTTPS-hosted policy; DANE for SMTP requires DNSSEC-authenticated TLSA records and validating senders. Do not assume either mechanism is universally preferable.
- Validate the published data against live mail service. Confirm that policy MX names match the hosts receiving mail and that TLS and certificate behavior meet the published requirements. For DANE, ensure TLSA data is correct and DNSSEC validation works.
- Use observation before strict enforcement where supported. MTA-STS testing mode can reveal policy failures through TLS-RPT while allowing delivery to continue; review reports and correct benign configuration faults before moving to enforce mode.
- Monitor and respond to reports. Establish who reviews TLS-RPT outcomes, investigates routing or TLS failures, and handles delayed or failed delivery. Protect the reporting endpoint from abuse and restrict report access appropriately.
What these mechanisms can and cannot establish
STARTTLS encrypts an SMTP hop when negotiation succeeds. MTA-STS and DANE add ways for participating senders to apply recipient-domain TLS requirements, while TLS-RPT gives operators an aggregate view of reported results. These mechanisms address transport between mail servers; they do not, by themselves, guarantee end-to-end encryption of message contents or prove that every sending system on the internet honors a domain’s policy.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
