What does 'starttls-not-supported' in TLS-RPT really mean?

You sent an email. It showed as delivered. But somewhere in the background, a handshake failed. No encryption. No protection. Just plain text. That’s what a "starttls-not-supported" result means in a TLS-RPT report: the receiving server didn’t even offer STARTTLS during the SMTP connection.

This isn’t a minor glitch. It means the mail server either has no TLS setup at all, or the configuration is misconfigured—rejecting encrypted connections outright. Modern inboxes increasingly block or flag unencrypted messages. If you're not fixing this, your deliverability is on a downgrade path.

You’ll learn exactly what this TLS-RPT result means, why it matters for deliverability, and how to fix it—no guesswork, just actionable steps based on real SMTP behavior and email infrastructure standards.

Key takeaways

  • A 'starttls-not-supported' result means the receiving mail server didn’t offer encryption during the SMTP handshake.
  • This indicates either missing TLS configuration or a misconfigured mail server, reducing email security and increasing deliverability risk.
  • Fixing it involves validating and correcting the server’s TLS setup—ensuring it advertises STARTTLS and supports valid certificates.

How TLS-RPT reports help identify encryption issues in email delivery

TLS-RPT reports, sent by receiving mail servers after delivery attempts, record whether encrypted email sessions succeeded. A starttls-not-supported result means the recipient’s server doesn’t accept TLS encryption, exposing messages to eavesdropping. These reports provide objective, post-delivery proof of encryption readiness, helping you fix connection issues before they impact deliverability.

Understanding TLS-RPT result types

When a receiving server logs a TLS-RPT report, it includes a result-type indicating the outcome of the encryption handshake. Common types include starttls-success, starttls-failure, and starttls-not-supported. The last one, starttls-not-supported, signals that the recipient’s mail server either didn’t advertise support for STARTTLS or couldn’t establish a secure channel during the session.

This result doesn’t mean your message was rejected — it means it was sent unencrypted. Over time, repeated starttls-not-supported reports across multiple domains may indicate a broader problem with your sending infrastructure's TLS configuration or DNS records. You’ll need to verify that your server advertises STARTTLS properly, using the appropriate MX record and certificate chain.

How to act on TLS-RPT data

Let’s say your reports consistently show starttls-not-supported from domains like @example.com or @corporate.org. That’s a red flag — those servers are either misconfigured or explicitly blocking encryption. Use tools like MXToolbox or RFC 6409 to test your server’s STARTTLS setup. Check your SSL certificate validity, chain completeness, and TLS version support.

You can also use MailTester’s inbox placement and bulk verification tools to test whether your outbound emails reach inboxes without encryption fallbacks. These tools simulate real delivery environments and can surface issues early — before your sender reputation suffers.

Why 'starttls-not-supported' hurts your sender reputation and inbox placement

When your email server fails to support STARTTLS, receiving providers like Gmail and Outlook log the failure, marking your domain as insecure. Repeated TLS negotiation failures degrade your sender reputation over time, increasing the odds your messages end up in spam or are rejected outright. You’re not just losing delivery—your long-term deliverability is at stake.

Why encrypted delivery matters to inbox providers

Email providers treat encryption as a baseline requirement. Gmail, Outlook, and Apple Mail all prioritize messages that arrive via TLS; not supporting it signals a lack of security rigor. If your outbound server doesn’t offer encryption, the receiving mail server records this as a failure—not just a technical hiccup, but a trust signal. This is not a minor detail; it’s part of how modern spam filtering works.

When thousands of messages from your domain attempt to connect without TLS, providers start to associate you with non-compliant senders. The longer this continues, the higher your risk of being flagged by reputation systems like those used by Spamhaus or Google’s own filtering infrastructure. You can’t just ignore this—it’s not a “nice-to-have.”

The long-term impact on your delivery

Sender reputation isn’t just about spam traps or bounces—it’s about consistency and compliance at scale. Each failed TLS negotiation adds negative weight. Over time, this reduces inbox placement and raises the chance of being blocked by filters. Even if your content is clean, a weak encryption posture can sink your entire email program.

Think of it like driving without seatbelts: you might not crash today, but every trip increases the risk. The same applies here. You may still send emails, but the system will quietly push you into junk folders. And once reputation drops, recovery takes time.

Let’s say you’re sending transactional alerts or marketing campaigns. If your infrastructure doesn’t support TLS, you’re handing the inbox providers a reason to doubt your legitimacy. No automated system rewards non-compliance with security standards.

