ProbeKit
Sign inSign up

SMTP 538: encryption required for this AUTH method

538Encryption required for requested authentication mechanismPermanent: retrying will not help

Typical wording
538 5.7.11 Encryption required for requested authentication mechanism

What it means

RFC 4954 defines 538 with enhanced code 5.7.11 as "Encryption required for requested authentication mechanism". The client asked to authenticate with a mechanism, usually PLAIN or LOGIN, that sends the password in a reversible form, and the server will not allow that on a plain connection.

The fix is almost always to run STARTTLS first (or use implicit TLS on port 465) and then authenticate. Many servers avoid sending 538 by simply not advertising PLAIN and LOGIN until TLS is active, so 538 tends to show up with older or unusual clients that ignore the EHLO list.

It differs from 530 with STARTTLS wording, which refuses everything until TLS, and from 534, which refuses the mechanism even with encryption. 538 is narrow: same mechanism, but over TLS.

Likely causes

  • The client has TLS turned off or set to "none" while using PLAIN or LOGIN authentication.
  • A STARTTLS failure was ignored by the client, which then carried on without encryption and tried to log in.
  • A device sends AUTH immediately after EHLO without checking whether STARTTLS is required.
  • A proxy or antivirus product strips STARTTLS from the server’s EHLO reply.

How to fix it

  1. Set the client to "STARTTLS" on port 587 or "SSL/TLS" on port 465.
  2. If TLS fails, find out why first (certificate trust, old TLS versions, an intercepting proxy) instead of turning it off.
  3. Remove any security software that rewrites SMTP traffic, or exclude the mail server from inspection.
  4. Retest and confirm the log shows STARTTLS, a second EHLO, and then a 235 success reply after AUTH.

Checks that apply

  • SMTP Diagnostics Verifies STARTTLS works and shows the certificate, so you can turn encryption on in the client without hitting a trust error.
  • TCP Port Test Tests port 465 for implicit TLS as an alternative when STARTTLS on 587 is blocked.
See the example diagnosed

The classification runs without network lookups and we never store your paste.

FAQ

Is it safe to switch to a plain text login to avoid 538?
No. The server is protecting your password; use TLS instead of looking for a mechanism it accepts without encryption.
Why does my client not get 538 on another server?
That server probably accepts PLAIN without TLS or hides it until STARTTLS; policies differ.

All 191 bounce codes