Email Not Being Delivered: Complete Debugging Guide
Embed This Widget
Add the script tag and a data attribute to embed this widget.
Embed via iframe for maximum compatibility.
<iframe src="https://ipfyi.com/iframe/guide/email-not-delivered/" width="420" height="400" frameborder="0" style="border:0;border-radius:10px;max-width:100%" loading="lazy"></iframe>
Paste this URL in WordPress, Medium, or any oEmbed-compatible platform.
https://ipfyi.com/guide/email-not-delivered/
Add a dynamic SVG badge to your README or docs.
[](https://ipfyi.com/guide/email-not-delivered/)
Use the native HTML custom element.
Step-by-step guide to diagnosing email delivery failures — from SPF and DKIM misconfiguration to IP reputation and reverse DNS issues.
Why Email Gets Rejected or Lost
Email delivery failures are among the most frustrating issues to debug because the problem could sit anywhere in a chain that spans your mail server, DNS configuration, IP reputation, and the receiving mail system. Modern spam filters apply dozens of checks before accepting a message, and a single misconfiguration can silently discard legitimate email.
This guide walks through every layer of email deliverability, from fundamental DNS records to advanced tools used by professional senders.
Check SPF, DKIM, and DMARC Records
These three DNS-based mechanisms form the foundation of email authentication. Start here before investigating anything else.
SPF (Sender Policy Framework)
SPF specifies which IP addresses are authorized to send email for your domain. A receiving mail server performs a DNS lookup on your domain and compares the sending IP against the list.
# Query your SPF record
dig TXT yourdomain.com | grep spf
# Example valid SPF record
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all
Common SPF mistakes:
| Problem | Symptom | Fix |
|---|---|---|
| Missing SPF record | PermError: no SPF record found |
Add TXT record with v=spf1 |
| Too many DNS lookups | PermError: too many DNS lookups |
Flatten nested includes (max 10) |
| Wrong qualifier | Legitimate email soft-fails | Change ~all to -all only when confident |
| Sending IP not listed | SPF fail for new relay | Add IP or include the relay's domain |
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outgoing messages. The receiving server verifies the signature against your public key in DNS.
# Query DKIM record (selector name varies by provider)
dig TXT default._domainkey.yourdomain.com
dig TXT google._domainkey.yourdomain.com
dig TXT mail._domainkey.yourdomain.com
# A valid DKIM TXT record looks like:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA...
If the p= field is empty, the key has been revoked. Generate a new keypair and update DNS.
DMARC (Domain-based Message Authentication)
DMARC ties SPF and DKIM together and tells receivers what to do when checks fail.
dig TXT _dmarc.yourdomain.com
# Example policy
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100
Start with p=none to collect reports without affecting delivery, then move to p=quarantine, then p=reject.
Analyze Email Headers
Raw email headers contain the full delivery path and authentication results. Access them in Gmail via More → Show original, in Outlook via File → Properties.
Key headers to examine:
Received: from mail.sender.com (203.0.113.10) by mx.receiver.com
Authentication-Results: mx.receiver.com;
spf=pass (sender IP is 203.0.113.10)
dkim=pass header.d=yourdomain.com
dmarc=pass
X-Spam-Status: No, score=-1.5
Walk the Received: headers from bottom to top — each hop adds a new header. Long delays between hops indicate queuing problems. Use Google's Message Header Analyzer to parse headers automatically.
# Simulate delivery with SMTP conversation
telnet mail.yourdomain.com 25
EHLO test.local
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: Test
.
QUIT
Check IP Reputation
If your sending IP has been blocklisted, even perfectly configured authentication will not help. Spam blacklists (RBLs) maintain lists of IPs that have sent spam or been flagged for abuse.
# Check a single IP against common blacklists
# Replace with your actual sending IP
IP="203.0.113.10"
# Manual dig lookups against major RBLs
dig +short ${IP##*.}.${IP%.*.*.*}*.zen.spamhaus.org
dig +short ${IP##*.}.${IP%.*.*.*}*.bl.spamcop.net
# Or use mxtoolbox (web-based, checks 100+ RBLs)
# https://mxtoolbox.com/blacklists.aspx
Key blacklists to check:
| Blacklist | Operator | Removal Process |
|---|---|---|
| Spamhaus ZEN | Spamhaus | Self-service at spamhaus.org |
| SpamCop BL | Cisco | Auto-expires in 24-48 hours |
| Barracuda BRBL | Barracuda | Request at barracudacentral.org |
| Microsoft SNDS | Microsoft | Smart Network Data Services portal |
| Google Postmaster Tools |
If your IP is listed, identify what triggered the listing (a compromised account, open relay, or misconfigured bounce handling) before requesting removal.
Verify Reverse DNS
A missing or mismatched PTR record is an immediate red flag for spam filters. Your sending IP should resolve to a hostname, and that hostname should forward-resolve back to the same IP (FCrDNS — Forward-Confirmed Reverse DNS).
# Check PTR record for your sending IP
dig -x 203.0.113.10
# Verify FCrDNS: the hostname from PTR should resolve back
dig mail.yourdomain.com
# Quick one-liner
host 203.0.113.10 && host $(host 203.0.113.10 | awk '{print $NF}')
For cloud-hosted servers, PTR records are set through your provider:
- AWS: Elastic IP → reverse DNS request in EC2 console
- GCP: Compute → VM instance → Edit → Custom hostname
- DigitalOcean: Networking → Floating IPs → Edit → Reverse DNS
- Hetzner: Server properties → set rDNS directly
The PTR hostname should match your MAIL FROM domain or the SMTP greeting hostname.
Test with Mail-Tester
Mail-Tester is the fastest way to get a comprehensive deliverability score. It generates a unique test address; you send an email to it and receive a detailed report.
What Mail-Tester checks:
- SPF, DKIM, DMARC alignment
- HTML/text ratio
- Spam trigger words
- Image-to-text ratio
- Blacklist status
- Unsubscribe link presence
- Broken links
A score of 9/10 or higher is considered good. Anything below 7/10 will likely cause deliverability problems with major providers.
Google Postmaster Tools
If you send significant volume to Gmail addresses, Google Postmaster Tools provides sender reputation data directly from Google's systems.
After verifying your domain, you gain access to:
| Dashboard | What It Shows |
|---|---|
| Spam Rate | Percentage of your mail marked as spam by Gmail users |
| Domain Reputation | HIGH / MEDIUM / LOW / BAD |
| IP Reputation | Per-IP reputation for your sending IPs |
| Delivery Errors | Bounce rates and reasons |
| Encryption | TLS encryption rate for inbound/outbound |
| DMARC | Authentication pass rate |
A spam rate above 0.1% will trigger filtering. Above 0.3% can result in blocking. Monitor this dashboard continuously.
Warming Up a New IP
A brand-new IP address has no sending history, and email providers treat unknown IPs with suspicion. Sending large volumes immediately from a fresh IP almost guarantees filtering.
IP warm-up schedule example:
| Week | Daily Volume | Cumulative |
|---|---|---|
| 1 | 200 | 1,400 |
| 2 | 1,000 | 8,400 |
| 3 | 5,000 | 43,400 |
| 4 | 20,000 | 183,400 |
| 5+ | Full volume | — |
Best practices during warm-up:
- Send only to highly engaged recipients (users who have recently opened or clicked)
- Maintain low bounce rates (remove invalid addresses before sending)
- Keep spam complaints below 0.08%
- Ensure a consistent sending cadence — gaps reset your reputation
- Monitor Postmaster Tools and bounce logs daily during this period
# Check your current sending limits with major providers
# Gmail: monitor via Postmaster Tools
# Microsoft: register at JMRP (Junk Mail Reporting Program)
# https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx
A properly warmed IP with clean authentication will achieve inbox placement rates above 95% with all major providers.