What Is SMTP AUTH? Authenticated Email Submission Explained

Every time your email app asks for a username and password before it can send, you are looking at SMTP AUTH. It is the small negotiation, invisible to you, where your outgoing mail server decides whether you are allowed to send at all. Without it, anyone could hand your provider a message claiming to be from your address, and the whole system would drown in forged mail.

This guide explains what SMTP AUTH actually is, how the exchange works step by step, and the change that has confused so many people lately: why Gmail, Microsoft 365, and others switched off plain password login and now want OAuth instead. That single shift is what broke countless printers, scanners, apps, and scripts that had worked for years — and there is a supported way forward. We will keep it concrete, name the real error codes, and point to the standards themselves so you can check any claim here.

What is SMTP AUTH, in one paragraph?#

SMTP AUTH is the SMTP service extension, defined in RFC 4954, that lets a client prove its identity to a mail server before submitting a message. It works by carrying a SASL (Simple Authentication and Security Layer) exchange over the SMTP AUTH command — the server offers a set of authentication mechanisms, the client picks one, and the two swap credentials until the server accepts or rejects. RFC 4954 replaced the older RFC 2554 and gives the extension its EHLO keyword, which is simply AUTH.

The reason it exists is submission control. A separate standard, RFC 6409, splits message submission (what your client does when you hit send) from message relay (servers handing mail to each other). It states that a submission server must, by default, reject the MAIL command if the session has not been authenticated using SMTP AUTH. In plain terms: to send through your provider, you have to prove the account is yours. Receiving mail from the outside world is a different job and does not use SMTP AUTH at all.

How does SMTP AUTH work, step by step?#

The exchange rides on the connection your client already opens to submit mail, normally on port 587. First the client greets the server with EHLO, and the server lists what it supports — including an AUTH line naming the mechanisms it will accept, such as PLAIN, LOGIN, or an OAuth mechanism. The client then issues AUTH with the mechanism it wants to use.

From there, the mechanism decides the back-and-forth. Some are a single step; others use a challenge and response, where the server sends an intermediate 334 reply meaning "your turn — send the next piece." When the credential checks out, the server answers 235, authentication succeeded, and the session may now send. If it fails, you get 535, invalid credentials, and nothing goes out.

One ordering rule matters for security. RFC 4954 requires that a server not permit a plaintext password mechanism unless the session is already protected — usually by running STARTTLS first, so the credential is encrypted in transit. That is why a modern setup is TLS first, then AUTH, then send. The response codes below are the ones you will actually see in a mail log or an error dialog.

What do the SMTP AUTH reply codes mean?#

When authentication misbehaves, the server tells you why with a numeric code. These are defined in RFC 4954, and reading them turns a vague "it won't send" into a fixable problem. A 535 is the one people hit most — and it almost always means the credential itself is wrong or stale, not that the server is broken.

Why did basic auth stop working for SMTP?#

"Basic auth" here means logging in with your account username and password through a password mechanism like PLAIN or LOGIN. It worked for decades, so why did it start failing? Because a reusable password is a soft target: it can be phished, guessed, reused across sites, or stolen from a device and then replayed to send mail as you, with no second factor in the way.

To close that hole, the large providers turned password login off for third-party mail apps. Microsoft has been retiring Basic Authentication across Exchange Online, including SMTP AUTH client submission, and Google retired password-based access for third-party apps to Gmail — the setting it used to call "less secure apps." Both now steer you to OAuth. These rollouts have run in stages with tenant-level exceptions, so as of 2026 you should check the provider's own current guidance for your account rather than assume a date.

This is exactly why so many devices broke at once. Office scanners, receipt printers, backup scripts, monitoring tools, and old apps that could only speak PLAIN or LOGIN with a saved password suddenly got 535 errors overnight, because the mechanism they relied on was no longer accepted. The supported replacements are an OAuth token or, where the provider still issues them, an app password.

SMTP AUTH vs app password vs OAuth: what is the difference?#

All three still satisfy SMTP AUTH — the extension itself did not change. What changed is the credential you present and the mechanism that carries it. An app password is still a password over PLAIN or LOGIN; it just swaps your real account password for a provider-issued, single-purpose one that you can revoke without changing your main login.

OAuth is the genuinely different one. Instead of a password, your client presents a short-lived, scoped access token, carried by a SASL mechanism built for it. Google's mechanism is XOAUTH2, a vendor design that predates any standard; the standardized equivalent, OAUTHBEARER, is defined in RFC 7628 and is meant for exactly this — carrying an OAuth bearer token over protocols like IMAP and SMTP, always inside TLS. A token can be scoped to "send mail only" and revoked from the provider's dashboard without touching your password, which is the security win.

The shift, pictured#

The move from a stored password to an OAuth token is the whole story in one picture. On the left is the old model: your app keeps a password that can send mail forever until you change it. On the right is the new one: your app holds a token that is scoped to a narrow permission and expires, and that you can pull back at any time from the provider without disturbing your login.

Common misconceptions about SMTP AUTH#

Because the terms overlap, a few wrong beliefs get repeated constantly. Clearing them up saves a lot of pointless troubleshooting.

• "SMTP AUTH encrypts my email." No. Encryption in transit is TLS (STARTTLS or an implicit-TLS port). SMTP AUTH only proves who is submitting; the two work together but do different jobs.
• "OAuth means no login at all." You still authenticate — you just present a token instead of a password. The account is still proven to be yours; the credential is safer.
• "An app password is the same as OAuth." It is not. An app password is still a password over PLAIN or LOGIN. OAuth uses a scoped, expiring token over XOAUTH2 or OAUTHBEARER.
• "SMTP AUTH is needed to receive mail." No. It governs submission — sending through your provider. Servers accepting inbound mail for your domain over the relay path do not use it.
• "Turning on SMTP AUTH stops spam reaching me." It stops other people sending as you, which protects your reputation. It does nothing about junk arriving in your inbox — that is inbound filtering.

How SMTP AUTH shows up in AI Emaily#

AI Emaily is an email client, not a mail server — it authenticates to your provider's submission server the same way any client does. We build AI Emaily, so here is how it handles the shift this article describes. When you connect a Gmail or Microsoft 365 account, it uses the OAuth path: you approve access on Google's or Microsoft's own consent screen, and AI Emaily keeps a scoped token rather than your password. For a standard IMAP mailbox that still uses a password mechanism, it accepts an app password instead.

Either way, those credentials are envelope-encrypted at rest and never written to a log in plain text, so the thing that authenticates your sending is not sitting around as reusable text. What AI Emaily does not do is run SMTP for you or replace your provider. It sits on top of the mail server you already have to triage your inbox and draft replies, and in its default Copilot mode nothing is sent until you approve it.

The bottom line on SMTP AUTH#

SMTP AUTH is the RFC 4954 extension that proves who is submitting a message before a mail server accepts it, carried as a SASL exchange over the AUTH command and required by default for submission under RFC 6409. It is about sending, not receiving, and it is separate from the TLS that encrypts the connection.

The change everyone felt is not in the extension but in the credential. Passwords over PLAIN and LOGIN are being retired at Gmail and Microsoft 365 in favor of OAuth tokens, which is what broke old printers and scripts and what an app password or an OAuth connection now fixes. When something fails, read the reply code — a 535 means the credential is wrong or expired, and the path forward is almost always OAuth or a fresh app password.