How do I investigate missing transactional emails?

To investigate missing transactional emails, work from the top of the delivery chain down to the mailbox. Here’s a practical checklist:

1) Confirm the email was actually triggered

• Check the app/backend logs for the event that should send the email.
• Verify the transaction occurred and the email job/message was queued or submitted.
• Look for retries, failures, or exceptions in the sending code.

2) Check your email service/provider logs

If you use a provider (SES, SendGrid, Mailgun, Postmark, etc.):

• Search for the recipient address, message ID, or timestamp.
• Confirm whether the message was:
  • accepted by the provider
  • queued
  • sent
  • bounced
  • deferred
  • dropped/suppressed

3) Verify the recipient address

• Make sure the address is spelled correctly.
• Check for typos, case issues, or unexpected aliases.
• Confirm the user didn’t change their email address in your system.

4) Look for suppression and bounce issues

• Check if the recipient is on a suppression list due to:
  • previous hard bounce
  • complaint/spam report
  • unsubscribe from transactional-equivalent stream (less common, but possible)
• Review bounce/deferred reasons from the provider.

5) Inspect spam/junk/quarantine

• Ask the recipient to check:
  • inbox
  • spam/junk
  • promotions/updates tabs
  • quarantine/security filtering
• For corporate mailboxes, check whether the company gateway quarantined it.

6) Validate domain/authentication

Poor authentication can cause silent filtering:

• SPF
• DKIM
• DMARC
• From/reply-to alignment
• Custom tracking domains, if used

7) Check sending reputation and volume

• Look for spikes in bounce rates or complaint rates.
• Review recent sending patterns:
  • sudden volume increase
  • new IP/domain
  • new content/template
  • new links or attachments
• Shared IP reputation may also be affecting delivery.

8) Review the content/template

Certain content can trigger filtering:

• misleading subject lines
• too many links
• URL shorteners
• attachments
• suspicious HTML or broken markup
• mismatched From name/domain

9) Inspect message IDs and traceability

• Ensure each email has a unique message ID or correlation ID.
• Log that ID in your app and provider so you can trace a single message end to end.

10) Test with controlled sends

Send the same transactional email to:

• Gmail
• Outlook/Hotmail
• Yahoo
• a corporate domain This helps determine whether the issue is:
• recipient-specific
• provider-wide
• domain-specific
• content-specific

11) Check queues and retries

If you run your own email queue:

• confirm jobs aren’t stuck
• check worker health
• check dead-letter queues
• verify retry policy and timeouts

12) Use provider webhooks/events

If available, enable and inspect events for:

• delivered
• bounced
• deferred
• opened/clicked
• rejected
• suppressed

13) Ask the recipient for exact timing and mailbox details

Useful details:

• exact time they expected it
• whether other emails from you arrive
• mailbox provider and domain
• whether they use filters/rules

---

Fast triage flow

1. Did your app attempt to send it?
2. Did your provider accept it?
3. Was it bounced/deferred/suppressed?
4. Did it reach the mailbox provider?
5. Was it filtered after delivery?

---

Good logging to add going forward

For each transactional email, log:

• recipient
• template name/version
• event/triggers
• timestamp
• message ID
• provider response
• delivery status updates/webhook events
• bounce/deferred error codes

If you want, I can also give you a step-by-step debugging playbook or a checklist tailored to SES / SendGrid / Mailgun / Postmark.