Chapter purpose
Replace vague statements like email is stuck with a traceable transport model from SMTP connection to final delivery.
Learning objectives
- Describe the Exchange transport pipeline.
- Explain Send versus Receive connectors.
- Understand queue and next-hop evidence.
- Design restricted application relay.
Why this matters in a real company
When mail stops, the company wants to know whether it is lost, delayed or rejected. Transport logs and queues answer that question.
4.1 Transport is a pipeline, not a single service
Microsoft describes the Exchange transport pipeline as services, connections, components and queues that route messages through categorization and delivery.
An SMTP server can accept a message and later queue it because the next hop is unavailable. Accepted is not the same as delivered.
4.2 Receive and Send connectors define boundaries
Receive connectors control inbound SMTP connections based on local bindings, remote source, authentication and permissions. Send connectors control outbound SMTP paths and address spaces.
Custom connectors should have a narrow, documented purpose.
4.3 Application relay must be constrained
Printers, ERP systems and scanners often need SMTP. If they cannot authenticate, source-IP restriction may be necessary. Scope it narrowly and decide whether external relay is really required.
A broad anonymous relay network can recreate the open-relay risks emphasized in the historical security book.
4.4 Trace one message
- Identify sender, recipient and timestamp.
- Confirm whether SMTP accepted the message.
- Search tracking logs.
- Find next-hop queue.
- Read last error and connector path.
- Confirm final delivery or rejection.
Get-Queue
Get-MessageTrackingLog -Start (Get-Date).AddHours(-1) -ResultSize 100
Get-ReceiveConnector
Get-SendConnector
Test-MailflowFront End Transport, Transport and Mailbox Transport
Current Exchange Mailbox servers use several transport services. Front End Transport handles incoming client or external SMTP proxying. The Transport service categorizes and routes messages. Mailbox Transport services handle delivery between the transport pipeline and mailbox databases.
This layered model is useful during troubleshooting because a successful TCP 25 connection proves only the first step. The message still has to be accepted, categorized, routed and delivered.
Accepted domains, DNS and next hops
Accepted domains define SMTP namespaces the organization is responsible for in different ways. Send connectors define routes toward external address spaces or smart hosts. DNS is often used to resolve remote MX records when sending directly to the internet.
When one remote domain fails, inspect its queue and SMTP error rather than changing organization-wide connectors. A precise failure should lead to a precise change.
Invoices queue for one partner domain
Internal delivery works, but outbound invoices to one customer are delayed.
Decision: Focus on that next-hop queue, DNS, TLS and remote SMTP response rather than restarting mailbox databases.
Evidence: Record queue error, remote domain, SMTP response and successful retry after resolution.
Hands-on lab
Send a lab message and document tracking events and queue state. Then design a restricted relay connector for one fictional printer.
Troubleshooting exercise
- Only one domain delayed: investigate that next hop.
- All outbound mail queues: inspect Send connector/internet/DNS.
- Printer sends internally but not externally: inspect relay permission and connector match.
Field checklist
- Queue monitoring exists.
- Message tracking retained.
- Custom relay sources inventoried.
- Connector scopes narrow.
- External DNS path known.
- SMTP response evidence retained.
Current technical references
The supplied PDF books are used as a historical curriculum map. Current implementation guidance is checked against current Microsoft documentation.