SMTP Troubleshooting Tutorial (2026): Fix “Connection Timed Out”, TLS Errors, and 535 Auth Failures on a VPS

Most SMTP failures look the same at first glance: “could not connect”, “TLS failed”, “authentication error”. Under the hood, they usually boil down to a short list.

Think blocked ports, bad DNS, broken TLS, incorrect credentials, or an IP/reputation policy hit. This SMTP troubleshooting tutorial gives you a checklist you can run on a VPS or dedicated server without guessing.

You’ll use a few practical tools (OpenSSL, dig, swaks), check the right logs, and confirm DNS is coherent.

The goal is simple: outbound mail leaves your server reliably, and inbound mail negotiates TLS and passes common policy checks.

Before you touch anything: confirm what “SMTP is failing” actually means

Write down three details first. This keeps you from debugging the wrong layer.

Direction: outbound (your app/WordPress sending) or inbound (others sending to you)?
Path: direct-from-server (Postfix/Exim) or relay (SMTP provider like Mailgun/SendGrid) or cPanel Exim?
Error location: client-side (WordPress plugin), server log, or remote bounce message?

If you’re on WHM/cPanel, pull the exact Exim log line.

On an Ubuntu/Debian VPS with Postfix, grab the relevant mail.log entry.

If you don’t have logs, fix that first. Otherwise you’re debugging blind.

Step 1: run a fast “is the port reachable” test (and from where)

Connection timeouts almost always come down to network policy.

In 2026, outbound TCP/25 is still blocked by default on many providers. Some networks also throttle it aggressively.

Don’t assume your firewall is the only control point.

Test outbound connectivity from your server

On the mail-sending server:

sudo apt-get update
sudo apt-get install -y netcat-openbsd openssl dnsutils

Then test ports to your target (replace mx1.example.net):

nc -vz mx1.example.net 25
nc -vz mx1.example.net 587
nc -vz mx1.example.net 465

Success: you see “succeeded” quickly.
Timeout: network block or routing issue.
Connection refused: host reachable but service not listening on that port.

Test inbound reachability from the public internet

From your laptop (or a separate VPS), test your server’s public IP/hostname:

nc -vz mail.yourdomain.com 25
nc -vz mail.yourdomain.com 587
nc -vz mail.yourdomain.com 465

If inbound 25 times out, start with firewall rules and cloud security groups.

Also check upstream filtering and whether the daemon is bound to the wrong interface.

Want to double-check you didn’t open extra services while testing? Use the same method from our firewall audit tutorial.

Step 2: confirm the SMTP daemon is listening on the right ports

On the server that should accept SMTP, verify listening sockets:

sudo ss -lntp | egrep ':(25|465|587)\b'

Common expectations:

Port 25: inbound server-to-server (MX traffic).
Port 587: submission (authenticated clients, STARTTLS).
Port 465: implicit TLS submission (still used by many clients).

If you run Postfix (Ubuntu/Debian)

Check the service and the active config:

sudo systemctl status postfix --no-pager
sudo postconf -n | egrep '^(myhostname|mydestination|inet_interfaces|smtpd_tls_|smtpd_sasl_|submission)'

A common mistake is inet_interfaces = loopback-only (or similar). That makes Postfix listen only on localhost.

For an internet-facing mail server, you usually want:

sudo postconf -e 'inet_interfaces = all'
sudo systemctl restart postfix

If you run cPanel/WHM (Exim)

In WHM, confirm Exim is enabled and listening.

Then verify status at the service level:

sudo /usr/local/cpanel/scripts/restartsrv_exim --status

If you’re building out a WHM mail stack end-to-end, follow our cPanel mail server setup guide.

Step 3: fix “connection timed out” the boring way: firewall + provider policy

When a port is blocked, find which layer is dropping packets.

Start at the host firewall. Then work outward to the provider edge.

On Ubuntu with UFW

sudo ufw status verbose

Minimum inbound rules for a typical mail host:

sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
sudo ufw allow 465/tcp
sudo ufw allow 143/tcp
sudo ufw allow 993/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

If you’re unsure how to open mail ports without locking yourself out of SSH, use our UFW firewall setup tutorial.

On RHEL/AlmaLinux/Rocky with firewalld

sudo firewall-cmd --state
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=smtp
sudo firewall-cmd --permanent --add-service=submission
sudo firewall-cmd --permanent --add-service=smtps
sudo firewall-cmd --reload

If outbound TCP/25 is blocked by policy

This is common on new VPS deployments. If your provider blocks outbound 25, you have three realistic options:

Use authenticated relay on 587/465 (recommended for app/WordPress transactional mail).
Request port 25 unblocking with a justification and abuse controls.
Send from a mail platform and keep your VPS for web hosting only.

If email is business-critical and you want one owner for PTR/rDNS, firewall policy, and mail defaults, managed VPS hosting can keep those pieces consistent.

