# Authentication failed email: fix mailbox and SMTP login errors > Fix authentication failed email errors by checking mailbox sign-in, SMTP AUTH credentials, TLS, and sender permissions. 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](/learning/email-authentication-failure) instead. The [email authentication hub](/learning/email-authentication) explains the separate receiver-side protocols. ## Quick takeaways - Start with the exact error code, prompt, timestamp, account, and affected app or device. - A `535 5.7.8` reply means the SMTP server rejected the credentials in that AUTH exchange. - Test the same credentials in the provider's supported webmail or account path before editing SMTP settings. - Check the server, port, TLS mode, and advertised AUTH mechanism as one configuration. - Do not change SPF, DKIM, or DMARC to fix a pre-submission login failure. ## 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](https://www.rfc-editor.org/rfc/rfc4954.html) 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." ```text 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](https://support.apple.com/en-ie/102413) lists those account-side causes and recommends checking the same credentials through webmail. ![Decision flow separating mailbox sign-in, SMTP AUTH, and receiver-side authentication evidence.](/images/editorial/authentication-failed-email/authentication-failed-email-evidence-flow.svg "1600x900") *Source: Original Palisade troubleshooting graphic based on [RFC 4954 SMTP Authentication](https://www.rfc-editor.org/rfc/rfc4954.html). [Open the full-size graphic](/images/editorial/authentication-failed-email/authentication-failed-email-evidence-flow.svg).* ## 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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off) 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](https://support.apple.com/en-ie/102413). ### 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](/learning/email-authentication-failure). At that point, headers and domain authentication evidence are relevant. DNS and DMARC reports are not primary validation for mailbox or SMTP login. They become useful only after a message is accepted and a receiver reports a domain-authentication result. For the protocol background behind that later stage, see [what email authentication means](/learning/what-is-email-authentication-and-why-does-it-matter). If you have a delivered message with receiver-added results, the [email header analyzer](/tools/email-header-analyzer) can help separate that later evidence from the submission error. ## Sources and further reading - [RFC 4954: SMTP Service Extension for Authentication](https://www.rfc-editor.org/rfc/rfc4954.html) - [Apple Support: If Mail on your Mac keeps asking for your password](https://support.apple.com/en-ie/102413) - [Microsoft Learn: Fix issues with SMTP AUTH client submission](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/fix-issues-with-printers-scanners-and-lob-applications-that-send-email-using-off) ## Frequently asked questions ### Does a 535 authentication error mean my email was rejected by the recipient? No. A `535 5.7.8` SMTP AUTH reply concerns the client authentication exchange with the submission server. It normally happens before that server accepts the message for delivery. Save the complete reply and test the same account and SMTP configuration. ### Can I fix an SMTP AUTH failure by changing SPF or DMARC? No. SPF, DKIM, and DMARC are receiver-side domain-authentication controls. They do not supply mailbox credentials or enable an SMTP AUTH method. Change them only when a delivered message has separate receiver-side authentication evidence. ### Why does webmail work but my mail app still says authentication failed? Webmail success usually narrows the problem to the client configuration, saved credential, selected authentication method, or the outgoing SMTP path. Compare the app's server, port, TLS mode, username, and From address with the provider's current requirements. ### Should I turn off multifactor authentication to make SMTP work? Not as a routine fix. A legacy client may not support the provider's required authentication method, but disabling a security control changes account policy. Use the provider's supported submission method or have an administrator assess the approved alternative. ### What evidence should I give an email provider or administrator? Provide the full error text, UTC timestamp, affected account, server hostname, port, TLS mode, application or device version, and whether the same account works through webmail. Do not send passwords, OAuth tokens, or full message content in a support ticket.