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.
How it connects to other RFCs
RFC 4954 obsoletes RFC 2554 (the original SMTP AUTH specification). It works with RFC 5321 (SMTP base protocol) and RFC 3207 (STARTTLS), since credentials should only be sent over an encrypted connection. RFC 6409 (submission port 587) requires SMTP AUTH for client connections.
Current status
RFC 4954 is the current SMTP AUTH standard, published July 2007. It is implemented by all major MTAs and mail submission servers. The PLAIN and LOGIN mechanisms it supports should only be used over TLS-encrypted connections per RFC 8314.
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.
Where you see AUTH in practice
SMTP AUTH is what makes port 587 (message submission) work. Every email client that sends mail on your behalf, from Thunderbird to Apple Mail to the Gmail app, authenticates via SMTP AUTH before transmitting. On the server side, Postfix uses Dovecot SASL or Cyrus SASL to authenticate against a user database; Exim has its own authenticator framework. If SMTP AUTH fails or is misconfigured, users see “550 authentication required” or “535 authentication failed” errors, both of which trace back to RFC 4954 semantics.
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) |
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 | Strong; delegated auth via OAuth | Gmail, Microsoft 365, modern IMAP+SMTP clients |
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
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 |
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. 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.
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.
About 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.
