SMTP authentication guide: SMTP AUTH flow and fixes

SMTP authentication, often called SMTP AUTH, is the login step that proves an app, user, or service account is allowed to submit email through an SMTP server. When it is configured correctly, the server accepts the message for delivery. When it is wrong, teams see errors like 535 Authentication failed, 530 Must issue STARTTLS first, or 550 Relay denied.

For product teams, SMTP auth is not just a mail-server setting. It affects password resets, OTP emails, magic links, invoices, alerts, onboarding, and any release-critical message sent by an application. MailSlurp helps you test SMTP authentication safely with an SMTP tester, Email Sandbox, real inboxes, header inspection, webhooks, and deliverability checks.

Quick answer: what is SMTP authentication?

SMTP authentication is the process where an SMTP client proves its identity before submitting email. The client connects to a server, negotiates TLS when required, advertises itself with EHLO, chooses an auth mechanism such as AUTH LOGIN, AUTH PLAIN, or XOAUTH2, and then submits the message if the server accepts the credentials.

Most modern providers require SMTP AUTH on submission ports:

587 with STARTTLS for standard message submission.
465 with implicit TLS when the provider requires it.
25 mainly for server-to-server relay, not normal application submission.

If an app sends user-facing email, test the exact endpoint, port, TLS mode, credentials, sender address, and received inbox result before release.

Executive summary

SMTP AUTH lets an application or mail client submit email through an SMTP server after proving it is authorized.
Port and TLS mode matter. 587 usually expects STARTTLS, while 465 usually expects implicit TLS.
A 535 error usually points to credentials, app-password policy, disabled SMTP AUTH, or an unsupported auth mechanism.
A 530 error usually means the server requires STARTTLS before authentication.
A successful SMTP login does not prove delivery. Use MailSlurp to verify inbox receipt, headers, links, spam score, and deliverability.

SMTP AUTH flow

A typical SMTP authentication flow looks like this:

Client connects to the SMTP endpoint and port.
Server sends a banner.
Client sends EHLO.
Server advertises capabilities such as STARTTLS and AUTH.
Client upgrades to TLS when required.
Client sends EHLO again after TLS.
Client authenticates with an advertised AUTH method.
Client submits the envelope and message with MAIL FROM, RCPT TO, and DATA.
Server accepts, rejects, queues, or relays the message according to policy.

Example transcript:

S: 220 smtp.example.com ESMTP ready
C: EHLO app.example.com
S: 250-smtp.example.com
S: 250-STARTTLS
S: 250-AUTH LOGIN PLAIN
C: STARTTLS
S: 220 Ready to start TLS
C: EHLO app.example.com
S: 250-AUTH LOGIN PLAIN
C: AUTH LOGIN
S: 235 Authentication successful
C: MAIL FROM:<no-reply@example.com>
C: RCPT TO:<test@example.net>
C: DATA
S: 250 Message accepted

The second EHLO is important. Many servers advertise different capabilities after TLS is active.

SMTP auth methods

AUTH LOGIN is a common username/password exchange. The username and password are Base64 encoded, not encrypted by the auth method itself, so it should be used only inside TLS.

AUTH PLAIN

AUTH PLAIN sends an encoded credential payload in one step. It is common in application libraries and is also safe only when TLS protects the connection.

XOAUTH2 and OAuth

Some providers require OAuth-backed SMTP authentication instead of account passwords. This is common for Gmail, Microsoft 365, and other providers that restrict legacy password-based auth.

App passwords

Providers may require app-specific passwords when MFA is enabled. In that case, the normal account password can be correct for browser login but fail for SMTP submission.

SMTP auth settings checklist

Before debugging application code, verify these settings:

Setting	What to check
Host	Use the provider's SMTP submission host, not an IMAP, POP3, or webmail host.
Port	Prefer `587` with STARTTLS unless the provider requires `465`.
TLS mode	Match the port: STARTTLS for `587`, implicit TLS for `465`.
Username	Use the exact account, service account, or API username expected by the provider.
Password or token	Use the app password, SMTP password, API secret, or OAuth token required for SMTP.
Sender address	Confirm the authenticated identity is allowed to use the `MAIL FROM` and From header.
Auth mechanism	Use a mechanism the server advertises after TLS.
Domain auth	Confirm SPF, DKIM, and DMARC are valid for the sender domain.

MailSlurp's SMTP tester helps validate the handshake, STARTTLS negotiation, authentication attempt, and transcript evidence before you ship the same settings in application code.

SMTP authentication errors and fixes

Error	Likely cause	What to do
`535 Authentication failed`	Wrong password, disabled SMTP AUTH, missing app password, wrong username, unsupported auth method	Confirm credentials, app-password rules, account policy, and advertised auth mechanisms
`530 Must issue STARTTLS first`	Client tried AUTH before TLS	Enable STARTTLS or switch to the provider's secure port
`534 Authentication mechanism is too weak`	Provider blocks password-based or non-OAuth auth	Use app password, OAuth, or provider-approved SMTP credentials
`550 Relay denied`	Auth succeeded but sender or recipient relay policy rejected the message	Check allowed sender addresses, relay permissions, and domain policy
`554 Transaction failed`	Server accepted the connection but blocked the message later	Inspect headers, sender identity, content, reputation, and provider logs
Timeout before AUTH	Firewall, wrong host, wrong port, or TLS mismatch	Test the endpoint and port independently, then retry with the right TLS mode

