How to Fix SMTP Authentication Errors (535, 530, 534)

Why SMTP authentication fails

SMTP authentication errors return a 5xx response code that tells you exactly what the server rejected. The most common ones you will see are 535 (invalid credentials), 530 (authentication required), and 534 (mechanism too weak). Decoding the response is the fastest way to fix the problem instead of guessing.

When SMTPTester runs your check, it shows the exact reply string from the server. Read that first — it almost always names the cause.

535 5.7.8 — Authentication credentials invalid

This is the classic "wrong username or password" reply, but the underlying cause is usually subtler. Walk through this checklist:

1. Use the full email address as the username. Most providers (Gmail, Microsoft 365, Zoho, FastMail) require the full address, not just the local part.
2. Generate an app password. Google, Microsoft, Apple, and Yahoo all block regular passwords for SMTP when 2FA is enabled. Create a dedicated app password and use that 16-character token instead.
3. Check for whitespace. Pasting from a password manager often introduces a trailing space. Re-type the value into SMTPTester to rule it out.
4. Verify the account is allowed to send. Some Microsoft 365 tenants disable SMTP AUTH by default; an administrator needs to enable it per mailbox.

530 5.7.0 — Authentication required

A 530 reply means the server accepted your connection but refused to relay until you authenticate. Two common causes:

• You connected to port 25 instead of the submission port (587 or 465).
• You issued MAIL FROM before AUTH. SMTPTester always authenticates first, so if you see this in our diagnostics it usually means your client library is misconfigured.

534 5.7.9 — Authentication mechanism too weak

The server requires a stronger mechanism than the one you offered. The most common scenario is presenting AUTH LOGIN over an unencrypted channel. Fix it by enabling STARTTLS on port 587 (or switch to implicit TLS on 465). If your client only supports plain auth, upgrade the library — modern providers will eventually drop legacy mechanisms entirely.

Gmail specifics

For smtp.gmail.com on port 587 with STARTTLS:

Username: you@gmail.com
Password: <16-char app password>

If you use Google Workspace, an administrator may also need to enable "Less secure app access" alternatives — typically by issuing OAuth-based credentials and switching to XOAUTH2. SMTP with app passwords still works for most Workspace tenants as of 2025.

Microsoft 365 specifics

Microsoft 365 disables SMTP AUTH on new tenants by default. As an admin:

1. Open the Microsoft 365 admin center and navigate to *Active users*.
2. Select the mailbox, open *Mail*, then *Manage email apps*.
3. Enable *Authenticated SMTP*.

Use smtp.office365.com:587 with STARTTLS and the user's full UPN.

SendGrid, Mailgun, Postmark, SES

Transactional providers use a fixed username (often the literal string apikey) and an API key as the password. Always generate a dedicated, scoped key for each application so you can rotate without breaking other services.

When authentication works but mail still bounces

A green check from SMTPTester means the server accepts you as a valid sender. Inbox placement is a separate layer:

• Publish SPF, DKIM, and DMARC records for your sending domain.
• Warm up new IPs gradually instead of sending a large batch on day one.
• Monitor bounces and complaint rates daily.

If you are seeing 5xx replies that are not on this list, paste the full server response into SMTPTester and we will surface the most likely cause in the recommendations panel.