SMTP AUTH mechanisms: which one to use and why

SMTP AUTH is the extension that lets a client prove who it is before submitting mail. A server advertises the mechanisms it accepts in its EHLO response, and clients pick one. The choice matters less for secrecy — TLS handles that — and more for what kind of credential you are forced to store.

What the server offers

$ openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf
EHLO test.example
250-AUTH PLAIN LOGIN XOAUTH2
250-STARTTLS

Everything in that AUTH list is available to you. Anything not in it will be refused, which is why "my client only supports CRAM-MD5" is a dead end on a modern provider.

The mechanisms, honestly compared

Two conclusions people find surprising:

PLAIN and LOGIN are the same thing. Choosing LOGIN because it sounds more secure buys nothing. Both are safe inside a TLS session and both are catastrophic outside one.

CRAM-MD5 is not an upgrade. Its single advantage — not transmitting the password — is already provided by TLS, and it imposes a real cost: the server must be able to compute the challenge response, which means storing passwords in a recoverable form rather than as salted hashes. That is a worse security posture overall.

Why OAuth is the answer where it is offered

XOAUTH2 presents an access token obtained through an OAuth consent flow. The properties that matter operationally:

• Scoped. A token can permit sending without permitting a full mailbox export.
• Revocable per application. Removing one integration does not change a password that five other systems use.
• Expiring. A leaked access token has a short useful life; a leaked password does not.
• Governable. On Google Workspace and Microsoft 365, an admin can see and control which applications hold access.

Microsoft has been phasing out basic authentication across Exchange Online, SMTP AUTH included, so for Microsoft 365 the practical answer is increasingly "OAuth or nothing" — check the current state for your tenant rather than assuming password authentication will keep working. On Google, an app password is still possible but requires two-step verification on the account and is a long-lived secret doing a job OAuth does better.

Where app passwords still make sense

A generated app password is the right tool when a client speaks only SMTP and IMAP and has no OAuth support. Rules that keep it from becoming a liability:

1. One per integration, named after it, so revocation is surgical.
2. Never in a shared document or a repository. It is mailbox access with no second factor in front of it.
3. Rotate it when anyone with access leaves.
4. Prefer OAuth the moment the tool supports it.

Reading an authentication failure

The codes tell you which half is wrong:

A 5xx here is permanent: retrying the same credentials in a loop achieves nothing and, on some providers, triggers account protections that make the real problem harder to diagnose.

Authentication is not deliverability

SMTP AUTH proves you may use a server. It says nothing about whether receivers trust your mail. Those are different mechanisms with confusingly similar names:

• SMTP AUTH — client to server, at submission time.
• SPF, DKIM, DMARC — domain-level assertions that receivers evaluate after the fact.

A perfectly authenticated session can still deliver mail that fails DMARC alignment and lands in spam. Check both: the session with openssl s_client, and the domain by reading Authentication-Results on a message you actually received elsewhere.

What not to do

• Do not pick LOGIN over PLAIN for security reasons. There are none.
• Do not seek out CRAM-MD5. It forces weaker password storage on the server.
• Do not authenticate over an unencrypted session, whatever the mechanism.
• Do not reuse one app password across tools.
• Do not retry a `535` automatically. Fix the credential; loops can lock accounts.
• Do not assume SMTP AUTH affects placement. It does not; domain authentication does.

How MailPilot helps

MailPilot authenticates over OAuth for Gmail, Google Workspace, Outlook and Microsoft 365, and over SMTP/IMAP for SendGrid, Amazon SES, Mailgun, Postmark and custom hosts where OAuth is unavailable. Connection problems are surfaced at setup rather than mid-warm-up, and the domain-level half — SPF, DKIM and DMARC alignment — is checked separately, alongside per-provider placement measurement and daily reputation tracking.