"Please turn on SMTP authentication" — what it means and the fix

"Please turn on SMTP authentication in your mail client" means the outgoing server requires the client to log in on port 587 (or 465) before accepting a message, and the client either skipped authentication entirely or offered a disabled method. This is a client configuration fault, not a recipient or reputation problem, and it blocks sending until the setting is corrected.

The exact transcript

> MAIL FROM:<you@yourdomain.com>
< 530 5.7.0 Authentication required

or, from providers that word it as plain text rather than an enhanced code:

> HELO mail.yourdomain.com
> MAIL FROM:<you@yourdomain.com>
< 550 Please turn on SMTP Authentication in your mail client, or login to
< the IMAP/POP server before sending your message

The server never reaches RCPT TO or DATA because it refuses the transaction at the authentication step. The enhanced code, where present, is 5.7.0 (authentication required) — a permanent failure for that attempt, not a deferral; the client must fix the login and try again.

Who is at fault

Sender-side, specifically the mail client's configuration. Common root causes, in order of frequency:

1. The outgoing (SMTP) server in the client is pointed at a server/port that needs auth, but "My outgoing server requires authentication" is unchecked.
2. The account uses an app-specific password or OAuth token requirement (Gmail, Microsoft 365) and the client is still sending a plain password.
3. The provider disabled basic authentication entirely — Microsoft 365 turned off SMTP basic auth for most tenants, so even a correct password fails until the account switches to modern auth or an app password.
4. Port mismatch: port 25 outbound to a consumer ISP that only authenticates on 587/465.

How the big three word it

Where this setting lives in common clients

• Outlook (desktop) — File > Account Settings > Account Settings > double-click the account > More Settings > Outgoing Server tab > check "My outgoing server (SMTP) requires authentication" and select "Use same settings as my incoming mail server," unless the provider issues a separate SMTP credential.
• Apple Mail — Mail > Settings > Accounts > select the account > Server Settings > under Outgoing Mail Server, untick "Automatically manage connection settings," then set Authentication to Password (or OAuth2 if the provider supports it) and confirm the username is filled in.
• Thunderbird — Account Settings > Outgoing Server (SMTP) > select the server > Edit > set Authentication method to "Normal password" or "OAuth2," and Connection security to STARTTLS on port 587.
• Mobile clients (iOS/Android native mail apps) — the outgoing server fields are usually hidden under "Advanced" or "SMTP server" in the account's manual setup screen; a quick re-add of the account using the provider's official app (Gmail app, Outlook app) often resolves this faster than hunting for the manual field, because the app handles OAuth automatically.

In every case the two settings that matter are: authentication turned on for the *outgoing* server specifically (incoming IMAP/POP authentication being correct does not imply outgoing SMTP is configured the same way), and a password or token type the provider still accepts.

Diagnostic commands

Test whether the server demands auth and which mechanisms it advertises:

openssl s_client -connect smtp.yourprovider.com:587 -starttls smtp

After EHLO, look for the 250-AUTH line:

250-smtp.yourprovider.com at your service
250-AUTH LOGIN PLAIN
250 STARTTLS

If AUTH is listed but your client isn't sending credentials, the client configuration is the fault, confirmed.

Ordered fix

1. In the mail client's outgoing/SMTP server settings, enable "My server requires authentication" and set it to use the same username/password as incoming mail (or a dedicated SMTP credential if the provider issues one).
2. Set the port to 587 with STARTTLS, or 465 with implicit TLS — not plain port 25.
3. If the provider is Google or Microsoft 365 and basic auth is disabled, generate an app-specific password (Google) or switch the client to modern authentication/OAuth (Microsoft 365) rather than retrying the plain password.
4. Save, then send a test message and confirm the client logs a successful 235 2.7.0 Authentication succeeded before MAIL FROM.
5. If it still fails, confirm the account itself isn't locked or flagged (password expired, MFA enforced) by logging into webmail with the same credentials.

What not to do

Do not switch the client to an unauthenticated relay or an open third-party SMTP relay to bypass this — that is how outbound mail ends up blocklisted, and most open relays reject you anyway. Do not keep retrying the same plain password against a tenant that disabled basic auth; it will never succeed no matter how many times you click send, because the server-side setting, not a typo, is blocking it. Do not store the account password directly in automation scripts as a workaround for OAuth — use an app-specific password or a proper OAuth client credential instead.

MailPilot connects to mailboxes over OAuth for Gmail and Outlook, or over authenticated SMTP/IMAP for SendGrid, Amazon SES, Mailgun, Postmark, and custom SMTP, so once a mailbox is connected correctly, authentication failures like this one are caught at setup rather than surfacing later as silent send failures.