SMTP AUTH Methods Explained: PLAIN, LOGIN, CRAM-MD5, SCRAM and OAuth 2.0 (XOAUTH2)

When an application logs in to an SMTP server it does not simply send a user name and password. It uses a named mechanism from the SMTP AUTH extension, such as PLAIN, LOGIN, CRAM-MD5, SCRAM-SHA-256 or XOAUTH2. The server announces which mechanisms it accepts, the client picks one it supports, and the two exchange a short sequence of messages. Most of the time a library hides all this and you only enter a user name and password. But the mechanism explains many puzzling errors: "authentication mechanism not supported", a login that works in one tool and fails in another, a provider that suddenly rejects the password you have always used, and the question of whether sending a base64-encoded password is safe. This guide explains how SMTP authentication works, what each mechanism does, how they compare on security, how to see which ones your server offers, and how to choose and troubleshoot.

How SMTP AUTH works

The mechanism list comes from the server's reply to EHLO. A line such as 250-AUTH PLAIN LOGIN XOAUTH2 says that the server accepts these three. Many servers only show the line after the connection has been encrypted, so check again after STARTTLS. The client then sends AUTH followed by the mechanism name and, depending on the mechanism, an initial response. The server may reply with a 334 challenge containing base64 data, the client answers, and the server finishes with 235 Authentication successful or a failure such as 535. The framework is defined in RFC 4954, and each mechanism has its own specification. After a successful login the client sends MAIL FROM, and so on. If it tries to send without authenticating, the server answers with a 530 reply; see SMTP 530 5.7.0.

The mechanisms

PLAIN

PLAIN (RFC 4616) sends the user name and password in a single step, in the form authorization-id NUL user NUL password, base64-encoded. It is the simplest mechanism and the one that nearly every server and library supports. It is secure only if the connection is encrypted, because base64 is an encoding, not encryption: anyone who can read the traffic can decode it in one command. That is why a correct client refuses to send PLAIN credentials before TLS is active.

LOGIN

LOGIN is an older, non-standard mechanism that sends the user name and the password in two separate base64 responses to two prompts. It carries the same security properties as PLAIN and is used for compatibility, mostly with Microsoft products and older clients. Where both are offered, PLAIN is the cleaner choice; if only LOGIN is offered, use it over TLS.

CRAM-MD5

CRAM-MD5 (RFC 2195) is a challenge-response mechanism. The server sends a random challenge, and the client replies with a keyed hash (HMAC-MD5) of it, so the password is never sent over the connection. In its day it was a good way to avoid sending passwords in clear on unencrypted links. Today it has drawbacks: the server must store the password in a form that lets it compute the same hash, MD5 is considered weak, and it gives no protection for the message itself. Many providers have dropped it. Do not choose it as a primary mechanism for new work, and do not rely on it as a replacement for TLS.

SCRAM-SHA-1 and SCRAM-SHA-256

SCRAM (RFC 5802, with SHA-256 in RFC 7677) is a modern challenge-response mechanism. The client proves it knows the password without sending it, the server stores a salted, iterated hash instead of the password, and each side verifies the other. It is a better design than CRAM-MD5. Support among SMTP servers and client libraries is thinner than for PLAIN, so check both ends before you depend on it. Even with SCRAM, use TLS.

XOAUTH2 and OAUTHBEARER

OAuth 2.0 mechanisms replace the password with an access token. The client first obtains a token from the provider's identity service using an authorised application, then sends it in the SMTP AUTH command. XOAUTH2 is the vendor format used by Google and Microsoft; OAUTHBEARER (RFC 7628) is the standard format. Tokens are short-lived and can be limited to a scope, and the user can revoke access without changing a password, which is why large providers prefer them for mailbox accounts and have restricted basic authentication on some account types. The cost is complexity: you must register an application, handle consent, refresh tokens and store them safely. For a sending service that gives you SMTP credentials or API keys, you normally do not need OAuth. For mailbox providers that require it, a library that supports the flow saves a lot of effort. See Microsoft 365 SMTP settings and Gmail SMTP settings for provider-specific details.

Comparison

The practical conclusion is short. Whatever mechanism you use, send credentials only inside TLS. With TLS in place, PLAIN and LOGIN are acceptable for credentials that are dedicated to sending and can be rotated. The mechanism matters less than whether the credential is limited in scope (an API key or an app password for sending only, not your personal password) and whether you rotate it. See API key security and rotation and how encryption in transit works.

See what a server offers

openssl s_client -starttls smtp -crlf -connect smtp.example.com:587
EHLO test.example.com
# look for a line like: 250-AUTH PLAIN LOGIN

# What does an AUTH PLAIN string look like?
printf '\[email protected]\0your-password' | base64

# swaks shows each step and lets you choose the mechanism
swaks --server smtp.example.com --port 587 --tls \
  --auth PLAIN --auth-user [email protected] --auth-password 'your-password' \
  --to [email protected] --from [email protected]

The base64 example shows why PLAIN needs TLS: the result decodes straight back to the user name and password. Do not paste real passwords into shared terminals or tickets, and rotate any credential you expose. More test methods are in how to test an SMTP connection.

Errors and what they mean

One subtle cause deserves a note: the user name. Some servers expect the full email address, others only the local part, and cloud services may use a fixed identifier such as an API user. If the password is right and authentication still fails, try the exact form your provider documents. Another is the character set: a password with non-ASCII characters can be encoded differently by different clients. Prefer generated credentials with plain characters.

Choosing a mechanism

1. Use whatever your provider documents. For a sending service, that is nearly always PLAIN or LOGIN over TLS, with credentials created for sending.
2. Let the library negotiate. Mainstream libraries pick a supported mechanism in a safe order, and a hard-coded mechanism creates failures when the server changes.
3. Insist on TLS before AUTH. Configure "STARTTLS required" or implicit TLS; never "if available" for credentials.
4. Use OAuth where the provider requires it for mailbox accounts, and keep tokens in a secrets store with expiry handling.
5. Use dedicated, least-privilege credentials and rotate them on a schedule and whenever someone with access leaves.
6. Alert on repeated failed logins from unfamiliar addresses, since credential stuffing is common against SMTP.

Server-side notes

If you run the server, advertise AUTH only after TLS has started (Postfix: smtpd_tls_auth_only = yes), limit the mechanisms to those you need, and disable anonymous and weak mechanisms through your SASL configuration (smtpd_sasl_security_options). Rate-limit failed logins, log the source address without logging passwords, and keep the SASL backend patched. The walk-through for Postfix is in configuring Postfix with SASL and TLS. For application settings that use these mechanisms, see our guides for PHPMailer, Python and Nodemailer.

References and further reading

• RFC 4954: SMTP Service Extension for Authentication
• RFC 4616: The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
• RFC 7628: A Set of SASL Mechanisms for OAuth