Fixing STARTTLS isn’t a one-time task. It requires checking your server configuration, ensuring your TLS certificate is valid and up to date, and verifying that your mail relay supports encryption. Tools like MailTester’s inbox placement tester can show you how your emails land in real inboxes—and whether encryption was negotiated.

How to diagnose 'starttls-not-supported' using real-world tools

When a domain returns a starttls-not-supported result, it means the mail server refuses or fails to negotiate a secure TLS connection on port 25. You can confirm this by testing the server directly using tools like MxToolbox or OpenSSL. A failed TLS handshake during a manual SMTP test confirms the server doesn’t support STARTTLS, which harms deliverability and blocks secure email.

Check domain-level STARTTLS support

  1. Go to MxToolbox and enter your domain in the "SMTP (STARTTLS) Test" tool. The result will show whether the server responds with a STARTTLS command during the SMTP handshake. If it doesn’t, STARTTLS is unsupported.
  2. Alternatively, use Google’s Admin Toolbox with the "SMTP Diagnostics" feature. Enter your domain and test the connection. The output will show the server’s handshake behavior, including if it rejects TLS.
  3. If either tool reports no STARTTLS support, the issue is on the recipient’s mail server — not your setup. This impacts email deliverability and may cause your messages to be rejected or downgraded.

Test the connection manually with OpenSSL

For full control and deeper insight, run a direct test using OpenSSL. Open a terminal and run:

openssl s_client -connect yourdomain.com:25 -starttls smtp

If the connection fails with connect: Connection refused or ssl handshake failure, the server does not support STARTTLS. If it says STARTTLS accepted, the connection works — but if it skips TLS entirely, the server blocks it.

A successful handshake shows Verify return code: 0 (ok). A failure means the server either doesn't list STARTTLS in its EHLO response or refuses secure connections. This is the root cause of the reported starttls-not-supported verdict.

Use these tools to verify if a domain’s mail server meets modern security standards. Ignoring unsupported TLS can hurt sender reputation, trigger filters, and reduce inbox placement. For broader list health checks — including real-time verification of mail server capabilities — consider MailTester’s API or bulk verification to catch issues early.

Common causes of 'starttls-not-supported' on the receiving side

When a mail server reports 'starttls-not-supported', it means the receiving server either lacks TLS configuration, has a broken certificate, or blocks encrypted connections. This breaks email security and can trigger delivery failures. The most common root causes are missing or expired TLS certificates, misconfigured mail software, or firewall rules blocking ports 587 (submission) or 465 (SMTPS). Let's walk through each.

Mail server software not configured for TLS

  • You're using Exim, Postfix, or another MTAs that default to plaintext SMTP unless explicitly configured with TLS certificates.
  • Check your MTA configuration: look for smtpd_tls_cert_file and smtpd_tls_key_file in Postfix or tls_certificate_file in Exim.
  • If these are missing or point to non-existent files, the server won’t advertise STARTTLS support — even if the port is open.

Certificates that prevent the handshake

  • A self-signed certificate may be present, but it's not trusted by the sending server, causing handshake failure.
  • An expired certificate also breaks encryption — even if the server supports TLS, it won't negotiate a secure session.
  • Use RFC 5246 (TLS 1.2) to understand handshake expectations; mismatched or invalid certs disrupt this process.
  • Test with openssl s_client -connect example.com:587 -starttls smtp to isolate certificate issues from network problems.

Network-level interference

  • Firewalls, load balancers, or legacy network devices may block or strip TLS traffic on ports 587 or 465.
  • Some providers misconfigure shared infrastructure to drop encrypted SMTP sessions, especially in managed email environments.
  • Check if traffic is being redirected or intercepted — tools like MxToolbox can help verify port openness.

SMTP service misconfiguration

  • The receiving server may disable TLS entirely via configuration or default to non-encrypted connections only.
  • Some legacy setups require explicit enabling of TLS in the service definition.
  • Double-check that the SMTP service listens on 587 and explicitly advertises STARTTLS in its SMTP response.
  • Use inbox placement testing to simulate real delivery and catch TLS issues before sending to real users.

Can the 'starttls-not-supported' result be a false positive?

Yes, a starttls-not-supported result can be a false positive. Some older or poorly maintained mail servers misreport their TLS capability due to misconfiguration, outdated software, or incomplete protocol implementation. In other cases, the receiving server may drop the connection before TLS negotiation begins—often due to rate limiting, IP blacklisting, or aggressive anti-spam rules triggered during the initial handshake.

