Email stops sending because mail queue services hang, SPF or DKIM records fail strict verification, or provider filters flag traffic as spam. You fix this by checking mail.log, validating DNS alignment, and ensuring your reverse PTR record matches the hostname. Most outages resolve within minutes once you isolate whether the block is local or remote.
The first step is boring but necessary. You need to see what the server actually says. In 2026, modern mail transfer agents (MTAs) like Postfix, Exim, or Sendmail write detailed traces. If you use cPanel, check the “Email Delivery” section. If you run headless servers, open your terminal.
Run this command to dump the last 50 lines of the mail log:
tail -n 50 /var/log/mail.log
Look for three specific patterns:
In support tickets I handled, the usual culprit was a full disk. When /var/mail fills up, the MTA stops processing new messages. Check disk space with df -h first. If usage is above 95, clean up logs or old cron outputs immediately.
Email protocols have tightened significantly. Major providers like Gmail, Outlook, and Yahoo now enforce strict alignment checks. If your SPF, DKIM, or DMARC records are misconfigured, mail bounces silently in many cases. The sender sees a generic “delivery failure” while the server logs show a policy rejection.
SPF (Sender Policy Framework) lists IP addresses allowed to send mail.
DKIM (DomainKeys Identified Mail) signs the email header with a private key.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers what to do if SPF or DKIM fails.
A common error occurs when a website migrates to a new VPS. The new IP sends mail, but the SPF record still points only to the old IP. The receiver sees a mismatch. The email goes to spam or bounces.
To fix this:
p=quarantine or p=reject.Cloudflare and Google both publish detailed guides on these standards. According to DMARC.org, organizations with properly configured DMARC records see a 40% reduction in phishing complaints related to their domain.
This is the most overlooked issue for new VPS users. Many cheap hosting providers and cloud instances (like DigitalOcean or Linode) block outbound port 25 by default. This prevents abusive spam bots from using your server as a relay.
When port 25 is blocked, your mail client hangs. It tries to connect, times out, and retries. Your queue grows. Users complain that “email is not sending.”
To test connectivity, run:
telnet mail.gmail.com 25
If the connection closes immediately or times out, port 25 is likely blocked on your end. You cannot force this open via firewalls alone. You must request unblocking from your hosting provider. Some providers require a support ticket explaining your legitimate use case. Others offer alternative submission ports like 587 or 2525, which work for SMTP relay but not for direct MTM communication.
If you cannot unblock port 25, switch to a transactional email service. Tools like Mailgun, SendGrid, or Amazon SES handle the heavy lifting. They have dedicated IPs and reputation management. You just send an API request, and they guarantee delivery. This is often the best long-term fix for high-volume sends.
Sometimes the server is fine, but the queue is stuck. This happens when a recipient domain has an MX record that points to an unreachable IP. The MTA keeps retrying, re-adding the message to the queue every 30 seconds or so.
Use this command to check your queue:
postqueue -p
If you see hundreds of messages for one domain, that domain is the bottleneck. You can clear them manually with:
postqueue -d 1A2B3C
(replace 1A2B3C with the Queue ID).
Why does this matter for your business? If you are sending marketing blasts, a single bad DNS entry for a user can clog your queue. This delays emails to valid users. In 2026, real-time delivery is expected. A 2-minute delay might be acceptable. A 2-hour delay looks like a server failure.
Monitor your queue depth. If it exceeds 100 messages, investigate the top destination domains. Check their MX records using dig mx example.com. If the IP is down, you may need to blacklist that subdomain temporarily.
Even if your DNS is perfect, content can trigger filters. In 2026, AI-driven spam filters analyze headers, links, and body text. They look for patterns: too many links, broken UTF-8 characters, or subject lines that mimic known phishing attacks.
Check your headers. Enable debug output in your SMTP config. Look for the Authentication-Results header in received emails. It tells you exactly why a filter caught your mail.
Common content triggers:
I once fixed an outage where a client’s newsletters stopped arriving. The logs looked fine. The DNS was correct. It turned out their new template included a base64-encoded font. The filter flagged the large binary blob as malware. Removing the font solved the issue instantly.
Always test with a disposable account before sending to production. Use services that analyze headers in real-time. This saves you from the embarrassment of a mass bounce.
Gmail maintains a dynamic blacklist of IPs with high bounce rates or spam complaints. If your IP was previously abused (a compromised server), it stays blacklisted for days. Check your IP on Spamhaus or Gmail’s whitelist status. If listed, request delisting immediately. Until then, switch to a different IP or use an SMTP relay.
No. Every email needs a source IP to be verifiable. If you are on a shared host, you share the IP with others. If one of those users sends spam, your emails suffer too. Dedicated IPs cost extra on most hosting plans but are necessary for serious sending. Always pair a dedicated IP with a static reverse DNS (PTR) record.
POP3 is for receiving mail to your local client. SMTP is for sending mail. If your “email not sending” issue is only in Thunderbird or Outlook, check your SMTP server settings. Ensure the username, password, and port (usually 465 for SSL) are correct. Authentication failures here are the #1 client-side error.
Not directly, but indirectly yes. If your CDN changes your server’s public IP for web traffic, ensure your mail servers bypass the CDN. Mail should come directly from the origin IP. If the CDN’s IP is not in your SPF record, strict receivers will reject the mail. Keep mail DNS records separate from web DNS records.