Email not received? A systematic debugging order

Step 4: delivered, but not seen#

A 250 acceptance means the receiving server took the message, not that it reached the inbox. From here, the message may have been:

• Filed as spam or junk. Ask the user to check spam, and any quarantine their organization uses.
• Sorted into a tab or folder, such as Gmail's Promotions or Updates, or a rule-based folder.
• Quarantined by a corporate gateway. Business recipients often have security appliances that hold messages for administrator review without notifying the user. Their IT team can search the quarantine.
• Removed by a user rule or forwarded elsewhere.
• Delayed internally by the recipient organization's own mail routing.

If it landed in spam, check the received headers on a copy, if the user can forward it as an attachment or share the original source, for authentication results.

Step 5: check your authentication#

Whether the message bounced for policy reasons or landed in spam, confirm your authentication is healthy:

dig +short TXT example.com | grep -i spf1
dig +short TXT _dmarc.example.com
dig +short TXT k1._domainkey.example.com

Then send a test to a mailbox you control at the same provider as the recipient, and read the Authentication-Results header. You want SPF or DKIM to pass and align, and DMARC to pass. A recent DNS change or a new sending service is a common culprit.

Step 6: check reputation and patterns#

If authentication is fine, widen the view:

• Is it one recipient or many? Look at bounce and delivery rates for the same receiving domain over the past few days. A spike suggests a block or reputation issue at that provider.
• Is it one template? A single template with poor delivery may have content or link problems, such as a link to a domain on a blocklist.
• Are you listed on a blocklist? Check your sending IPs and domains against major blocklists if bounces mention them.
• What do postmaster tools say? Google Postmaster Tools and Microsoft SNDS show reputation and complaint data for their users.

Step 7: work with the recipient's administrator#

For business recipients, the most effective step is often to ask their IT team to search their mail logs for the message by time and sender. They can see whether their gateway accepted, quarantined or rejected it and why. Provide the date, time, From address, subject and the provider's message ID or the Message-ID header.

Common resolutions#

• Typo in the address: fix it and resend.
• Suppressed after an old bounce: verify the address works, remove the suppression, resend.
• Corporate quarantine: ask IT to release it and allowlist your sending domain.
• Spam folder: confirm authentication, ask the user to mark it not spam, and review content.
• Receiver block: investigate reputation, fix the cause, follow the receiver's mitigation process.

Checklist#

• Exact address, email type and time confirmed.
• Application logs show the send was requested.
• Address checked against the suppression list.
• Provider response and message ID found.
• Receiving server's response read in full.
• Spam, tabs and quarantine checked for accepted messages.
• Authentication verified with a test message.
• Patterns checked across recipients, domains and templates.

Key takeaways#

• Debug in order: your app, your provider, the receiving server, then the recipient's mailbox.
• Suppression lists and typos explain a large share of "never received" reports.
• A 250 acceptance means the receiver has the message; it may still be filtered or quarantined.
• Read full SMTP responses; they usually name the cause.
• For business recipients, their administrator's logs are often the fastest answer.