📧 Exchange Online Course · Module 4 of 7
Mail Flow — Domains, Connectors, Rules & Message Trace
MS-203 Exam Alignment
MS-203
Skill Area 2 — Manage mail flow (the most heavily weighted MS-203 domain): configure accepted domains and remote domains, create and manage connectors, write transport rules, understand Exchange Online Protection filtering order, and trace messages end-to-end.
- Know the three accepted domain types cold — Authoritative vs Internal Relay vs External Relay
- Understand when a connector is required and when default mail flow (MX to EOP) is sufficient
- Know transport rule structure: conditions, exceptions, actions, priority order, and stop processing
- Understand SPF, DKIM, and DMARC at the level of what each record validates
- Know Message Trace retention: 10 days real-time, up to 90 days via extended trace reports
Exam Tip: Expect at least one hybrid-coexistence question where the answer hinges on the accepted domain type — if some mailboxes remain on-premises, the shared domain must be Internal Relay in Exchange Online, so unresolved recipients route onward instead of bouncing with "user not found".
Mail Flow is the operational heart of Exchange Online — and the largest skill area on the MS-203 exam. The EAC Mail flow section contains Message trace, Rules, Remote domains, Accepted domains, Connectors, and Alerts. This module walks each one: how mail enters and leaves your tenant, how to route it through partners and gateways, how to enforce policy in transit with transport rules, and how to prove exactly what happened to any message with Message Trace.
🗺️ How Mail Flows Through Exchange Online
💡 The Default Path — MX → EOP → Mailbox
In a standard Exchange Online tenant, your domain's MX record points to Exchange Online Protection (e.g. techcareers-in.mail.protection.outlook.com). Inbound mail arrives at EOP, passes connection filtering, anti-malware, anti-spam and anti-phishing checks, then transport rules run, and the message is delivered to the mailbox. Outbound mail leaves via EOP directly to the recipient's MX. No connectors are needed for this default flow — connectors exist only for special routing scenarios.
🌐 Accepted Domains
An accepted domain is any SMTP namespace for which your organisation sends or receives email. Every email domain added and verified in Microsoft 365 automatically appears here. The type controls what Exchange Online does with mail addressed to recipients it cannot find:
| Type | Behaviour for Unknown Recipients | When to Use |
|---|---|---|
| Authoritative | Reject with NDR 550 5.1.10 (recipient not found) — Exchange Online is the final destination | Default. All recipients for the domain exist in this tenant |
| Internal Relay | Relay onward via a connector to another email system (e.g. on-premises Exchange) | Hybrid coexistence, or a domain shared with another mail system |
| External Relay | Accept and relay to an external system that is fully authoritative for the domain | Rare — you accept mail for a domain hosted entirely elsewhere |
PowerShell — Accepted Domains
Connect-ExchangeOnline # List all accepted domains and their types Get-AcceptedDomain | Select-Object Name,DomainName,DomainType,Default # Change a domain to Internal Relay (hybrid coexistence) Set-AcceptedDomain -Identity "techcareers.in" -DomainType InternalRelay
🌍 Remote Domains
Remote domains control outbound message formatting and policy per destination domain — a frequently overlooked EAC page. The Default remote domain (*) applies to all destinations unless a more specific entry exists:
| Remote Domain Setting | Controls | Common Use |
|---|---|---|
| Out of Office types | Whether external OOF replies are sent to that domain | Suppress OOF to the internet, allow to partner domains |
| Automatic replies / forwards | Whether auto-replies and auto-forwards are allowed to the domain | Allow auto-forward only to an acquired company's domain |
| Delivery / read receipts (NDRs) | Whether delivery reports and NDRs flow to the domain | Suppress NDR backscatter to untrusted destinations |
| Message format | Rich text (TNEF) vs MIME, character sets | Fix "winmail.dat" attachment issues to a specific domain |
🔌 Connectors
Connectors define trusted routing paths beyond the default flow. Directionality is from the Exchange Online perspective:
| Connector | Direction | Typical Scenarios |
|---|---|---|
| Inbound connector | Partner org or your on-premises server → Exchange Online | Hybrid mail flow; third-party gateway (Mimecast/Proofpoint) delivering filtered mail; multifunction printers/apps relaying via your tenant; enforcing TLS from a partner |
| Outbound connector | Exchange Online → partner org, smart host, or on-premises | Routing all outbound mail through a security gateway; delivering to on-premises mailboxes in hybrid; forcing TLS + certificate validation to a partner domain |
EAC › Mail flow › Connectors › + Add a connector
🏠 Home
👤 Recipients
📧 Mail flow
Message trace
Rules
Remote domains
Accepted domains
Connectors
Alerts
🔑 Roles
New connector — Connection from ①
Connection from: ◉ Partner organization | ○ Your organization's email server
Authenticate sent email by ②
◉ By verifying that the sender IP address matches one of these IP addresses: 203.0.113.10, 203.0.113.11
○ By verifying the subject name on the TLS certificate: *.gateway-partner.com
☑ Reject email messages if they aren't sent over TLS
① In Mail flow → Connectors, click + Add a connector and choose the connection direction — from a partner organization (gateway/partner) or from your own email server (hybrid).
② Choose the authentication method — sender IP addresses or TLS certificate subject. For security gateways, IP-based identification is most common; keep the IP list current or inbound mail will be rejected.
PowerShell — Create & Audit Connectors
Connect-ExchangeOnline # Inbound connector for a third-party security gateway (identified by IP) New-InboundConnector -Name "Inbound from Gateway" -ConnectorType Partner -SenderDomains * -SenderIPAddresses 203.0.113.10,203.0.113.11 -RequireTls $true # Outbound connector routing ALL outbound mail via the gateway smart host New-OutboundConnector -Name "Outbound via Gateway" -ConnectorType Partner -RecipientDomains * -SmartHosts "smtp.gateway-partner.com" -TlsSettings EncryptionOnly -UseMXRecord $false # Audit all connectors Get-InboundConnector | Format-List Name,Enabled,SenderIPAddresses,RequireTls,ConnectorType Get-OutboundConnector | Format-List Name,Enabled,SmartHosts,TlsSettings,RecipientDomains,UseMXRecord # Validate an outbound connector end-to-end Validate-OutboundConnector -Identity "Outbound via Gateway" -Recipients "test@partner.com"
📜 Transport Rules (Mail Flow Rules)
Transport rules inspect every message in transit and apply actions when conditions match. Rules are evaluated in priority order (0 = first), and a rule can stop processing of subsequent rules. Each rule is built from conditions, exceptions, and actions:
| Scenario | Condition | Action |
|---|---|---|
| Block external auto-forwarding | Message type is Auto-Forward AND recipient is outside the org | Reject with explanation |
| Outbound disclaimer | Sender is inside org AND recipient is outside org | Append HTML disclaimer |
| Encrypt sensitive mail | Message contains sensitive info types (credit card, Aadhaar, PAN) | Apply Office 365 Message Encryption |
| Bypass filtering for trusted relay | Sender IP is in a defined range | Set SCL to -1 |
| Prepend external tag | Sender is outside the organisation | Prepend "[External]" to subject |
| Route Finance mail via partner | Sender is a member of the Finance group | Use the specified outbound connector |
PowerShell — Key Transport Rules
Connect-ExchangeOnline # 1. Block external auto-forwarding (security baseline) New-TransportRule -Name "Block External Auto-Forward" -MessageTypeMatches AutoForward -SentToScope NotInOrganization -RejectMessageReasonText "External auto-forwarding is not permitted. Contact IT." -Priority 0 # 2. Tag external mail in the subject New-TransportRule -Name "Tag External Mail" -FromScope NotInOrganization -PrependSubject "[External] " # 3. Outbound HTML disclaimer New-TransportRule -Name "Outbound Disclaimer" -FromScope InOrganization -SentToScope NotInOrganization -ApplyHtmlDisclaimerText "<p>This email and any attachments are confidential.</p>" -ApplyHtmlDisclaimerLocation Append -ApplyHtmlDisclaimerFallbackAction Wrap # Review all rules in priority order Get-TransportRule | Sort-Object Priority | Select-Object Priority,Name,State,Mode # Test a rule safely before enforcing Set-TransportRule -Identity "Tag External Mail" -Mode TestWithPolicyTips
⚠️ Rule Mode — Test Before You Enforce
Every transport rule supports three modes: Enforce (live), TestWithPolicyTips (show tips to senders, take no action), and TestWithoutPolicyTips (log matches only — visible in message trace). For any rule that rejects or redirects mail, run it in a test mode first and review message trace results before enforcing. A badly-scoped reject rule can bounce legitimate business mail organisation-wide within minutes.
🛡️ Email Authentication — SPF, DKIM, DMARC
Exchange Online Protection validates inbound mail using three DNS-based standards, and you must publish them for your own domain to protect outbound reputation:
| Standard | What It Validates | DNS Record |
|---|---|---|
| SPF | The sending server's IP is authorised to send for the domain | TXT: v=spf1 include:spf.protection.outlook.com -all |
| DKIM | Message integrity — a cryptographic signature matched against a public key in DNS | Two CNAMEs: selector1._domainkey and selector2._domainkey → onmicrosoft.com keys; enabled in Defender portal |
| DMARC | Alignment of SPF/DKIM with the From: header, and instructs receivers what to do on failure | TXT at _dmarc: v=DMARC1; p=quarantine; rua=mailto:dmarc@techcareers.in |
🔍 Message Trace
Message Trace, at Mail flow → Message trace, follows email through Exchange Online: whether it was received, rejected, deferred, delivered, quarantined, or acted on by a rule. Real-time trace data covers the last 10 days; older messages (up to 90 days) require a downloadable extended trace report.
PowerShell — Message Trace (v2 cmdlets)
Connect-ExchangeOnline # Trace by sender over the last 48 hours Get-MessageTraceV2 -SenderAddress amit@techcareers.in -StartDate (Get-Date).AddHours(-48) -EndDate (Get-Date) | Select-Object Received,SenderAddress,RecipientAddress,Subject,Status # Hop-by-hop detail for one message (use MessageTraceId from above) Get-MessageTraceDetailV2 -MessageTraceId <id> -RecipientAddress user@partner.com | Select-Object Date,Event,Detail # Find all FAILED messages today Get-MessageTraceV2 -StartDate (Get-Date).Date -EndDate (Get-Date) -Status Failed | Select-Object Received,SenderAddress,RecipientAddress,Subject
💡 Reading Trace Status Values
- Delivered — reached the mailbox or next hop successfully
- Failed — rejected or NDR'd; open detail to see which check or rule rejected it
- Quarantined — held by anti-spam/anti-phishing policy; release from the Defender portal quarantine page
- FilteredAsSpam — delivered to Junk Email per spam policy action
- Pending / Deferred — still being processed or retried; persistent deferrals usually indicate connector or destination issues
💡 Best Practices
- Never create connectors "just in case" — default MX-to-EOP flow needs none, and unnecessary connectors are a common cause of mail loops
- Keep inbound connector IP lists in change control — a gateway IP change without a connector update silently breaks inbound mail
- Give every transport rule a comment describing its business purpose and owner; audit rules quarterly
- Deploy the Block External Auto-Forward rule at Priority 0 in every tenant unless there is a documented business exception
- Run new reject/redirect rules in TestWithoutPolicyTips mode for at least a week and review trace hits before enforcing
- Publish SPF with -all (hard fail), enable DKIM for every sending domain, and move DMARC from p=none to p=quarantine once reports are clean
- Bookmark Message Trace — it answers "the email never arrived" tickets in minutes and is the first tool to open for any delivery complaint
🎓 Interview Q&A
Q: What are the three accepted domain types and when is each used?
Authoritative — Exchange Online is the final destination; unknown recipients are rejected with NDR 5.1.10. Internal Relay — unknown recipients are relayed onward via a connector to another system sharing the namespace, essential in hybrid coexistence. External Relay — mail is accepted and relayed to an external system fully authoritative for the domain. Most tenants use Authoritative for every domain; Internal Relay appears the moment mailboxes are split across two systems.
Q: When do you need a connector in Exchange Online, and when do you not?
You do NOT need connectors for standard internet mail — MX to EOP inbound, EOP direct-to-MX outbound. You DO need connectors for: hybrid mail flow with on-premises Exchange (created by the Hybrid Configuration Wizard), routing outbound through a third-party gateway smart host, receiving filtered mail from a gateway identified by IP, application/device SMTP relay, and enforcing mandatory TLS with a specific partner.
Q: A user reports an important external email never arrived. Walk through your troubleshooting.
Open Mail flow → Message trace and search by sender address and date range. If no result: the message never reached EOP — check the sender got an NDR, verify MX records, and check the sending side. If Status = Failed: open detail to see which check rejected it. If Quarantined: review and release from the Defender quarantine. If FilteredAsSpam: check the user's Junk folder and tune the anti-spam policy. If Delivered: the message is in the mailbox — check inbox rules that may have moved or deleted it (Get-InboxRule).
Q: What do SPF, DKIM, and DMARC each validate?
SPF validates that the sending server's IP is authorised by the domain owner (TXT record). DKIM validates message integrity via a cryptographic signature verified against a public key in DNS. DMARC validates that SPF or DKIM aligns with the visible From: address and tells receiving servers what to do on failure (none/quarantine/reject) plus where to send aggregate reports. Together they prevent spoofing of your domain and protect outbound deliverability.
Q: How long is message trace data available?
Real-time (interactive) message trace covers the last 10 days. For messages between 10 and 90 days old, you run an extended trace from the same EAC page, which is generated asynchronously as a downloadable CSV report. Beyond 90 days, trace data is gone — for long-term investigation you need audit logs or journaling captured at the time.
🎯 MS-203 Mock Test
Module 4 — Exchange Online: Mail Flow
Question 1 of 5
Contoso is mid-migration: half its mailboxes are in Exchange Online, half remain on-premises. Internet senders' mail arrives at Exchange Online first. Mail to on-premises users bounces with "recipient not found". What should you change?
✅ Correct answer: B. With Authoritative type, Exchange Online rejects any recipient it can't resolve. Internal Relay makes it relay unresolved recipients onward through the hybrid connector to on-premises. (In a properly synced hybrid, mail users represent on-prem mailboxes — but when recipients are bouncing as unknown, the domain type is the exam-correct fix.) External Relay (A) is for domains hosted entirely elsewhere.
Question 2 of 5
All outbound email must be routed through a third-party DLP gateway at smtp.gateway.com before reaching the internet. What should you create?
✅ Correct answer: C. An outbound connector scoped to * (all recipient domains) with the gateway as smart host and UseMXRecord $false routes all outbound mail through the gateway. An inbound connector (A) handles the return path from the gateway, not outbound routing. Remote domains (D) control formatting/policy per destination, not routing.
Question 3 of 5
You must deploy a rule that rejects messages containing customer credit card numbers sent to external recipients — but leadership requires proof it won't block legitimate mail first. What is the correct approach?
✅ Correct answer: A. TestWithoutPolicyTips evaluates conditions and logs matches (visible in message trace) without taking the reject action — exactly the evidence needed. Low priority (B) doesn't prevent the action from firing. A disabled rule (C) logs nothing while disabled. A pilot scope (D) changes the rule being tested and still enforces against the pilot group.
Question 4 of 5
A recipient's mail server rejects your organisation's email, citing DMARC failure. SPF passes for your domain. What is the most likely cause?
✅ Correct answer: D. DMARC requires that a passing SPF or DKIM identity ALIGNS with the visible From: domain. A common failure: a marketing/CRM platform sends "from" your domain, SPF passes for THE PLATFORM's envelope domain (not aligned), and DKIM isn't signed with your domain's key. Fix by adding the service to your SPF and configuring its DKIM signing for your domain. MX records (A) affect inbound, not outbound DMARC evaluation.
Question 5 of 5
A compliance officer asks you to confirm whether a specific email was delivered 45 days ago. What should you do?
✅ Correct answer: B. Interactive message trace covers only the last 10 days, but an extended trace — requested from the same Mail flow → Message trace page — reaches back up to 90 days and is delivered asynchronously as a downloadable report. 45 days falls inside that window, so answer C is wrong; Recoverable Items (D) shows mailbox content, not transport evidence.
🔒
This module is lockedComplete Module 3 and pass its mock test to unlock this module.