Learn › Exchange Online › 2 · Mail flow fundamentals

The life of a message

Every mail-flow mystery is solved by knowing which stage owns it. Walk one message from Send to Inbox — with the trace evidence at each hop — and NDRs, delays and misroutes become lookups instead of folklore.

The flow — what actually happens

Plain-language first; the packet-level view underneath each step is what you'd see in a Wireshark trace, and what healthy looks like.

  1. Submission

    Outlook hands the message to the service (MAPI submission), or an app submits via SMTP client submission/Graph/HVE. Whatever the door, the message enters the transport pipeline and gets its identity: the Message-ID and an internal conversation of tracking events begins.

    On the wire Message trace shows RECEIVE as the first event, with the submitting client/connector named. A message that never traces = it never submitted — the failure is client-side, stop looking at transport.
  2. Categorisation and routing decision

    Transport resolves recipients (expanding DLs, rewriting via forwarding), consults accepted domains and connectors, and decides each recipient's road: local mailbox, another tenant, the internet via a connector, or on-prem in hybrid. One message becomes N recipient journeys — traces are per-recipient for exactly this reason.

    On the wire Trace detail shows EXPAND (DLs), RESOLVE and REDIRECT (forwarding) events — the 'why did Bob get this' answers live in these events, not in guesswork.
  3. Policy gauntlet: rules then protection

    Transport rules (ETRs) fire in priority order — stamping, redirecting, blocking. Inbound mail additionally runs the EOP pipeline (connection filtering, anti-malware, spam, phish — its own concept). A message can be modified, forked, quarantined or dropped here, all evidenced.

    On the wire Trace detail lists each rule that matched with its action; quarantine events name the verdict. 'The filter ate it' becomes 'rule 14, action Quarantine, verdict HighConfPhish' — an argument-ender.
  4. Delivery — or the queue, or the NDR

    Local recipients: the message lands (DELIVER) and inbox rules run. Remote: a connector attempts the next hop — transient failures queue and retry (DEFER events, hours of patience), permanent failures generate the NDR with its 5.x.x code (the decoder concept). Nothing vanishes silently: every terminal state has an event.

    On the wire Trace final states: Delivered, Failed (with the SMTP response from the far side — READ it, it names the rejecting party), Pending (still queued/deferred), Quarantined. The far-side response text is the single most under-read diagnostic in Exchange.

The stage-to-symptom map

Symptom Stage First evidence
Sender got no error, recipient got nothing Delivery (quarantine/junk/inbox rule) Trace final state + quarantine search
Instant bounce on send Submission/categorisation (bad recipient, size, restriction) The NDR code + trace RECEIVE/FAIL
Bounce minutes-to-hours later Remote delivery (far side rejecting/deferring) The far-side SMTP response in the FAIL event
Some recipients got it, others didn't Per-recipient forks Per-recipient traces — never debug the message, debug the recipient journey
Message arrived modified/with banner ETR stage Rule-hit list in trace detail
Delayed an hour, then fine DEFER/retry cycle DEFER events with the deferral reason

Three facts that reframe troubleshooting

  1. Transport is evented, not mystical — every hop writes trace events for 90 days (10 interactive). The discipline is reading them in stage order rather than theorising.
  2. The far side speaks in the FAIL event — remote rejections include the receiving server's actual SMTP response ("550 5.7.1 ... blocked by " "policy") which names WHOSE policy. Half of 'Exchange is bouncing our " "mail' tickets are the recipient's security stack, provably.
  3. Forks are normal — DL expansion, forwarding, journaling create sibling journeys; a 'delivered' summary can hide one failed fork. Always expand to per-recipient detail on multi-recipient disputes.

What to watch (proofs)

  • Get-MessageTrace / Get-MessageTraceDetail (or the modern V2 cmdlets) — the per-stage event stream; export the detail on any dispute and walk it top to bottom once with this page open.
  • Mail flow dashboards/reports (EAC): queues, deferral trends — the fleet view over the per-message tool.
  • Your delivery-latency percentiles from trace timestamps — the Pulse concept's EXO metric; a rising p95 is a pipeline problem announcing itself.
  • One deliberately-broken test: send to a bad external address, read the NDR AND the trace — the far-side-response habit, installed in ten minutes.

The wire

  • Submission: MAPI (Outlook), SMTP AUTH 587, Graph sendMail, HVE — different doors, one pipeline
  • Remote delivery: connector -> MX of recipient domain; far-side SMTP responses recorded in trace FAIL events

PowerShell for this concept

  • Get-MessageTrace > [!NOTE] > This cmdlet is replaced by the Get-MessageTraceV2 cmdlet and will...
  • Get-MessageTraceDetail > [!NOTE] > This cmdlet is replaced by the Get-MessageTraceDetailV2 cmdlet and will...
  • Get-TransportConfig View organization-wide transport configuration settings.
  • Get-AcceptedDomain View the configuration information for the accepted domains in your organization.

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.