Why older or misconfigured servers fail to advertise TLS

Older mail servers, particularly those running legacy software stacks, may not correctly advertise STARTTLS support even if they’re capable of it. This can happen because the server's configuration file doesn't include the proper TLS flags, or because the underlying service (like Exim or Sendmail) has TLS disabled by default for compatibility reasons. Such servers don’t respond to the STARTTLS command in the SMTP negotiation, which leads to a starttls-not-supported result—even though TLS might work under other conditions.

Some mail servers also fail to advertise STARTTLS if they prioritize backward compatibility over security. These systems may accept unencrypted connections but do not initiate TLS at all, even when requested. This lack of support isn't always intentional: it’s often a byproduct of years of unattended maintenance and patch cycles skipped during infrastructure updates.

Connection drops before TLS handshake completes

Even when a server does support STARTTLS, network-level issues can prevent the handshake from finishing. Some receiving servers rate-limit incoming connections from certain IP ranges, especially if they're associated with email-sending services. If your IP hits a limit before the STARTTLS command, the server drops the connection abruptly—returning a starttls-not-supported code that's misleading.

Similarly, servers behind anti-spam systems like Barracuda or Proofpoint may drop suspicious connections during the SMTP phase—before TLS negotiation starts—based on reputation, header analysis, or envelope data. This happens even if the server would otherwise support TLS. The error isn’t from the server refusing TLS; it’s from the connection being interrupted before any TLS attempt occurs.

These issues are documented in industry reports on email infrastructure reliability and are commonly observed in large-scale email delivery environments. For example, RFC 3207 outlines the correct sequence for initiating STARTTLS, and deviations from that sequence can result in misreported behaviors.

If you’re validating email lists at scale, understanding this limitation helps avoid over-cleaning valid addresses. You can test these endpoints manually using tools like MailTester’s inbox placement test to see if delivery succeeds despite the report. Or use the real-time verification API to verify individual addresses with deeper diagnostics.

How to verify if a recipient domain is truly not supporting STARTTLS

When you see a starttls-not-supported result, it means the recipient's mail server didn’t offer STARTTLS during SMTP negotiation. But this doesn’t always mean the domain is broken — it could be a temporary glitch, relay issue, or outdated testing. To confirm it’s a real configuration issue, you need to validate it across multiple checks, over time, and with real-world data. Only then can you trust the verdict.

Check the MX record and test consistently

Start by verifying the domain’s MX record. A misconfigured or outdated MX record can point to a server that no longer handles mail or lacks TLS support. Use tools like MXToolbox to check the current mail server configuration. Then, run repeated SMTP tests from multiple geolocations using services like MailTester’s inbox placement checker. Consistent failures across multiple runs—especially from different networks or email providers—suggest the domain truly doesn’t support STARTTLS.

Use bulk verification to detect patterns

One failing address might be a fluke. Hundreds failing with starttls-not-supported across a list is a red flag. Use MailTester’s bulk email verification to test hundreds of addresses at once. If multiple domains or subdomains show this result consistently, it’s likely a real TLS configuration issue on their side. Tools like MailTester use real SMTP connections and simulate actual sending behavior, so their results reflect real-world delivery challenges.

Let’s be clear: a single test result isn’t proof. A well-configured server can misreport due to network issues, timeouts, or temporary routing changes. But repeated, consistent failures across multiple test points—especially from different infrastructure locations—indicate a deeper, persistent issue. This is where automation and real-time data help. MailTester’s API (API email checker) lets you integrate validation into your workflow, so you’re not relying on spot checks.

Also, check known sources like RFC 3207 for the standard definition of STARTTLS, and note that most modern mail servers should support it. If a large number of recipients in your list consistently fail TLS checks, it may point to an issue not with the individual address, but with the domain’s core email infrastructure.

You can’t directly see a TLS-RPT result-type like starttls-not-supported, but MailTester identifies domains at risk of failing encrypted delivery by simulating real SMTP sessions, including TLS negotiation attempts. It flags domains where encryption is likely to fail—before you send—reducing bounces and protecting sender reputation. This proactive validation helps you avoid sending to domains that either reject encrypted connections or lack valid certificates.

Simulating real SMTP behavior to catch encryption risks

