Diagnostic flowchart for email failures — from "recipient didn't receive" to root cause. Covers outbound sending issues, DNS problems, receiver rejection, and silent drops. Focused on the most common UK failure modes with specific commands and tools.
Before diagnosing:
Narrow the scope: one-off vs systemic, recipient-specific vs sender-specific.
Look in sender's inbox (including spam folder) for a Non-Delivery Report. If found:
5.1.1 = bad mailbox, 5.7.1 = policy, 4.2.2 = full, 5.7.9 = DMARC.Bounce clarity usually jumps straight to root cause. No bounce → continue diagnostic.
Is the message still queued (deferred) or did it ever leave?
# Postfix
mailq | grep message-id
# Exim
exim -bp | grep message-id
# Check mail server logs for the specific Message-ID
grep MESSAGE-ID /var/log/mail.logFindings:
Recipient's MX must resolve correctly:
# Lookup recipient's MX
dig MX recipient-domain.co.uk
# Resolve each MX to IP
dig A mx1.recipient-domain.co.uk
dig A mx2.recipient-domain.co.uk
# Check from multiple resolvers
dig MX recipient-domain.co.uk @1.1.1.1
dig MX recipient-domain.co.uk @8.8.8.8Findings:
Can your server reach theirs?
# Basic TCP connectivity
telnet mx1.recipient-domain.co.uk 25
# With TLS
openssl s_client -connect mx1.recipient-domain.co.uk:25 -starttls smtp
# Full SMTP transaction
swaks --to [email protected] --from [email protected] --server mx1.recipient-domain.co.ukFindings:
If SMTP connection succeeds but message refused, authentication issues are common. Check your DNS:
# Your SPF
dig TXT firm.co.uk | grep v=spf1
# Your DMARC
dig TXT _dmarc.firm.co.uk
# Your DKIM (requires selector)
dig TXT selector._domainkey.firm.co.uk
# Your PTR
dig -x YOUR-SENDING-IPAll must be valid. See respective troubleshooting articles if any fail.
Need recipient's cooperation:
Mail accepted by receiver, not bounced, but not delivered to inbox or spam folder. Rare but possible:
Diagnostic: receiver's IT team should be able to locate the Message-ID in their mail system. If they cannot, mail truly never arrived.
Mail not delivered?
├── Sender received bounce?
│ ├── Yes → read bounce code; see bounce management guide
│ └── No → continue
├── Sender log shows message sent?
│ ├── No → check client-side (user's device, webmail)
│ ├── Queued/deferred → check queue reason
│ └── Delivered successfully → continue
├── DNS for recipient's MX resolves?
│ ├── No → recipient-side DNS issue
│ └── Yes → continue
├── SMTP connection succeeds?
│ ├── No (refused/timeout) → network/firewall issue
│ └── Yes → continue
├── Authentication passes (SPF, DKIM, DMARC)?
│ ├── No → see respective fix guides
│ └── Yes → continue
├── Recipient checked spam/junk?
│ ├── In spam → see spam fix guide
│ └── Not there → continue
└── Recipient's IT located Message-ID?
├── Yes → they can trace disposition
└── No → mail never arrived; investigate with sender logs + DNSGOV.UK mail filtering strict. Causes: missing DMARC, SPF fail, DKIM fail, reputation issue. Run through full diagnostic; GOV.UK's Mail Check may reveal specific issues if domain is auditable.
Normal pattern. Small percentage fail for various reasons (bad addresses, temporary failures). Process bounces; check for systemic patterns in what fails vs succeeds. Isolated failures may be acceptable.
Systemic. Likely blocklist listing, severe reputation drop, or target Exchange server blocked your IP. Check blocklists; check Microsoft SNDS; contact customer's IT.
Specific Microsoft error. Means sender failed authentication. DMARC or DKIM issue. Diagnose via Authentication-Results header (if obtainable) or via Microsoft sender support.
BT may have blocklisted sender or filtered based on content. Check Spamhaus/SpamCop status. BT's abuse desk may provide info if ticketed.
Internal routes through your own server; external goes through public internet. Likely outbound firewall blocking port 25, DNS routing issue, or reputation at external receivers. Internal success rules out server configuration.
Q: How long should I wait before concluding mail didn't arrive?
A: 24-72 hours. Soft-bounced mail retries for up to 72 hours before giving up. If no bounce within that window and recipient confirms no receipt, concluded lost.
Q: Can a single failed delivery damage my reputation?
A: No — one failure is routine. Systemic failures (many recipients, sustained) damage reputation.
Q: Should I resend if recipient didn't receive?
A: Depends on cause. If content/authentication fixed, resending new message is fine. If recipient-side issue, resending repeats the same failure. Diagnose first.
Q: What's the most common "mystery" delivery failure cause?
A: Recipient's spam filter or internal mail rules. Mail often arrives but is filtered before user sees. Ask recipient's IT to search mail trace.
Q: Can I get a delivery confirmation from the receiver?
A: Generally no. Receivers don't confirm delivery to sender. Some enterprise filters provide delivery receipts but rare in UK consumer mail.
Q: If mail consistently fails to one UK domain but works everywhere else, what do I check first?
A: That receiver's filtering policy. Likely you are blocklisted or content-blocked specifically at their infrastructure. Contact their IT to investigate.