SMTP response received
550 Must issue a STARTTLS command firstYou received this code because the receiving mail server refused delivery because your sending MTA transmitted mail commands over an unencrypted connection. The receiver requires STARTTLS negotiation before accepting any MAIL FROM or RCPT TO. This is a permanent policy rejection on the sender side, not the receiver: your outbound configuration must upgrade the connection to TLS before sending mail commands. Gmail, Yahoo, and Microsoft have progressively hardened this requirement since 2024, and receivers now uniformly reject cleartext SMTP conversations from bulk senders. See our full SSL/TLS for email setup guide for the surrounding infrastructure (MTA-STS, DANE, TLS-RPT).
๐ In this guide
๐ค Who sees this code
- Operator of a self-hosted Postfix, Exim, or Sendmail server whose outbound mail suddenly bounces at major receivers
- Deliverability lead investigating a rise in 550 rejections coinciding with Gmail-Yahoo bulk sender enforcement (2024+)
- Ops team debugging a legacy sending pipeline that predates opportunistic TLS becoming universal in mainstream MTAs
๐ง What this guide fixes
- Confirm whether your sending MTA offers and uses STARTTLS on outbound connections
- Enable STARTTLS with a valid TLS certificate at the sending server
- Verify the fix with openssl and confirm the next send succeeds at Gmail, Outlook, and Yahoo
โก Do these 3 things first (before diving deeper)
Capture the exact SMTP conversation between your sender and the receiver
The 550 Must issue STARTTLS response comes from the receiver in the SMTP dialogue at exactly the point your MTA sent MAIL FROM without first issuing STARTTLS. Enable verbose SMTP logging on your outbound server temporarily and reproduce a failing send. In Postfix: smtp_tls_loglevel = 2 logs the full negotiation. The log shows whether your MTA issued STARTTLS after EHLO or went straight to MAIL FROM in cleartext. That decision point identifies your side of the fix. Same instrumentation is available in Exim via tls_log_certificate_verification.
Test STARTTLS support at the receiver with openssl
Confirm the receiving server actually offers STARTTLS by running openssl s_client -starttls smtp -connect mx.example.com:25 -crlf. A successful handshake with certificate details proves the receiver supports STARTTLS per RFC 3207 and expects you to use it. If openssl succeeds but your MTA still gets the 550, the problem is your MTA configuration, not the receiver or the network path. This test also surfaces certificate issues at the receiver, which are their side but useful context if you contact their postmaster.
Check your outbound MTA STARTTLS policy configuration
Every mainstream MTA has a configuration directive controlling whether outbound connections attempt STARTTLS. In Postfix: postconf smtp_tls_security_level. If it returns "none", you never upgrade. In Exim: check the transport tls_certificate and hosts_require_tls settings. In Sendmail: check the confSTARTTLS options. A configuration audit at this stage tells you exactly what to change.
Common causes of 550
- STARTTLS disabled by policy on your outbound MTA. Postfix installations with
smtp_tls_security_level = none(or unset on old defaults) never attempt STARTTLS even when the receiver advertises it in EHLO. The MTA proceeds directly to MAIL FROM in cleartext, hits the receiver TLS enforcement, and gets 550 Must issue STARTTLS. This is by far the most common cause on legacy self-hosted servers that predate opportunistic TLS becoming universal in Postfix 3.0+ (2015). If your Postfix version is 2.x or your configuration was carried forward from that era, this is almost certainly your cause. - Missing or invalid TLS certificate on the sending side. Some MTAs decline to negotiate STARTTLS if they have no valid certificate to present. Others try but fail the handshake because the receiver rejects the certificate. Either failure mode falls back to cleartext, which then triggers the 550. Confirm your sending server has a valid certificate for its hostname, and that the hostname in the certificate matches the reverse DNS of the sending IP: mismatch between certificate CN, EHLO hostname, and PTR record is a frequent quiet failure. See our 550 5.7.25 PTR reverse DNS for the exact FCrDNS setup steps, and our SSL/TLS for email setup for the certificate side.
- Outbound firewall blocking or inspecting the TLS handshake. STARTTLS begins on port 25 (or 587 for submission) after EHLO, per RFC 3207. Some restrictive firewalls inspect SMTP traffic and interfere with the STARTTLS upgrade, either stripping the STARTTLS advertisement from the receiver EHLO response or blocking the subsequent handshake. This is common in legacy corporate networks with SMTP proxies. Symptoms: intermittent 550 rejections that correlate with specific outbound network paths but not others. Test by sending from a machine outside the corporate proxy path with the same MTA configuration.
- Very old MTA software without STARTTLS support. Sendmail versions before 8.11 (2001) and other legacy MTAs may not implement STARTTLS at all. If your sending stack runs on hardware and software that has not been updated in over a decade, you may need to modernize the MTA before you can even attempt TLS. Extreme cases: some embedded systems, industrial controllers, or old print-server appliances send mail through a fossilized minimal SMTP client. The pragmatic fix is to route their mail through a modern Postfix relay that speaks STARTTLS on their behalf rather than upgrading the legacy stack in place.
- Receiver enforcing STARTTLS as part of Gmail-Yahoo bulk sender rules (2024+). Since February 2024, Gmail and Yahoo require encrypted TLS connections for senders shipping 5,000+ messages per day. Microsoft applies similar policy on high-volume connections; see our 550 5.4.1 Office 365 for the Microsoft side. A sender that used to get through with occasional cleartext connections now sees consistent 550 Must issue STARTTLS on every message once volume crosses the threshold. This is enforcement of a policy that always existed, not a brand-new requirement. The fix is the same: enable STARTTLS on your outbound side, plus the broader authentication story in 550 Anti-spoofing policy.
How to fix 550, step by step
- Enable opportunistic STARTTLS in Postfix. Add or change these lines in
/etc/postfix/main.cf:smtp_tls_security_level = mayandsmtp_tls_loglevel = 1. The "may" level uses STARTTLS when the receiver advertises it and falls back to cleartext when it does not, which is the right default for general outbound. Reload Postfix withpostfix reload. Send a test message and inspect the log for "Trusted TLS connection established" or equivalent success wording. See our full Postfix guide for the surrounding TLS parameters (smtp_tls_CAfile, smtp_tls_note_starttls_offer, DANE opt-in). - Enable STARTTLS in Exim. In the smtp transport of
/etc/exim/exim.conf(or split-configuration equivalent), ensuretls_certificate = /etc/ssl/mail/cert.pemandtls_privatekey = /etc/ssl/mail/key.pempoint at your certificate. Addhosts_try_dane = *andtls_verify_certificates = systemto the main configuration to opt into DANE verification. Restart Exim and test outbound to a Gmail address that was previously bouncing. Our Exim guide covers the router/transport separation in detail. - Install a valid TLS certificate. Use certbot with Let's Encrypt to issue a certificate for your sending hostname:
certbot certonly --standalone -d mail.yourdomain.com. The hostname on the certificate must match what your MTA presents in EHLO and match the reverse DNS of the sending IP. Certbot automates renewal every 60 days; make sure the auto-renewal cron or systemd timer is enabled or your MTA will start failing STARTTLS again in 90 days. Reload the MTA after each renewal. Full certificate lifecycle and validation approaches are in our SSL/TLS for email setup. - Verify STARTTLS works end-to-end from the command line. From your outbound server:
openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -crlf. This should succeed with a valid Gmail certificate returned. Then verify your own inbound STARTTLS from an external tool: check-tls.email runs a broader battery, and Google Admin Toolbox has a specific SMTP TLS test. All should show STARTTLS negotiation succeeding and the certificate validating. Also test with swaks for a full envelope:swaks --to test@gmail.com --server gmail-smtp-in.l.google.com --tls. Reference protocol behavior in RFC 3207. - Publish MTA-STS policy on your inbound side. For your own inbound side, publish an MTA-STS policy that instructs other senders to use TLS with your domain. This is separate from the 550 you are fixing but complements the story: full TLS coverage in both directions signals a mature sender. Publish a
_mta-sts.yourdomain.comTXT record and a policy file athttps://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Full record structure, policy syntax, and validation flow are in our SSL/TLS setup guide. - Enable SMTP TLS Reporting (TLSRPT) for ongoing visibility. Publish a
_smtp._tls.yourdomain.comTXT record withv=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com. Receivers with TLSRPT support (Google, Microsoft, others) send daily aggregate reports about TLS negotiation success and failure rates for mail to your domain. This catches regressions in your TLS posture weeks before they surface as delivery incidents. Parse the reports weekly and alert on any successful-session count that drops below your baseline. Cross-reference with your Authentication-Results headers at receivers to correlate TLS failures with auth outcomes.
๐ How each provider sends this exact code
โ How this code differs from adjacent ones
530 5.7.0421 4.7.0554 5.7.3Prevention going forward
The 550 Must issue STARTTLS error is a policy fault line: receivers have moved fast toward mandatory TLS, and senders that never audited outbound TLS posture see it silently. Preventing recurrence means treating outbound STARTTLS as monitored infrastructure, not a set-and-forget setting.
- Audit outbound STARTTLS quarterly by sending test mail to a monitored inbox at Gmail, Microsoft, and Yahoo. Parse the Authentication-Results header in each delivered message: all three should show TLS negotiation success. If any receiver shows plaintext delivery, your MTA policy has regressed.
- Publish TLSRPT records for your sending domains and process the aggregate reports weekly. Reports catch STARTTLS failures across receivers before they become visible bounces. Full TLSRPT setup in our SSL/TLS setup guide.
- Automate certificate renewal for the certificate your MTA presents. Certbot auto-renewal plus a monitoring check that the certificate has more than 30 days remaining validity prevents expiry-driven regressions.
- When migrating between servers or MTAs, verify STARTTLS is enabled on day one of the new stack. New Postfix installations default to
smtp_tls_security_level = mayin versions 3.0+, but restored configurations from older setups may carry forward "none" as an explicit setting. - Complement TLS with strong authentication: publish SPF, DKIM, and DMARC records with proper alignment. Receivers combine TLS presence with authentication verdicts in their overall trust signal, so a TLS fix alone leaves the other half of the deliverability story on the table.
Frequently asked questions about 550
What is the difference between STARTTLS and implicit TLS on port 465?
Does STARTTLS make my mail end-to-end encrypted?
Why does Gmail reject my plaintext connections now when it used to accept them?
How does MTA-STS relate to STARTTLS?
Should I use smtp_tls_security_level = may or encrypt in Postfix?
How do I test STARTTLS from the command line?
openssl s_client -starttls smtp -connect mx.example.com:25 -crlf. A successful handshake returns the receiver certificate and a "250 Ok" response after the TLS negotiation completes, matching the extension defined in RFC 3207. Common failures: connection refused (firewall), no STARTTLS advertised (receiver does not support it or your network strips it), certificate validation error (receiver has a bad cert but the connection succeeds anyway for testing). Also useful: swaks --to test@example.com --server mx.example.com --tls exercises the full envelope including MAIL FROM and RCPT TO, closer to what your actual sending stack does.Stop 550 bounces before they happen.
SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes before you send. Fewer bounces means less firefighting and a healthier sender reputation. 13 validation types, 25 free daily, no card required.
๐ Deep dive on related codes
550 5.4.1Office 365 tenant policyRecipient address rejected at Microsoft โ auth or reputation cause
550 5.7.1Relaying deniedSender-side SMTP AUTH failure โ fix your outbound config
550 5.7.606Microsoft IP banPermanent Microsoft ban with mitigation form
550 5.7.25PTR reverse DNS missingFCrDNS setup coordination with hosting provider
About the Author
Alaa ยท LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. Iโve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
