SMTP error 538
Encryption required for the requested authentication mechanism.
Updated Jul 1, 2026
SMTP 538 (enhanced status 5.7.11, "encryption required for requested authentication mechanism") means the server refused your AUTH command because you tried to authenticate over an unencrypted connection. The fix is on the client: enable TLS before authenticating, either STARTTLS on port 587 or implicit TLS on port 465, then resend AUTH.
Enable STARTTLS on 587 or implicit TLS on 465 before AUTH.
What it means
538 carries enhanced status 5.7.11 and the text "encryption required for requested authentication mechanism". It is a permanent 5xx failure returned in response to AUTH, defined in RFC 4954 section 6. It means the server will not let you authenticate over a plaintext connection. Mechanisms like PLAIN and LOGIN send credentials in the clear, so servers refuse them unless an encryption layer is already active. One thing to know: RFC 4954 explicitly deprecates sending 538, documenting it for historical purposes only, and modern servers should instead simply not advertise plaintext mechanisms until encryption is active. If you receive a live 538, you are talking to a server using the older behavior, but the fix is the same.
Common causes
Your client or library connected on a plain port, often 25, and issued AUTH without first upgrading to TLS.
The outgoing connection is set to "no encryption" or "plain".
You connected to 587 but never sent STARTTLS before AUTH.
A handshake was attempted but failed, from an outdated TLS version or cipher, leaving the channel unencrypted when AUTH ran.
How to fix it
- Use an encrypted submission port
Port 587 with STARTTLS starts plain then upgrades to TLS before AUTH; port 465 with implicit TLS is encrypted from the first byte. Both are valid per RFC 8314, and 465 is not deprecated. Avoid plain port 25 for authenticated submission.
- Turn on TLS or SSL in your mail client
In Outlook, Thunderbird, and similar, set the outgoing SMTP encryption to STARTTLS (port 587) or SSL/TLS (port 465) rather than "none".
- Order STARTTLS before AUTH in code
Ensure your library negotiates TLS first. In Python smtplib, call ehlo, then starttls with a default SSL context, then ehlo again, then login, so encryption happens before login. In Nodemailer, use port 465 with secure set to true for implicit TLS, or port 587 with secure false and requireTLS true for STARTTLS.
- Use the correct credentials for the provider
For personal Gmail, Less Secure Apps access was removed on May 30, 2022, so use an App Password with 2-Step Verification or OAuth2. Google Workspace followed a separate later timeline, with full enforcement by May 2025. Either way, send credentials over TLS on port 587 or 465.
- If TLS is on but still failing, update your stack
The handshake may be falling back to plaintext. Update your client, library, and OpenSSL so a modern TLS version (1.2 or later) and cipher are offered, then retry. After enabling encryption and re-issuing AUTH, the login should succeed.
Paired code
A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:
Common questions
Is SMTP 538 the same as 530 5.7.0?
No. 530 5.7.0 ("authentication required" or "must issue a STARTTLS command first") means the server wants authentication or STARTTLS before accepting mail. 538 5.7.11 specifically means you tried to authenticate with a mechanism only permitted over an encrypted connection. Both are resolved by enabling TLS, but they are distinct codes.
Is SMTP 538 deprecated?
Yes. RFC 4954 documents 538 for historical purposes only and says modern servers should instead withhold plaintext mechanisms until encryption is active. A live 538 means an older server, but the corrective action, enabling TLS, is the same.
Which port fixes SMTP 538, 587 or 465?
Either works. Port 587 uses STARTTLS to upgrade the connection before AUTH; port 465 uses implicit TLS from the first byte. Both are valid per RFC 8314.