Step 4: validate DNS for mail (MX, A/AAAA, and reverse DNS)

Bad DNS creates confusing symptoms. Remote servers may reject you for “invalid HELO”, “no reverse”, or vague “policy” failures.

Get DNS straight before you tweak TLS.

Check MX and where it points

dig +short MX yourdomain.com
dig +short A mail.yourdomain.com
dig +short AAAA mail.yourdomain.com

Rules that save you hours:

Your MX should point to a hostname that has an A record (and optionally AAAA) resolving to your mail server.
That hostname should match what your SMTP daemon announces in its banner (myhostname in Postfix, primary hostname in WHM).

Check reverse DNS (PTR) matches your sending identity

From your server’s public IP:

dig +short -x YOUR_SERVER_IP

A solid baseline is: PTR → mail.yourdomain.com, and mail.yourdomain.com A → your IP.

If PTR is missing or points elsewhere, fix that before treating remote rejections as “random”.

Use our walkthrough: rDNS setup guide tutorial.

Step 5: troubleshoot TLS the right way (not by disabling it)

TLS failures usually come from certificate name mismatch, an incomplete chain, the wrong SNI name, or incompatible protocol/cipher policy.

OpenSSL will show you what’s actually happening.

Test STARTTLS on port 25 (server-to-server)

openssl s_client -connect mail.yourdomain.com:25 -starttls smtp -servername mail.yourdomain.com -showcerts

Look for:

Certificate subject/SAN: should include mail.yourdomain.com.
Verify return code: 0 (ok) is what you want.
Chain issues: errors like “unable to get local issuer certificate” often mean an incomplete chain file configured on the server.

Test submission (587) with STARTTLS

openssl s_client -connect mail.yourdomain.com:587 -starttls smtp -servername mail.yourdomain.com -showcerts

Test implicit TLS (465)

openssl s_client -connect mail.yourdomain.com:465 -servername mail.yourdomain.com -showcerts

If your Let’s Encrypt renewals keep failing or chains break after changes, follow our TLS certificate renewal troubleshooting tutorial.

For initial deployment, this guide is the cleanest route: SSL certificate deployment tutorial.

cPanel note: AutoSSL is your friend, but verify hostname coverage

On WHM servers, AutoSSL can issue and renew certificates for service subdomains.

Still, confirm the certificate used by Exim/Dovecot covers the hostname your clients connect to (often mail.yourdomain.com).

Step 6: fix 535 authentication failures (wrong auth method, username format, or policy)

“535 5.7.8 Authentication credentials invalid” doesn’t always mean the password is wrong.

Often, the client is using the wrong port or username format. Another common cause is trying to authenticate without TLS.

Common causes you can check quickly

Wrong port: Use 587 (STARTTLS) or 465 (TLS). Port 25 is not for end-user login in most setups.
Wrong username: Many systems require the full email address (user@domain.com), not just user.
TLS required: Server policy blocks auth on non-encrypted sessions.
Account locked/suspended: mailbox disabled or password expired in the control panel.

Use swaks to test auth like a client (recommended)

swaks gives you a repeatable SMTP test. It also removes “maybe my mail client is weird” from the equation.

sudo apt-get install -y swaks
swaks --to you@gmail.com \
  --from user@yourdomain.com \
  --server mail.yourdomain.com \
  --port 587 \
  --auth LOGIN \
  --auth-user user@yourdomain.com \
  --auth-password 'YOUR_PASSWORD' \
  --tls

If that works, your SMTP server is doing its job.

Focus on the app/client configuration next.

If you’re troubleshooting WordPress SMTP

Make sure your plugin uses:

Host: mail.yourdomain.com
Encryption: STARTTLS on 587 (or SSL on 465)
Auth: enabled
Username: full mailbox address

Also confirm your site’s DNS isn’t still pointing at the old host after a move.

If mail broke right after migration, check our DNS propagation troubleshooting tutorial.

Step 7: read the logs that matter (and ignore the noisy ones)

If the port is reachable and TLS looks clean, the logs usually tell you what’s left.

Don’t skim. Search by exact timestamp and message ID.

Postfix (Ubuntu/Debian) log locations and commands

On Ubuntu/Debian, Postfix logs commonly go to /var/log/mail.log (depending on rsyslog/journald setup).

sudo tail -n 200 /var/log/mail.log
sudo grep -iE 'warning|error|reject|defer|tls|sasl' /var/log/mail.log | tail -n 200

Useful patterns:

deferred: remote temp failure, greylisting, rate limiting, DNS, or TLS negotiation issues.
reject: policy, SPF/DMARC alignment, HELO/PTR mismatch, or authentication problems.

Exim (cPanel/WHM) quick checks

On cPanel servers, focus on Exim’s main log and the queue.

