📄 Article
Exchange Online Mail Flow: Complete Administration Guide
Email flow is the backbone of any organisation using Microsoft 365. Whether you’re managing a hybrid environment or a cloud-only deployment, understanding how email moves through Exchange Online — and how to troubleshoot it — is critical for every M365 administrator.
📧 Understanding Email Flow Basics
💡 Mail Flow Directions in Exchange Online
- Outbound: From your organisation to the internet
- Inbound: From the internet to your organisation
- Internal: Between users within your organisation
- Hybrid: Between on-premises Exchange and Exchange Online
🌐 MX Records — The Foundation of Mail Flow
💡 What an MX Record Does
Your MX record is the traffic controller of your email. It tells the internet where to deliver emails sent to your domain. When you point your MX record to Exchange Online, all inbound email is directed to Microsoft’s servers first.
The typical Exchange Online MX record format:tenant-name.mail.protection.outlook.com — Priority 10
🗺️ Mail Flow Scenarios
Cloud-Only Organisation
✅ How It Works
- All mailboxes reside in Exchange Online
- Inbound email arrives at the Exchange Online MX record and is delivered directly
- Outbound email goes from Exchange Online → Microsoft SMTP → recipient’s mail server
- No on-premises connectors required
Hybrid Environment with Centralised Mail Flow
💡 How Centralised Mail Flow Works
- All email — both cloud and on-premises users — routes through Exchange Online before going to the internet
- Inbound emails arrive at Exchange Online MX, then on-premises users’ mail is routed via an inbound connector to on-premises Exchange
- On-premises users’ outbound mail goes via outbound connector → Exchange Online → internet
- This is the Microsoft-recommended approach for hybrid deployments — centralises anti-spam, DLP, and transport rule enforcement
Large Environments — 100,000+ Mailboxes
💡 How Inbound/Outbound Flow Scales
The mail flow architecture doesn’t fundamentally change at scale — it’s the same MX-based routing and connectors — but at 100,000+ mailboxes you need to plan for throttling limits, message rate limits per connector, and hybrid connector capacity. Inbound mail for cloud users still arrives at the Exchange Online MX record and is delivered directly to their mailbox; for on-premises users in a hybrid setup, it’s routed via the inbound connector. Outbound mail from cloud users leaves via Exchange Online’s outbound SMTP directly; on-premises users route out through Exchange Online first if centralised mail flow is configured. At this scale, organisations typically also implement dedicated outbound IP pools and monitor connector throughput closely to avoid delivery delays.
🛠️ Troubleshooting Mail Flow Issues
1
Email Not Being Received
Work through these checks in order to identify where mail flow is breaking down.
⚠️ Diagnosis Checklist
- Verify MX record points correctly to Exchange Online (use MXToolbox or nslookup)
- Test SMTP connectivity to the MX endpoint
- Check Mail Flow Rules — confirm none are silently deleting or redirecting messages
- Review Connector settings for partner or on-premises connectors
- Check Quarantine in Microsoft Defender for blocked or spam-filtered emails
PowerShell — Exchange Online Message Trace
Connect-ExchangeOnline # Run message trace for the last 48 hours Get-MessageTrace -RecipientAddress "user@yourdomain.com" -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) | Select-Object Received,SenderAddress,RecipientAddress,Subject,Status,ToIP,FromIP | Format-Table -AutoSize # Get detailed trace for a specific message Get-MessageTraceDetail -MessageTraceId "YourMessageTraceID" -RecipientAddress "user@yourdomain.com"
2
On-Premises Emails Not Reaching Cloud Users (Hybrid)
In hybrid environments, inbound mail flow from on-premises to Exchange Online relies on properly configured connectors. Check these when cloud users don’t receive mail from on-prem senders.
⚠️ What to Check
- Verify the inbound connector from on-premises exists and is enabled in Exchange Online
- Confirm the on-premises server’s IP address is in the connector’s allowed sender list
- Verify TLS is properly configured on both the on-premises server and Exchange Online connector
- Check that the on-premises Exchange server’s certificate matches the connector’s domain name requirement
PowerShell — Check Inbound Connector
Connect-ExchangeOnline # List all inbound connectors Get-InboundConnector | Select-Object Name,Enabled,SenderIPAddresses,RequireTls,TlsSenderCertificateName # List all outbound connectors Get-OutboundConnector | Select-Object Name,Enabled,SmartHosts,TlsSettings,UseMXRecord # Check mail flow rules that may be affecting delivery Get-TransportRule | Select-Object Name,Priority,State | Format-Table -AutoSize
3
Security Group vs Mail-Enabled Security Group
A common source of confusion in mail flow troubleshooting — understanding the difference between these two group types is a frequent interview topic.
| Feature | Security Group | Mail-Enabled Security Group |
|---|---|---|
| Access control (permissions) | ✅ Yes | ✅ Yes |
| Has email address | ❌ No | ✅ Yes |
| Can receive emails | ❌ No | ✅ Yes |
| Use in mail flow rules | ❌ No | ✅ Yes |
| Typical use case | SharePoint / file permissions | Distribution + security combined |
🔐 Email Authentication — SPF, DKIM, DMARC
💡 What Each Record Does
- SPF (Sender Policy Framework): Lists the authorised IP addresses and mail servers allowed to send email on behalf of your domain. Receiving servers check this to validate the sender.
- DKIM (DomainKeys Identified Mail): Adds a cryptographic digital signature to every outbound email. Receiving servers verify this signature to confirm the message hasn’t been tampered with in transit.
- DMARC (Domain-based Message Authentication): Builds on SPF and DKIM by telling receiving servers what to do when authentication fails — none, quarantine, or reject. Also enables reporting back to the domain owner.
⚠️ SPF: Hard Fail vs Soft Fail
- Soft fail (~all): Emails from unauthorised sources are marked as suspicious but still delivered. Recommended for new organisations while you identify all legitimate senders.
- Hard fail (-all): Emails from unauthorised sources are rejected outright. Use only when you are confident all legitimate sending sources are listed in your SPF record.
🏢 Accepted Domains & Onboarding a New Domain
💡 Accepted Domain Types
- Authoritative: All recipients for this domain exist in your Exchange Online organisation — mail to unknown recipients is rejected as undeliverable
- Internal Relay: Some recipients exist elsewhere (e.g. on-premises during migration) — Exchange Online relays mail it can’t resolve locally
- External Relay: The domain is not hosted here at all — Exchange Online simply relays mail through to another mail system
📦 Mailbox and Archive Both Full Under Litigation Hold
⚠️ Why This Happens
When litigation hold is enabled, Exchange Online preserves every item — including ones the user deletes — in a hidden Recoverable Items folder, so normal deletion doesn’t free up space. If the primary mailbox and the in-place archive both hit their quota, users can’t send or receive mail even though “deleting” items appears to work.
✅ Resolution Steps
- Confirm the mailbox and archive are genuinely full via Get-MailboxStatistics and check quota settings
- Request a temporary quota increase (Exchange Online Plan 2 / Auto-Expanding Archive supports growth beyond default limits)
- Enable Auto-Expanding Archiving if not already active — it automatically adds storage as the archive fills
- Do not disable litigation hold to “fix” the space issue — that removes the legal preservation requirement
- Work with legal/compliance to see if the hold scope or duration can be narrowed appropriately
🔑 Registering an Application to Send Email
💡 Modern Approach — OAuth 2.0 with Microsoft Graph or SMTP AUTH
Since Basic Authentication is deprecated, applications must authenticate using OAuth 2.0 client credentials flow. Register the app in Entra ID (App registrations → New registration), grant it the Mail.Send application permission for Microsoft Graph (with admin consent), generate a client secret or certificate, and have the app request a token from Entra ID before calling the Graph sendMail API. For legacy SMTP-based apps that can’t use Graph, configure an app registration with SMTP AUTH OAuth and scope it to a specific mailbox via a mail-enabled security group, rather than enabling SMTP AUTH tenant-wide.
💡 Best Practices & Recommendations
- Use Centralised Mail Flow in hybrid environments — all email through Exchange Online ensures consistent policy enforcement
- Enable TLS for all connectors — enforces encrypted transmission between your on-premises servers and Exchange Online
- Monitor Mail Flow Rules regularly — accidental or misconfigured rules are a common cause of silent mail delivery failures
- Configure Accepted Domains correctly — ensure all domains your organisation uses for email are listed as authoritative or relay domains
- Implement SPF, DKIM, and DMARC for all sending domains to protect against spoofing and phishing
- Use Message Trace as your first diagnostic tool for any mail flow complaint — it shows exactly where in the pipeline a message failed
🎓 Common Interview Questions
Q: How does email flow from your organisation to the internet in Exchange Online?
The user sends an email from their client → Exchange Online SMTP processors accept the message → it is processed through mail flow rules (transport rules) → Microsoft Defender for Office 365 scans it for threats → Exchange Online performs a DNS lookup for the recipient’s domain MX record → establishes SMTP connection to the recipient’s mail server → email is delivered.
Q: What is the difference between a security group and a mail-enabled security group?
A security group is used for access control only — it has no email address and cannot receive emails. A mail-enabled security group has both access control capabilities AND an email address, making it usable for both permission assignment and email distribution.
Q: How does centralised mail flow work in a hybrid Exchange environment?
All email — both inbound and outbound — routes through Exchange Online. External inbound email arrives at the Exchange Online MX record; on-premises users’ mail is then routed via an inbound connector to the on-premises Exchange server. On-premises users’ outbound email goes through an outbound connector to Exchange Online, then to the internet. This centralises anti-spam, DLP, and transport rule enforcement in one place.
Q: In an environment with 100,000+ mailboxes, how does inbound/outbound mail flow work for cloud users?
Architecturally it’s the same MX-based routing as any Exchange Online tenant — inbound mail arrives at the tenant’s MX record and is delivered directly to the cloud mailbox; outbound mail leaves via Exchange Online’s outbound SMTP infrastructure. What changes at this scale is capacity planning: message rate limits per connector, hybrid connector throughput if on-premises users are involved, and often dedicated outbound IP pools to protect sender reputation. Monitoring connector health and throttling becomes essential at this volume.
Q: What is the relationship between SPF, DKIM, and DMARC?
SPF validates which servers are authorised to send on behalf of your domain. DKIM adds a cryptographic signature to prove message integrity. DMARC builds on both — it requires either SPF or DKIM (or both) to pass and align, and it tells receiving servers what action to take when they fail (none, quarantine, or reject). Implementing all three together provides the strongest protection against email spoofing.
Q: How would you troubleshoot an email that was sent but not received?
Start with a Message Trace in the Exchange Admin Center or via PowerShell (Get-MessageTrace). This shows the delivery status at every hop. Look for: GettingStatus (delayed), Failed (delivery failure with error code), FilteredAsSpam (quarantined), or Delivered (check recipient’s Junk folder). Then check: MX record, mail flow rules, connectors, and quarantine depending on what the trace reveals.
Q: A new organisation was acquired — what steps do you follow to allow email from their domain in M365?
Add the acquired company’s domain as an accepted domain in Exchange Online (as internal relay if mailboxes are migrating gradually, or authoritative once fully migrated). Verify the domain via DNS TXT record in Microsoft 365 admin center, update SPF/DKIM/DMARC for the new domain so mail sent from it authenticates properly, add any necessary mail flow connectors if their mail system still exists in parallel during transition, and update accepted domain and address policies so new mailboxes can use the domain as a proxy or primary address.
Q: A user’s primary mailbox and in-place archive are both full with litigation hold enabled. How do you resolve this?
Litigation hold preserves every item — including deleted ones — in the Recoverable Items folder, so normal deletion doesn’t reclaim space. Verify actual usage with Get-MailboxStatistics, then request a quota increase or enable Auto-Expanding Archiving to add storage automatically. Do not remove litigation hold just to free up space, since that defeats its legal purpose — work with legal/compliance if the hold itself needs to be reviewed.
Q: An application needs to be registered to send emails. How do you configure this?
Register the app in Entra ID under App registrations, grant it the Mail.Send application permission for Microsoft Graph, get admin consent, and generate a client secret or certificate for authentication. The app then requests an OAuth 2.0 token from Entra ID and calls the Graph sendMail API — no shared mailbox password required. For legacy apps that must use SMTP, configure SMTP AUTH with OAuth scoped to a specific mailbox rather than enabling basic SMTP AUTH tenant-wide, since that’s deprecated and a security risk.
📚 References & Further Reading
- 🔗 Mail flow best practices for Exchange Online — Microsoft Learn
- 🔗 Run a message trace in Exchange Online — Microsoft Learn
- 🔗 Email authentication in Microsoft 365 (SPF, DKIM, DMARC) — Microsoft Learn