SMTP authentication

Why it exists

Original SMTP had no authentication. Any client could connect to any server and hand it mail for any destination, which is exactly what made large-scale spam relaying possible in the protocol's first decades.

AUTH closes that by making relay conditional on identity. A server that accepts mail from unauthenticated clients for external recipients is an open relay, and open relays are blocklisted quickly and comprehensively.

We hold our own infrastructure to that exact bar. On Nitrosend's forwarding relay, TCP 2525 is firewall-restricted to our API host, TLS and exact SMTP authentication are mandatory, and every one-recipient route snapshot is HMAC-signed. Unsigned or replayed requests, arbitrary destinations, extra recipients and multiple forwarding hops are all rejected. The relay's EC2 host sends no marketing campaigns and is not an open relay, and we put all of that in writing to AWS Trust and Safety in July 2026 when they reviewed its reverse DNS setup.

The extension is advertised in the server's EHLO response, along with the mechanisms it will accept. A client reads that list and selects one, rather than assuming.

Common ports and security

Port 587 is the submission port and expects authentication. Encryption arrives through a STARTTLS upgrade, specified in RFC 3207.

Implicit TLS runs on 465, where the connection is encrypted before any command is sent, reinstated as a recommended submission port by RFC 8314.

That leaves 25, intended for server-to-server relay rather than submission. Authenticating on it is possible but unusual, and most networks block the port outbound anyway.

Authentication before encryption is the failure to avoid. Credentials sent on an unencrypted connection are readable in transit, so a client must complete STARTTLS before issuing AUTH. Well-configured servers refuse AUTH on a plaintext connection specifically to prevent this.

Authentication methods

AUTH PLAIN and AUTH LOGIN both transmit the credential itself, base64-encoded. Encoding is not encryption, so both are only safe inside TLS. They remain the most widely supported mechanisms.

CRAM-MD5 uses a challenge-response exchange, so the password never crosses the network. It offers less benefit now that TLS is universal, and its underlying hash is dated.

XOAUTH2 carries an OAuth access token rather than a password. Google and Microsoft are both moving to it as the required mechanism, since a token is scoped, expiring and revocable in a way a password is not.

App passwords sit between the two models. They are ordinary passwords that authenticate through PLAIN or LOGIN, but are generated per application and revocable individually, which limits the damage when one leaks.

Troubleshooting common errors

A 535 means authentication failed. The credential is wrong, the account has SMTP AUTH disabled, or the provider requires an app password rather than the account password. The accompanying text is provider-specific and usually distinguishes these, so it is worth reading in full rather than treating 535 as one condition.

A 530 means the server is refusing to proceed without authentication or without encryption. Where the message references STARTTLS, the client attempted AUTH before upgrading the connection.

A 534 or 535 referencing an application-specific password means exactly that: the account has two-step verification and will not accept its own password from a mail client.

Connection failures before any authentication exchange are not AUTH problems. A hang on port 25 from a cloud host is a blocked port, and a certificate error is a TLS problem, and neither is fixed by changing credentials.

The order of diagnosis that holds up: confirm the connection opens, confirm TLS negotiates, then confirm the mechanism the server advertises matches the one the client is attempting, and only then examine the credential.

Credential lifetime is the thing to design around

The SMTP AUTH mechanisms themselves are settled and uninteresting. What changes between setups, and what actually breaks in production, is how long a credential lives and what happens when it stops living.

Long-lived secrets and short-lived tokens fail in opposite ways. Passwords keep working until somebody revokes them, so an application can quietly outlive the person whose account it borrows. Tokens expire on a schedule, so anything using one needs a refresh path or it stops at a predictable moment.

We ran into the practical version of that on our own tooling: the OAuth token minted by nitrosend login lasts about two hours, which is fine for an interactive session and completely unsuitable for a server-side application, and it is exactly why production integrations run on nskey_live_ API keys instead. The lesson generalizes directly to mail credentials. Match the credential's lifetime to the process using it, and never assume something minted for a human at a keyboard will survive an unattended job.

The other half is scope. A credential that authenticates should also constrain, and an application sending mail does not need standing access to everything an account can do. Least privilege is cheaper to apply at issue time than to retrofit after an incident.

George, our CEO, hit the sharp edge of that on our own SendGrid integration. Our Test connection probed GET /v3/verified_senders, an endpoint that requires the Sender Authentication scope, so a valid least-privilege Mail Send key 403'd and was reported invalid even though it sent fine from the customer's own CLI. He swapped the probe to GET /v3/scopes, which any valid key can read and an invalid key still fails with a 401, and the regression test runs five for five green. Least-privilege keys are the right call, but every check in the path has to be scoped as tightly as the key it is checking.

Scoping a credential correctly is exactly the kind of task that is easy to get subtly wrong by hand, ours included, per the story above. Handing the send to an AI agent through Nitrosend's MCP server removes the credential-scoping decision from the workflow: the agent connects once from inside Claude, Cursor or Codex, and there is no standing API key sitting in a script for someone to over-scope or forget to rotate.

Go deeper