These show whether you’re failing fast or piling up.

sudo exim -bp | head
sudo exim -bpc
sudo tail -n 200 /var/log/exim_mainlog

If the queue is growing or messages are frozen, follow the dedicated guide: cPanel mail queue troubleshooting tutorial.

Step 8: stop deliverability-related SMTP failures (SPF, DKIM, DMARC, and alignment)

Not every “SMTP problem” is transport-level.

A remote system can accept your connection, then bounce later. It can also accept and spam-folder the message if authentication doesn’t line up.

Minimum baseline for a domain that sends mail in 2026:

SPF: authorizes your sending IP(s) or relay.
DKIM: signs outbound mail.
DMARC: sets policy and reporting, and forces alignment over time.

If you haven’t published these yet, use our hands-on guide: DMARC setup tutorial.

If mail started failing right after a DKIM change, rotate keys carefully. This helps avoid intermittent failures across cached DNS resolvers: DKIM key rotation tutorial.

Step 9: quick fixes for the most common SMTP errors

Once you’ve run the tests above, this table helps you jump straight to the most likely fix.

Error symptom	Likely cause	What to check first
Connection timed out	Firewall / provider block / wrong IP	`nc -vz`, `ufw status`/`firewall-cmd`, provider policy on outbound 25
Connection refused	Service not listening	`ss -lntp`, daemon status, correct bind/interface
TLS handshake failure	Bad cert/chain, wrong hostname/SNI	`openssl s_client` with `-servername`, verify chain files
535 auth failed	Wrong creds/username format/TLS required	`swaks` auth test on 587, full email as user
Remote says “HELO rejected” or “no reverse”	PTR/hostname mismatch	`dig -x`, Postfix `myhostname` / WHM hostname, A/PTR alignment

Step 10: harden your SMTP surface without breaking clients

After it works, tighten it up.

Mail ports get scanned constantly, and weak auth settings get hammered.

Require TLS for submission: allow auth only on 587/465 and prefer TLS.
Disable plaintext auth on port 25: keep it for server-to-server only.
Rate-limit brute force: Fail2Ban or control-panel equivalents for auth endpoints.
Keep SSH tight: most mail incidents start with server access problems, not SMTP itself.

For server access, pair this with our SSH hardening tutorial.

If you need safer admin access without exposing SSH broadly, a jump host pattern is covered here: SSH jump host setup tutorial.

Checklist: your 15-minute SMTP triage runbook

Run nc -vz tests to confirm reachability on 25/587/465.
Confirm daemon listening: ss -lntp.
Check firewall rules (UFW/firewalld) and upstream policy on outbound 25.
Validate MX + A/AAAA + PTR alignment with dig.
Validate TLS with openssl s_client (25 STARTTLS, 587 STARTTLS, 465 TLS).
Validate auth with swaks on 587 with TLS.
Read the right logs: Postfix mail log or Exim mainlog; inspect queue size.
Confirm SPF/DKIM/DMARC are published and match your sending path.

Summary: make SMTP boring again

Reliable mail comes from proof, not hunches.

Confirm reachability, confirm TLS, and confirm auth. Then clean up DNS and policy alignment.

You’ll stop taking risky shortcuts—like disabling encryption—just to get a message out.

If you want a clean foundation for mail and hosting services, start with a HostMyCode VPS sized for your workload.

If you’d rather not spend evenings babysitting mail queues, managed VPS hosting is the practical upgrade for production operations.

If you’re troubleshooting SMTP on a busy web server, consistency beats clever tweaks. HostMyCode offers plans for hands-on admins and for teams that want a guided setup with fewer surprises.

Pick a HostMyCode VPS for full control, or choose managed VPS hosting if you want help keeping mail, DNS, and security defaults production-ready.

FAQ

Should I use port 25 or 587 for sending from WordPress?

Use 587 with STARTTLS (or 465 with TLS) and authenticate. Port 25 is for server-to-server delivery and is more likely to be blocked outbound.

Why does SMTP work from my laptop but not from my VPS?

Your VPS might have outbound TCP/25 blocked by provider policy, or your server IP may be on a restrictive network range. Test from the VPS with nc -vz and use 587/465 with auth if needed.

What’s the fastest way to debug TLS errors on SMTP?

Run openssl s_client against the exact port your client uses, and include -servername for SNI. Look for hostname mismatch and chain verification errors.

Do I need reverse DNS (PTR) if I’m only sending via an SMTP relay?

It’s still helpful, but less critical if all outbound mail goes through the relay’s infrastructure. If your VPS sends directly to the internet, PTR alignment becomes important quickly.

My server accepts inbound mail, but Gmail/Outlook reject or spam it. Is that an SMTP issue?

Transport might be fine. Check SPF, DKIM, DMARC alignment, and rDNS. Policy failures often show up as bounces even when the SMTP connection succeeds.