SMTP Authentication (SMTP AUTH): How It Works and How to Set It Up

SMTP authentication (SMTP AUTH) is the SMTP extension, defined in RFC 4954, that makes a client prove who it is with a username and password or a token before the server accepts mail from it for relay. It is what keeps a mail server from being an open relay. It is not the same thing as SPF, DKIM or DMARC: those authenticate a message’s domain to the receiving server, while SMTP AUTH controls who may submit mail to your server in the first place. Use it on the submission ports (587 or 465), always inside TLS.

How the SMTP AUTH exchange works

The server advertises AUTH in its reply to EHLO. Per RFC 4954, “the AUTH EHLO keyword contains as a parameter a space-separated list of the names of available SASL mechanisms,” and that list “MAY change after a successful STARTTLS command.” That is why you will often see no AUTH line at all until TLS is up. The RFC also says a server “MUST implement a configuration in which it does NOT permit any plaintext password mechanisms” unless STARTTLS has been negotiated or the session is otherwise protected from snooping.

This is an example session on port 587 with placeholder hosts. C: is the client, S: is the server. Wording of the text after each code varies by server.

S: 220 smtp.example.com ESMTP
C: EHLO client.example.com
S: 250-smtp.example.com
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   ... TLS handshake; everything after this is encrypted ...
C: EHLO client.example.com
S: 250-smtp.example.com
S: 250-ENHANCEDSTATUSCODES
S: 250 AUTH PLAIN LOGIN
C: AUTH PLAIN AHVzZXJAZXhhbXBsZS5jb20AcGFzc3dvcmQ=
S: 235 2.7.0 Authentication successful

Three details matter here. The client sends EHLO a second time after STARTTLS, because the capability list can change. The base64 string is authzid NUL username NUL password, which is encoding, not encryption (RFC 4616). And a wrong password gets a reply like this instead of the 235:

S: 535 5.7.8 Authentication credentials invalid

To run this yourself with OpenSSL or swaks, see how to test SMTP authentication, which also covers building the base64 credentials. For the underlying protocol, see how SMTP works.

SMTP AUTH mechanisms compared: PLAIN, LOGIN, CRAM-MD5, SCRAM, XOAUTH2 and OAUTHBEARER

The server’s AUTH line lists SASL mechanisms. Status below comes from the IANA SASL mechanisms registry and the RFCs themselves.

Mechanism	How credentials are sent	Defined in	Status today	Use it when
PLAIN	Username and password in one base64 string, no protection of its own	RFC 4616	IANA: COMMON	Default choice, but only inside TLS
LOGIN	Username and password in two separate base64 replies	No RFC; the expired draft-murchison-sasl-login-00	IANA: OBSOLETE	A legacy client supports nothing else
CRAM-MD5	Password never sent; client answers a server challenge with a keyed MD5 digest	RFC 2195	IANA: LIMITED	Rarely; the RFC itself says MD5 “probably has a limited effective lifetime”
SCRAM-SHA-1, SCRAM-SHA-256	Salted challenge-response; password never sent	RFC 5802, RFC 7677	IANA: COMMON	Both ends support it
OAUTHBEARER	OAuth 2.0 bearer token	RFC 7628	IANA: COMMON	The provider supports it
XOAUTH2	OAuth 2.0 access token	No RFC; documented by Google and Microsoft	IANA: OBSOLETE	Gmail or Microsoft 365 requires a token

The practical rule: use PLAIN or LOGIN only inside TLS, and prefer a token mechanism when the provider offers one. RFC 4616 says PLAIN “should not be used without adequate data security protection,” and that implementations “SHOULD advertise and make use of the PLAIN mechanism only when adequate data security services are in place.” RFC 4954 adds that clients and servers “MUST implement the PLAIN SASL mechanism running over TLS,” which is why PLAIN over TLS is the interoperable baseline.

LOGIN is the odd one. Dovecot’s docs say it is “typically used only by SMTP servers to let Outlook clients perform SMTP authentication,” and its own Postfix guide enables it for that reason. The IANA registration for XOAUTH2 is flagged OBSOLETE with no RFC, yet Google and Microsoft both document it for SMTP. Google’s format is base64("user=" {User} "^Aauth=Bearer " {Access Token} "^A^A"), where ^A is Control+A, with the scope https://mail.google.com/ (Google XOAUTH2 docs). Microsoft documents the same encoding for Exchange Online (Microsoft Learn). Treat the registry flag as a statement about standards, not about what the big providers accept today.

SMTP AUTH is not SPF, DKIM or DMARC

SMTP AUTH answers “may this client send through my server?” SPF, DKIM and DMARC answer “is this message really from this domain?” They run at different points, are checked by different servers, and fail in different ways. Passing one tells you nothing about the others. A message sent through a fully authenticated session can still land in spam if the sending domain has no DKIM signature.

	SMTP AUTH	SPF, DKIM, DMARC
What it authenticates	The user or app submitting the message	The sending domain, and whether the message was authorized for it
Who checks it	Your submission server (or your provider’s)	The receiving mail server
Where it happens	During submission, before your server accepts the message	When the recipient’s server receives the message
Credential	Username and password, or a token	DNS records and, for DKIM, a signing key
What failure looks like	An error such as 535 5.7.8 to your client; nothing is sent	The recipient’s server rejects the message, sends it to spam, or flags it

