The sender's log says “250 queued,” but the recipient cannot see the message. Those observations can both be true. A successful final SMTP response records acceptance of responsibility at one hop. It does not describe the recipient's current folder, filtering outcome or user interface. Begin with the accepted transaction and trace what happened next.
Verify that the right acceptance was observed
SMTP includes successful responses to individual commands as well as the final response after message data. A 250 after MAIL FROM or RCPT TO does not prove that the complete message was accepted. Preserve the final DATA response, accepting server, timestamp and queue identifier. RFC 5321 sections 3.3 and 6.1.
Identify whether that server is the final destination, an outbound relay or an intermediate gateway. If an outbound service accepted a submission, the destination might still be pending or later reject it. A dashboard's “sent” status may describe only the service's own boundary. Ask what event its status represents rather than assuming end-to-end mailbox delivery.
Correlate the recipient and message
Use envelope recipient, submission time, Message-ID and available queue or trace identifiers. Visible To and Cc fields can differ from the actual envelope recipients because of aliases, blind copies and forwarding. Message-ID is useful for correlation but is not a globally trustworthy deduplication token or proof that two copies followed the same route. RFC 5322 section 3.6.4.
For multiple recipients, record the disposition separately. One successful recipient does not prove every recipient completed delivery. Confirm the intended account, domain and mailbox before searching for the message. Similar display names or multiple signed-in accounts can create an apparent disappearance that is unrelated to SMTP.
Inspect receiving-side handling
With the proper authorization, inspect message trace, quarantine, junk folders, inbox rules, forwarding and mailbox-level actions. Preserve policy identifiers and timestamps rather than immediately disabling a filter. If the recipient's provider is outside the sender's control, ask the authorized recipient or administrator for a bounded trace using the known identifiers.
A trusted receiving Authentication-Results field may help explain SPF, DKIM or DMARC evaluation, but arbitrary embedded header text is not proof of that evaluation. Read results from the receiver's understood trust boundary. An authentication pass does not guarantee inbox placement, and a missing inbox item does not by itself prove authentication failed. RFC 8601 sections 1.2 and 7.
Work through a hypothetical missing-message case
Suppose a sender has final DATA acceptance from its outbound relay for an invoice, but no receiving-service trace. That evidence establishes a handoff to the relay. The next question is its downstream queue outcome, not whether the recipient should disable spam filtering.
Now suppose an authorized receiving administrator finds that same message in quarantine with a policy identifier and timestamp. The investigation has moved from transport to receiving policy. Review why it was held and whether release is authorized. If a different case shows the message in the correct server-side inbox but not one desktop client, investigate account selection, views and synchronization instead.
These are hypothetical branching cases, not measured inbox placement, performed tenant checks or a deliverability experiment. No percentage or causal improvement is claimed. A real closure needs the actual message-specific receiving evidence and the intended recipient's outcome.
Close the actual gap
Record the last confirmed stage, the responsible system and the next unresolved event. If a rule moved the message, verify the intended policy before changing it. If a downstream delivery failed, correlate the later notification with the original transaction. Avoid blind resends while the first accepted copy remains unaccounted for.
Report precisely whether the message was accepted by a relay, delivered to a mailbox, placed in a folder or confirmed by its recipient. These are different outcomes. Keeping them distinct prevents a successful SMTP test from becoming an unsupported promise of inbox delivery.
Choose the next evidence source
- Only submission-service acceptance: inspect the outbound queue and downstream trace.
- Destination accepted, folder unknown: ask the authorized receiver for the mailbox, quarantine or rule event.
- Correct server folder confirmed, one client missing it: inspect account selection, filters and synchronization.
- Authentication result disputed: establish which trusted receiver supplied it.
- Before resend: account for the first copy and each intended recipient.