SMTP Authentication Methods Explained

Why Authenticate SMTP?

Early SMTP (RFC 821, 1982) had no authentication — any server could send mail claiming to be anyone. The AUTH extension (RFC 4954) added client authentication, letting mail servers verify that the sender is authorized to submit email. Without SMTP AUTH, open relays enable spam and abuse.

Modern submission ports (587 for STARTTLS, 465 for implicit TLS) require authentication before accepting mail. Port 25 is reserved for server-to-server relay and is blocked by most ISPs for end-user devices.

AUTH PLAIN

AUTH PLAIN sends credentials as a single base64-encoded string: \0username\0password. It is the simplest mechanism:

C: AUTH PLAIN
S: 334
C: AGFsaWNlAHNlY3JldA==   ← base64(\0alice\0secret)
S: 235 2.7.0 Authentication successful

Or in a single step:

C: AUTH PLAIN AGFsaWNlAHNlY3JldA==
S: 235 2.7.0 Authentication successful

Security note: credentials are only base64-encoded, not encrypted. Always use STARTTLS or implicit TLS before sending AUTH PLAIN — otherwise credentials are transmitted in the clear.

AUTH LOGIN

AUTH LOGIN sends username and password separately, each base64-encoded. It is slightly older than PLAIN and functionally equivalent:

C: AUTH LOGIN
S: 334 VXNlcm5hbWU6   ← 'Username:'
C: YWxpY2U=            ← 'alice'
S: 334 UGFzc3dvcmQ6   ← 'Password:'
C: c2VjcmV0            ← 'secret'
S: 235 2.7.0 Authentication successful

Like PLAIN, LOGIN requires TLS to be safe. It is deprecated in RFC 8314 but still widely supported by legacy servers.

AUTH CRAM-MD5

CRAM-MD5 is a challenge-response mechanism that never transmits the password in any form. The server sends a challenge; the client returns an HMAC-MD5 of the challenge using the password as the key:

C: AUTH CRAM-MD5
S: 334 PDExMjcuMTcwNTkzNjA2QGV4YW1wbGUuY29tPg==
  ← challenge: '<[email protected]>'
C: YWxpY2UgZDcxMzVhMWUyMjg1NjkzMGYyNWM3OTEy...
  ← 'alice ' + HMAC-MD5(challenge, password) in hex
S: 235 2.7.0 Authentication successful

CRAM-MD5 is safer for unencrypted connections but is rarely used today because TLS is the standard. MD5 is also considered cryptographically weak for new designs.

OAuth 2.0 for SMTP

Modern email providers (Gmail, Microsoft 365, Yahoo) increasingly require XOAUTH2 or OAUTHBEARER — SMTP AUTH using OAuth 2.0 access tokens instead of passwords:

C: AUTH XOAUTH2 dXNlcj1hbGljZQFhdXRoPUJlYXJlciBhY2Nlc3NfdG9rZW4B
  ← base64('user=alice\x01auth=Bearer access_token\x01\x01')
S: 235 2.7.0 Accepted

This eliminates password storage — the application only holds an OAuth access token, which can be revoked without changing the password.

STARTTLS and Implicit TLS

STARTTLS (port 587): the connection starts as plaintext SMTP, then upgrades to TLS using the STARTTLS command:

S: 220 mail.example.com ESMTP
C: EHLO client.example.com
S: 250-STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
← TLS handshake occurs here →
C: EHLO client.example.com   ← re-send EHLO after TLS
C: AUTH PLAIN ...

Implicit TLS (port 465, also called SMTPS): TLS is established immediately at the TCP connection level, before any SMTP commands. This is simpler and more secure — there is no opportunity for a downgrade attack as with STARTTLS.

Best practice: prefer port 465 (implicit TLS) for new integrations.

Common Authentication Errors

Security Best Practices

• Use implicit TLS (port 465) rather than STARTTLS where possible
• Use OAuth 2.0 / XOAUTH2 for Gmail and Microsoft 365 — these providers are deprecating password-based SMTP auth for new apps
• Store SMTP credentials in a secrets manager, never in source code
• Rotate SMTP credentials regularly and immediately on suspected compromise