Capture the full transcript when possible. The exact phase where the failure happens is usually the shortest path to a fix.

Port and TLS guidance

SMTP authentication depends on port and transport mode.

Port	TLS model	Best use
`587`	STARTTLS	Standard app and client submission
`465`	Implicit TLS	Provider-specific secure submission
`25`	Opportunistic TLS or relay policy	Server-to-server relay, usually not app submission
`2525`	Provider-specific alternative	Workaround when networks block common ports

If you are choosing a port, read the SMTP port decision guide and then test the selected configuration with the SMTP tester.

Gmail and Google Workspace SMTP auth

Gmail SMTP authentication often depends on account policy.

Check:

whether app passwords are required,
whether the account has MFA enabled,
whether OAuth/XOAUTH2 is required,
whether the correct server and port are used,
whether your application is allowed by workspace policy.

For implementation details, use the Gmail SMTP server guide and Gmail API overview when an API-based approach fits the application better.

Microsoft 365 and Outlook SMTP auth

Microsoft environments frequently fail because SMTP AUTH is disabled at the tenant or mailbox level.

Check:

mailbox-level SMTP AUTH status,
tenant policy for legacy authentication,
app password or OAuth requirements,
server family for the account type,
TLS expectations for the selected port,
sender permissions for shared or alias addresses.

Related guides:

How to test SMTP auth with MailSlurp

Use this workflow before shipping SMTP settings into production code.

1. Verify the connection

Use SMTP tester to check the host, port, banner, TLS negotiation, advertised capabilities, and auth response. Save the transcript when debugging provider support issues.

2. Send to a MailSlurp inbox

Send the test message to a MailSlurp inbox rather than a teammate's mailbox. That gives you a clean test address, API access to the received message, and repeatable assertions.

3. Inspect headers and sender identity

Confirm:

From and return-path domains are expected,
SPF, DKIM, and DMARC posture is healthy,
the message was not rewritten unexpectedly,
the subject and body match the release template.

4. Assert links, OTPs, and reset tokens

Use MailSlurp to parse the message and extract:

OTP codes,
magic links,
password reset URLs,
account confirmation links,
invoice identifiers,
support routing markers.

This turns SMTP auth testing into a product workflow check, not only a connection test.

5. Add deliverability and spam checks

After auth succeeds, run email deliverability testing and spam score checks. A successful SMTP login does not guarantee inbox placement.

CI release gate example

For a release-critical email flow, use this gate:

Gate	Pass condition
SMTP auth	The configured endpoint, port, TLS mode, and credentials authenticate successfully.
Inbox receipt	A MailSlurp inbox receives the message within the expected timeout.
Content assertion	Subject, body, dynamic fields, and links match the expected template.
Auth headers	SPF, DKIM, and DMARC are valid for the sending domain.
Deliverability	Inbox placement and spam score stay within team thresholds.
Regression record	The test runs in CI before sender, template, or provider changes are released.

Use Email Sandbox and Email integration testing to build this into your normal release process.

Security guidance

SMTP AUTH should be narrow and observable.

Use service accounts instead of personal mailboxes for application sending.
Store SMTP secrets in a secrets manager or deployment platform, not source code.
Rotate credentials after provider migrations or suspected exposure.
Disable unused auth methods where provider policy allows.
Avoid broad relay permissions.
Keep test credentials separate from production sending credentials.
Monitor failures by environment and message type.

The goal is controlled submission: reliable enough for customer email, narrow enough to reduce abuse risk, and observable enough to debug quickly.

FAQ

Is SMTP AUTH the same as SMTP?

No. SMTP is the protocol for email submission and transfer. SMTP AUTH is the authentication extension that lets a client prove it is allowed to submit messages through a server.

Is Base64 in SMTP AUTH encrypted?

No. Base64 is encoding only. Use TLS to protect credentials and message content in transit.

Why does SMTP auth work locally but fail in production?

Common causes include different environment variables, blocked ports, missing STARTTLS, different credentials, provider IP restrictions, or sender policy differences.

Why does SMTP auth succeed but delivery still fail?

Authentication only proves the client may submit. Delivery can still fail because of sender identity, relay scope, SPF, DKIM, DMARC, reputation, recipient policy, message content, or provider queue behavior.

Can MailSlurp test SMTP auth and inbox receipt together?

Yes. Use MailSlurp to validate the SMTP connection path, send to a real test inbox, inspect headers, parse OTPs or links, and add deliverability checks before release.

SMTP Authentication: SMTP AUTH, Login Flow, and Error Fixes