Authentication failed email: fix mailbox and SMTP login errors

An "authentication failed" email error usually happens before a message is accepted for delivery. It points to a mailbox sign-in or SMTP AUTH problem, such as invalid credentials, a blocked account, a disabled submission method, an unsupported login mechanism, or a TLS mismatch. Save the complete error first, then test the same account and sending path. If a receiver reports SPF, DKIM, or DMARC results after delivery, use the email authentication failure diagnostic instead. The email authentication hub explains the separate receiver-side protocols.

What does the failure mean?

Mailbox sign-in and SMTP AUTH are different from receiver-side email authentication. SMTP AUTH is a client-to-server exchange that starts with the AUTH command after the server advertises supported mechanisms. RFC 4954 defines a 535 5.7.8 response as invalid or insufficient authentication credentials, while 454 4.7.0 indicates a temporary server failure. The reply text can add provider-specific context, but preserve it rather than guessing from the word "authentication."

535 5.7.8 Authentication credentials invalid
454 4.7.0 Temporary authentication failure

These are protocol examples, not proof of the cause in a particular account. A password prompt can also mean the provider changed its authentication method, reset the password, or suspended the account. Apple's current Mail troubleshooting lists those account-side causes and recommends checking the same credentials through webmail.

What usually causes it?

The account password or account state changed

The quickest distinction is whether the account can sign in through its normal webmail or provider account flow. Apple documents that a Mail password prompt can follow use of an old password, a provider-required reset, an account suspension, or a changed authentication method. A failed webmail test points to the account or provider path, not to the mail client's outgoing-server settings.

The SMTP credentials do not match the configured mailbox

An SMTP client can reach a server and still fail AUTH because the submitted username or password is wrong, expired, or no longer accepted. RFC 4954 assigns 535 5.7.8 to invalid or insufficient credentials. Do not assume that a client-side password field contains the current account credential.

The server requires a different TLS or AUTH method

The server advertises AUTH mechanisms in the EHLO response, and that list may change after STARTTLS. RFC 4954 also says a server should reject an unsupported mechanism or one that requires encryption with 504. This means the server, port, TLS mode, and mechanism must be checked together.

The authenticated account is not allowed to submit as the visible sender

Successful login does not always authorize every From address. For Microsoft 365 SMTP client submission, Microsoft's current troubleshooting guidance says the app normally sends from the mailbox used to log on, or that mailbox needs Send As permission for another sender. Microsoft also documents 5.7.60 for a sender-permission mismatch.

How do I diagnose the failure?

1. Capture the exact failed path

Record the full error or SMTP reply, UTC timestamp, server hostname, port, TLS setting, username form, From address, and the app or device version. Redact the password, OAuth token, and message content. A test from another mail client only helps if it uses the same account, server, network, and submission method.

2. Test the account outside the affected client

Sign in through the provider's supported webmail or account page using the same account. If that test fails, reset or recover the account through the provider and stop changing SMTP settings. Apple uses this same comparison to distinguish a rejected account password from a Mail configuration problem in its webmail test guidance.

3. Compare the SMTP settings with the server's requirements

Confirm the server name, port, TLS mode, and authentication method from the provider's current documentation. For an SMTP session you control, save the greeting, EHLO capabilities, the STARTTLS result, and the AUTH reply without recording secrets. The AUTH capability list is the evidence for which mechanisms the server offered in that session.

4. Check account authorization and the submission route

If the client authenticates but sending still fails, compare the authenticated mailbox with the visible From address and the intended submission route. Microsoft documents that SMTP AUTH must be enabled for the mailbox in its client-submission scenario, and that a client without a credential field may need a different submission method. Treat provider administration changes as provider-specific repairs, not universal SMTP instructions.

How do I fix it?

Repair the account or credential that the evidence identifies

Replace a stale saved password only after confirming the current credential through the provider's approved account path. Complete a required reset or account recovery there. If webmail still rejects the account, contact the provider or administrator rather than repeatedly retrying SMTP AUTH.

Match TLS and the supported AUTH mechanism

Use the provider's documented server, port, TLS setting, and supported login method. Do not force an older plaintext mechanism to work around a TLS or authentication-method rejection. RFC 4954 says servers should not permit plaintext password mechanisms without protection against password snooping, such as negotiated STARTTLS.

Enable or choose the correct submission path

When provider documentation shows that SMTP AUTH is disabled for the mailbox, have the account administrator enable the supported method or choose the documented alternative. Microsoft notes that direct send and SMTP relay have different login requirements from SMTP AUTH client submission. Do not weaken multifactor or conditional-access policy as a default repair. That is a security-policy decision, not a technical equivalent of correcting credentials.

Correct the sender authorization separately

If AUTH succeeds but the server rejects the visible sender, give the authenticated mailbox the appropriate provider-defined permission or use the correct relay route. This repair changes sender authorization. It does not change mailbox credentials, SPF, DKIM, DMARC, or receiver enforcement.

How do I validate the repair?

Repeat the same route that failed: the same app or device, network, server, port, TLS mode, authenticated account, and From address. A successful sign-in in another client is useful, but it does not prove the affected configuration now works.

• Confirm that the account can sign in through the provider's supported account path when that was the failed layer.
• Confirm that the affected client completes SMTP AUTH and accepts the expected submission settings.
• Send a controlled message through the same sender route and retain the success or failure reply.
• If the message is accepted but later fails at a recipient, inspect the recipient result and switch to the receiver-side authentication diagnostic. At that point, headers and domain authentication evidence are relevant.