MailTester doesn’t parse TLS-RPT reports, but it mimics the handshake process that happens during actual email delivery. When you verify an email address using the real-time API or bulk list verification, MailTester attempts to connect to the recipient’s mail server and initiates TLS negotiation. If the server refuses or fails the TLS handshake, MailTester records that as a high-risk signal.

This testing isn’t just theoretical. It reflects what happens in real delivery pipelines—where a failed handshake leads to delivery failure or rejection, especially with providers enforcing encryption via RFC 8314 or stricter policies. Domains that don’t support STARTTLS are increasingly viewed as insecure, which can hurt deliverability and reputation.

Filtering out risky domains before they harm your list

With 98.9% accuracy, MailTester distinguishes valid addresses from those with configuration-level issues, including encryption incompatibility. You get actionable verdicts like invalid, catch-all, risky, or valid. A risky label often indicates a domain that may not support TLS or has weak certificate settings—exactly the kind of domain that would trigger a starttls-not-supported TLS-RPT result.

By catching these risks early, you avoid sending to domains where encryption fails, which reduces bounce rates and protects your sender reputation. You’re not relying on passive reports; you’re actively testing delivery readiness in a way that mirrors actual SMTP behavior.

Let’s say you’re sending transactional emails to a customer list. Using MailTester’s bulk verification lets you filter out addresses linked to servers that won’t accept encrypted mail. It’s a concrete step to prevent delivery failures caused by missing or broken TLS.

For automated workflows, the real-time verification API returns this data instantly, so you can enforce delivery security at the point of capture. Integrations with platforms like Mailchimp, HubSpot, and SendGrid (see integrations) allow you to apply these checks at scale. Even if your provider doesn’t yet report on TLS-RPT, MailTester gives you the equivalent insight—before you send.

Proactive testing isn’t optional when compliance and inbox placement matter. Standards like the IETF’s requirement for encrypted delivery in some contexts underscore why encryption readiness is a delivery signal, not a side feature.

How to fix 'starttls-not-supported' on your own sending infrastructure

If your mail server reports starttls-not-supported, it means outgoing mail isn't negotiating encryption, leaving messages exposed. This harms deliverability and violates modern email security standards. Fix it by ensuring your server has a valid TLS certificate, enables STARTTLS on port 587 (or 25), and successfully completes SSL handshakes. Use tools like MXToolbox or RFC 8314 to verify configuration and test connectivity.

Verify Your Server's TLS Setup

  1. Confirm your mail server has a valid, trusted TLS certificate. Self-signed or expired certs cause handshake failures. Use SSL Shopper's checker or openssl s_client -connect yourdomain.com:587 -starttls smtp to verify. A trusted certificate from a CA like Let’s Encrypt or DigiCert is required for consistent acceptance by receiving servers.
  2. Ensure your SMTP daemon (Postfix, Exim, etc.) is configured to enable STARTTLS on port 587. Check your MTA’s config files — for Postfix, look in /etc/postfix/main.cf for smtpd_tls_security_level=may and smtpd_tls_auth_only=yes. On port 25, STARTTLS should be optional, but port 587 should enforce it. Without proper config, the server won’t advertise STARTTLS support.
  3. Test the configuration using online tools and monitor logs. Run MXToolbox's SSL Check to verify port 587 responds with TLS. Check logs at /var/log/mail.log or /var/log/maillog for lines like STARTTLS failed or certificate verification failed. These reveal whether the issue is missing certs, misconfiguration, or connectivity issues.
  4. Restart the mail service and retest immediately. After changing any configuration, restart the service (e.g., systemctl restart postfix). Then run the same test again. A successful handshake shows CONNECTED and STARTTLS success in the output. Never rely on old configuration state — restart is mandatory.

Proactive Monitoring and Prevention

Leverage tools like MailTester's Inbox Placement to simulate real-world delivery and validate that encryption is negotiated end-to-end across popular inboxes. This helps catch issues before they impact your sender reputation. Regular checks can prevent issues that lead to lower inbox placement, especially when third-party services flag unencrypted connections.

Fixing starttls-not-supported is not optional. It's a core requirement in today’s email ecosystem. A properly secured server improves trust with ISPs and increases the likelihood of your messages reaching the inbox — not the quarantine.

Should you block emails to domains that report 'starttls-not-supported'?

You don’t have to block emails to domains that report starttls-not-supported—especially if the recipient is important. Many small organizations, legacy systems, or older infrastructure simply don’t support TLS encryption, yet still deliver mail reliably. Blocking them outright risks missing critical communications.

When to treat it as a low-risk signal

