SMTP Authentication Error: Causes and How to Fix It

An SMTP authentication error means the outgoing mail server rejected your login: it does not accept the username and password your client presented, so it refuses to send the message. The two codes you see most often are 535 5.7.8 (username and password not accepted) and 530 5.7.0 (authentication required). Almost every case comes down to one of four things: a wrong username or password, using an account password where an app password is required, SMTP authentication being switched off on the account, or the wrong port and encryption. The fix is to connect with credentials the server accepts, on a port that supports authentication.

What an SMTP authentication error means

An SMTP authentication error is the outgoing mail server refusing your login: it received a username and password through the AUTH command, did not accept them, and dropped the message instead of relaying it. It is a failure of identity, not of permission to reach a recipient.

Before a server relays your mail, it wants to know who you are. When your client opens an SMTP session, it issues an AUTH command and hands over a username and password. If the server accepts them, sending proceeds. If it does not, it returns an authentication error and drops the message rather than forwarding it. This is a question of identity: you are proving who you are, not whether you are allowed to relay to a particular destination.

That distinction matters because a different failure, 554 5.7.1 relay access denied, happens for authorization reasons after identity is settled: the server knows who you are but will not pass your message to that recipient. An authentication error stops you at the door; a relay error stops you at the destination. Reading the exact code tells you which problem you have.

Common causes of SMTP authentication errors

SMTP authentication errors almost always trace to one of a few credential or transport problems, not to anything about the recipient. The message is about your credentials and how they are sent. This short list accounts for nearly all failures:

• The username or password is wrong, or the username is not the full email address the provider expects.
• You are using your normal account password where the provider requires a dedicated app password because two-factor authentication is on.
• SMTP AUTH is disabled on the account, which is the default for new Microsoft 365 tenants.
• The port or encryption setting is wrong, so authentication never gets a chance to succeed.
• The provider expects OAuth 2.0 and rejects basic username-and-password sign-in.
• A sign-in from an unfamiliar IP address or region is blocked by the provider as a security precaution.

SMTP error 535 5.7.8: username and password not accepted

A 535 5.7.8 error means the server received your credentials and rejected them, so the connection is working but the username or password is not accepted. The most common cause is an account with two-factor authentication that needs an app password instead of the account password; on Microsoft 365 it can also mean SMTP AUTH is turned off for the mailbox.

Because the credentials reached the server, the connection itself is fine and the problem is what you sent. Start by retyping the password rather than trusting a saved one, and confirm the username is the complete email address, not just the part before the @ sign.

If the password is definitely correct and 535 persists, the usual reason is that the account has two-factor authentication enabled and the provider will not accept a plain account password from an outside client. In that case you need an app password instead, which the next sections cover. On Microsoft 365, a 535 can also mean SMTP AUTH is turned off for the mailbox even though the credentials are valid.

SMTP error 530 5.7.0: authentication required

A 530 5.7.0 error means the server needs you to authenticate and you have not yet done so, often because the connection is not encrypted. It may read "authentication required" or "must issue a STARTTLS command first," both pointing to the same fix: enable authentication in your client and secure the session with STARTTLS before sending a username and password.

Two fixes cover most 530 errors. First, make sure authentication is actually enabled in your client, since a client set to connect anonymously produces this code. Second, confirm you are using a port and encryption pairing that the server accepts, because a 530 that mentions STARTTLS is telling you the connection was not secured before the AUTH attempt.

App passwords versus account passwords

An app password is a dedicated, provider-generated credential you use in place of your account password when two-factor authentication is on. The account password is your normal interactive sign-in password, which providers such as Google and Microsoft reject over SMTP once 2FA is enabled. This is why authentication can fail even when your password is correct.

Providers issue the app password as a single-use credential you generate once and paste into the mail client. Google documents this for Gmail accounts with 2-Step Verification, where a 16-character app password is required for any client that does not support OAuth. Microsoft 365 behaves the same way for accounts with multi-factor authentication.

