Troubleshooting Email Delivery Issues

## Email Delivery Troubleshooting: A Systematic Approach Email delivery problems are frustrating because failures can happen at multiple points in a complex chain and the error messages are often cryptic. The key to effective troubleshooting is systematically ruling out causes rather than guessing. This guide works through the most common email delivery issues — from messages landing in spam to complete delivery failures — with specific diagnostic steps and fixes for each. ## Step 1: Identify the Failure Mode Before diving into DNS records, characterize exactly what's failing: **Email not delivered at all (hard bounce)**: Sender gets a Non-Delivery Report (NDR) with an error code **Email delivered to spam/junk folder**: Message arrives but recipients don't see it in inbox **Email not received but no bounce**: Message appears sent but recipient never gets it (soft failure or silent drop) **Email delivery delayed**: Message eventually arrives but after significant delay **Specific recipients affected, others fine**: Provider-specific or recipient-domain-specific issue The failure mode points to different root causes. ## Diagnosing Bounced Email (Hard Bounces) Non-Delivery Reports include an SMTP error code. These codes identify the problem: ### Common SMTP Error Codes | Code | Category | Typical Cause | |---|---|---| | 550 | User unknown | Recipient address doesn't exist | | 550 | SPF check failed | Your IP not in SPF record | | 550 | DMARC policy | DMARC enforcement blocking your email | | 550 | Blacklisted | Sending IP or domain on a blocklist | | 451 | Temporary failure | Receiving server issue, try again later | | 421 | Service not available | Recipient server temporarily unavailable | | 552 | Mailbox full | Recipient's quota exceeded | Read the full bounce message — it often contains the specific reason in human-readable text after the code. ### Checking SPF Failures If the bounce mentions SPF, diagnose the SPF record: 1. **Verify current SPF record**: Run `dig TXT yourdomain.com` or use DNS Record Helper 2. **Check that your sending server's IP is authorized**: Tools like mxtoolbox.com/spf can test SPF against a specific IP 3. **Check for multiple SPF records**: Only one `v=spf1` TXT record is allowed per domain — multiple records cause `permerror` 4. **Check lookup count**: More than 10 DNS lookups in SPF processing causes `permerror` Fix: Edit your SPF record to include the sending server's IP or service domain. Merge any duplicate records. ### Checking DMARC Failures DMARC failures are more complex — they require SPF or DKIM to also fail (or misalign): 1. **Check your DMARC record**: `dig TXT _dmarc.yourdomain.com` 2. **Check alignment**: Is the domain in `From:` header the same as the domain in the SPF check or DKIM signature? 3. **For forwarded email**: DMARC often fails for forwarded messages because SPF alignment breaks during re-delivery. Consider `p=quarantine` instead of `p=reject` if forwarding is involved Read aggregate DMARC reports (sent to the address in your `rua` tag) — they show exactly which sources are failing and why. ## Diagnosing Spam Folder Landing This is the most common complaint. Email arrives but goes to spam/junk instead of inbox. ### Step 1: Check Email Headers Ask a recipient to share the full email headers (in Gmail: three dots → "Show original"). Look for: ``` Authentication-Results: mx.google.com; dkim=fail [email protected] spf=pass (google.com: domain of [email protected] designates ...) dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) ``` A DKIM failure here reveals the exact problem. Check whether DKIM is even configured and whether the DNS record is in place. ### Step 2: Check Gmail's Spam Reasoning Gmail sometimes provides a reason for spam classification. In the spam folder, look for a message at the top explaining why the message was filtered (e.g., "This message seems dangerous," "Similar messages were identified as spam"). ### Step 3: Test with mail-tester.com Send a test email to the address provided at mail-tester.com and view your score. The report shows: - SPF check result - DKIM check result - DMARC check result - Blacklist status - Content analysis - Links to problematic elements A score below 8/10 means you have identifiable issues affecting deliverability. ### Step 4: Check Blacklist Status Use mxtoolbox.com/blacklists to check whether your sending domain or IP is on any major blacklists. Check both the domain name and the sending IP address. If blacklisted, identify why (complaint rate, spam trap hit, or explicit listing) and follow the delisting process for the specific list. ### Step 5: Examine Sending Reputation Register with Google Postmaster Tools (postmaster.google.com) and verify your domain. The dashboard shows: - Domain reputation (Low/Medium/High/Very High) - IP reputation - Spam complaint rate from Gmail users A "Low" reputation means Gmail is aggressively filtering your email. See Email Deliverability: How Domain Reputation Matters for the remediation process. ### Common Spam Causes and Fixes **Missing or failed DKIM** - Fix: Generate DKIM key in your email provider's admin console, add the TXT record to DNS, activate signing **SPF set to `?all` or `+all`** - Fix: Change `?all` or `+all` to `~all` or `-all` **Brand new domain, no reputation** - Fix: Warm up gradually over 4–8 weeks, start with highly engaged recipients **High complaint rate** - Fix: Remove complainers, clean list of unengaged subscribers, improve targeting and content relevance **Sending to purchased or unverified lists** - Fix: Stop immediately. Send only to confirmed opt-in subscribers. **Missing unsubscribe link (for bulk email)** - Fix: All marketing email must include a working unsubscribe mechanism and List-Unsubscribe header ## Diagnosing MX Record Problems If inbound email isn't arriving at all, the MX records are the first place to check. ### Verify MX Records Are Correct ```bash dig MX yourdomain.com ``` Compare output against what your email provider requires. If they don't match, you have stale or incorrect MX records. ### Check for Multiple/Conflicting MX Records If you see MX records for multiple mail providers, email is splitting between them. One provider gets some email, another gets the rest. Delete all MX records and add only your current provider's records. ### Check MX Record TTL If you recently changed MX records and email isn't arriving yet, DNS Propagation may be incomplete. Check TTL (Time To Live) on the old records — if it was 86400 (24 hours), cached resolvers may still be routing to the old server. Use DNS Record Helper to check what different global resolvers see for your MX records. If some show old records and others show new, propagation is still in progress. ### Test SMTP Connectivity After confirming MX records are correct, test that the mail server is actually accepting connections: ```bash nslookup -type=MX yourdomain.com # Get MX hostname telnet mail.yourmailserver.com 25 # Test SMTP port ``` If telnet times out or refuses connection, the mail server is not accessible on port 25 — a server-side or firewall issue, not a DNS problem. ## Diagnosing Authentication Configuration ### Testing SPF ```bash dig TXT yourdomain.com | grep spf ``` Check for common issues: - More than one TXT record starting with `v=spf1` (only one allowed) - Missing `include:` for a sending service you use - Too many includes (10 lookup limit) ### Testing DKIM ```bash dig TXT {selector}._domainkey.yourdomain.com ``` Replace `{selector}` with your actual DKIM selector (e.g., `google`, `selector1`, `s1`). If no record is returned, DKIM is not configured in DNS. After confirming the DNS record exists, check whether your email provider has DKIM signing enabled in its admin console (configuration in DNS alone doesn't activate signing). ### Testing DMARC ```bash dig TXT _dmarc.yourdomain.com ``` If no record is returned, add a DMARC record. If the record exists but email is still going to spam, check the `p=` value — `p=none` means no enforcement. ## Provider-Specific Issues ### Gmail Rejecting Your Email Gmail's rejection messages are usually specific. Common Gmail blocks: - **"Our system has detected that this message is 550-5.7.1 likely unsolicited mail"**: Reputation issue, check Postmaster Tools - **"This message does not have authentication information or fails to pass authentication"**: SPF or DKIM failure - **"The IP you're using to send mail is not authorized"**: SPF failure — your sending IP isn't listed Gmail's Postmaster Tools is essential for diagnosing Gmail-specific delivery issues. ### Microsoft/Outlook Rejecting Your Email Microsoft uses a different set of block codes. Check: - Microsoft's Smart Network Data Services (SNDS) for IP reputation data - Register for the Junk Mail Reporting Program (JMRP) to receive copies of complaints Common Microsoft block: "550 5.7.606 Access denied, banned sending IP" — your sending IP is on Microsoft's block list. Submit a delisting request at sender.office.com. ## Systematic Diagnostic Checklist Work through this list when email delivery issues arise: **DNS Verification** - [ ] MX records correct per email provider's documentation - [ ] Only one SPF Record TXT record, with correct syntax - [ ] DKIM TXT record present and matching provider's generated value - [ ] DMARC TXT record present at `_dmarc.yourdomain.com` **Authentication Testing** - [ ] Send test email to mail-tester.com → score ≥ 8/10 - [ ] Email headers show `spf=pass`, `dkim=pass`, `dmarc=pass` **Reputation Checks** - [ ] Domain not on major blacklists (mxtoolbox.com/blacklists) - [ ] Google Postmaster Tools reputation: Medium or High - [ ] Spam complaint rate < 0.1% **Infrastructure** - [ ] Reverse DNS (PTR Record) (PTR record) matches mail server hostname - [ ] Mail server SMTP port (25) accessible from external IPs - [ ] SSL certificate valid on mail server ## When to Contact Your Email Provider Some issues require your email provider's support: - You're certain DNS records are correct but DKIM signing still fails → Provider-side issue - Postmaster Tools shows high complaints but you can't identify the source → Need sending log access - Email routes to the correct server but doesn't appear in mailboxes → Delivery routing rules - Sudden, unexplained deliverability drop after years of reliable sending → IP reputation change by provider Document your troubleshooting steps before contacting support — it speeds resolution significantly. ## Next Steps - **SPF, DKIM, DMARC: Email Authentication Trilogy** — Configure authentication from scratch correctly - **MX Records Deep Dive: Email Routing Explained** — Deeper understanding of MX routing - **Email Deliverability: How Domain Reputation Matters** — Long-term reputation maintenance - **Domain-Based Email Security Best Practices** — Prevent security issues that cause delivery problems