SMTP authentication is how a mail client proves to a mail server that it is allowed to send. It happens during the SMTP conversation using the AUTH command, with mechanisms such as PLAIN, LOGIN, CRAM-MD5, and XOAUTH2. It is separate from SPF, DKIM, and DMARC, which authenticate the message rather than the sender's connection.
The distinction that trips everyone up
Two completely different things share the word "authentication" in email, and confusing them wastes hours of debugging.
SMTP AUTH is connection-level. It answers: is this client permitted to hand mail to this server? It uses a username and password (or a token) and happens before the message is transmitted. Get it wrong and you see a 535 error.
Domain authentication — SPF, DKIM, DMARC — is message-level. It answers: does this message legitimately come from the domain it claims? It uses DNS records and cryptographic signatures, and it is evaluated by the receiving server. Get it wrong and your mail still sends, it just lands in spam.
You need both. SMTP AUTH gets your message accepted by your relay; domain authentication gets it accepted by the recipient's inbox.
The mechanisms, compared
| Mechanism | How it works | Security | Use it? |
|---|---|---|---|
| AUTH PLAIN | Sends username and password base64-encoded in one string | None on its own; safe only inside TLS | Yes, over TLS. Most common today. |
| AUTH LOGIN | Same credentials, exchanged in two base64 steps | Identical to PLAIN — base64 is encoding, not encryption | Yes, over TLS. Widely supported legacy option. |
| CRAM-MD5 | Server sends a challenge; client returns an MD5 HMAC | Password never crosses the wire, but MD5 is dated | Only if a legacy system requires it |
| DIGEST-MD5 | Richer challenge-response with nonces | Better than CRAM-MD5, largely deprecated | No |
| SCRAM-SHA-256 | Modern salted challenge-response | Strong, resists replay | Yes where supported; still uncommon |
| XOAUTH2 | Passes an OAuth 2.0 bearer token instead of a password | Strongest; tokens are scoped and revocable | Required by Google and Microsoft for user mailboxes |
The practical takeaway: base64 is not security. AUTH PLAIN and AUTH LOGIN are perfectly acceptable in 2026 because the connection underneath them is encrypted with TLS. Without TLS, both hand your password to anyone on the network path.
How the handshake actually looks
Connect on port 587, and the conversation runs roughly like this:
- Client opens the connection; server replies
220with its greeting. - Client sends
EHLO yourdomain.com. - Server lists capabilities, including
250-STARTTLSand250-AUTH PLAIN LOGIN. - Client sends
STARTTLSand the connection is upgraded to encrypted. - Client re-sends
EHLO— required, because the capability list can change after TLS. - Client sends
AUTH PLAINwith credentials. Server replies235 Authentication successful. MAIL FROM,RCPT TO,DATA, message body,.,QUIT.
Notice that many servers only advertise AUTH mechanisms after TLS is negotiated. If your client reports "no supported authentication mechanism," the usual cause is that it never completed STARTTLS.
Ports and encryption modes
| Port | Mode | Recommendation |
|---|---|---|
| 587 | STARTTLS — plain connection upgraded to TLS | The standard submission port. Use this. |
| 465 | Implicit TLS — encrypted from the first byte | Also fine, and formally re-recognized. Use if 587 is blocked. |
| 25 | Server-to-server relay | Do not use for authenticated submission. Widely blocked by ISPs. |
| 2525 | Non-standard alternative | Fallback only, when a host blocks 587 and 465. |
If you are choosing a port for an application, start at 587 and fall back to 465. Our guide to SMTP relay services covers the connection settings side in more depth.
OAuth 2.0 has replaced passwords at the big providers
Google and Microsoft have both retired basic username-and-password SMTP authentication for standard user accounts. If you are connecting an app to a Gmail or Microsoft 365 mailbox, you now need either XOAUTH2 or a provider-issued app password where one is still offered.
The XOAUTH2 flow: register an app with the provider, request the mail send scope, have the user consent, receive an access token and a refresh token, then pass the access token in the AUTH XOAUTH2 string. Access tokens expire — typically within an hour — so your code must refresh them automatically and retry on a 535.
This is a real improvement. Tokens are scoped to a single capability, revocable from the account owner's side, and useless if leaked after expiry. But it also means "just put the password in the config file" is no longer a viable pattern for those providers.
Reading the error codes
- 535 Authentication failed — wrong credentials, an expired token, or an account that requires OAuth. Check the exact username string; many services want the full email address, not the local part.
- 530 Authentication required — you tried to send before authenticating, or before STARTTLS.
- 504 Unrecognized authentication type — you offered a mechanism the server does not support. Re-read the EHLO response.
- 454 Temporary authentication failure — usually rate limiting or a backend hiccup. Retry with backoff.
- Connection timeout on 587 — a firewall or hosting provider is blocking outbound submission. Try 465 or 2525.
Getting it right in production
- Never hardcode credentials. Use environment variables or a secrets manager, and keep them out of version control.
- Use per-application credentials. One key per service means you can revoke one without breaking everything else, and your logs tell you which app misbehaved.
- Verify TLS certificates. Disabling certificate validation to "fix" a connection error removes the entire protection that makes AUTH PLAIN safe.
- Reuse connections. Authenticate once and send multiple messages on the same session rather than reconnecting per email.
- Handle token refresh centrally if you use XOAUTH2, so every sending path shares one refresh mechanism.
- Rotate credentials on a schedule and immediately if a machine is decommissioned.
Authentication is necessary, not sufficient
Successful SMTP AUTH means your relay accepted the message. It says nothing about whether Gmail will put it in the inbox. That depends on SPF alignment, a valid DKIM signature, a DMARC policy, your complaint rate, and your sending history — the message-level layer.
Both layers should be handled for you by a competent provider. IGSendMail configures SPF, DKIM, and DMARC automatically when you set up a sending domain, so the only thing you manage in your application is the SMTP credential itself. If you want to understand what happens after your message leaves the relay, our guide to email deliverability covers the receiving side.
Frequently asked questions
What is the difference between SMTP authentication and SPF or DKIM?
SMTP AUTH proves a client is allowed to connect and submit mail to your outbound server. SPF and DKIM prove to the recipient's server that the message genuinely came from your domain. They operate at different points in the journey.
Is AUTH PLAIN secure?
Only inside an encrypted connection. Base64 encoding is trivially reversible, so AUTH PLAIN over an unencrypted link exposes your password. Over TLS on port 587 or 465, it is standard practice.
Why do I get a 535 error with correct credentials?
Common causes are a provider that has disabled basic authentication and now requires OAuth, an expired access token, a username that needs to be the full email address, or an account requiring an app-specific password.
Should I use port 587 or 465?
Start with 587 using STARTTLS. Use 465 with implicit TLS if 587 is blocked by your host or network. Both are secure when TLS is actually negotiated.
Do I need OAuth for SMTP?
You do for Gmail and Microsoft 365 user mailboxes. Dedicated sending platforms typically issue API keys or SMTP credentials that work with AUTH PLAIN over TLS, which is simpler for application sending.
Want SMTP that just works, with SPF, DKIM, and DMARC configured for you and 99% inbox deliverability behind it? Get started with IGSendMail.