SMTP Errors: Fixing Connection, Authentication and TLS Problems

Most SMTP errors fall into four groups: the server cannot be reached (connection timed out or refused), the login is wrong (535 authentication failed), the encryption does not match (certificate or TLS handshake errors), or the receiving side rejects the message (550, 554 and relay denied). Work through them in that order, because each stage has to succeed before the next one can even be tested. The error text usually tells you which stage failed.

This guide is for site owners, office managers and developers looking at an SMTP error in a WordPress plugin log, a CRM, a scanner or an app. It explains each common error in plain words and what to check, in the order that finds the cause fastest.

#Read the error first: what the code tells you

Every SMTP error carries a three-digit code, and many add an extended code such as 5.7.8. The first digit tells you whether to wait or to act. These meanings come from section 4.2 of RFC 5321 (opens in a new tab) and, for login errors, RFC 4954 (opens in a new tab).

A timeout or "connection refused" has no SMTP code at all, because the conversation never started. That alone tells you the problem is the network, the host name or the port, not your password.

#A simple diagnosis flow

Check each stage in order. There is no point changing a password if the server cannot be reached.

1. Confirm the host name and port against your provider's own help page, character by character.
2. Confirm the encryption pair: 587 with STARTTLS, or 465 with SSL/TLS. See my guide to SMTP settings, ports and encryption if you are unsure.
3. Test the login with a fresh app password or SMTP credential.
4. Check the From address is the mailbox you logged in as, or a domain the provider has verified.
5. Read the bounce or log for the receiving server's reply if the message was accepted but never arrived.
6. Change one thing at a time and send a test after each change, so you know which fix worked.

#Connection timed out

A timeout means your app knocked and nobody answered. Something between your server and the SMTP server is silently dropping the connection.

The most common cause is a hosting or cloud provider blocking outbound mail ports. At the time of writing (November 2026), DigitalOcean blocks ports 25, 465 and 587 (opens in a new tab) on Droplets by default, Google Cloud blocks outbound port 25 (opens in a new tab) to destinations outside your network, Azure blocks port 25 on virtual machines for most subscription types, and AWS throttles port 25 on EC2. Amazon SES's documentation (opens in a new tab) specifically warns that sending on port 25 from EC2 can cause timeouts.

What to check:

• Switch from port 25 to 587 or 465. If both of those are blocked too, ask your sending provider for an alternate port; Mailgun offers 2525 and Amazon SES offers 2587 and 2465.
• Check your server's own firewall, and any cloud firewall in your provider's dashboard, for rules that block outbound mail ports.
• On shared hosting, ask the host whether outgoing SMTP to external servers is allowed. Some hosts only let you send through their own mail server.
• An encryption mismatch, such as SSL selected on port 587, can also look like a timeout in some plugins. Recheck the pair.

#Connection refused

"Connection refused" is different from a timeout. The other machine answered, but said nothing is listening on that port. That points to the wrong host name, the wrong port, or a mail service that is down.

Check for a typo in the host, such as smtp.office365.com written as smtp.office.com. Make sure you are not pointing at your website's address when your mail is hosted elsewhere. If the host is your own server, the mail service (Exim or Postfix) may have stopped.

#535 authentication failed

535 means the server received your username and password and rejected them. RFC 4954 describes it as authentication failing "due to invalid or insufficient authentication credentials".

The usual causes, in order of how often they turn up:

• The wrong password type. Google accounts with 2-Step Verification need an app password (opens in a new tab), and Google revokes every app password when you change the account password.
• Password login is switched off. Microsoft 365 disables SMTP login for organisations created after January 2020 until an admin enables it per mailbox, and its updated timeline (opens in a new tab) says password-based (Basic) SMTP login will be disabled by default for existing tenants at the end of December 2026. Expect a wave of failing printers, scanners and plugins after that date unless they move to OAuth or a sending service.
• The wrong username. Sending services give separate SMTP credentials. Your Amazon SES SMTP username is not your AWS login.
• A copied space or hidden character at the end of the password.

If the login works but you see Microsoft's "5.7.60 Client doesn't have permissions to send as this sender", the From address is different from the mailbox you logged in as. Microsoft's device and app sending guide (opens in a new tab) says the login account then needs Send As permission on that mailbox.

#Certificate and TLS errors

Certificate errors mean the encrypted connection could not be trusted. The two common causes are a host name that does not match the certificate, and an encryption setting that does not match the port.

Host name mismatch. The certificate on a mail server is issued for specific names. cPanel's mail client settings page (opens in a new tab) explains that it shows mail.yourdomain only when your domain has a valid certificate, and the server's own host name otherwise. If you type mail.yourdomain but the certificate only covers the server's host name, you get a mismatch. Use exactly the host cPanel or your provider shows.

Wrong encryption for the port. Implicit TLS (SSL) belongs on 465 and STARTTLS on 587. Swapping them breaks the handshake.

Old TLS versions. Microsoft 365 requires TLS 1.2 or 1.3, and its guide says a device that defaults to port 465 does not support the TLS versions it needs. Old scanners, printers and outdated PHP builds often fail here.

Never fix a certificate error by switching off certificate checks in a plugin. That hides the problem and exposes your password.

#550 and 554 rejections, and relay denied

550 and 554 mean the conversation worked but a server refused the message by policy. Read the text after the code, because it names the reason.

550 mailbox unavailable or user unknown. The recipient address does not exist. Check for typos, and remove the address from any list it is on.

550 or 554 relay denied (often "relay access denied" or "relaying not permitted"). RFC 5321 says a server should return 550 when it declines to relay for policy reasons. In practice this means you are asking a server to deliver to an outside address without logging in. Turn on authentication, or use the host you are actually allowed to send through.

550 or 554 rejected as spam, or for authentication policy. The receiving server did not trust the message. Google's email sender guidelines (opens in a new tab) require SPF or DKIM for all senders, valid reverse DNS for the sending IP, and DMARC for anyone sending more than 5,000 messages a day to Gmail. Check SPF, DKIM and DMARC for the sending domain, and whether the server's IP is on a blocklist.

554 on connect. RFC 5321 lets a server answer 554 instead of a greeting, meaning "No SMTP service here". This often means the receiving server blocked your IP outright.

#When to get help

Most single errors are fixed in an hour with the checks above. Get help when:

• Order confirmations, password resets or invoices are already failing and every hour costs customers.
• The error comes back after a fix, or different recipients get different errors.
• You see blocklist or spam rejections from Gmail or Outlook, which point to a reputation or DNS problem.
• The sender is a VPS or cloud server and you are not sure what is blocked at the provider, the firewall or the mail service.

My SMTP and transactional email setup service includes diagnosing and fixing connection, login and TLS errors and moving your site to a reliable sending service. Rejections for spam or authentication belong to the email deliverability service. For the background on why websites hit these errors in the first place, read what SMTP is and how it works, and if you are building an app, SMTP vs email API explains how logs and bounce webhooks catch these failures early.