Email deliverability guides
Why was your email delayed or rejected?
Start with the full SMTP reply and the server that issued it. A temporary 4xx response calls for a different investigation than a permanent 5xx failure, especially when invoices, alerts, or password resets are affected.
Published by InboxGenius
Read the delivery outcome
4xx means the attempt was deferred
If your platform is retrying, check the age of the oldest affected message, the next retry time, and the queue expiry. Compare the delay with how long the message is useful. A password reset can expire before the sending platform gives up. Repeated manual sends can create duplicates if the original messages are still queued.
For example, if Gmail returns 421 4.7.28 and the text points to an unusual sending rate, compare recent traffic for the IP or domain named in the reply.
5xx means the attempt failed permanently
Read the enhanced status code and the text after it before resending. A policy rejection may require a change to authentication, routing, or the recipient organization’s permissions. A generic 550 reply alone does not tell you which change to make.
If Gmail returns 550 5.1.1 for an address it cannot find, verify the recipient’s address before trying again.
A final 250 reply means that server accepted the message
Check which server accepted it. A sending relay or corporate gateway may be one hop in the delivery chain. If the destination accepted the message and the recipient finds it in junk, follow the spam-placement investigation.
See SMTP reply code definitions and the Gmail SMTP error reference for provider-specific examples.
Collect evidence before changing anything
Keep the complete reply and identify the responding server
Record the basic code, any enhanced code, reply text, timestamp with time zone, message or queue ID, sending source, and destination domain. In an Exchange Online nondelivery report, look for the Remote server and SMTP response fields in the administrator details. The system that generated the report can differ from the server that issued the rejection.
Compare an affected message with a successful one
Start with the same sending source and time window. Check whether failures cluster at one recipient organization, one mailbox provider, or one email flow. If the reply points to a sender identity problem, use the authentication and alignment guide to compare what the affected platform actually sends.
Route the investigation to the team that can act
Ask the sending platform about a queue or retry problem. If the same source succeeds elsewhere and a single corporate gateway issues the rejection, give the recipient’s mail administrator the timestamp and full response through an approved channel. If the failure crosses providers or platforms, compare common sending identities and recent changes before altering infrastructure.
Need help investigating a recurring delivery failure?
Tell us which business emails are affected, when the problem began, and what the receiving server reported. Share a redacted reply and keep credentials, recipient lists, and message contents out of the inquiry.