SMTP error: could not authenticate - find the real server reply

"SMTP Error: Could not authenticate." is not an SMTP error. It is a message your mail library

prints after the server refused an AUTH command - PHPMailer emits that exact sentence, and

Swift Mailer, Nodemailer and most CMS mail wrappers emit near-identical ones. The server

underneath sent a real reply code, and that code is the only thing that tells you what to fix.

Until you have it, you are guessing.

So the first step is never "check your password". It is **turn on SMTP debug output and read the

server's reply**.

Get the real reply

In PHPMailer, set $mail->SMTPDebug = 2;. In Nodemailer, pass logger: true, debug: true. On a

server you control, swaks is faster than either:

$ swaks --to test@mailpilots.in --server smtp.gmail.com:587 \
        --auth LOGIN --auth-user sender@yourdomain.com -tls
=== TLS started with cipher TLSv1.3:TLS_AES_256_GCM_SHA384
 -> AUTH LOGIN
 <- 334 VXNlcm5hbWU6
 -> c2VuZGVyQHlvdXJkb21haW4uY29t
 <- 334 UGFzc3dvcmQ6
 -> ********
 <- 535-5.7.8 Username and Password not accepted. For more information, go to
 <- 535 5.7.8  https://support.google.com/mail/?p=BadCredentials - gsmtp
*** No authentication type succeeded

Now you have something to work with.

What each underlying reply means

The 454 4.7.0 row is the one worth noticing. It is a 4xx, which means transient - retry it

later. Every other row in that table is permanent, and retrying on a timer only increases your

failed-login count, which some hosts respond to by throttling the IP.

The ordered fix

1. Confirm which credential type the mailbox requires. If the account has two-step

verification enabled, the account password will never work over SMTP - you need an

app-specific password, and Google returns 534 5.7.9 or 535 5.7.8 for the account password

regardless of how correct it is.

1. Regenerate the app password rather than re-typing it. App passwords are invalidated

whenever the account password changes or two-step verification is toggled. The old string is

permanently dead; there is nothing to correct.

1. Match the port to the encryption mode. Port 587 expects STARTTLS on a connection that

begins in the clear. Port 465 expects TLS from the first byte. Setting 465 with STARTTLS, or

587 with implicit TLS, produces an authentication-looking failure that has nothing to do with

your password.

1. Check SMTP AUTH is enabled at tenant and mailbox level. Microsoft 365 ships new tenants

with SMTP client authentication disabled, and it is set per mailbox as well as org-wide - one

mailbox can be refused while another in the same tenant works. Google Workspace removed

less-secure-app access entirely, so a Workspace mailbox needs either an app password or OAuth.

1. Prefer OAuth where the provider offers it. For Gmail and Outlook, OAuth removes this whole

class of failure: no password to rotate, no app password to be invalidated, no basic-auth

deprecation to be caught by.

1. Send exactly one test message after each change, not a batch. If the credential is still

wrong you learn it in one attempt instead of a hundred failed logins.

Firewalls and ports, briefly

Many residential ISPs and some cloud providers block outbound port 25 entirely, and a few block

1. That produces a connection timeout, not an authentication error - if your library reports

"could not authenticate" you reached the server and spoke to it, so the port is open. Do not

start rewriting firewall rules for a 535.

The genuine network-adjacent cause is a transparent proxy or security appliance that intercepts

port 587, strips the STARTTLS advertisement, and leaves the session in the clear. The server

then refuses AUTH with 530 5.7.0 Must issue a STARTTLS command first. The debug transcript

makes this obvious: STARTTLS will be missing from the EHLO response.

What not to do

• Do not keep retrying. A rejected credential is permanent. Repeated AUTH failures from one

IP look exactly like a brute-force attempt and are treated accordingly.

• Do not store the account password "temporarily" while you sort out an app password. It will

not work, and it will sit in config until someone finds it in a log.

• Do not disable TLS to make the error go away. Some clients will then authenticate in

plaintext against a server that permits it, which sends the credential across the network

unencrypted.

• Do not treat this as a bounce. The failure happened at AUTH, before MAIL FROM - no

recipient was ever named. Any system that records this against the recipient address suppresses

a healthy contact for no reason.

• Do not paste the error into a search engine and apply the first fix. Four different server

replies produce the same client-side sentence, and the fix for one makes no difference to the

others.

MailPilot connects Gmail and Outlook mailboxes over OAuth specifically so that this category

disappears: there is no app password to be revoked mid-ramp. For SendGrid, Amazon SES, Mailgun,

Postmark and custom SMTP it uses SMTP/IMAP credentials, validates them at connection time rather

than at first send, and reports the server's actual reply string instead of a wrapper's summary

of it.