SMTP Error 538

SMTP reply code 538 carries the enhanced status code 5.7.11 and the text "Encryption required for requested authentication mechanism." It is a permanent (5xx) failure returned in response to the AUTH command, defined in RFC 4954 §6. It means the server will not let you authenticate over a plaintext (unencrypted) connection.

What causes SMTP Error 538?

The server received your AUTH command (for example AUTH LOGIN or AUTH PLAIN) on a connection that is not protected by TLS. Mechanisms like PLAIN and LOGIN transmit credentials in the clear, so servers refuse them unless an encryption layer is already active. Per RFC 4954, the code signals that "the selected authentication mechanism may only be used when the underlying SMTP connection is encrypted."

Typical triggers:

• Your mail client or SMTP library connected on a plain port (often 25) and issued AUTH without first upgrading to TLS.
• Connection encryption is disabled in your client settings ("No encryption" / "Plain").
• You connected to port 587 but never sent STARTTLS before AUTH.
• A TLS handshake was attempted but failed (outdated TLS version or cipher), leaving the channel unencrypted when AUTH ran.

Note: RFC 4954 explicitly deprecates sending 538 — it is "documented here 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 that still uses the older behavior, but the corrective action is the same.

How do I fix SMTP Error 538?

The fix is on the client side — establish encryption before you authenticate. You almost never need to contact the server admin.

1. Use an encrypted submission port.
2. Port 587 with STARTTLS (the channel starts plain, then STARTTLS upgrades it to TLS before AUTH).
3. Port 465 with implicit/SSL TLS (the channel is encrypted from the first byte). Both are valid per RFC 8314; 465 is not deprecated.

4. Avoid plain port 25 for authenticated submission.

5. Turn on TLS/SSL in your mail client. In Outlook, Thunderbird, etc., set the outgoing (SMTP) encryption to STARTTLS (port 587) or SSL/TLS (port 465) rather than "None."

6. Order STARTTLS before AUTH in code. Ensure your library negotiates TLS first. Examples:

Python smtplib (STARTTLS):

import smtplib, ssl
s = smtplib.SMTP("smtp.example.com", 587)
s.ehlo()
s.starttls(context=ssl.create_default_context())  # encrypt BEFORE login
s.ehlo()
s.login(user, password)

Nodemailer (implicit TLS on 465):

const transport = nodemailer.createTransport({
  host: "smtp.example.com",
  port: 465,
  secure: true,        // implicit TLS; use false + requireTLS:true for 587/STARTTLS
  auth: { user, pass },
});

4. Use the correct credentials for the provider. For personal Gmail accounts, "Less Secure Apps" access was removed on May 30, 2022 — use an App Password (with 2-Step Verification enabled) or OAuth2. Google Workspace accounts followed a separate, later timeline: the admin-console LSA setting was removed in phases, with full enforcement (no LSA, password-only sign-in disabled) landing by May 2025. Either way, send credentials over TLS on port 587 or 465.

5. If TLS is enabled but still failing, the handshake may be falling back to plaintext. Update your client/library and OpenSSL so a modern TLS version (1.2+) and cipher are offered, then retry.

After enabling encryption and re-issuing AUTH, the login should succeed.