535 5.7.8 username and password not accepted

535 5.7.8 Username and Password not accepted means the mail server took your connection, offered to authenticate you, and then refused the credentials you sent. It is a login failure, not a network or DNS failure. On a personal Gmail account the fix is a 16-digit app password, which needs 2-Step Verification turned on first. On Google Workspace and Microsoft 365 an ordinary account password will not work at all any more.

The two Stack Overflow questions carrying the string in their titles hold 278,551 and 205,549 views, and the larger one has fourteen answers. Checked through the Stack Exchange API on 23 August 2026.

What is your mail server actually rejecting?

SMTP authentication happens after the connection is already open and encrypted. Your tool connects to the submission port, the server advertises which authentication methods it supports, your tool picks one and sends a username and a secret, and the server answers. 535 is the permanent-failure class for that last step, and 5.7.8 narrows it to invalid credentials. Nothing about the message itself has been looked at yet.

That matters because it rules three other failures out immediately.

• If the connection never opens at all, and you get a timeout rather than a numbered reply, your host is probably blocking the port. That is a different problem, covered in your host blocks the SMTP port.
• If authentication succeeds and the message is accepted but never appears anywhere, see the sign-in email never arrives.
• If the message is accepted by your relay and then bounced back later by the recipient's provider, you are looking at a delivery rejection, not a login one. Gmail's 550 5.7.26 is the common one.

The reason this hits self-hosted support tools so hard is that pointing a new install at your own Gmail account is the cheapest possible way to get email working, and it is the first thing most people try. Fider's issue tracker carries an open request, #1213, opened on 10 October 2024 and still open on 23 August 2026, asking for XOAUTH2 support specifically because Google and Microsoft have been withdrawing plain SMTP authentication.

How do you fix it on a personal Gmail account?

Your normal Google password will never work here. Google requires an app password, and app passwords have a prerequisite that catches people out.

• Step one, turn on 2-Step Verification on the Google account. Without it the app password screen does not exist, and searching for it only finds other people confused about the same thing.
• Step two, generate an app password at myaccount.google.com/apppasswords. Google's own documentation describes it as "a 16-digit passcode" that "can only be used with accounts that have 2-Step Verification turned on".
• Step three, paste that code into your tool's SMTP password field with the spaces removed, and keep the username as the full Gmail address.
• Step four, use smtp.gmail.com on port 587 with STARTTLS.

Google's page opens by saying app passwords "aren't recommended and are unnecessary in most cases". They still work, but you are using a documented fallback rather than the supported path.

How do you fix it on Google Workspace or Microsoft 365?

Neither of these is an app-password problem. Both have removed the mechanism you are trying to use.

Google Workspace states it plainly in its SMTP relay documentation:

Google Workspace accounts no longer support less secure apps, third-party apps, or devices that ask you to sign in to your Google Account with your username and password. You must use OAuth.

Google Workspace Admin Help

The supported route for a server-side tool is the SMTP relay service, configured in the admin console and pointed at smtp-relay.gmail.com on port 587 with TLS.

Microsoft 365 has two separate gotchas. First, per Microsoft's own guidance for applications sending mail, "SMTP AUTH is disabled for organizations created after January 2020 but you can enable it per-mailbox". If your tenant is newer than that and nobody has enabled it, the credentials are correct and the answer is still 535. Second, use smtp.office365.com on port 587. Microsoft warns that a device or application defaulting to port 465 "doesn't support the required versions of TLS for client SMTP submission" with them.

How do you check it worked, without waiting for your app?

Test the credentials outside your tool, so you know whether you are debugging mail or configuration loading. swaks is the fastest way:

swaks --to you@example.com \
      --from board@example.com \
      --server smtp.gmail.com:587 \
      --tls \
      --auth LOGIN \
      --auth-user board@example.com \
      --auth-password 'yourappasswordhere'

A success ends with 250 2.0.0 OK. A failure repeats the same 535 5.7.8, which proves the credentials are wrong rather than your tool.

If swaks is not installed, openssl will show you the handshake:

openssl s_client -starttls smtp -crlf \
        -connect smtp.gmail.com:587

Type EHLO test at the prompt. The server lists what it supports, and the 250-AUTH line tells you which methods are on offer. If you see no AUTH line at all after STARTTLS, the server is not offering authentication on that port, and no password will ever be right.

What if the password is definitely correct?

Then something between your tool and the server is changing it, or the account is refusing the login for a reason other than the secret itself. Work through these in order.

• A trailing space or a copied newline. Config files and environment variables preserve both. Print the variable with delimiters, for example printf '[%s]' "$SMTP_PASSWORD", and look at where the brackets land.
• Spaces left in a Google app password. Google displays the 16 characters in four groups. Some clients accept the spaces, some do not.
• The wrong username. Several providers want the full email address, not the local part, and a few want an account ID that is not an email address at all.
• Character escaping in Docker Compose. A $ in a password is interpreted as a variable reference in a Compose file unless you write it as $$.
• The account is not the sender. If authentication passes but you then get 5.7.60 Client doesn't have permissions to send as this sender on Microsoft 365, the login worked and the From address is the problem.

If you have not yet set up SPF, DKIM and DMARC for whichever sender you settle on, do that next. SMTP for self-hosted tools covers what each record does, and SPF permerror, too many DNS lookups covers the limit people hit once they add a second sender.

Where this error cannot reach

One honest note, because it changes what you need to secure. A support centre only hits 535 if it authenticates to a mail server in the first place. Docket's free edition sends no email at all, and its runtime is static files plus two endpoints, so there is no SMTP client anywhere in it to hold a credential. The paid tiers add email notifications, and at that point the same rules apply to Docket as to anything else: pick a sender, publish the DNS records, and test the login before you rely on it.

Frequently asked questions