Your email won't send — stuck spinning in the outbox. Here's how to diagnose SMTP auth failures, wrong ports, and relay misconfigurations.
You hit send. The email slides into your outbox. And sits there.
The little spinner icon mocks you. Five minutes pass. Ten. The message goes nowhere. You try again — same result. Eventually, Thunderbird throws an error you don't quite understand. Something about authentication. Or connection refused. Or STARTTLS not supported. Super helpful.
I've stared at that spinner more times than I'd like to admit. Once I spent 45 minutes — forty-five — convinced my provider was down, only to realize I'd typed "smpt" instead of "smtp" in the server field. Brilliant. Another time it was a missing @ symbol in my username. These are the kinds of mistakes you make at 2am when you're just trying to get email working so you can go to bed.
We're the JustEmails team, part of Velocity Digital Labs. We help people set up and troubleshoot email infrastructure every day. Here's the systematic approach to diagnosing why your email is stuck and fixing the SMTP misconfiguration that's causing it.
By the end of this, you'll be able to:
If you're not sure which port to use in the first place, our email ports guide covers 25 vs 465 vs 587 in detail. This post assumes you've already configured something — it's just not working.
Let's go through these in order of how often I see them.
Port 587 and port 465 look similar enough that people mix them up constantly. And port 25 — the legacy SMTP port — doesn't work from most consumer internet connections because ISPs block it to prevent spam.
Symptoms:
The fix:
Most providers accept one of two pairings:
Which of the two your provider actually opens is the thing to confirm, because getting this wrong produces exactly the silent-outbox symptom above. On JustEmails it's 587 with STARTTLS — we publish no implicit-TLS port at all, so if your client is set to 465 with SSL/TLS against mail.justemails.app, that alone is your bug: nothing is listening, so the client waits rather than reporting a failure. Authentication is PLAIN or LOGIN, which most clients label "Normal password".
Don't use port 25. Blocked. Even if your provider technically supports it, your ISP almost certainly doesn't allow outbound connections on that port. This has been standard since the mid-2000s — and yet people still try it. (I still try it sometimes. Old habits.)
Quick test: if you've been waiting more than 30 seconds with no error message, you're probably hitting a blocked or wrong port. Switch ports and try again.
This one's subtle. You've got the right port, but the wrong security setting — and the error messages are genuinely confusing.
Port 587 wants STARTTLS. The connection starts unencrypted, then upgrades to TLS after a handshake. If you select "SSL/TLS" (implicit) on port 587, you'll get a handshake failure because the server is expecting to negotiate STARTTLS first.
Port 465 wants implicit TLS. The connection is encrypted from the first byte. If you select "STARTTLS" on port 465, you'll get errors about TLS negotiation failing.
Symptoms:
The fix:
| Port | Security Setting | Also Called |
|---|---|---|
| 587 | STARTTLS | "TLS" in some clients |
| 465 | SSL/TLS | "Implicit TLS", "SSL" |
Match these exactly. I know the terminology varies between mail clients — Apple Mail calls it "TLS/SSL" while Thunderbird says "SSL/TLS" — but the concept is the same. Port 587 = upgrade-style encryption. Port 465 = encrypted from the start. Why mail clients can't just agree on what to call things is beyond me, but here we are.
The server connected, the TLS handshake worked, but then... authentication failed. Your username or password is wrong. Or so it claims.
Symptoms:
Why this happens (in order of likelihood):
Wrong username format. Some providers want your full email address (mike@example.com). Others want just the part before the @ (mike). Check your provider's documentation. JustEmails uses the full email address.
Two-factor authentication is enabled. On Google and Microsoft accounts, switching on 2FA stops your regular password working for SMTP. You need an "app password" — a separate password generated specifically for mail clients — and both of them keep it in security settings under that exact name. Not every provider works this way: JustEmails doesn't issue app passwords at all, so 2FA on the dashboard changes nothing about SMTP and the mailbox password remains the credential.
(This trips up more people than anything else. The error message says "authentication failed" but doesn't mention 2FA. Why would it? The server just sees a wrong password. It doesn't know you have 2FA enabled. Frustrating design — but that's the reality.)
SMTP access not enabled. Some providers require you to explicitly enable SMTP access in account settings. This is a security feature — it prevents mail clients from connecting until you opt in. Check your account's security or app access settings. If you're managing email across multiple products (like many SaaS founders building multiple apps), keeping track of which accounts have SMTP enabled becomes critical.
Caps lock or copy-paste whitespace. Laugh if you want, but I've seen this dozens of times. Passwords are case-sensitive. And if you copy-paste your password from a notes app, sometimes trailing whitespace comes along for the ride. I once spent 20 minutes debugging what turned out to be a single space character. Not my finest hour.
Server hostnames aren't standardized. You might assume it's smtp.yourdomain.com, but your provider might use mail.yourdomain.com, or outgoing.yourdomain.com, or something completely different like smtp-relay.provider.net.
Symptoms:
The fix:
Check your provider's official documentation. Don't guess. For JustEmails, it's mail.justemails.app — one host for SMTP, IMAP and POP3, and note the mail. rather than the smtp. prefix you'd assume from everyone else, which is exactly the kind of thing guessing gets wrong. For Gmail, it's smtp.gmail.com. For Outlook/Microsoft 365, it's smtp.office365.com (not outlook.com, which confuses people).
If you're managing email for your own domain, the SMTP server is still your provider's server, not your domain. Don't try to connect to smtp.yourdomain.com unless your DNS actually has that record pointing somewhere.
Sometimes the problem isn't your configuration at all — it's your network.
Symptoms:
Common causes:
Corporate firewalls often block SMTP ports. They want you to use their approved email systems, not random SMTP relays. If you're on a work network, this might be policy — talk to IT before trying workarounds.
Some VPNs interfere with SMTP. If you're connected to a VPN and email won't send, try disconnecting the VPN temporarily. VPN providers sometimes block or filter SMTP traffic to prevent their IPs from getting blacklisted for spam.
Public wifi at hotels and airports sometimes blocks outbound SMTP entirely. Use your phone's hotspot if you need to send urgent mail.
The test:
Try a different network. If email sends fine on a different connection, the problem is your original network, not your SMTP settings.
If authentication fails with 2FA enabled on a Google or Microsoft account, generate an app password in that account's security settings and use it instead. On JustEmails, keep using the mailbox password — there is no app password to generate.
Apple Mail can be finicky about caching old credentials. Annoying, but that's Apple. If you change the password and it still fails, try removing and re-adding the account entirely.
Outlook sometimes requires you to close and reopen the app for settings changes to take effect. Classic Outlook. Some things never change.
The new Outlook auto-configures most settings, which is great until it auto-configures them wrong.
If you can't edit settings (some accounts lock them), you may need to remove and re-add the account with manual configuration.
Before blaming your mail client, verify the SMTP server itself is reachable.
On Mac/Linux, open Terminal:
openssl s_client -connect smtp.yourprovider.com:465
For port 587 with STARTTLS:
openssl s_client -starttls smtp -connect smtp.yourprovider.com:587
If you see certificate information and a 220 response, the server is reachable and TLS is working. If you get "Connection refused" or the command hangs, there's a network problem between you and the server.
On Windows, use PowerShell:
Test-NetConnection -ComputerName smtp.yourprovider.com -Port 587
If TcpTestSucceeded shows True, the port is reachable. If it shows False, firewall or ISP is blocking.
Here's a quick reference for the cryptic errors you'll see:
| Error Message | Translation | Fix |
|---|---|---|
| Connection timed out | Port blocked or wrong | Try 587 or 465 |
| Connection refused | Server down or wrong hostname | Verify server address |
| 535 Authentication failed | Wrong username/password | Check creds, check 2FA |
| Certificate verify failed | Hostname mismatch | Use exact server hostname |
| STARTTLS not supported | Wrong security setting | Use SSL/TLS, not STARTTLS |
| SSL handshake failed | Wrong security type for port | Match port to security type |
| Relay access denied | Not authenticated | Check "requires auth" setting |
The "relay access denied" one deserves special mention. In the old days, SMTP servers let anyone send through them — open relays. That era ended in the late '90s when spam became unbearable. Now every server requires authentication. If you get "relay access denied," your client isn't sending credentials, or they're being rejected.
Sometimes everything is configured correctly and email still won't send. Before you lose your mind:
Check server status. Providers have outages. Check your provider's status page or Twitter. If their SMTP is down, no amount of troubleshooting on your end will help.
Check your account standing. If you've been flagged for spam or your account is suspended, SMTP will fail with auth errors. Log into webmail and see if you can send from there. For urgent business communication while email is down, consider having a backup like VeloCalls for voice outreach.
Check email quotas. Some providers limit how many emails you can send per day. Hit the limit, and SMTP will refuse new messages. JustEmails has such a limit and it is worth knowing the shape of: 20/day for an account's first week after a domain verifies, 200/day for the second, then 500/day from day 15 onward, counted across the whole account rather than per mailbox, with API sends in the same total. An outbox that jams right after a large batch is worth checking against that figure before you go back through the port settings.
Check blacklists. If your outgoing IP is blacklisted (more relevant for self-hosted setups), some receiving servers reject your mail. Tools like ClickzProtect help monitor traffic quality, though blacklisting is usually a sender reputation issue, not a relay config issue.
Email stuck in the outbox usually means your mail client can't connect to the SMTP server or authentication failed. Common causes: wrong SMTP port (using 25 instead of 587), incorrect username/password, a missing app password on a provider that issues them when 2FA is enabled, firewall blocking the connection, or STARTTLS/TLS security mismatch. Check your outgoing server settings against your provider's documentation — one wrong character in the server name or port can block everything.
Use port 587 with STARTTLS — it's the standard submission port, and on JustEmails it's the only one we publish, so pair it with STARTTLS rather than SSL/TLS. Some other providers also offer 465 with implicit TLS; mail.justemails.app does not, and pointing a client at 465 there gives you a connection that hangs instead of an error. Never use port 25 from a mail client; ISPs block it. If 587 is unreachable from your network, it's being blocked upstream — test from a different connection rather than changing the port.
SMTP authentication errors mean username or password is wrong. First, verify you're using your full email address as the username (not just the part before @). Second, if you have two-factor authentication enabled on a provider that issues app-specific passwords, such as Google or Microsoft, you need one of those rather than your regular login; JustEmails doesn't issue them, so the mailbox password stays correct there. Third, some providers require you to enable SMTP access separately in account settings. Finally, check for typos and make sure caps lock isn't on.
Webmail connects directly to the mail server's backend — no SMTP involved for sending. Your mail client uses SMTP, which requires separate authentication and correct port/security configuration. If webmail works but your client doesn't, the problem is always in your client's outgoing (SMTP) settings: wrong server hostname, wrong port, wrong security type, or wrong credentials.
Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.