Your SMTP stopped working. Emails aren’t going out. OTPs are failing. Users are complaining they never got their verification link.
And you have no idea what just broke.
It feels like your entire system is down – but in most cases, the actual problem is much smaller than that. SMTP failures almost always come down to a handful of common issues: wrong credentials, a blocked port, a missing DNS record, or a misconfigured setting nobody noticed until something went wrong.
In this guide, we’ll walk through the 10 most common SMTP errors, explain exactly why each one happens, and give you the step-by-step fix – so you can stop guessing and start sending.
Why Is SMTP Not Working? (Quick Answer)
SMTP stops working for a few core reasons:
- Wrong credentials – incorrect username, password, or API key
- Port or encryption mismatch – using the wrong port or SSL/TLS setting
- Firewall or hosting restrictions – your host is blocking outbound SMTP traffic
- Missing email authentication – no SPF, DKIM, or DMARC records configured
Most SMTP failures trace back to one of these four categories – and all of them are fixable once you know where to look.
What Is SMTP? (The Short Version)
SMTP stands for Simple Mail Transfer Protocol. It’s the system your application uses to send emails – think of it like a courier service for digital mail.
You hand it a message. It figures out where the recipient’s inbox is. It delivers the email. If anything goes wrong along the way – wrong address, locked gate, bad credentials – the email doesn’t arrive.
That’s it. Now let’s get into the actual errors.
10 Common SMTP Errors and How to Fix Them
Worth knowing: Most SMTP server not sending emails issues happen due to authentication or configuration problems – not server outages. Before assuming something is down, check your settings first.
Error 1: SMTP Authentication Failed (Error 535) – Causes & Fix
Error message:
535 Authentication failed
535 5.7.8 Username and Password not accepted
Why this happens:
Your SMTP server is rejecting your login. It doesn’t recognize the credentials you’re sending, so it won’t let you send anything.
Here’s where most people mess up: they assume the SMTP password is the same as their email account password. Often, it isn’t.
Common causes:
- Typing the wrong username or password
- Using a regular account password when an App Password or API key is required
- SMTP access is disabled in your email provider’s settings
- Two-factor authentication (2FA) is turned on, but no App Password has been generated
Real example:
A developer configures Gmail SMTP for sending transactional emails. They enter their regular Gmail password. Gmail has 2FA enabled, so it rejects that password with a 535 Authentication failed error – because it wants an App Password, not the regular one.
How to fix it:
- Confirm your SMTP username is your full email address (e.g., hello@yourdomain.com – not just hello)
- If 2FA is on, generate an App Password: Google Account → Security → App Passwords
- If using SendGrid, Mailgun, or similar – use an API key as the SMTP password, not your login password
- Enable SMTP access explicitly: Gmail → Settings → See all settings → Forwarding and POP/IMAP → Enable IMAP
- If you recently changed your email password, update it everywhere your SMTP config is stored
Error 2: SMTP Connection Timed Out – How to Fix SMTP Not Connecting
Error message:
Connection timed out
SMTP Error: Could not connect to SMTP host
Why this happens:
Your application is trying to reach the SMTP server, but nothing is responding. The connection attempt just hangs until it gives up.
This is almost always a port or firewall issue – not a server problem.
Common causes:
- Using port 25, which most hosting providers block to prevent spam
- A firewall on your server blocking outbound SMTP traffic
- Wrong SMTP host address, so the request is going nowhere
Real example:
A website on shared cPanel hosting tries to send emails using port 25. The provider silently blocks port 25 across all shared accounts. The connection times out every time – even though every other setting is correct.
How to fix it:
- Switch to the correct port:
- Port 587 – TLS/STARTTLS (recommended for most setups)
- Port 465 – SSL
- Port 25 – avoid this; blocked by most hosts and ISPs
- Test your connection from the terminal:
- telnet smtp.yourprovider.com 587
If it hangs or fails, the port is blocked on your end.
- On a VPS or dedicated server, check outbound firewall rules:
- ufw status
- iptables -L -n | grep 587
- Contact your hosting provider and ask them to whitelist outbound traffic on port 587 or 465.
Error 3: SMTP Server Not Responding – Fix SMTP Host Connection Failure
Error message:
Could not connect to SMTP host
SMTP connect() failed
No route to host
Why this happens:
Unlike a timeout (where the server ignores you), this error means the connection fails immediately. The server either doesn’t exist at that address, or DNS can’t resolve it.
This silently breaks your emails – your code thinks it’s sending, but nothing is going through.
Common causes:
- Typo in the SMTP hostname
- DNS resolution failing for the server address
- The SMTP provider’s servers are temporarily down
Real example:
Someone configures SMTP with host smtp.google.com instead of smtp.gmail.com. These look almost identical – but one resolves to a real SMTP server and the other doesn’t. Every send attempt fails immediately with an SMTP host connection failure.
How to fix it:
- Verify the exact SMTP hostname from your provider’s documentation:
- Test DNS resolution from your terminal:
- nslookup smtp.yourprovider.com
- Check your provider’s status page for outages before spending time debugging config.
- If DNS fails, try using the server’s IP address temporarily to confirm it’s a DNS issue.
Error 4: Emails Going to Spam – Fix SMTP Deliverability Issues
Error message:
There is no error. The email sends successfully – but lands in the spam or junk folder.
Why this happens:
This is one of the most frustrating SMTP problems. Your configuration is working, but inbox providers don’t trust your emails enough to deliver them properly.
This is often ignored – but it directly kills your email deliverability.
Inbox providers like Gmail and Outlook run constant checks on every incoming email. If your domain lacks the right authentication records, they flag your emails as suspicious – even when your content is completely legitimate.
Common causes:
- Missing SPF record – receiving servers can’t verify you’re allowed to send from your domain
- Missing DKIM signature – emails aren’t cryptographically signed, so they look unverified
- No DMARC policy – your domain has no declared policy for handling suspicious emails
- Shared IP reputation – on shared hosting, other users may be spamming from the same IP, damaging your sender score
- Spammy content – words like “FREE!!!”, “Act Now”, or “Guaranteed” in subject lines
Real example:
A SaaS company launches and starts sending welcome emails from hello@theirstartup.com. Their SPF record isn’t configured. Gmail checks whether theirstartup.com has authorized that sending server – it hasn’t. Every welcome email goes straight to spam. New users think the signup flow is broken.
How to fix it:
- Set up SPF – Add a DNS TXT record:
- v=spf1 include:_spf.google.com ~all
(Replace with your provider’s SPF include value)
- Set up DKIM – Your email provider generates a DNS record like this:
- selector._domainkey.yourdomain.com TXT “v=DKIM1; k=rsa; p=MIGfMA0…”
Add it exactly as given. Once propagated, every outgoing email is cryptographically signed.
- Set up DMARC – Add this DNS TXT record:
- _dmarc.yourdomain.com TXT “v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com”
- Test your spam score before sending: mail-tester.com
- Avoid spam trigger words in subject lines and body copy.
- If you’re on a new domain or IP, warm up gradually – start with low sending volumes and increase over weeks.
Error 5: Too Many Requests / SMTP Rate Limit Error (421) – How to Fix
Error message:
421 Too many connections from your IP
421 4.7.0 Try again later
450 Requested action not taken – try again
Why this happens:
You’re sending too many emails too fast. The SMTP server is throttling you because you’ve hit the provider’s limit – on emails per hour, per day, or on simultaneous connections.
This is a common email sending failed issue for apps that don’t use a proper queue.
Real example:
An e-commerce store runs a flash sale and sends 40,000 promotional emails at once through a basic SMTP account. The provider allows 200 emails/hour. The cap hits within two minutes. The remaining 39,800 emails fail with 421 errors.
How to fix it:
- Implement an email queue – never fire all emails simultaneously. Use a background job system:
- Node.js: Bull or BullMQ
- Python: Celery
- Ruby: Sidekiq
- Stay within your provider’s limits – check their caps and stay 20% below to avoid edge failures.
- Add delays between batches – if sending 10,000 emails, spread them over hours, not seconds.
- Upgrade your plan or switch to a provider with higher limits for your sending volume.
- Separate transactional and marketing emails – keep OTPs and receipts on a different SMTP config so a bulk campaign never blocks a critical password reset.
Error 6: SMTP SSL/TLS Error – Fix SSL Handshake and Encryption Mismatch
Error message:
SSL: WRONG_VERSION_NUMBER
SSL handshake failed
Could not initiate SSL/TLS connection
Why this happens:
Your app is trying to establish a secure connection, but the encryption settings don’t match what the server expects. The handshake fails before a single byte of your email is transmitted.
This is often ignored – people assume it’s a network issue when it’s actually an SMTP configuration problem.
Common causes:
- Using port 465 with secure: false (should be true)
- Using port 587 with secure: true (should be false, then STARTTLS kicks in)
- Using an outdated TLS version the server no longer supports
Real example:
A developer sets port: 465 and secure: false in their Nodemailer config. Port 465 requires SSL – secure must be true. The SSL handshake fails every single time.
How to fix it:How to Fix It
1. Match port with encryption (this is where most people mess up):
- Port 465 → SSL → secure: true
- Port 587 → STARTTLS → secure: false
If you mismatch these, the connection will fail every time.
2. Example in Nodemailer (Node.js)
// Port 465 — SSL
const transporterSSL = nodemailer.createTransport({
host: 'smtp.yourprovider.com',
port: 465,
secure: true,
auth: {
user: 'your@email.com',
pass: 'yourpassword_or_api_key',
},
});
// Port 587 — TLS / STARTTLS
const transporterTLS = nodemailer.createTransport({
host: 'smtp.yourprovider.com',
port: 587,
secure: false,
auth: {
user: 'your@email.com',
pass: 'yourpassword_or_api_key',
},
});
3. Example in PHPMailer
$mail->isSMTP();
$mail->Host = 'smtp.yourprovider.com';
$mail->SMTPAuth = true;
$mail->Username = 'your@email.com';
$mail->Password = 'yourpassword';
// Port 587 — TLS
$mail->SMTPSecure = 'tls';
$mail->Port = 587;
// Port 465 — SSL (alternative)
// $mail->SMTPSecure = 'ssl';
// $mail->Port = 465;
4. Important Note
Do not mismatch port and encryption settings:
- Port 465 requires SSL
- Port 587 uses STARTTLS
If these don’t align, the SMTP connection will fail before sending any email.
Error 7: SMTP Sender Address Rejected (Error 550) – Causes & Fix
Error message:
550 Sender rejected
553 5.1.3 Sender address not allowed
501 Bad sender address syntax
Why this happens:
The SMTP server is refusing to relay your email because the “From” address isn’t authorized. You’re claiming to be a sender you’re not – at least as far as the server is concerned.
Real example:
A developer sets the From address as noreply@gmail.com to make emails look official. Gmail’s SMTP server rejects it immediately – you can only send from addresses tied to your authenticated account. You don’t own @gmail.com.
How to fix it:
- Only send from email addresses you own and have verified with your SMTP provider.
- Use a domain-based email for all application sending:
- noreply@yourapp.com
- yourapp@gmail.com
- Verify your sender domain in your provider dashboard – SendGrid, Mailgun, and Amazon SES all require domain verification before you can send.
- Make sure the “From” address matches the domain your SMTP account is authorized for. If you log in as team@yourdomain.com, send from @yourdomain.com.
Error 8: Invalid Recipient Address (Error 550) – Fix Email Bounce Issues
Error message:
550 5.1.1 User unknown
501 Invalid address format
550 No such user here
Why this happens:
The email address you’re delivering to doesn’t exist, is incorrectly formatted, or has been deleted. The receiving server bounces it back immediately.
Real example:
A user signs up with john@gmial.com – a typo for gmail. Your system stores it without validation. When you send the welcome email, the server at gmial.com can’t find john. The email bounces, and the user never onboards.
How to fix it:
- Validate email format at signup – use a library before storing any address:
- JavaScript: validator.js
- Python: email-validator
- PHP: filter_var($email, FILTER_VALIDATE_EMAIL)
- Use double opt-in – require users to confirm their email before you send anything critical.
- Handle bounces automatically – when an email hard-bounces, remove that address from your system immediately.
- Monitor bounce rates – anything above 2–5% can get your SMTP account flagged or suspended.
Error 9: SMTP Blocked by Hosting Provider – Fix Shared Hosting SMTP Issues
Error message:
Connection refused
Port blocked
SMTP relay not permitted
Why this happens:
Shared hosting providers block outbound SMTP ports – particularly port 25 – to prevent their servers from being used to send spam. This is a policy restriction, not a bug.
No amount of SMTP configuration changes will fix this. You need a different sending infrastructure.
Real example:
A developer builds a contact form on cPanel shared hosting. They configure PHPMailer with a third-party SMTP service on port 587. Everything looks correct – but the host blocks all outbound SMTP connections. Emails never leave the server.
How to fix it:
- Contact your host and ask which SMTP ports are open, or whether external SMTP relay is permitted at all.
- If they don’t allow it – and most shared hosts don’t – the correct fix is to route emails through a dedicated SMTP service rather than fighting the hosting restriction.
This is exactly where a service like PhotonConsole Relay solves the problem cleanly. Instead of depending on your web host’s restricted infrastructure, PhotonConsole provides:
- A dedicated SMTP relay that isn’t tied to your hosting environment
- High deliverability with SPF, DKIM, and DMARC support built in
- Scalable sending limits that grow with your application
- Detailed delivery logs so you know exactly what happened to every email
If you’re constantly losing emails because of shared hosting restrictions, switching to a dedicated SMTP provider is the cleanest and most permanent fix. Setup takes minutes – and you stop depending on infrastructure that was never designed for reliable application email.
Error 10: Misconfigured SMTP Settings – How to Fix SMTP Configuration Problems
Error message: Generic – could be connection errors, authentication failures, or timeouts – depending on which setting is wrong.
Why this happens:
Sometimes there’s no single dramatic failure. A small typo in your config – wrong port number, incorrect hostname, mismatched encryption – quietly breaks everything. And the error messages often point you in the wrong direction.
Here’s where most people waste hours: they check firewalls, credentials, DNS – when the actual issue is a single transposed digit in the port number.
Real example:
A developer copies SMTP settings from their provider docs but accidentally types port 578 instead of 587. Every connection attempt fails with a timeout. They spend two hours debugging – when the actual issue is one wrong number.
How to fix it:
Go through every SMTP setting one by one against your provider’s official documentation:
| Setting | What to Check |
| Host | Exact hostname – no typos, no trailing spaces |
| Port | 587 for TLS, 465 for SSL – not 25, not 578 |
| Username | Full email address, not just the handle |
| Password | Case-sensitive – use App Password if 2FA is on |
| Encryption | Must match port: SSL for 465, TLS for 587 |
| From address | Must be an authorized sender on your account |
Test your settings before deploying:
- SMTPer.net – quick SMTP connection test
- MXToolbox SMTP Test – full diagnostic
The Real Problem: Infrastructure, Not Just Config
If you’ve gone through this entire list and are still hitting errors – or if the same problems keep coming back – the issue probably isn’t your code.
Shared hosting SMTP blocks, poor IP reputation, rate limits on consumer email accounts – these aren’t bugs you can configure your way out of. They’re fundamental limitations of trying to run application email through infrastructure that was never built for it.
If you’re constantly facing SMTP errors due to hosting restrictions, poor deliverability, or unreliable servers, switching to a dedicated SMTP service solves most of these issues in one move.
PhotonConsole provides stable, production-ready SMTP infrastructure with high deliverability, proper authentication support, and scalable sending limits. Instead of debugging the same email sending failed issues every month, you get emails that actually reach the inbox – and logs that tell you exactly what happened when they don’t.
Pro Tips to Keep SMTP Working Reliably
Always use a domain-based email address for sending. Use noreply@yourapp.com instead of yourapp@gmail.com. Free email providers impose strict limits on SMTP usage and flag your emails more aggressively. This is a foundational part of any solid SMTP configuration.
Set up SPF, DKIM, and DMARC – all three. These are no longer optional. If your domain is missing any of them, major inbox providers will quietly downgrade or block your emails. This is often ignored until spam complaints start coming in.
Keep transactional and marketing emails on separate SMTP setups. Use one SMTP configuration for OTPs, receipts, and notifications – and a separate one for newsletters or campaigns. A bulk marketing send should never be able to block a critical password reset email.
Monitor your email logs regularly. Don’t wait for users to report missing emails. Most SMTP providers offer delivery logs with bounce codes and failure reasons. Check them proactively – before users start complaining.
Handle bounces automatically. When an email hard-bounces, remove that address from your system immediately. Continuously sending to known-bad addresses damages your sender reputation and can get your SMTP account suspended.
Never use shared hosting SMTP for production applications. It’s acceptable for a contact form on a personal blog. It is not appropriate for any application that sends OTPs, onboarding emails, or transactional receipts at any meaningful volume.
Related SMTP Issues You Might Face
Even after fixing the errors above, some users run into platform-specific or environment-specific SMTP problems. Here are the most common ones:
SMTP server not sending emails: Usually caused by a misconfigured port, blocked firewall rule, or authentication failure. Start by verifying your host, port, and credentials – then test with an SMTP diagnostics tool.
SMTP not working in WordPress: WordPress uses the wp_mail() function with PHP’s mail() by default, which often gets blocked by hosts or flagged as spam. Install an SMTP plugin (like WP Mail SMTP) and connect it to a dedicated SMTP provider for reliable delivery.
SMTP not working in PHP (PHPMailer): Common issues include incorrect SMTPSecure settings (tls vs ssl), mismatched port, or missing SMTPAuth = true. Enable PHPMailer’s debug mode ($mail->SMTPDebug = 2) to see exactly where the connection fails.
Gmail SMTP not working: Gmail SMTP requires either an App Password (if 2FA is enabled) or OAuth2 authentication. Standard passwords no longer work for third-party SMTP access. Also confirm that IMAP is enabled in Gmail settings before connecting.
SMTP port blocked error: If port 587 or 465 is blocked, your hosting environment is the problem – not your config. Switch to a dedicated SMTP relay service, or contact your host to request the port be opened.
Frequently Asked Questions About SMTP Errors
Q1. Why is my SMTP not working?
The most common reasons are incorrect credentials, wrong port number, firewall or hosting restrictions blocking outbound SMTP, or missing DNS authentication records (SPF, DKIM, DMARC). Start by verifying your SMTP host, port, username, and password against your provider’s documentation – most SMTP configuration problems are in these four settings.
Q2. Which SMTP port should I use?
Port 587 with TLS is the recommended standard for most applications. It’s widely supported, rarely blocked, and works with STARTTLS encryption. Use port 465 with SSL if your provider specifically requires it. Avoid port 25 – it’s blocked by most hosting providers and ISPs to prevent spam.
Q3. How do I fix an SMTP authentication error (535)?
Confirm your username is your full email address and your password is correct. If the account has 2FA enabled, generate an App Password for SMTP access. For services like SendGrid or Mailgun, use your API key as the SMTP password – not your account login. Also make sure SMTP access is explicitly enabled in your provider’s settings.
Q4. Why are my emails going to spam even though SMTP is working?
This is a deliverability problem, not an SMTP configuration error. The most common causes are missing SPF, DKIM, or DMARC records, a poor sender IP reputation (especially on shared hosting), or spam-triggering content in your subject line or body. Set up all three DNS authentication records and test your email at mail-tester.com before sending at scale.
Q5. What’s the difference between SMTP and a transactional email service?
SMTP is the protocol – the rules that govern how emails travel from one server to another. A transactional email service like PhotonConsole manages that protocol for you, along with deliverability infrastructure, bounce handling, authentication setup, and sender reputation. You still connect via SMTP, but the service handles everything beneath that makes emails actually land in the inbox.
Conclusion: Stop Patching SMTP – Fix the Infrastructure
Most SMTP errors are solvable. Wrong credentials, incorrect ports, missing DNS records – these are all fixable with the right configuration and the fixes in this guide.
But if SMTP keeps failing – emails bouncing, hosting providers blocking ports, deliverability problems resurfacing week after week – you’re no longer dealing with a configuration error. You’re dealing with an infrastructure problem.
And if your business depends on email, this is not a small issue. Unreliable SMTP directly affects user experience, conversions, and revenue. Every failed OTP is a user who can’t log in. Every missed onboarding email is a customer who churns before they start. Every blocked transactional receipt is a support ticket waiting to happen.
Using shared hosting or consumer email accounts to send application emails is like shipping products through a personal car instead of a courier network. It works until it doesn’t – and when it breaks, it breaks at the worst possible time.
Switching to a dedicated SMTP service like PhotonConsole is the one change that eliminates most of these problems permanently. Stable relay infrastructure, proper authentication support, real-time delivery logs, and scalable sending limits – so you stop firefighting and get back to building.
Read More About Email Deliverability
Understanding SMTP errors is only half the picture. If your emails are sending successfully but still not landing in the inbox, the problem goes deeper – and it’s worth understanding fully.
For a detailed breakdown of why emails land in spam and exactly how to fix it, read our complete guide:
👉 Why Emails Go to Spam in Gmail – 7 Real Reasons & Fixes (2026)