Which organization or system handled this message, and who should I ask to investigate the evidence?
Start with the handoff, not the brand name
A single message can cross several networks and mail systems, so “who handled it?” needs a narrower question: which component produced this log, response or status? The sender’s internet access provider carries traffic from a device to a service; a submission service accepts mail from an application; receiving systems handle it on the recipient side. SMTP may deliver directly or pass through multiple relays [1].
Map each piece of evidence to the transaction it describes. SMTP servers add Received trace fields when accepting mail for relay or final delivery; multiple such fields can record successive hops [1]. They are useful clues, not a complete incident report: preserve the raw message and logs, note the reporting host and time, and do not treat a hostname as proof of who controls every earlier step.
Access ISP: the path to the mail service
The access ISP is the network connection—broadband, cable, fiber or mobile—that lets the sender’s device reach the internet. Its evidence concerns that connection: whether the device was online, could resolve or reach the configured submission endpoint, and encountered a connection or port restriction. It is not automatically the company that runs the sender’s SMTP relay, the recipient’s mailbox, or a filtering gateway.
The subscriber or organization’s network administrator can first compare the client’s connection error, time, network and destination with other networks or endpoints. Contact the access provider when evidence points to connectivity, routing or a blocked connection on that access service. An ISP can investigate its network service; it cannot use that fact alone to explain a recipient’s spam folder or change a mailbox provider’s delivery decision. If submission succeeded, move on to the mail-service evidence.
Submission service or relay: the sender’s mail handoff
A submission service receives a message from an application or user; an SMTP/API relay can then queue and transfer it toward the destination. The standard distinguishes message submission from message transfer: an MSA accepts submissions and can relay them onward, while authentication and authorization may govern who is allowed to submit [2]. A cloud relay is therefore a mail-handling system, not simply the sender’s broadband ISP.
The authorized sender, account owner or relay administrator should gather the application’s submission result, authenticated account or tenant, request/message ID, relay queue events and any later SMTP response from the next server. A success at the submission endpoint proves that endpoint accepted the submission—not that a recipient mailbox placed it in Inbox. Check whether the relay queued, deferred, rejected or attempted onward delivery before changing sender credentials, configuration or retry behavior.
Recipient MX, gateway and mailbox: separate destinations
On the receiving side, a domain’s inbound SMTP system may be a mailbox provider, an enterprise gateway, or a gateway that passes mail to a separate mailbox service. The gateway may apply organizational filtering or routing before mailbox delivery. If an SMTP server returns success after message data, RFC 5321 says it takes responsibility for delivery or properly reporting failure [1]; that handoff does not by itself establish where a user will see the message.
Ask an authorized recipient-side administrator to search the receiving system’s trace using the recipient, time and message ID. Google Workspace Email Log Search can show delivery steps and post-delivery information such as message location, spam status or deletion [3]. Exchange Online message trace shows events and statuses as messages travel through that Microsoft 365 organization [4]. If a separate gateway is in the path, its administrator may need to check its own quarantine, policy and routing logs; a mailbox trace may not explain an earlier gateway decision.
Use the evidence to choose the next actor
Build a short timeline, and label every result with the system that generated it: client-to-relay connection, submission acceptance, relay-to-recipient SMTP exchange, gateway action, then mailbox status. Be precise about which server issued a 250 and at what stage. A 250 after DATA is a formal SMTP handoff to that server; a relay’s submission success and a recipient system’s later response are different events [1].
Escalate only to the party with access to the relevant evidence: the access provider for a demonstrated network-path problem, the relay operator for its submission or queue, and the recipient or gateway administrator for inbound policy and mailbox handling. A message accepted by a receiving server may still be filtered, quarantined, routed elsewhere or not visible in the Inbox; use recipient-side trace evidence to determine which, rather than inferring placement from sender-side success [1][3][4].
Fictional example: submission succeeded, user cannot find the message
Example only. No customer message, real mailbox or live account data is shown.
All domains, people and events below are fictional and illustrative.08:12 — Sam’s mail app connects to RelayCo through a home fiber service.08:12 — RelayCo’s log records Sam’s authenticated submission as accepted/queued, request ID R-204.08:13 — RelayCo’s SMTP log records `mx.northstar.example` returning `250` after message data.08:13 — Northstar’s gateway trace matches the Message-ID and records `quarantined`; no mailbox-delivery event is shown.The `250` from Northstar’s inbound server marks SMTP responsibility handoff to that server, not Inbox placement [1]. RelayCo’s log proves its own acceptance; the gateway trace is the evidence pointing to the next investigation. An authorized Northstar gateway or mail administrator should inspect the quarantine and policy/routing decision. Nothing here indicates that Sam’s fiber ISP handled the mail after the connection to RelayCo succeeded.
What to check next
- 01Preserve the raw SMTP conversation or client error, including host, timestamp/time zone, response code, full text and the stage at which the response occurred.
- 02Export the relay’s submission/API record, request or message ID, authenticated account, queue state and onward-delivery attempts; distinguish accepted from delivered.
- 03Keep the original message headers and compare `Received` fields as hop clues; record which system generated each field and avoid assuming the trace is complete.
- 04For a demonstrated connection failure, note the access type, time, submission endpoint and exact connectivity symptom before contacting the access ISP; never share passwords or API secrets.
- 05Ask an authorized recipient/gateway administrator to search by recipient, time and Message-ID for receive, defer, reject, quarantine, delivery, post-delivery location or deletion events.
Check the source
Standards and provider documentation are linked beside the claims they support. Provider policies can change; check the current document before changing a live sending program.
- [1]RFC 5321: Simple Mail Transfer Protocol SMTP relay and delivery model; responsibility handoff after a successful end-of-data response; Received trace records; delivery or failure reporting duties.
- [2]RFC 6409: Message Submission for Mail Distinction between submission and transfer; MSA and MTA roles; authenticated/authorized submission and submission server policy.
- [3]Google Workspace Admin Help: Find messages with Email Log Search Administrator Email Log Search for sent/received messages, delivery steps, message location, spam status and post-delivery information.
- [4]Microsoft Learn: Message trace in the Exchange admin center in Exchange Online Exchange Online organization-scoped message trace, status and action events including receive, reject, defer and mailbox delivery.