When an application reports an email failure, start with the SMTP response and the stage where it happened. Repeatedly resending the same message or changing servers can hide the original cause. This checklist helps your application owner and mail administrator investigate the same evidence.
First identify the failure stage
- Connection: record the destination hostname, port, time and whether TLS negotiation completed. A connection timeout is not an invalid-recipient verdict.
- Authentication: check that the application uses the intended submission credentials and supported authentication method. Never paste passwords into a support ticket.
- Recipient or message rejection: retain the complete response, including its enhanced status code and receiving hostname.
- Accepted but missing: check delivery events and the recipient mailbox. Server acceptance does not prove inbox placement.
Read the response before retrying
SMTP 4xx responses describe temporary failure; queue a controlled retry rather than creating duplicate jobs. A 5xx response is a permanent failure for that attempt and normally requires correction before resubmission. Interpret the complete diagnostic text: identical leading codes can describe different policy or mailbox problems. See RFC 5321 for the protocol definitions.
Build a useful incident record
- Choose one affected message and record its queue ID, timestamp and timezone.
- Separate application submission logs from onward delivery logs.
- Compare an affected recipient domain with an unaffected one, without sending unsolicited test messages.
- Record recent changes to DNS, credentials, routing, templates or sending volume.
- Redact recipient personal data and secrets before sharing logs.
Match the investigation to the evidence
Authentication errors call for a credentials and submission-configuration check. Domain-specific policy errors call for examining the receiver response and authentication results. An unavailable mailbox should enter the appropriate suppression workflow. A burst of deferred messages needs queue-age and retry-schedule review, not unlimited parallel resending.
For a message that was accepted but placed in spam, preserve its full received headers. Review SPF, DKIM and DMARC alignment alongside audience permission, complaints and message expectations. Authentication is necessary infrastructure, not a guarantee of delivery to the inbox.
Keep retries observable
Use one owner for retries, a bounded attempt policy and an alert on growing queue age. Confirm whether your application and SMTP provider both retry: two independent retry loops can create duplicate delivery. Keep the original error and final disposition together so that a successful retry does not erase evidence of recurring faults.
Before asking for help
Prepare the affected time range, sanitized responses, relevant queue IDs and the expected behavior. State whether the issue affects every message, one recipient provider or one application. Agree on a controlled verification test and a rollback plan before changing production routing.
QuickSolutions4u can review your requirement through email deliverability consulting. For connection and hosting requirements, see SMTP server services; for current commercial options, see pricing.