Fix SMTP Authentication Failed Sending Email From Server

Before You Start: What's Actually Happening

You're trying to send an email from your server — maybe a script, a CMS like WordPress, or a command-line tool — and you get back an error like 535 5.7.3 Authentication unsuccessful or just a generic "SMTP Authentication Failed". This usually happens when your server can't prove to the mail server that it's allowed to send. Common triggers: a password change you forgot to update, or a firewall that suddenly started blocking port 587.

Fix 1: The 30-Second Check — Credentials and Port

Most SMTP auth failures are stupid simple: wrong username, wrong password, or wrong port. Let's rule that out first.

Check your SMTP credentials. Log into your email provider's control panel (like cPanel, Office 365 admin, or Google Workspace admin). Verify the exact username and password your application uses. Many people copy the wrong email address or leave a trailing space. For example, if you're using Office 365, the username is usually the full email address like user@contoso.com, not just user.
Check the SMTP port and encryption. Most modern mail servers require port 587 with STARTTLS. Port 25 is often blocked by ISPs or used for unauthenticated relay. Port 465 with SSL is less common now. If your app uses port 25, try changing to 587 and enabling STARTTLS. After changing, you should see a different error or a success message.
Test with a command-line tool. SSH into your server and run:
```
openssl s_client -connect smtp.office365.com:587 -starttls smtp -crlf
```
After the connection opens, type:
```
EHLO yourserver.com
AUTH LOGIN
```
Paste your base64-encoded username and password (each on a separate line). If you get 535 5.7.3 here, it's a credential problem. If you get 334 prompts but no error, your auth is fine — the issue is elsewhere.

Expected outcome: If credentials or port were wrong, fixing them gets email sending working again. If not, move to Fix 2.

Fix 2: The 5-Minute Fix — DNS and Relay Settings

Sometimes the mail server rejects your connection because your server's hostname doesn't match what's expected, or your IP isn't allowed to relay.

Verify your server's hostname and PTR record. Many mail servers (especially Office 365 and Google) check that the server's hostname resolves back to its IP. Run:
```
hostname -f
```
This should return something like mail.yourdomain.com. Then check the PTR record (reverse DNS) for your server's IP. You can do this at a site like mxtoolbox.com. If the PTR doesn't match your hostname, contact your hosting provider to set it. After it's fixed, wait an hour for DNS to propagate, then test again.
Check if your IP is allowed to relay. If you're using a third-party SMTP relay like SendGrid or Mailgun, log into their dashboard and confirm your server's IP is whitelisted. If you're using your own mail server (like Postfix), check the relay settings. On a Postfix server, run:
```
postconf -n | grep relay
```
Look for relayhost. If it's empty, Postfix tries to deliver directly, which often fails. Set it to your provider's SMTP server, like:
```
relayhost = [smtp.office365.com]:587
```
Then run postmap /etc/postfix/sasl_passwd to apply the password file.
Test again with a real email. Use a simple script or command to send a test email. For Postfix, you can use sendmail or mailx. Example:
```
echo "Test email body" | mail -s "SMTP test" you@example.com
```
Check /var/log/maillog or /var/log/mail.log for errors. If you see "relay access denied", that's a relay permission issue — fix your IP whitelist.

Expected outcome: If DNS or relay settings were the problem, you should see success in the logs and receive the email. If not, move to the advanced fix.

Fix 3: The 15+ Minute Fix — Deep Config and Log Analysis

This is when the problem is buried in your mail server configuration or authentication mechanism. You'll need to look at logs and change settings that aren't in the GUI.

Read the mail logs line by line. Tail the log while sending a test email:
```
tail -f /var/log/maillog
```
Send a test email from your app or script. Look for lines containing sasl_username, auth, or relay. Example of a failed auth line:
```
postfix/smtp[12345]: 535 5.7.3 Authentication unsuccessful
```
Right above it, you might see warning: SASL authentication failure: Password verification failed — that means your password hash is wrong. On Postfix, run:
```
cat /etc/postfix/sasl_passwd
```
Verify the file contains smtp.office365.com:587 username:password with no extra spaces. Then run postmap /etc/postfix/sasl_passwd to update the database. After that, restart Postfix: systemctl restart postfix.
Check SASL configuration. If you're using Dovecot or Cyrus for SASL, make sure it's running and configured for SMTP auth. On a typical Postfix+Dovecot setup, verify Dovecot is listening on the socket:
```
netstat -an | grep 587
```
Should show LISTEN. Then check Dovecot's config: doveconf -n and look for auth_mechanisms = plain login. If it's missing login, add it. Also check service auth section — make sure unix_listener /var/spool/postfix/private/auth exists and has correct permissions (mode 0666, user postfix).
Test with a different authentication method. Some mail servers require AUTH LOGIN instead of AUTH PLAIN. In your application, you might need to specify the auth method. For example, in PHP's PHPMailer, set:
```
$mail->SMTPAuth = true;
$mail->AuthType = 'LOGIN';
```
In Python's smtplib, it's usually automatic, but you can force it with smtp.ehlo() before login.
Check for TLS/SSL version mismatch. Old servers might not support TLS 1.2 or 1.3. If your mail server enforces TLS 1.2 and your client only offers TLS 1.0, the handshake fails silently. Update your application's TLS library. For example, in Python, set:
```
import ssl
context = ssl.create_default_context()
context.minimum_version = ssl.TLSVersion.TLSv1_2
```
For Postfix, check smtp_tls_security_level = may and smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1.
Last resort: rebuild the password database. If nothing else works, delete the sasl_passwd.db file and recreate it:
```
rm /etc/postfix/sasl_passwd.db
postmap /etc/postfix/sasl_passwd
systemctl restart postfix
```
Test again. If it still fails, you might have a firewall blocking outbound connections on port 587. Use telnet smtp.office365.com 587 from your server — if it hangs, the firewall is the problem.

Expected outcome: After these steps, the mail logs should show status=sent or delivered. If you still see auth errors, you likely have a credential issue that's deeper than you think — double-check the password in a different app (like Outlook) to make sure it hasn't expired or been changed.

When to Call Your Provider

If you've done all three fixes and still get SMTP auth errors, it's time to contact your email or hosting provider. Provide them with the exact error code and the lines from your mail log. Ask them to check if your account has been blocked for suspicious activity, or if they've changed their SMTP settings recently. Sometimes they require OAuth2 now, which your old app doesn't support. In that case, you'll need to update your application to use Microsoft Graph API or Gmail API instead of SMTP.

One last thing: if you're using a free email account (like Gmail), they often block "less secure apps". Enable "App Passwords" or use OAuth2. That's a different problem, but it looks exactly like SMTP auth failure.