A bounce arriving after someone has already resent a message is easy to misread. It might describe the original attempt, the replacement, or a delayed downstream event. Establish the identity and timeline of each submission before taking another action. The newest notification in the inbox is not necessarily evidence about the newest message.
Distinguish a warning from a terminal failure
A delivery-status notification can report delayed rather than failed. RFC 3464 defines these as different Action values. A delayed report means that, when it generated the report, the reporting system would continue delivery attempts; consult its status fields and queue evidence rather than treating the warning as a cancellation. Will-Retry-Until, when supplied, provides a stated retry horizon, not evidence that delivery has already completed. RFC 3464 section 2.3.
Action: failed means the reporting MTA abandoned attempts for that recipient. It can accompany a transient 4.x.x Status, which describes the cause rather than a promise of another retry. A failed report is terminal for the reported delivery action, but it may concern only one recipient and one attempt. Preserve the recipient block, original submission time, reporting system and diagnostic. A later corrected submission has its own lifecycle even when its subject and content look identical to the first message.
Build the timeline from queue evidence
Create one row per attempt or notification: submission time, queue identifier, envelope recipient, Message-ID, accepting or rejecting hop, response class and current disposition. Include the original delivery attempts as well as manual resubmissions. Do not use notification arrival time as a substitute for the last-attempt time described inside the report.
For a multi-hop route, an outbound relay may accept the message and continue working after the application marks it sent. Ask which system currently owns the queue. An application's resend button may create a new submission rather than instruct the existing relay queue to try sooner. That difference determines the risk of duplicate delivery and duplicate business processing.
Follow a hypothetical two-queue timeline
At 09:00, suppose an original submission enters queue Q-original. At 09:10, one recipient receives a temporary capacity refusal and remains pending. At 09:20, a user presses resend, creating Q-replacement. At 09:30, capacity returns and both queues later reach final DATA acceptance. These invented times explain ordering, not a standards-compliant retry interval or a provider schedule.
The replacement did not cancel the original, so two accepted delivery events are possible. A delay warning about Q-original arriving after 09:30 could describe its earlier condition, not the current state of Q-replacement. Use recipient, queue identifiers, attempt times and current logs to establish that relationship. Similar subjects or Message-IDs alone do not prove it.
No transactions were executed for this example. In a real incident, distinguish each accepted hop from confirmed mailbox delivery, and ask the application owner whether duplicate messages could trigger duplicate business actions. Preserve both records rather than rewriting the original as a successful replacement.
Decide whether another submission is justified
First check the current state of the original and replacement attempts. If either is still queued or its final response is uncertain, another resend increases ambiguity. A timeout after message data can leave the sender unsure whether the receiver accepted the message, a risk recognized in SMTP's timeout and reliability discussion. RFC 5321 sections 4.5.3.2 and 6.1.
If an original remains pending, use the service's supported queue controls only with appropriate authority. Do not delete queued business mail merely to tidy the incident, and do not assume a cancellation succeeded until the system confirms it. For time-sensitive transactional content, coordinate with the application owner so repeated message delivery does not repeat an irreversible business action.
Close each attempt separately
Record whether each submission failed, expired, remained pending, was canceled through an authorized action or was accepted at the relevant hop. Tie the late notification to the attempt it actually describes. If correlation remains uncertain, say so rather than declaring the most recent send failed.
Communicate the practical result to the sender: whether the intended recipient received the information and whether any duplicate action needs attention. Keep SMTP acceptance, mailbox delivery and business completion distinct. An accurate timeline is more useful than another unverified resend.
Decide before another resend
- Original pending: confirm queue ownership and supported next-attempt controls.
- Replacement pending: investigate it separately; its existence does not cancel the original.
- Acceptance uncertain: reconcile receiving evidence before adding another copy.
- Final failure: establish which recipient and submission it belongs to.
- Closure: record every submission and confirm whether any duplicated business action needs attention.