For the second column, see SPF, DKIM, and DMARC.

Submission ports and TLS

AUTH belongs on the submission ports, not on server-to-server delivery. RFC 6409 reserves port 587 for message submission, and RFC 8314 says clients and servers should implement both STARTTLS on port 587 and Implicit TLS on port 465 for a transition period, and that “there is no significant difference between the security properties of STARTTLS on port 587 and Implicit TLS on port 465” when both ends require TLS. So the choice between port 587 or 465 is mostly about what your client supports. Whichever you pick, send credentials only over a TLS-protected connection, and configure the server to refuse AUTH otherwise.

Set up SMTP AUTH on your own server (Postfix with Dovecot SASL)

This is a minimal example for a server you run, using Dovecot as the authentication backend. It assumes Postfix and Dovecot are installed and users already exist in Dovecot. Every setting below comes from the Postfix SASL_README, the Postfix parameter reference, the stock master.cf and Dovecot’s Postfix SASL guide.

1. Dovecot: expose an auth socket to Postfix.

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

auth_mechanisms = plain login

2. Postfix main.cf: use Dovecot and set the relay policy.

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_relay_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination

smtpd_sasl_path is relative to the Postfix queue directory, so it works whether or not the SMTP server runs chrooted. permit_sasl_authenticated is what lets an authenticated client relay to remote recipients. You also need a server certificate for TLS; smtpd_tls_chain_files is the preferred setting in Postfix 3.4 and later.

3. Postfix master.cf: enable AUTH on the submission service only.

submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_relay_restrictions=
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Postfix documents smtpd_tls_security_level=encrypt as “mandatory TLS encryption” that rejects plaintext commands except HELO, EHLO, STARTTLS, NOOP and QUIT, and smtpd_tls_auth_only as “do not announce or accept SASL authentication over unencrypted connections.” The last two lines mirror the stock master.cf, which leaves the submission relay policy to the recipient restrictions.

Run postfix reload, then check that EHLO on port 587 shows AUTH only after STARTTLS. For port 465, the Postfix TLS docs show a submissions service with -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes. Postfix’s own warning applies to any setup: “Always set at least the noanonymous option,” which is already the default for smtpd_sasl_security_options. Once it works, confirm you did not create an open relay by following the open relay test in the SMTP test guide; the concept is explained in authenticated relay.

Configure an app or device to use SMTP AUTH

Any client needs the same five things:

• Host: your provider’s SMTP hostname (if you do not have a provider yet, see these free SMTP servers)
• Port and security: 587 with STARTTLS, or 465 with implicit TLS
• Username: usually the full email address
• Password, app password or OAuth token: whatever the provider accepts
• Sender address: often it must match the authenticated account

A minimal Python example with placeholders, using smtplib:

import smtplib, ssl
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "[email protected]"
msg["To"] = "[email protected]"
msg["Subject"] = "SMTP AUTH test"
msg.set_content("Sent with an authenticated session.")

context = ssl.create_default_context()
with smtplib.SMTP("smtp.example.com", 587, timeout=15) as s:
    s.ehlo()
    s.starttls(context=context)
    s.ehlo()
    s.login("[email protected]", "APP_PASSWORD_HERE")
    s.send_message(msg)

The Python docs say starttls() puts the connection in TLS mode and that “you should then call ehlo() again.” login() tries CRAM-MD5, PLAIN and LOGIN in that order and raises SMTPAuthenticationError when the server rejects the credentials. For implicit TLS on port 465, use smtplib.SMTP_SSL instead. More examples are in sending email from Python.

Two providers have changed what “password” means:

• Gmail: Google’s Workspace SMTP page says that since May 1, 2025, accounts no longer support apps that sign in with just a username and password, and tells you to authenticate with an app password. An app password is “a 16-digit passcode,” and “can only be used with accounts that have 2-Step Verification turned on” (Google Account Help). Google recommends Sign in with Google where an app supports it. See Gmail app passwords for the setup.
• Microsoft 365: basic authentication for SMTP AUTH is being retired in favor of OAuth. The dates change, so read Microsoft 365’s SMTP AUTH changes rather than relying on a copy here.

SMTP AUTH errors and what they mean

Codes and text below come from RFC 4954 section 6 and the IANA enhanced status codes registry.

Reply	Meaning	What to check
530 5.7.0	Authentication required	The server wants AUTH before MAIL FROM. Run STARTTLS if needed, then authenticate
534 5.7.9	Authentication mechanism is too weak	Server policy rejects the mechanism you chose. Retry with a stronger one
535 5.7.8	Authentication credentials invalid	Username, password or app password; an expired OAuth token
538 5.7.11	Encryption required for requested authentication mechanism	Start TLS first. RFC 4954 keeps this code “for historical purposes only”
454 4.7.0	Temporary authentication failure	A backend problem such as a down auth service. Retry later
504 5.5.4	Unsupported or invalid authentication mechanism	Compare your client’s mechanism with the server’s AUTH list

Many servers answer “must issue STARTTLS first” with 530 5.7.0 rather than 538, so read the text after the code. A 550 5.7.1 is a different problem: the server accepted your session but refused to relay, covered under 550 relay denied.

Frequently Asked Questions