Where in the email path did delivery fail, and what evidence distinguishes a sender-side connection problem from recipient-side rejection or filtering?
Begin at the application and first handoff
Start with the system that created or sent the message: an app, website, device or campaign platform. It may submit through an authenticated SMTP submission service or an API. RFC 6409 distinguishes message submission by an application from message transfer between mail servers; a submission service may then relay the message onward.[1]
If the app cannot resolve or connect to its configured endpoint, or authentication fails there, the message may never enter the mail-transfer route. Check the app event, endpoint, timestamp and submission response. A sender’s broadband, office Wi-Fi or mobile network is the path to that first service—not the same thing as a recipient provider’s spam or reputation decision.[1]
Follow the relay and its outbound connection
After submission, the service may queue the message and its outbound mail-transfer agent (MTA) may connect to another server. A relay can be an intermediate hop rather than the final destination; SMTP allows messages to pass through multiple relays or gateways.[2] Look for the queue ID, retry history, next-hop hostname and the actual outbound connection result, not just a ‘sent’ label in the app.
The receiver sees the connecting MTA’s network identity at that hop; it need not be the address of the user’s home or mobile connection. Microsoft describes Outlook.com filtering as considering sending IP and domain reputation, authentication, list accuracy, complaints and content.[5] So a functioning sender access network does not establish that the recipient will accept or favor the relay’s traffic.
DNS points the sender toward a mail host
For a destination domain, the sending MTA uses DNS to determine a next hop. An MX record names a host willing to act as a mail exchange, and preference values rank exchanges; SMTP specifies how the mailer uses MX routing.[2][3] The MTA then needs to resolve and connect to that host. A wrong, stale or unavailable lookup—or a network failure to the selected host—can interrupt delivery before the recipient server accepts the message.
A DNS result is routing evidence, not a test of the full address or a promise about where a message will appear. Record which domain was queried, which resolver answered, the MX response and preference, and the resulting host/IP at the time of the attempt. An MX record identifies mail-handling infrastructure; it does not by itself establish that a particular mailbox exists or that the recipient will place a message in the Inbox.[2][3]
The receiving gateway makes its own decision
The MX host may be a gateway or relay, not the mailbox store. It can accept mail and forward it to another system, or decline the transaction. Once an SMTP server accepts responsibility, SMTP requires it to deliver the message or properly report failure; a successful response after the message data is a handoff, not proof of final mailbox placement.[2]
At this layer, authentication, reputation, complaints, content and local policy can affect treatment. Gmail says unauthenticated messages may be marked as spam or rejected, and its guidance says authentication makes messages less likely—not guaranteed—to be rejected or marked as spam.[4] A receiver may accept a message and still classify it as spam or apply other mailbox handling.
Diagnose from the last confirmed event
Build one timestamped sequence across app logs, relay queue events, DNS answers and SMTP logs. Preserve the exact remote hostname, response code and full response text, including any enhanced status code. A successful response from the submission service confirms that service accepted the submission; only the response from the relevant receiving SMTP hop documents what that hop did.[1][2]
If the recipient gateway returned a successful post-message response, move the investigation to recipient-side trace, spam or quarantine folders, mailbox rules and the recipient’s search. If no connection reached the submission service, investigate the app-to-service network path; if the receiver rejected the connecting MTA, inspect the receiver’s reply and the MTA’s sending identity. Diagnose the layer shown by evidence, not by the word ‘sent.’[2][4][5]
Fictional example—not a Sky customer case
Example only. No customer message, real mailbox or live account data is shown.
10:02 — App submits to smtp.submit.example; submission service replies 250.10:03 — Relay queue m-741 resolves example.net MX to mx1.example.net.10:03:14 — Relay connects from 203.0.113.44; mx1.example.net replies ‘250 2.0.0 queued as R-92’ after message data.10:20 — Recipient reports no message in Inbox.The first response shows submission-service acceptance; the later response shows the receiving gateway accepted responsibility for the message. Neither proves Inbox placement. Use the queue and remote reference to request a recipient-side trace and check spam, quarantine and rules. The reserved example domains and IP are synthetic.
What to check next
- 01Capture the app’s event, recipient, timestamp, configured endpoint and complete submission response.
- 02Test connectivity from the actual sending host to its submission endpoint; do not substitute a test from a different access network.
- 03Record relay queue ID, retries, bounce or deferral text, and the public egress IP used for delivery.
- 04Save the contemporaneous DNS MX response, resolver, preference values and resolved host addresses.
- 05Preserve the receiving host name and complete SMTP transcript, especially the final reply after message data.
- 06For a successful receiving response, ask the mailbox provider to trace the message and check spam, quarantine, rules and search results.
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 6409: Message Submission for Mail Separates application message submission from message relay and defines the submission agent’s role.
- [2]RFC 5321: Simple Mail Transfer Protocol SMTP multi-hop relaying, MX-based routing, relay/gateway roles, successful end-of-data handoff and responsibility to deliver or report failure.
- [3]RFC 1035: Domain Names—Implementation and Specification Defines MX preference and exchange fields and describes MX records as identifying hosts willing to act as mail exchanges.
- [4]Email sender guidelines — Gmail Help Gmail authentication guidance, possible spam marking or rejection, and sender troubleshooting evidence.
- [5]Sender Support in Outlook.com — Microsoft Support Outlook.com sender reputation and filtering factors, including IP, domain, authentication, list accuracy, complaints and content.