On this page
Module 2: Mail-Flow Architecture Patterns
Learning Objectives
By the end of this module, you will be able to:
- Sketch and explain end-to-end mail flow for Microsoft 365 / Exchange Online, Google Workspace, on-premises Exchange, and hybrid environments.
- Distinguish MX-based, connector-based, inline, and API-based (non-inline) security deployment models, and state where scanning and policy enforcement physically occurs in each.
- Identify, for any given architecture, the decision points and dependencies a message passes through, and which system owns each one.
- Explain how journaling, BCC-based archiving, transport rules, and routing connectors interact with — and can be confused with — the security product's own processing.
- Recognize the signatures of a routing loop and of a duplicate-delivery scenario, and explain why each occurs.
- Given a described symptom and topology, correctly identify which system is the most likely owner of the failure before doing any deep diagnosis.
Key Terminology
- MX-based (inline) deployment
- The security product's MX records are published as the domain's mail exchanger, so all inbound mail routes directly to the product first, before the mailbox platform. The product is literally in the SMTP path.
- Connector-based deployment
- The mailbox platform (M365/Google) receives mail first (or last, for outbound) and is configured with an explicit mail-flow connector to route messages to/from the security product for processing.
- API-based (non-inline / journal-style) deployment
- The product does not sit in the SMTP path at all. The mailbox platform delivers mail normally, and the product retrieves or receives a copy via API after delivery, then acts on it (e.g., retracting or quarantining after the fact).
- Inline
- Any deployment where the product is physically between the internet and the mailbox platform in the SMTP conversation, and can accept, reject, or hold a message before final delivery.
- Non-inline
- Any deployment where the product observes or acts on mail only after the mailbox platform has already accepted it.
- Journaling
- The mailbox platform sends a copy of messages, per policy, to a separate address/system for archival, compliance, or (in some architectures) security processing.
- Transport rule / mail flow rule
- A policy configured on the mailbox platform itself (e.g., Exchange Online Transport Rules) that can redirect, modify, or block mail — separate from, and sometimes conflicting with, the security product's own policy engine.
- Connector
- A configured mail-flow path between two systems — for example, an Exchange Online inbound/outbound connector pointing at the security gateway's IP address or hostname.
- Routing loop
- A configuration where two or more systems each route a message to the other under conditions that never resolve, causing the message to cycle — and often multiply — between them.
Lesson
In Module 1 you learned to read the delivery chain itself — the sequence of SMTP hops a message travels through on its way from sender to mailbox. This module answers a different question: for any given customer, what does that chain actually look like, and where inside it does the security product sit? The chain isn't identical from customer to customer. It depends on whether the customer runs Microsoft 365, Google Workspace, on-premises Exchange, or some hybrid combination of these, and on whether the security product has been deployed inline — directly in the SMTP path — or via an API that only acts after the mailbox platform has already taken delivery. Get the architecture wrong and every diagnostic step that follows is built on a false assumption: you'll pull logs from the wrong system, trust the wrong system's verdict, and hand the customer an explanation that doesn't match what actually happened. Architecture identification isn't a preliminary step you rush through to get to the "real" troubleshooting — for a mail-flow ticket, it usually is the real troubleshooting.
As you work through the patterns below, it's worth pausing on each one and asking whether it matches a real customer environment you've already seen on a ticket. This is a module you'll come back to again and again on live tickets, not one you read once and set aside.
2.1 Why Architecture Determines Diagnosis
The single biggest determinant of how you troubleshoot a mail-flow ticket is which architecture the customer is running — not the symptom the customer reports. That's worth sitting with, because it cuts against instinct. When a customer says "the message never arrived," the natural impulse is to start pulling logs from the security product's own console. That impulse is only correct about half the time.
If the security product is deployed inline — sitting directly in the SMTP path between the internet and the mailbox platform — its own logs are authoritative for what happened to the message: accepted, rejected, held, relayed onward. Nothing else touches the message before the product does, so there's nowhere else to look first.
If the security product is deployed via API — observing or acting on mail only after the mailbox platform has already accepted delivery — its logs tell you something different: not whether the message was delivered, but only what the product did after delivery already happened. In this model, the mailbox platform's own logs (Exchange Online message trace, Google Workspace's Gmail log search) are the authoritative source for delivery itself.
Two identical symptoms, two completely different correct first moves — and the only way to know which applies is to determine the deployment architecture first, before you open any tool. Make that your step zero on every mail-flow ticket, not something you fall back on once your first guess turns out wrong.
2.2 Microsoft 365 / Exchange Online Mail Flow
With no third-party security product involved, Microsoft 365 / Exchange Online's baseline inbound flow looks like this:
Internet → Exchange Online Protection (EOP) front-end
→ [EOP scanning: connection filtering, anti-spam, anti-malware]
→ Transport rules (mail flow rules)
→ Mailbox delivery (Exchange Online mailbox)Layer a third-party security product into that flow and you'll most often see one of two patterns in the field:
Pattern A — MX pointed at the product (inline). The domain's MX records are changed to point at the security product instead of Microsoft. Every inbound message reaches the product first; the product evaluates it and, if accepted, relays it onward into Microsoft 365 — commonly through a dedicated inbound connector configured to accept mail only from the product's published IP ranges. Because the product is now the first line of scanning, engineers typically set EOP's own spam filtering to a reduced or "trust" mode on that connector, specifically to avoid the message being filtered twice by two independent engines.
Pattern B — MX stays at Microsoft, connector-based. The domain's MX records are left pointed at Microsoft 365, and an inbound connector or mail-flow rule redirects matching mail out to the security product for scanning and back in — or, in some configurations, the product operates purely via API after EOP has already delivered the message, with no connector round-trip at all.
When you're troubleshooting an M365 mail-flow ticket, work through these decision points in order:
- Is the domain's MX record actually pointed at Microsoft, or at the security product? Don't assume it from the deployment's nominal design — check it directly (Module 3 covers how).
- Is Enhanced Filtering for Connectors (Microsoft's skip-listing mechanism) configured, and correctly scoped? Misconfiguration here is a common cause of EOP re-filtering — and sometimes re-flagging — mail the product has already cleared.
- Are there transport rules present on the mailbox platform that could redirect, silently discard, or modify mail independently of the security product's own policy? A transport rule and the product's policy engine are two separate systems that can produce a compounding or contradictory result, and this is a frequent root cause of "why did this still get flagged" or "why did this still get through" tickets.
Worked Example — An Enhanced Filtering Misconfiguration in Action
Here's what this failure mode looks like in practice, reconstructed from a typical case shape. A message arrives inbound, is scanned by the security product (inline via MX), evaluated as clean, and relayed on into Microsoft 365. But when the recipient checks their inbox, the message isn't there — it's sitting in Quarantine, this time flagged by Exchange Online Protection itself, carrying its own spam confidence score. Nothing about the product's own verdict changed; a second, independent filtering engine simply reached a different conclusion on the exact same content.
The root cause in cases like this is almost always the same: EOP's own filtering was never told to trust mail arriving from the product's IP ranges. Enhanced Filtering for Connectors, or an equivalent skip-listing setting, was either never configured, or was scoped to the wrong connector. Without it, EOP treats mail arriving from the product exactly as if it had arrived directly from the open internet — it evaluates the product's own outbound-facing IP addresses (not the true originating sender) for reputation and authentication purposes, and layers its own spam/malware verdict on top of the product's. Two policy engines, two independent verdicts, no coordination between them. That's exactly the situation Enhanced Filtering exists to prevent, and it's exactly what to check first the moment a ticket reads "the product cleared it, but the customer says it was still blocked."
2.3 Google Workspace Mail Flow
Baseline inbound flow, no third-party product:
Internet → Google Front End
→ [Gmail spam/phishing/malware scanning]
→ Compliance/routing rules (Admin console → Apps → Gmail → Compliance)
→ Mailbox deliveryWith a third-party product, the two comparable patterns from 2.2 reappear: MX pointed directly at the product (inline), versus Google Workspace routing rules — the Inbound Gateway setting, or a dedicated routing rule — sending mail to the product for scanning, with the mail returned via a configured route. Google Workspace's Inbound Gateway setting is architecturally significant on its own: it tells Google to expect inbound mail only from the listed gateway IP addresses and, depending on configuration, can affect how Google's own spam scoring treats that mail. This is a common point of confusion when a customer expects Google's own filtering to still apply independently — sometimes it does, sometimes it doesn't, entirely depending on how that setting was configured.
Decision points for a Google Workspace mail-flow ticket:
- MX destination — pointed at Google or at the product.
- Inbound Gateway configuration, and specifically whether its SPF handling ("Message is rejected if it's not from one of the listed IP addresses" / "Perform inbound SPF checks…") is set consistently with the actual mail path. This is a very common source of legitimate mail being rejected outright when it's misconfigured relative to the real path the mail takes.
- Compliance/routing rule precedence relative to the product's own policy.
2.4 On-Premises Exchange
Internet → Edge Transport / Receive Connector
→ Anti-spam agents (if enabled) → Transport rules
→ Mailbox Transport → Mailbox databaseOn-prem introduces variables that cloud platforms abstract away entirely: the customer's own firewall and NAT rules, receive-connector scoping (which IP ranges are actually permitted to relay), and the customer's own patch and version currency. All of these sit entirely outside the security product's control, and all of them are frequently the actual root cause of what gets reported as "a product issue." Always ask for the on-prem topology diagram — or reconstruct it from headers if none exists — rather than assuming a cloud-equivalent architecture applies. On-prem environments do not follow the same defaults cloud platforms do, and guessing here is a fast way to chase the wrong system.
2.5 Hybrid Environments
Hybrid — part on-prem, part cloud, same organization — is the highest-complexity pattern in this module, because a message's actual path depends on where the recipient's mailbox currently is, and that is not always obvious from the domain alone. Hybrid environments commonly share a single external domain across both on-prem and cloud mailboxes, with internal routing directing each message to whichever location actually hosts that recipient. Failures in hybrid environments are disproportionately caused by internal routing or connector misconfiguration between the on-prem and cloud sides — not by inbound internet-facing mail flow at all. When a hybrid customer reports an issue, always confirm which side actually hosts the affected mailbox before assuming the security product's inbound path is even involved.
2.6 Secure Email Gateway (SEG) vs. API-Based Deployment — the Core Architectural Fork
If you only carry one idea out of this module, make it this one. Nearly every pattern above is a variation on a single underlying question: where does scanning happen relative to delivery? This is the organizing idea behind the whole module — everything in 2.2 through 2.5 is really just this same fork, expressed differently on four different platforms.
| SEG / Inline / MX-based | API-based / Non-inline | |
|---|---|---|
| Where scanning happens | Before the mailbox platform ever sees the message | After the mailbox platform has already accepted and delivered the message |
| Can it block delivery outright? | Yes — it can reject or hold at the SMTP level before delivery | No — it can only act after delivery (e.g., retract or quarantine from the mailbox), which is why this model is sometimes called "post-delivery remediation" |
| Time-of-click protection relevance | Often paired with URL rewriting at scan time | Often relies more heavily on time-of-click / post-delivery re-scan, since the message already reached the inbox before any action is possible |
| Authoritative delivery log | The product's own MTA logs are authoritative for "was it delivered" | The mailbox platform's own logs (message trace / Gmail log search) are authoritative for "was it delivered"; the product's logs only show what it did after the platform already delivered |
| Failure isolation implication | "Message not received" investigation starts in the product | "Message not received" investigation starts in the mailbox platform, then moves to the product only to check what post-delivery action, if any, occurred |
2.7 Multi-Gateway and Layered-Security Environments
Some customers run more than one security layer at once — for example, the mailbox platform's native filtering, plus this product, plus a legacy gateway that hasn't been decommissioned yet. Layered environments are a common source of three specific problems worth recognizing on sight:
- Double-scanning artifacts — headers added twice, URLs rewritten twice by different products, occasionally producing broken or nested rewritten links.
- Conflicting verdicts — one layer quarantines a message while another releases it, or one layer's "clean" verdict is presented to the customer while a different layer actually made the blocking decision.
- Attribution confusion — a customer reports "your product blocked this" when a different layer in their own stack was actually responsible.
Make it a habit, early in triage for any customer you know or suspect is running layered security, to ask directly: what other filtering do you have in front of or behind this product? Getting that answer before you dig into logs saves you from investigating the wrong system's decision.
2.8 Journaling, BCC, Transport Rules, and Routing Connectors
These four mechanisms are frequently confused with the security product's own operation, and it's worth being able to distinguish each of them clearly enough to explain the difference to a customer in plain language.
Journaling copies messages to a separate mailbox or system for compliance and archival purposes. It does not, by itself, apply any security policy — a journaled copy existing tells you nothing about whether the "real" message was scanned or handled in any particular way.
BCC-based routing, used by some legacy archiving and continuity tools, silently copies mail to a second location. It's a common source of "why did this show up in a second mailbox" tickets that have nothing at all to do with the security product.
Transport rules (see 2.2) can independently redirect, modify, or block mail on the mailbox platform, entirely outside the product's own policy engine.
Routing connectors define how mail physically moves between systems, and they're a common single point of misconfiguration — a wrong IP address or hostname, an expired TLS certificate, an incorrect port — that produces symptoms indistinguishable from a genuine product defect until the connector configuration itself is actually reviewed.
2.9 Encryption Services and Secure-Message Portals
Where a message is encrypted or routed to a secure pickup portal, an additional "leg" of delivery is introduced: the recipient doesn't receive the message content directly. Instead they receive a notification message that links to a portal, and the actual retrieval of the content is a separate, portal-side authentication event. That means an encryption or portal ticket always has at least two independent failure points to isolate: did the notification message deliver, and did the portal retrieval succeed. Treat these as two separate questions — never as a single event — when you triage a ticket like this, because the fix for one has nothing to do with the fix for the other.
2.10 Email Archiving and Continuity Systems
Archiving and continuity systems — for example, a spooling or queueing continuity service that holds mail during a mailbox-platform outage — sit adjacent to, not inside, the primary security path in most architectures. But they can appear to a customer as part of "the product" if the two were bundled or co-sold together. Confirm the actual architecture before assuming an archiving or continuity ticket is even in scope for the security product's own troubleshooting playbooks — it may belong to an entirely separate system with its own support path.
2.11 Isolating Which System Owns a Failure — the General Method
Everything above is architecture-specific. This section is the method that applies regardless of which architecture you're looking at. For any architecture, work through this sequence before you deep-dive into any one system's logs:
- Confirm the deployment model — inline/MX-based, connector-based, or API-based. This alone determines which system's logs are authoritative for the rest of the investigation.
- Identify every hop the message is expected to traverse for this specific customer's configuration — not a generic assumption drawn from the "typical" pattern.
- Determine the last hop for which you have positive evidence of acceptance: a log entry, a
Received:header, a trace record. - The next hop after that is the presumptive owner of the failure — but confirm it by checking whether that next system has any record of the message at all. The absence of a record is itself informative, not a dead end.
- Only escalate or attribute fault once a specific hop has actually been identified as the point of divergence from expected behavior.
Worked Example — Walking a Header Trace Against the Architecture
Here's what applying this method looks like end to end. Take a sanitized message header trace for a customer you've confirmed is running Pattern A from 2.2 — MX pointed at the product, inline, relaying into Microsoft 365. Lay the Received: chain out top to bottom (oldest to newest, per Module 1) and narrate it against the architecture diagram for that pattern: this hop is the sending organization's outbound MTA, this hop is the product accepting the message inline, this hop is the product relaying into the dedicated M365 inbound connector, this hop is EOP's mailbox transport placing it in the store.
Now suppose the chain stops after the product's relay hop — there's no subsequent Received: header from Microsoft 365 at all. Per step 3 of the method, the last hop with positive evidence of acceptance is the product. Per step 4, you check whether Microsoft 365 has any record of the message — a message trace lookup by Message-ID. If M365 shows nothing, Microsoft 365 (or, more specifically, the connector between the product and M365) becomes your presumptive owner of the failure, and that's where you focus next: connector health, TLS certificate validity, whether the product's relay attempt even completed successfully. Notice what didn't happen: you didn't start by assuming the product failed, and you didn't start by assuming Microsoft failed. You followed the evidence, hop by hop, until it stopped — and only then did you name a system.
2.12 Routing Loops and Duplicate Delivery
Routing loops typically occur when two systems are each configured to relay to the other under overlapping conditions. A common shape: a transport rule on the mailbox platform redirects mail matching some condition back out to the gateway, while the gateway is simultaneously configured to route matching mail back to the mailbox platform — and neither system recognizes the message as "already processed." The symptom is a message with an unusually long, repeating chain of near-identical Received: headers between the same two systems, and/or a mailbox platform's own loop-detection rejection, such as a "too many hops" 5xx response.
Duplicate delivery most often results from one of three causes: (a) a routing loop that eventually resolves after N hops, delivering the message once for each pass through the delivery point; (b) journaling or BCC configured in addition to, rather than instead of, primary delivery; or (c) a retried delivery attempt where both a deferral-retry and a separate manual or administrative resend happened concurrently. Distinguish these by comparing Message-IDs (true duplicates from a single send share one Message-ID) and Received: header chains — a loop shows the same two systems repeating; independent duplicate causes do not.
Worked Example — Reading a Routing-Loop Header Chain
Here's how to spot one before you've even reached for a diagram. Suppose a customer forwards a message complaining that they received it four separate times. You pull the full headers and list every Received: line in order. Instead of the usual four or five hops you'd expect from Module 1's delivery chain, you count fourteen — and when you read the hostnames, the same two systems keep alternating: the gateway's hostname, then the mailbox platform's hostname, then the gateway's again, then the platform's again, six times over, before the message finally lands in the mailbox.
That alternating, repeating pattern between exactly two systems is the signature of a routing loop — not four independent duplicate-delivery events. The next move is to find where the loop should have been broken: check the mailbox platform's transport rule that redirects mail out to the gateway, and check the gateway's own routing configuration for mail coming back from the platform. Somewhere in one of those two configurations, a condition that should have excluded "mail the gateway already processed" is either missing or scoped too broadly — that's the fix, not anything in the message content itself.
Hands-On Lab
Lab 2.1 — Architecture Identification and Ownership Assignment
Given five customer scenario cards (each describing a topology in prose, without a diagram), work through each one and:
- Draw the mail-flow diagram from the description.
- Mark where the security product sits — inline or API-based — and justify the classification from the details given.
- For the symptom accompanying each card, state which system is the presumptive owner of the failure and what evidence would confirm or rule that out.
Lab 2.2 — Header-Chain Loop / Duplicate Diagnosis
Given three header sets — one clean, one showing a routing loop, one showing non-loop duplicate delivery — correctly classify each and explain the distinguishing evidence you used.
Scenario-Based Exercise
Scenario: A hybrid customer reports that external senders' emails to "Executive A" are being delayed by 20–40 minutes, but emails to "Executive B" arrive normally. Both executives' mailboxes are nominally in the same tenant. The customer assumes this is a security-product scanning delay.
Task: Write out the hybrid-specific question you must ask first, per 2.5, before any product-side investigation begins, and explain — in your own words — why the answer to that question could fully explain the symptom without the security product being involved at all.
Knowledge Check
Answer each question yourself before expanding it.
1. What is the fundamental difference between an inline/MX-based deployment and an API-based deployment, in terms of what the product can and cannot do to a message?
2. In an M365 environment with a third-party gateway inline, why might Enhanced Filtering for Connectors (skip-listing) misconfiguration cause a message the gateway already cleared to be re-flagged?
3. A customer says "your product blocked this attachment," but the environment has two filtering layers. What must you confirm before accepting that attribution?
4. Why can journaling not be assumed to mean a message was security-scanned?
5. In a hybrid environment, why is "which side hosts this mailbox" the first question, not the last, when troubleshooting a delay?
6. What header-level evidence distinguishes a routing loop from independent duplicate delivery?
7. For an API-based (non-inline) deployment, which system's logs are authoritative for "was the message delivered," and why?
Common Misconceptions
Key Takeaways
- Before you touch any tool on a mail-flow ticket, answer one question first: what deployment model is this customer on, and how do you know? Skipping that step is the single most common way to misattribute a failure to the wrong system.
- Inline versus API-based isn't just technical trivia — it determines which system's logs you trust as authoritative. Get the model wrong, and you'll spend the whole investigation looking at the wrong evidence.
- Don't let yourself escalate a ticket until you can state both the deployment model and the last hop you have positive evidence for. If you can't state both, you're not ready to escalate — you're ready to keep investigating.
- Journaling, BCC copies, transport rules, and routing connectors are frequently mistaken for the security product's own behavior. Learn to recognize each on sight so you don't chase the product for something a completely different system did.
- A routing loop and a duplicate-delivery event can look identical at a glance — multiple copies of the same message. Compare Message-IDs and Received: chains before you conclude which one you're actually looking at.