Current standard
What this RFC defines
RFC 4954 defines the SMTP AUTH extension, which allows SMTP clients to authenticate to a submission server before sending mail. It specifies the AUTH command, the list of SASL authentication mechanisms (PLAIN, LOGIN, CRAM-MD5, etc.), and how the authentication exchange proceeds.
Where you see it in practice
When you configure your email client with your email account credentials to send mail, those credentials are verified via SMTP AUTH as defined by RFC 4954. The AUTH PLAIN or AUTH LOGIN exchange your client performs before the MAIL FROM command is the mechanism this RFC defines. ESPs that issue API credentials for SMTP submission (username + password or API key as password) are using the RFC 4954 AUTH extension. On the server side, Postfix delegates the check to Dovecot SASL or Cyrus SASL, and Exim uses its own authenticator framework. When AUTH is missing or rejected, clients see 530 (authentication required) or 535 (credentials invalid), both defined by this RFC.
SMTP authentication mechanisms
RFC 4954 obsoleted RFC 2554 and formalized SMTP AUTH as an ESMTP extension. Clients negotiate authentication by including AUTH in the EHLO exchange; the server advertises supported SASL mechanisms (PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, XOAUTH2, SCRAM-SHA-256). The client chooses one, sends credentials in the appropriate encoding, and the server accepts or rejects. Once authenticated, the session can send mail even from senders that would normally be blocked (open-relay protection), because the sender has proven identity via password or token.
Which mechanisms to use
PLAIN and LOGIN both transmit the password in Base64, which is trivially decoded; they only provide security when the session is wrapped in TLS via STARTTLS or a dedicated TLS port. CRAM-MD5 and DIGEST-MD5 provide challenge-response with better resistance to interception but are considered legacy. XOAUTH2 is the modern choice for Gmail and Microsoft 365, using OAuth 2.0 tokens instead of passwords. SCRAM-SHA-256 is the current recommendation for password-based authentication, providing salted mutual authentication. Any new implementation should target XOAUTH2 or SCRAM, not the older mechanisms.
RFC 4954 (July 2007) defines the SMTP AUTH service extension: how clients authenticate to servers during SMTP submission. Advertised as AUTH in EHLO response with a space-separated list of supported SASL mechanisms (PLAIN, LOGIN, CRAM-MD5, SCRAM-SHA-1, XOAUTH2, and others). Almost always combined with STARTTLS or implicit TLS to prevent credential interception. Obsoletes RFC 2554. Essential for message submission per RFC 4409 on port 587 and its successor RFC 6409.
RFC 4954 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Authenticate SMTP clients to servers during submission |
| Advertised | AUTH LOGIN PLAIN CRAM-MD5 XOAUTH2 in EHLO response |
| Framework | SASL (RFC 4422); RFC 4954 profiles SASL for SMTP |
| Command | AUTH mechanism [initial-response] |
| Typical ports | 587 (submission with STARTTLS), 465 (implicit TLS submission) |
| Security requirement | Must be used over TLS in modern deployments per RFC 8314 |
| Published | July 2007 (obsoletes RFC 2554) |
| Status | Proposed Standard, still current; updated by RFC 5248 (enhanced status code registry) |
Common SASL mechanisms in SMTP AUTH
| Mechanism | How it works | Security | Where used |
|---|---|---|---|
PLAIN | Sends base64(NUL + username + NUL + password) | Credentials sent in cleartext (base64 is trivially decoded); requires TLS | Most common for user-to-server submission |
LOGIN | Server prompts for base64 username, then base64 password | Same as PLAIN; requires TLS | Legacy; widely supported |
CRAM-MD5 | Challenge-response with MD5 HMAC of password | Password not sent; MD5 broken | Legacy; use SCRAM instead |
SCRAM-SHA-1, SCRAM-SHA-256 | Salted challenge-response with SHA hash | Password not sent; mutual auth; strong | Modern replacement for CRAM-MD5 |
XOAUTH2 | OAuth 2.0 bearer token instead of password (vendor mechanism defined by Google) | Strong; delegated auth via OAuth | Gmail, Microsoft 365, modern IMAP+SMTP clients |
OAUTHBEARER | Standardized OAuth 2.0 bearer token mechanism (RFC 7628) | Strong; same model as XOAUTH2 | Gmail and newer client libraries |
GSSAPI | Kerberos-based authentication | Strong; ticket-based | Enterprise Kerberos environments |
EXTERNAL | Uses TLS client certificate identity | Strong; certificate-based | Rare; specialized deployments |
AUTH PLAIN over TLS: complete dialogue
S: 220 mail.example.com ESMTP
C: EHLO client.example.net
S: 250-mail.example.com
S: 250-STARTTLS
S: 250 SIZE 52428800
C: STARTTLS
S: 220 Ready to start TLS
<<< TLS handshake >>>
C: EHLO client.example.net
S: 250-mail.example.com
S: 250-SIZE 52428800
S: 250-AUTH LOGIN PLAIN
S: 250 8BITMIME
C: AUTH PLAIN AGFsaWNlAHNlY3JldFBhc3N3b3JkMTIz
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<alice@example.com>
S: 250 2.1.0 Ok
…
The base64 blob is: NUL + “alice” + NUL + “secretPassword123”
Sent over TLS-encrypted channel, safe from eavesdropping.
Response codes specific to SMTP AUTH
| Code | Meaning | Typical cause |
|---|---|---|
235 2.7.0 | Authentication successful | Credentials verified |
334 | Server challenge (in mechanism exchange) | Multi-step mechanism awaiting client response |
432 4.7.12 | Password transition needed | Server requires password change before continuing |
454 4.7.0 | Temporary authentication failure | Auth backend unavailable; retry |
500 5.5.6 | Authentication exchange line too long | Malformed AUTH exchange |
530 5.7.0 | Authentication required | Server requires AUTH before MAIL FROM; client didn’t authenticate |
534 5.7.9 | Authentication mechanism too weak | Server refuses PLAIN or LOGIN without TLS |
535 5.7.8 | Authentication credentials invalid | Wrong username or password |
538 5.7.11 | Encryption required for requested mechanism | Client tried AUTH before STARTTLS |
Microsoft 365: the end of basic SMTP AUTH
Exchange Online is the largest remaining user of password-based SMTP AUTH (smtp.office365.com, port 587), mostly from printers, scanners and line-of-business apps. Microsoft has moved the deadline several times; the timeline it published on January 27, 2026 is:
| Date | What happens |
|---|---|
| Until December 2026 | No change: basic SMTP AUTH keeps working where it is enabled |
| End of December 2026 | Basic SMTP AUTH disabled by default for existing tenants; administrators can still turn it back on |
| Tenants created after December 2026 | Basic SMTP AUTH unavailable by default; OAuth is the supported method |
| Second half of 2027 | Microsoft announces the final removal date |
Once basic authentication is off, a client that tries it gets 550 5.7.30 Basic authentication is not supported for Client Submission. Devices that cannot do OAuth need another path, such as an IP-based connector to Exchange Online on port 25 or a third-party SMTP relay. The SMTP AUTH clients report in the Exchange admin center shows which senders still use basic authentication.
Common SMTP AUTH deployment mistakes
Related standards and further reading
- SSL/TLS Email Setup Guide: TLS paired with AUTH
- Email Protocols and Ports Guide: 587 vs 465 for authenticated submission
- Postfix Guide: SASL AUTH configuration on Postfix
Frequently asked questions
Why do I see “530 5.7.0 authentication required” when trying to send?
The server requires AUTH before accepting MAIL FROM but the client did not authenticate. Common causes: client is sending to port 25 (which typically requires no AUTH but rejects relay) or the client’s authentication step failed silently. Fix: verify the client is configured to submit on port 587 or 465 with valid credentials, and that STARTTLS or implicit TLS is enabled before AUTH.
What is the difference between “535 authentication failed” and “530 authentication required”?
530 means the server demands AUTH but the client did not attempt to authenticate. 535 means the client attempted AUTH but the credentials were rejected (wrong password, disabled account, unknown username). Fix for 530: enable AUTH in the client configuration. Fix for 535: verify username, password, and account state at the server.
Should I still use AUTH PLAIN in 2026?
Yes if paired with TLS; the combination is secure. PLAIN over TLS is functionally equivalent to a POST with a password over HTTPS. The concern is PLAIN without TLS, which leaks credentials to any network observer. If your infrastructure enforces STARTTLS or uses implicit TLS on port 465, PLAIN is fine. That said, moving to OAuth (XOAUTH2) or SCRAM-SHA-256 for new deployments provides additional defense against credential replay and phishing.
Can I use OAuth for SMTP AUTH?
Yes, via XOAUTH2 or the standardized OAUTHBEARER mechanism (RFC 7628). Instead of a password, the client sends an OAuth 2.0 bearer token in the AUTH exchange. Gmail and Microsoft 365 support this and increasingly require it for third-party clients. The token has a short lifetime (typically 1 hour) and can be revoked; even if stolen, its impact is limited compared to a static password. XOAUTH2 is the modern default for consumer mail integrations.
What does “550 5.7.30 Basic authentication is not supported” mean?
It is Exchange Online refusing a username and password on its client submission endpoint because basic SMTP AUTH is disabled for the tenant. Switch the app or device to OAuth, or, if it cannot do OAuth, send through an IP-based connector or another relay. Microsoft plans to disable basic SMTP AUTH by default for existing tenants at the end of December 2026.
Can the authenticated identity differ from MAIL FROM?
Per RFC 4954, yes. The AUTH= parameter on MAIL FROM lets a trusted submitter identify a different origin identity. Policy usually restricts this: most operators require the authenticated user to own or be permitted to send as the MAIL FROM address. Allowing arbitrary MAIL FROM after AUTH enables authenticated spam if credentials leak; enforcing alignment is a standard hardening step.
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.