Not every starttls-not-supported result means the domain is unsafe. Some senders simply haven’t updated their mail servers since pre-2015 standards—when TLS wasn’t widely required. If you're sending to a regional partner, a public-sector agency, or a nonprofit with minimal IT resources, it’s common for them to lack encryption. These domains often still deliver consistently, even without encryption.

Let’s say you’re sharing a contract with a local government office. Even without TLS, their email works. It’d be counterproductive to block messages based on an outdated security flag alone. Instead, consider logging such domains for awareness and route messages through a compliant relay when needed.

When to flag or quarantine

However, if the domain is known for poor security hygiene—like a high-volume marketing service that frequently appears in spam reports—then starttls-not-supported is a warning sign. Combined with other red flags (e.g., low sender reputation, inconsistent MX records), it suggests a high-risk recipient.

For essential recipients, use a trusted relay—like a cloud-based email service with strong TLS enforcement—to forward messages. This preserves delivery while maintaining your own encryption standards. For less critical or high-risk domains, consider quarantining messages until reviewed manually.

Use tools like inbox-placement testing to assess how messages perform in real user inboxes before sending at scale. You can also run a bulk verification on your list to flag domains with persistent TLS issues before sending.

As outlined in RFC 8314, the absence of STARTTLS support should not be treated as an automatic rejection. The decision should depend on context: relationship importance, risk profile, and operational need. The goal isn't to block everything—just to understand what you're sending.

Final take: Why TLS readiness is no longer optional in modern email delivery

Modern email delivery demands encryption as a baseline. Domains that fail to support STARTTLS are flagged by major providers as insecure, increasing the risk of rejection or delivery delays.

Without proactive verification, sending to non-TLS-ready domains leads to bounces, poor sender reputation, and lower inbox placement. These issues are not temporary — they're systemic and escalating.

By checking for STARTTLS compatibility upfront, you avoid technical debt, protect your domain’s trust score, and ensure consistent delivery across provider networks.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What is the difference between starttls-not-supported and starttls-failure?

starttls-not-supported means the receiving server never initiated TLS. starttls-failure suggests TLS was attempted but failed during handshake—often due to certificate issues or unsupported cipher suites.

Can a domain report starttls-not-supported even if it supports TLS?

Yes—if the server fails to advertise STARTTLS during the SMTP pre-connection phase, it will show as unsupported, even if TLS works under different conditions.

Do all major email providers enforce TLS-RPT reporting?

No—TLS-RPT is not mandatory. However, leading providers like Gmail and Microsoft do send reports to senders who enable reporting via DMARC policies.

How often should I test for STARTTLS support across my list?

Run checks quarterly, or before major campaigns. High-value campaigns should include verification against known TLS failure patterns.

Can MailTester detect if a recipient server lacks TLS support?

Yes—MailTester’s verification process simulates SMTP handshake behavior, including TLS negotiation. It flags domains with consistent failure patterns, helping identify non-compliant recipients.

What’s the impact of sending to domains with starttls-not-supported?

Emails may be accepted without encryption, or rejected entirely. Either way, repeated unencrypted delivery harms sender reputation and increases spam filter risk.

Is STARTTLS the same as opportunistic TLS?

Yes—opportunistic TLS is the practice of upgrading a plaintext connection to encrypted via STARTTLS when possible. If the server doesn’t support it, the connection remains unencrypted.

How do I enable TLS in Postfix?

Configure the `smtpd_tls_security_level` and `smtpd_tls_cert_file` settings, ensure certificates are valid, and restart the service. Test with `telnet localhost 25` and `STARTTLS` command.

What should I do if a domain says starttls-not-supported but delivers fine?

Monitor the domain for patterns. If only a few emails are affected, and deliverability is stable, it may be low-risk. If many domains fail, reassess your sender reputation and alignment with best practices.

Can a mail server support STARTTLS on port 587 but not 25?

Yes—some servers enable TLS only on submission ports (587) and leave port 25 for plaintext. This is common in relay or forwarding setups.

How does DMARC relate to TLS-RPT reports?

DMARC policies can specify reporting recipients for TLS-RPT data. If a domain publishes a DMARC record with `rua=`, it can receive TLS reports from receiving mail servers.

Are there free tools to test for TLS readiness?

Yes—MxToolbox, Google Admin Toolbox, and OpenSSL offer basic TLS checks. But for bulk, consistent reporting across large lists, dedicated tools like MailTester provide better insight.