The modern alternative is OAuth 2.0, where the client obtains a token instead of holding a password at all. If your provider and client both support OAuth, it avoids app passwords entirely, but many devices and scripts still rely on an app password for basic authentication.

SMTP port 587 vs 465 and STARTTLS vs SSL

Port 587 with STARTTLS is the standard, recommended pairing for authenticated SMTP submission; port 465 uses implicit SSL/TLS and is encrypted from the first byte. Both are secure, and the common hidden cause of authentication failures is pairing a port with the wrong encryption mode, which makes the server reject the login before credentials are accepted.

The difference is when encryption starts. Port 587 opens a plain connection and then upgrades it to an encrypted one with STARTTLS before credentials are sent, while port 465 encrypts the connection from the first byte. Which port and encryption pairing you choose has to match what the provider expects.

Port	Encryption	How it works
587	STARTTLS	Starts plain, upgrades to TLS before login (standard submission port)
465	Implicit SSL/TLS	Encrypted from the first byte of the connection
25	None or STARTTLS	Server-to-server relay; usually blocked for client submission

If you are unsure, start with port 587 and STARTTLS, which almost every provider supports for authenticated submission. Reserve port 465 for providers that specifically ask for it, such as Yahoo.

Provider fix checklists

To fix an SMTP authentication error, work in one order regardless of provider: correct the credentials first, then the authentication method (app password or OAuth), then the port and encryption. The provider-specific steps below follow that sequence.

Gmail and Google Workspace

• Use smtp.gmail.com on port 587 with STARTTLS, and your full Gmail address as the username.
• If 2-Step Verification is on, generate an app password and use it instead of your account password.
• For Google Workspace, an administrator may need to allow the app or configure SMTP relay before third-party clients can authenticate.

Microsoft 365 and Office 365

• SMTP AUTH is disabled by default on new tenants, so enable it per mailbox or organization-wide before a client can authenticate. Microsoft explains this in its guide to authenticated client SMTP submission.
• Use smtp.office365.com on port 587 with STARTTLS, and check the current Microsoft 365 SMTP settings for the sending option that fits your case.
• If multi-factor authentication is on, use an app password or move the client to OAuth 2.0.

Generic provider or your own server

• Confirm the outgoing server requires authentication and that the username and password match the provider's requirements exactly.
• Verify the server hostname, port, and encryption against the provider's documentation rather than guessing.
• If sign-ins from a new location are blocked, complete any security verification the provider sends before retrying.

FAQs

How do I fix an SMTP authentication error?

Retype the username and password, using the full email address as the username. If two-factor authentication is on, switch to an app password. Then confirm the server, port, and encryption are correct for your provider, starting with port 587 and STARTTLS.

Do I need an app password for SMTP authentication?

You need one if the account has two-factor or multi-factor authentication enabled and the client uses basic authentication. Providers like Google and Microsoft reject the normal account password over SMTP in that case and require an app password or OAuth instead.

Why does SMTP authentication fail even with the correct password?

The most common reasons are that the account requires an app password rather than the account password, that SMTP AUTH is disabled on the mailbox (the default on new Microsoft 365 tenants), or that the port and encryption settings do not match what the server expects.

What is the difference between SMTP port 587 and 465?

Port 587 uses STARTTLS, which begins as a plain connection and upgrades to encryption before login. Port 465 uses implicit SSL/TLS and is encrypted from the start. Both are secure, and 587 is the standard submission port most providers recommend.

What is STARTTLS in SMTP?

STARTTLS is a command that upgrades a plain SMTP connection to an encrypted one before any credentials are sent. A 530 error that says "must issue a STARTTLS command first" means the server will not accept your login until the connection is secured this way.

Fixing the authentication error gets your mail sending again, but landing in the inbox depends on sending to real, valid addresses. Run your list through BounceCheck before your next send so invalid contacts are not quietly dragging down your deliverability.