If you’ve spent even a few months managing Microsoft 365, you already know that Exchange Online Real-World Troubleshooting Scenarios rarely follow textbook patterns.
Users don’t say: “My SPF alignment is failing due to DNS lookup recursion limits.”
They say: “Emails aren’t working.”
That’s where real expertise begins.
This blog dives deep into Exchange Online Real-World Troubleshooting Scenarios, based on practical field cases. These scenarios are not theoretical—they reflect real production issues across mail flow, security, hybrid environments, compliance, and identity.
The goal is simple: sharpen your troubleshooting instincts, not just your command syntax.
Exchange Online Real-World Troubleshooting Scenarios represent the true test of an admin’s skill. These scenarios combine real production issues with structured troubleshooting including:
- Situation
- Approach
- Resolution Steps
- Key PowerShell Commands
- Root Cause Analysis
Each scenario is derived from real-world enterprise troubleshooting labs designed to build diagnostic expertise.
Table of Contents
Scenario 1: External Partner Not Receiving Mail
Situation
A partner reports no emails received for 72 hours; No NDR was generated on either side. Internal users confirm Sent Items show the messages as delivered.
Approach
Start at the end (recipient) and work backwards to the source. The absence of an NDR is itself a clue — the message was accepted but not delivered.
Resolution Steps
Step 1 — Confirm via Message Trace
Run an Extended Message Trace (M365admin Portal → Exchange Admin Center → Mail flow → Message trace) for the sender’s address and the specific recipient domain. Filter by the last 7 days and look for status codes.
Step 2 — Decode the Status
A status of ‘Delivered’ with no further hop means EOP handed it off successfully. A status of ‘FilteredAsSpam’ or ‘GettingStatus’ signals the receiving gateway rejected or silently dropped.
Step 3 — Check Outbound Connector
Verify the outbound connector is not forcing TLS to the partner domain. Use: Get-OutboundConnector | FL. If TLS is enforced and the partner certificate expired, mail silently queues then drops.
Step 4 — SMTP Telnet Test
From Exchange Online using Test-Message, or from an on-premise server: telnet Partner MX on port 25. Observe the banner and MX response.
Step 5 — Engage Partner IT
Request the partner’s gateway logs for your sending IP (visible in EOP message trace headers). Their spam filter may be silently discarding based on IP reputation or SPF failure.
Key PowerShell Commands
Get-MessageTraceV2 -SenderAddress user@yourdomain.com -RecipientAddress partner@domain.com -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) | FLGet-OutboundConnector | Select Name, TlsSettings, SmartHosts, Enabled | FLTest-OutboundConnectivity -Identity "ConnectorName"Root Cause Analysis
Outbound connector enforcing opportunistic TLS failed negotiation with partner’s expired certificate. Messages were queued silently and expired. Fix: remove TLS enforcement or update partner cert.
Exchange Online Emails Not Delivering to External Domains – Solve Step-by-Step
How Message Trace Works in Exchange Online: The Ultimate Positive Guide for Admins
Scenario 2: NDR 5.7.57 on Shared Mailbox — SMTP Auth Blocked by Policy
Situation
A service account trying to send via a shared mailbox receives NDR 5.7.57: ‘Client not authenticated to send Anonymous mail during MAIL FROM.’ The mailbox was working fine last week.
Approach
NDR 5.7.57 specifically means SMTP AUTH was attempted but blocked. Work from authentication policy to mailbox-level settings.
Resolution Steps
Step 1 — Check Authentication Policy
Run Get-AuthenticationPolicy to see if a policy blocking SMTP AUTH was recently applied. This is the most common cause after security hardening runs.
Step 2 — Inspect the Mailbox
Run Get-CASMailbox | FL SmtpClientAuthenticationDisabled. If True, SMTP AUTH is explicitly disabled at the mailbox level.
Step 3 — Check Organization-wide Setting
Run Get-TransportConfig | FL SmtpClientAuthenticationDisabled. If True at org level, all mailboxes are blocked regardless of per-mailbox setting.
Step 4 — Re-enable Selectively
Enable SMTP AUTH specifically for the shared mailbox only — do not enable org-wide. Set-CASMailbox -SmtpClientAuthenticationDisabled $false.
Step 5 — Verify App Credentials
Confirm the application sending via this mailbox uses SMTP AUTH with correct credentials. If it uses delegated access, it should use Graph API or SMTP OAuth instead of basic auth.
Key PowerShell Commands
Get-CASMailbox 'SharedMailbox@domain.com' | FL SmtpClientAuthenticationDisabled
Get-TransportConfig | FL SmtpClientAuthenticationDisabled
Set-CASMailbox 'SharedMailbox@domain.com' -SmtpClientAuthenticationDisabled $false
Get-AuthenticationPolicy | FLRoot Cause Analysis
A tenant-wide security policy applied SmtpClientAuthenticationDisabled=$true. Shared mailbox had no individual override. Fix: per-mailbox re-enable and transition to OAuth.
SMTP Relay Office 365: Ultimate Expert Guide to Secure & Powerful Email Delivery
Scenario 3: Emails Going to Spam SPF Softfail from SaaS Relay
Situation
Marketing newsletters sent via a third-party SaaS platform are landing in recipients’ Junk folders. The SPF record exists but the SaaS relay IPs are missing.
Approach
Trace the authentication chain: SPF lookup → alignment → composite score. The SPF pass/fail depends entirely on which IP the mail is sent from.
Resolution Steps
Step 1 — Read the Message Headers
Open the raw headers of a junk-delivered message. Look for: Authentication-Results: spf=softfail. The softfail (~all) allows delivery but marks as suspicious.
Step 2 — Identify Sending IPs
In the SaaS platform’s documentation or admin panel, find all IPs and IP ranges used for sending. These must be in your SPF record.
Step 3 — Update SPF Record
Add the SaaS include mechanism: v=spf1 include:_spf.yourdomain.com include:sendgrid.net ~all. Validate with: nslookup -type=TXT yourdomain.com. Ensure total DNS lookups do not exceed 10 (SPF permerror).
Step 4 — Set Up DKIM in SaaS Platform
Most SaaS providers allow you to add a CNAME in your DNS that delegates DKIM signing. This adds a cryptographic pass that carries more weight than SPF alone.
Step 5 — Set DMARC Policy
Add a DMARC TXT record: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com. Start with p=none for monitoring, then tighten. Ensure SPF and DKIM both align to the From domain
Key PowerShell Commands
nslookup -type=TXT yourdomain.com Resolve-DnsName yourdomain.com -Type TXT | Select Strings
Get-HostedContentFilterPolicy | Select SpamAction, HighConfidenceSpamAction, BulkThresholdRoot Cause Analysis
Third-party SaaS relay IPs absent from SPF record. SPF softfail lowered composite spam score, triggering junk folder classification. Fix: SPF include + DKIM CNAME + DMARC monitoring.
Emails Going to Spam in Exchange Online – Causes & Step-by-Step Fix
Scenario 4: Connector Failure After TLS Certificate Renewal
Situation
Mail flow on an inbound partner connector stopped immediately after the partner renewed their TLS certificate. Messages queue and return NDR 4.7.57: ‘TLS negotiation failed.’
Approach
Certificate-based TLS failures are binary — either the cert is trusted or it isn’t. Start with certificate validation, then connector configuration.
Resolution Steps
Step 1 — Confirm Error Details in Message Trace
Extended Message Trace will show the exact TLS error: certificate untrusted, expired, or subject mismatch. Note the certificate CN in the error.
Step 2 — Inspect Connector TLS Setting
Run Get-InboundConnector | FL to find if the connector is set to RequireTls: $true and TlsSenderCertificateName: . If the CN changed during renewal, this is the failure point.
Step 3 — Verify New Certificate
Ask the partner for the new certificate’s Subject CN or Subject Alternative Names. Use Test-OutboundConnectivity or openssl s_client to verify the new cert is being served.
Step 4 — Update Connector
Run Set-InboundConnector -Identity ‘PartnerConnector’ -TlsSenderCertificateName ‘new.partner.domain.com’. This allows EOP to accept the new cert’s CN.
Step 5 — Test and Flush Queue
After updating, send a test message from the partner. Retry any queued messages from the EOP dashboard or via Retry-Queue.
Key PowerShell Commands
Get-InboundConnector | FL Name, TlsSenderCertificateName, RequireTls, Enabled
Set-InboundConnector -Identity 'PartnerInbound' -TlsSenderCertificateName 'mail.partner.com'
Test-MigrationServerAvailability -Autodiscover -EmailAddress admin@partnerdomain.comRoot Cause Analysis
Connector’s TlsSenderCertificateName referenced the old certificate CN. After partner renewal, cert CN changed, causing TLS mismatch on every inbound connection. Fix: update TlsSenderCertificateName to new CN.
Scenario 5: Mail Loop — Hybrid Routing Misconfiguration
Situation
A message sent to an on-premises mailbox from Exchange Online is bouncing between EOP and the on-prem server. NDR 5.4.6: ‘Routing loop detected.’ appears after multiple hops.
Approach
Mail loops in hybrid always stem from routing logic: either the on-prem server is re-routing accepted mail back to EOP, or the Hybrid Connector is misconfigured.
Resolution Steps
Step 1 — Read the X-MS-Exchange-Organization Headers
Open the full headers and look for repeated X-MS-Exchange-Organization-SCL and Received headers. Count hops. Identify where the loop turns back.
Step 2 — Check On-Prem Send Connector
On Exchange Server (2016/2019), verify the Send Connector is not pointing to EOP for all mail, including internal domains. This creates a loop when EOP also routes to on-prem.
Step 3 — Verify Accepted Domains
In EOP, check that the hybrid domain is listed as Internal Relay (not Authoritative) if some mailboxes remain on-prem. Authoritative + missing on-prem mailbox = loop.
Step 4 — Inspect MX Record
If MX points to EOP and on-prem has a send connector routing everything back through EOP, you have a full loop. On-prem should route outbound to internet directly or via a smart host.
Step 5 — Fix and Test
Update Accepted Domain to InternalRelay for the hybrid domain, or correct the on-prem send connector Smart Host. Run a test end-to-end message.
Key PowerShell Commands
Get-AcceptedDomain | FL DomainName, DomainType
Set-AcceptedDomain -Identity 'yourdomain.com' -DomainType InternalRelay
Get-SendConnector | FL Name, AddressSpaces, SmartHosts, EnabledRoot Cause Analysis
Domain marked as Authoritative in EOP while mailboxes still existed on-prem. EOP accepted messages then NDR’d them as undeliverable. Fix: change to InternalRelay and update on-prem routing.
Scenario 6: NDR 5.2.2 — Mailbox Full Despite Cloud Storage
Situation
A user receives NDR 5.2.2 ‘Mailbox is full’ when receiving external mail. The user has a 100GB Exchange Online mailbox and claims it is not full, but messages from outside are bouncing.
Approach
NDR 5.2.2 can be triggered by a ‘dumpster’ (Recoverable Items) folder that is full, not just the primary quota. This is commonly missed.
Resolution Steps
Step 1 — Check Total Mailbox Usage
Run Get-MailboxStatistics to see primary quota usage. Also check the RecoverableItemsSize separately — this has its own 30GB quota and counts independently.
Step 2 — Check Recoverable Items
Run Get-MailboxFolderStatistics -FolderScope RecoverableItems. If any folder shows usage near 30GB, this is the problem — especially when Litigation Hold is enabled.
Step 3 — Enable Archive for Dumpster Relief
Enabling an In-Place Archive offloads old items. Enable-Mailbox -Identity user@domain.com -Archive. Then create an Archive Policy to auto-move items older than 2 years.
Step 4 — Increase Recoverable Items Quota Temporarily
Set-Mailbox -Identity user@domain.com -RecoverableItemsQuota 60GB -RecoverableItemsWarningQuota 55GB. This requires E3 or above licensing. Or enable litigation hold on user mailbox for temporary it will increase recoverableitemQuota from 30 GB to 110 GB.
Step 5 — Clean Dumpster if Permitted
If legal hold is not active: Search-Mailbox -Identity user@domain.com -SearchDumpsterOnly -DeleteContent -Force. Validate with legal team first.
Key PowerShell Commands
Get-MailboxStatistics 'user@domain.com' | Select DisplayName, TotalItemSize, ItemCount, StorageLimitStatus
Get-MailboxFolderStatistics "Mamta Kumari" -FolderScope RecoverableItems | Format-List Name,FolderAndSubfolderSize
Get-Mailbox "Test@Tenant365admin.com" | Format-List RecoverableItemsQuota, RecoverableItemsWarningQuota, ProhibitSendQuota, ProhibitSendReceiveQuota, UseDatabaseQuotaDefaults, RetainDeletedItemsFor, UseDatabaseRetentionDefaults
Set-Mailbox 'user@domain.com' -RecoverableItemsQuota 60GB -RecoverableItemsWarningQuota 55GBRoot Cause Analysis
Litigation Hold active + large delete history filled the Recoverable Items folder (30GB cap). External NDRs generated even though primary mailbox had 40GB free. Fix: archive enablement + quota increase.
Scenario 7: Delayed Mail Delivery — Greylisting by Receiving Domain
Situation
Outbound messages to a specific domain consistently take 5–15 minutes to deliver. No NDR is generated. Recipients confirm they eventually receive the mail but it always arrives late.
Approach
Greylisting is a spam defense that temporarily rejects first-time mail with a 4xx (soft fail) code. The sending server retries and delivery succeeds — but with delay.
Resolution Steps
Step 1 — Confirm in Message Trace
Extended Message Trace will show multiple ‘Temporary failure’ events followed by a final ‘Delivered’ for the same message. The 4xx codes (421, 451) are greylisting indicators.
Step 2 — Identify the Retrying IP
EOP rotates outbound IPs. Greylisting servers whitelist a specific IP after the first successful retry. If EOP rotates IPs between retries, the greylist timer resets each time.
Step 3 — Check for Dedicated Outbound IP Option
If your subscription supports dedicated outbound IPs (E5 or Defender add-on), consider requesting one. This reduces rotation variance against greylisting servers.
Step 4 — Communicate with Partner
The most direct fix is asking the partner to whitelist EOP’s outbound IP ranges (published by Microsoft at aka.ms/o365ips). This bypasses their greylist check.
Step 5 — Document SLA Impact
If delays are business-critical, document as a known limitation of recipient’s greylisting policy. Use time-critical alternatives (phone, Teams) for urgent communications.
Key PowerShell Commands
Get-MessageTraceDetailV2 -MessageTraceId | Select Date, Event, Detail Resolve-DnsName -Name autodiscover.domain.com -Type A
Get-HostedOutboundSpamFilterPolicy | FLRoot Cause Analysis
Receiving domain uses greylisting. EOP’s rotating outbound IP pool caused repeated greylist resets. Fix: partner IT to whitelist EOP IP ranges from aka.ms/o365ips.
Scenario 8: Outbound Mail Blocked — User Added to Restricted Senders List
Situation
A user reports they cannot send external mail. All messages return NDR: ‘Your account has been restricted.’ No prior warning was given. Internal mail works fine.
Approach
EOP automatically adds senders to the Restricted Senders list when outbound spam thresholds are exceeded. This is an account compromise indicator requiring immediate investigation.
Resolution Steps
Step 1 — Verify in Restricted Senders List
Go to Microsoft Defender → Email & Colloboration → Review → Restricted entities. Confirm the user is listed and note the timestamp.
Step 2 — Investigate for Compromise
Before releasing, check the Unified Audit Log for suspicious sign-ins, inbox rule changes, and unexpected forwarding rules on this account. Check for new forwarding in Get-InboxRule.
Step 3 — Reset Credentials
Force a password reset and revoke all active sessions: Revoke-AzureADUserAllRefreshTokens. Enable MFA if not already present.
Step 4 — Remove Forwarding Rules
Delete any suspicious inbox rules: Remove-InboxRule -Mailbox user@domain.com -Identity . Check for external forwarding addresses.
Step 5 — Remove from Restricted List
After confirming the account is clean and secured, remove from restricted senders list via Defender portal. Monitor the account’s outbound volume for 48 hours.
Key PowerShell Commands
Get-InboxRule -Mailbox 'user@domain.com' | Select Name, ForwardTo, ForwardAsAttachmentTo, DeleteMessage
Get-MessageTrace -SenderAddress 'user@domain.com' -StartDate (Get-Date).AddDays(-3) | Where {$_.Status -eq 'Failed'}
Search-UnifiedAuditLog -UserIds user@domain.com -Operations 'Set-InboxRule','New-InboxRule' -StartDate (Get-Date).AddDays(-7)Root Cause Analysis
Account compromised via credential phishing. Attacker created inbox rule forwarding all mail externally and sent spam campaigns. Account added to restricted list automatically. Fix: reset + MFA + rule removal + remove restriction.
Scenario 9: DMARC Failure — Subdomain Not Covered by SPF
Situation
Automated notification emails from a subdomain (notifications.yourdomain.com) are failing DMARC at recipient gateways. The primary domain passes DMARC but the subdomain is not configured.
Approach
DMARC alignment requires that the RFC5321 MAIL FROM (used for SPF) or the DKIM d= tag aligns with the RFC5322 From header domain. Subdomains need explicit coverage.
Resolution Steps
Step 1 — Check DMARC Record for Subdomain
Run: nslookup -type=TXT _dmarc.notifications.yourdomain.com. If no record exists, the subdomain inherits the parent’s DMARC policy. Confirm what p= is set to on the parent.
Step 2 — Check SPF for Subdomain
Run: nslookup -type=TXT notifications.yourdomain.com. If no SPF record exists for the subdomain, SPF will fail or permerror since there’s no record to evaluate against.
Step 3 — Create Subdomain SPF
Add a TXT record on notifications.yourdomain.com: v=spf1 include:servers.yourapplication.com ~all. This scopes SPF specifically for that subdomain’s sending servers.
Step 4 — Add DKIM for Subdomain
In your SaaS notification platform, generate a DKIM key specifically for the notifications.yourdomain.com domain. Add the CNAME or TXT record to DNS.
Step 5 — Publish Subdomain DMARC Record
Add: _dmarc.notifications.yourdomain.com TXT v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start monitoring, then tighten to quarantine.
Key PowerShell Commands
Resolve-DnsName _dmarc.yourdomain.com -Type TXT
Resolve-DnsName notifications.yourdomain.com -Type TXT
Get-DkimSigningConfig | Select Domain, Enabled, StatusRoot Cause Analysis
Subdomain used for notifications lacked SPF and DKIM records. Parent DMARC policy was p=reject, causing all subdomain mail to be rejected at destination. Fix: subdomain SPF + DKIM + p=none DMARC monitor record.
DKIM and DMARC Record Guide: A Powerful Interview Mastery Resource
DMARC Record Guide: A Positive Masterclass for Ultimate Email Protection
Scenario 10:External Forwarding Blocked — Anti-Exfiltration Policy Active
Situation
A legitimate vendor relationship requires automatic forwarding of support tickets to an external inbox. Users set up inbox rules to forward, but mail is never delivered externally. No NDR is returned.
Approach
Microsoft 365 blocks external automatic forwarding by default via the outbound spam policy. This is a security control, not a bug. Exemptions must be explicitly created.
Resolution Steps
Step 1 — Confirm Automatic Forwarding Block
Get-HostedOutboundSpamFilterPolicy | Select AutoForwardingMode. Default is ‘Automatic’ (blocks forwarding). ‘Off’ blocks all. ‘On’ allows.
Step 2 — Understand the Policy Scope
The default outbound policy applies to all users. A custom policy can be scoped to specific users or groups to allow forwarding without opening it org-wide.
Step 3 — Create a Scoped Exception
Create a new outbound spam filter policy: New-HostedOutboundSpamFilterPolicy -Name ‘AllowVendorForwarding’ -AutoForwardingMode On. Apply it to specific users via New-HostedOutboundSpamFilterRule.
Step 4 — Use a Connector Instead
A more secure approach is to use a mail flow rule (transport rule) that forwards specific messages to the external address rather than giving users permission to forward everything.
Step 5 — Monitor Forwarding Activity
Enable alerts in Defender: Forwarding Activity → New forwarding activity alert. This ensures any unexpected forwarding is flagged even after the exemption is in place.
PowerShell
Get-HostedOutboundSpamFilterPolicy | Select Name, AutoForwardingMode
New-HostedOutboundSpamFilterPolicy -Name 'VendorForward' -AutoForwardingMode On
New-HostedOutboundSpamFilterRule -Name 'VendorForwardRule' -HostedOutboundSpamFilterPolicy 'VendorForward' -SentTo 'supportteam@domain.com'Root Cause Analysis
Default outbound spam policy blocks all automatic forwarding (AutoForwardingMode: Automatic). User inbox rule forwarding to external vendor silently dropped. Fix: scoped outbound policy for the specific user or use transport rule.
Phishing Email Bypassed All Filters — Whitelisted Sender Domain
Situation
A phishing email that contained a credential-harvesting link was delivered to multiple users. Investigation shows it came from a domain that was added to the tenant’s allowed sender list 6 months ago.
Approach
Allowlisted domains bypass anti-spam and anti-phishing checks. This is a common security gap. The review must cover how the domain got allowlisted and what the forward path should be.
Resolution Steps
Step 1 — Confirm Delivery Path
In Threat Explorer, examine the message. Check ‘Overrides’ column — it will show ‘Allowed Sender’ as the reason for bypass. This confirms the allowlist caused the bypass.
Step 2 — Identify the Allowlist Entry
Get-HostedContentFilterPolicy | Select AllowedSenders, AllowedSenderDomains. Find the domain in question. Research why it was added and by whom (audit log).
Step 3 — Remove from Allowlist
Set-HostedContentFilterPolicy -Identity Default -AllowedSenderDomains @{Remove=’compromised-domain.com’}. This restores normal filtering for that domain.
Step 4 — Remediate Affected Users
Use Threat Explorer to find all users who received mail from that domain in the past 90 days. Initiate soft-delete of phishing messages: New-ComplianceSearch followed by New-ComplianceSearchAction -Purge.
Step 5 — Review Allowlist Hygiene
Audit all entries in AllowedSenders and AllowedSenderDomains. Remove any that don’t have a documented, current business justification. Implement a quarterly review process.
Key PowerShell Commands
Get-HostedContentFilterPolicy | Select AllowedSenders, AllowedSenderDomains | FL
Set-HostedContentFilterPolicy -Identity 'Default' -AllowedSenderDomains @{Remove='bad-domain.com'} New-ComplianceSearch -Name 'PhishCleanup' -ExchangeLocation All -ContentMatchQuery 'from:bad-domain.com'Root Cause Analysis
Domain added to allowlist 6 months ago for a now-expired business reason. Domain was later compromised. Phishing mail bypassed all Defender filters due to allowlist override. Fix: remove domain from allowlist + content purge.
How to Investigate Phishing Attacks in Microsoft 365 – Admin Playbook
Scenario 12: Attachment Stripped by Safe Attachments Policy
Situation
Recipients report receiving emails with no attachment, while senders confirm they attached files. The email body arrives but the attachment is missing. No notification is sent to sender or recipient.
Approach
Microsoft Defender for Office 365 Safe Attachments can silently strip attachments in ‘Block’ mode. The recipient never sees the attachment and no NDR is generated.
Resolution Steps
Step 1 — Check Safe Attachments Policy
Get-SafeAttachmentPolicy | FL Action, Enable, Redirect, RedirectAddress. If Action is ‘Block’, detected attachments are deleted with no notification.
Step 2 — Check the Message Trace for Attachment Verdict
In Threat Explorer (Defender portal), search for the message. The ‘Attachments’ column shows verdicts: Malware, Suspicious, Clean. Blocked attachments show ‘Malware’ even if false-positived.
Step 3 — Review the Specific File Type
If the attachment is a macro-enabled Office file (.xlsm, .docm), Safe Attachments is extremely aggressive. Verify whether the file is genuinely malicious or a false positive.
Step 4 — Enable Redirect for Review
Change policy from Block to redirect: Set-SafeAttachmentPolicy -Redirect $true -RedirectAddress admin@domain.com. This sends suspicious attachments to admin for review instead of silently dropping.
Step 5 — Submit for Reclassification
If attachment is a known clean file, submit for reclassification via Defender portal: Submissions → Email Attachments. Microsoft re-evaluates and updates the verdict.
Key PowerShell Commands
Get-SafeAttachmentPolicy | FL Name, Enable, Action, Redirect, RedirectAddress
Set-SafeAttachmentPolicy -Identity 'Default' -Redirect $true -RedirectAddress 'securityadmin@domain.com'
Get-SafeAttachmentRule | FL Name, Priority, SafeAttachmentPolicy, RecipientDomainIsRoot Cause Analysis
Safe Attachments policy in Block mode silently removed a macro-enabled Excel file flagged as suspicious. No notification configured. Fix: enable redirect to admin mailbox, review, and submit for reclassification.
Safe Links vs Safe Attachments — What’s the Difference? A Complete Masterclass
Scenario 13: Emails Delivered But Marked Unread, Appearing in Wrong Folder
Situation
A user complains emails from their manager are always delivered to a subfolder called ‘Archive-Old’ instead of the Inbox. The user did not create this rule. Other emails arrive normally.
Approach
Inbox rules can be created by compromised sessions, delegated access holders, or accidental rule creation. Auditing is required to understand when and how the rule was created.
Resolution Steps
Step 1 — List Inbox Rules
Get-InboxRule -Mailbox ‘user@domain.com’ | FL Name, Description, From, MoveToFolder, Enabled. Identify the suspicious rule targeting messages from the manager.
Step 2 — Check Rule Creation in Audit Log
Search-UnifiedAuditLog -Operations ‘New-InboxRule’,’Set-InboxRule’ -UserIds user@domain.com -StartDate (Get-Date).AddDays(-30). Note the ClientIP and user agent of who created it.
Step 3 — Assess for Compromise Indicators
If the ClientIP is from an unexpected geography or the creation timestamp was odd-hours, treat as a compromise event. Review sign-in logs in Entra ID for suspicious activity.
Step 4 — Remove the Rule
Remove-InboxRule -Mailbox ‘user@domain.com’ -Identity ” -Confirm:$false. Verify the rule is gone: Get-InboxRule -Mailbox user@domain.com.
Step 5 — Secure the Account
Force password reset and revoke refresh tokens: Revoke-MgUserSignInSession. Enable MFA if not present. Monitor for 72 hours.
Key PowerShell Commands
Get-InboxRule -Mailbox 'user@domain.com' | FL Name, From, MoveToFolder, Enabled, RuleIdentity Remove-InboxRule -Mailbox 'user@domain.com' -Identity 'RuleIdHere'
Search-UnifiedAuditLog -Operations 'New-InboxRule' -StartDate (Get-Date).AddDays(-30) -UserIds 'user@domain.com'Root Cause Analysis
Inbox rule created during compromised session redirected all mail from manager to an obscure subfolder. Attacker monitoring for sensitive communications. Fix: remove rule, secure account, full audit review.
Scenario 14: Emails With Large Attachments Silently Dropped
Situation
Design team members report that emails with large CAD/video files (80–150 MB) sent externally are never received. No NDR is returned to sender. Internal large attachments work fine.
Approach
Exchange Online has configurable message size limits. Exceeding these limits at EOP results in silent drops for some paths. Inbound and outbound limits are set separately.
Resolution Steps
Step 1 — Check Org Message Size Limits
Run Get-TransportConfig | Select MaxSendSize, MaxReceiveSize. Default limits are 25MB (legacy) or 150MB (modern). Connectors may have lower overrides.
Step 2 — Check Connector-Level Limits
Run Get-OutboundConnector | Select MaxMessageSize. A connector may override the org limit with a lower value, causing larger messages to fail silently at the connector.
Step 3 — Check Mailbox-Level Send/Receive Limits
Get-Mailbox user@domain.com | Select MaxSendSize, MaxReceiveSize. Mailbox-level limits override org defaults. Verify they are not restricting large attachments.
Step 4 — Consider Alternate for Large Files
For files over 25MB, recommend OneDrive or SharePoint sharing links instead. Exchange Online is not designed for large binary file transfer. Set policies accordingly.
Step 5 — Set Appropriate Limits
If large attachment sending is a business requirement: Set-TransportConfig -MaxSendSize 150MB. Note: recipient’s gateway must also accept files this size.
Key PowerShell Commands
Get-TransportConfig | Select MaxSendSize, MaxReceiveSize
Get-Mailbox 'user@domain.com' | Select MaxSendSize, MaxReceiveSize
Get-OutboundConnector | Select Name, MaxMessageSizeRoot Cause Analysis
Outbound connector had MaxMessageSize 30MB. Messages over 30MB were rejected by the connector with no NDR generated to sender. Fix: increase connector limit or redirect large files to SharePoint links.
Scenario 15: Distribution List Not Receiving External Mail
Situation
An external vendor reports their emails to a distribution list bounce with NDR 5.7.133: ‘Message rejected because the group does not accept external messages.’ The DL was recently modified.
Approach
NDR 5.7.133 is explicit — the distribution group is configured to reject external senders. This is a deliberate setting changed either by policy or admin action.
Resolution Steps
Step 1 — Check DL External Sender Setting
Get-DistributionGroup -Identity ‘groupname@domain.com’ | Select RequireSenderAuthenticationEnabled. If $true, only authenticated (internal) senders can send to the group.
Step 2 — Allow External Senders
Set-DistributionGroup -Identity ‘groupname@domain.com’ -RequireSenderAuthenticationEnabled $false. This allows external senders to post to the group.
Step 3 — Check for Moderation
Get-DistributionGroup -Identity ‘groupname’ | Select ModerationEnabled, ModeratedBy. If moderation is on and no moderators are assigned (or moderators are inactive), all external mail sits in pending.
Step 4 — Check Accepted Senders
Get-DistributionGroup -Identity ‘groupname’ | Select AcceptMessagesOnlyFrom, AcceptMessagesOnlyFromSendersOrMembers. If this list is populated, only listed senders can send to the group.
Step 5 — Test and Notify Vendor
After configuring, ask the vendor to resend. Verify in Message Trace. If moderation was the issue, release any pending messages from the moderation queue.
PowerShell
Get-DistributionGroup 'dl-name@domain.com' | Select RequireSenderAuthenticationEnabled, ModerationEnabled, AcceptMessagesOnlyFrom
Set-DistributionGroup 'dl-name@domain.com' -RequireSenderAuthenticationEnabled $false
Get-DistributionGroup 'dl-name@domain.com' | Select ModeratedBy, BypassModerationFromSendersOrMembersRoot Cause Analysis
Group policy modification enabled RequireSenderAuthenticationEnabled=$true, blocking all external senders. Fix: set to $false and optionally enable moderation to allow external mail with admin approval.
Scenario 16: Mail Relay Rejected — Application Server IP Not in Connector
Situation
An on-premise ERP application started returning SMTP error 550 5.7.54: ‘SMTP relay is not allowed’ when trying to send transactional emails via Exchange Online. It was working until a connector was rebuilt.
Approach
Exchange Online only accepts relay from on-premise IPs when an inbound connector explicitly lists those IPs. After rebuild, the IP allowlist must be reconfigured.
Resolution Steps
Step 1 — Identify the Sending IP
Check the ERP server’s network configuration for its outbound IP. This is the IP appearing in Exchange Online’s connection logs when relay is attempted.
Step 2 — Check Connector IP List
Get-InboundConnector | FL SenderIPAddresses. Verify the application server’s IP is in the allowlist. If it was removed during rebuild, relay will be blocked.
Step 3 — Add IP to Connector
Set-InboundConnector -Identity ‘AppRelayConnector’ -SenderIPAddresses @{Add=’10.10.5.22′}. Use /32 for a single host, /24 for a subnet if multiple app servers exist.
Step 4 — Verify Connector Type
The inbound connector must be Type: OnPremises (or Partner) — not Default. The Default connector does not enforce IP-based relay trust. Confirm with Get-InboundConnector | Select ConnectorType.
Step 5 — Test Relay from App Server
From the application server, use telnet or an SMTP test tool to send to an internal address via the Exchange Online SMTP endpoint. Confirm 250 OK acceptance.
PowerShell
Get-InboundConnector | Select Name, ConnectorType, SenderIPAddresses, Enabled | FL
Set-InboundConnector -Identity 'RelayConnector' -SenderIPAddresses @{Add='10.10.5.22'}
New-InboundConnector -Name 'AppRelay' -ConnectorType OnPremises -SenderIPAddresses '10.10.5.0/24'Root Cause Analysis
Inbound connector rebuild omitted the ERP server IP from SenderIPAddresses. EOP rejected SMTP relay attempt with 5.7.54. Fix: add application server IP to connector’s IP allowlist.
Scenario 17: Users Receiving Duplicate Emails
Situation
Several users report receiving every external email twice — once directly, once via a distribution group. This started after a new group was created during a reorganization.
Approach
Duplicate delivery almost always means a user is both a direct recipient and a member of a group that is also a recipient of the same message.
Resolution Steps
Step 1 — Examine the Duplicate Headers
Compare the Message-ID headers of both copies. If identical, it’s true duplication. Check the To/CC/BCC fields — one copy likely shows a group address.
Step 2 — Trace the Group Membership
Run Get-DistributionGroupMember -Identity ‘GroupName’. If affected users are direct members AND appear in a parent group that includes the same group, duplicates occur.
Step 3 — Check Nested Group Structure
If Group A includes Group B and Group B includes the same users as individual members in Group A, any mail to Group A results in double delivery.
Step 4 — Clean Group Membership
Remove direct memberships where the user is already covered by a nested group, or restructure the group hierarchy to avoid overlap.
Step 5 — Validate with Test Send
After cleanup, send a test message to the top-level group and confirm each member receives exactly one copy.
Key PowerShell Commands
Get-DistributionGroupMember -Identity 'GroupName' | Select Name, PrimarySmtpAddress
Get-DistributionGroup -ResultSize Unlimited | Where {$_.Members -contains 'user@domain.com'}
Get-Recipient -RecipientType MailUniversalDistributionGroup | Select Name, MemberCountRoot Cause Analysis
Reorganization created a new group that included users who were already direct members of the parent group. Double membership path resulted in duplicate delivery. Fix: remove redundant direct memberships.
Scenario 18: Inbound Mail Blocked — SPF Record Exceeds 10-Lookup Limit
Situation
Inbound mail from a specific sending domain starts failing SPF with ‘permerror.’ Recipients’ logs show: SPF = permerror (too many DNS lookups). The sending organization added a new include mechanism.
Approach
SPF has a hard limit of 10 DNS-interactive mechanisms (include, a, mx, ptr, exists, redirect). Exceeding this causes permerror, which most receivers treat as a failure.
Resolution Steps
Step 1 — Count the Lookups
Use an SPF analyzer tool or manually trace: dig TXT yourdomain.com. Count every include, a, mx, ptr, exists, redirect. Each include that itself contains includes adds to the count recursively.
Step 2 — Identify Redundant Mechanisms
Common culprits: outdated email service includes (old providers no longer used), too many regional includes when a global one would suffice.
Step 3 — Flatten the SPF Record
Replace include mechanisms with their actual IP ranges. Convert include:sendgrid.net to the actual IPs published by SendGrid. This reduces lookup count to zero for those entries.
Step 4 — Use a Macro or SPF Management Service
Services like dmarcian or Valimail dynamically manage SPF flattening and serve the record via CNAME, staying within the 10-lookup limit automatically.
Step 5 — Validate and Monitor
After fix: dig TXT yourdomain.com to verify new record. Test with mxtoolbox.com SPF checker. Set up DMARC rua reporting to monitor authentication passes going forward.
Key PowerShell Commands
Resolve-DnsName yourdomain.com -Type TXT | Select Strings
nslookup -type=TXT yourdomain.com 8.8.8.8
Resolve-DnsName _spf.google.com -Type TXTRoot Cause Analysis
SPF record accumulated 14 DNS lookups after three new SaaS includes were added. SPF permerror caused DMARC failure at receiving domains. Fix: flatten SPF to use IPs directly, reducing lookups below 10.
Powerful SPF Record Guide: A Positive Masterclass for Email Deliverability Success
MX and SPF Record Mastery: Essential Insights for Successful Interview Performance
Scenario 19: Out-of-Office Reply Looping — Auto-Reply to External Domains
Situation
A mailing list sends a newsletter to 500 subscribers. One subscriber has an OOF (Out of Office) reply that responds to the mailing list address, triggering another newsletter send, causing a loop.
Approach
Exchange Online has OOF suppression rules but they can be misconfigured. The mailing list manager must also respect RFC standards for auto-reply suppression.
Resolution Steps
Step 1 — Identify the Loop Source
In message trace, find the repeated cycles between the mailing list address and the subscriber. The OOF will have ‘Auto-Submitted: auto-replied’ in its headers.
Step 2 — Verify OOF External Setting
Get-MailboxAutoReplyConfiguration -Identity user@domain.com. Check if AutoReplyState is Enabled and ExternalAudience is set to All. External OOFs to mailing lists cause loops.
Step 3 — Check Remote Domain Auto-Reply Setting
Get-RemoteDomain | Select DomainName, AutoReplyEnabled. If the mailing list’s domain is listed with AutoReplyEnabled:$true, OOFs are being forwarded. Set it to $false.
Step 4 — Add Mailing List to Safe Recipients (No OOF)
For distribution groups, enable ‘Do not send automatic replies’ on the group: Set-DistributionGroup -Identity ‘newsletter’ -ReportToManagerEnabled $false -ReportToOriginatorEnabled $false.
Step 5 — Set Transport Rule to Block Auto-Replies to DL
Create a transport rule that deletes messages where header ‘Auto-Submitted’ is not equal to ‘no’ and recipient is the distribution list address.
Key PowerShell Commands
Get-MailboxAutoReplyConfiguration 'user@domain.com' | FL
Get-RemoteDomain | Select DomainName, AutoReplyEnabled | FL
Set-RemoteDomain -Identity '*' -AutoReplyEnabled $falseRoot Cause Analysis
OOF set to reply to All External with no suppression. Remote domain policy allowed auto-replies to return to mailing list. Triggered recursive send cycle. Fix: block auto-replies via transport rule + remote domain setting.
Scenario 20: Mobile Device Cannot Sync Email — ActiveSync Device Blocked
Situation
A user’s new smartphone cannot sync Exchange email. The device shows ‘Account verification failed.’ The user’s other devices work fine. The new device was never registered.
Approach
ActiveSync device access can be controlled at org level, mailbox level, or by quarantine. New devices may need explicit allow in non-default policy configurations.
Resolution Steps
Step 1 — Check Device Access State
Get-MobileDeviceStatistics -Mailbox ‘user@domain.com’ | Select DeviceFriendlyName, DeviceModel, Status, LastSyncAttemptTime. The new device should appear with status ‘Quarantined’ or ‘Blocked’.
Step 2 — Check Organization-Level Default Access
Get-ActiveSyncOrganizationSettings | Select DefaultAccessLevel. If Quarantine, new devices need admin approval. If Block, no new devices are allowed without explicit allow rules.
Step 3 — Allow the Specific Device
Set-CASMailbox -Identity ‘user@domain.com’ -ActiveSyncAllowedDeviceIDs @{Add=’DeviceIDHere’}. Or use the EAC mobile device portal to approve the quarantined device.
Step 4 — Check Device Access Rules
Get-ActiveSyncDeviceAccessRule | FL AccessLevel, QueryString. A rule may block specific device types or OS versions (e.g., block Android < 11).
Step 5 — Verify After Allow
After allowing, the device must re-attempt sync. It may take up to 1 hour. Monitor Last Sync time in Get-MobileDeviceStatistics. Confirm mail and calendar sync successfully.
Key PowerShell Commands
Get-MobileDeviceStatistics -Mailbox 'user@domain.com' | Select DeviceFriendlyName, DeviceId, Status, LastSyncAttemptTime
Get-ActiveSyncOrganizationSettings | Select DefaultAccessLevel
Set-CASMailbox 'user@domain.com' -ActiveSyncAllowedDeviceIDs @{Add='DEVICEIDHERE'}Root Cause Analysis
Organization default access level set to Quarantine. New device was quarantined pending admin approval. Fix: approve device in EAC quarantine list or add DeviceID to CASMailbox AllowedDeviceIDs.
Outlook Web Access (OWA) Policies: The Ultimate Positive Admin Guide for Secure Email Access
Final Takeaways on Exchange Online Real-World Troubleshooting Scenarios
Across these Exchange Online Real-World Troubleshooting Scenarios:
- 80% issues come from misconfigurations
- Security features often introduce side effects
- Message trace + PowerShell = ultimate toolkit
Final Thought
Mastering Exchange Online Real-World Troubleshooting Scenarios is not about memorizing commands—it’s about thinking in layers and patterns.
Great admins fix issues. Expert admins explain WHY they happened.
Outlook Running Slow Fix: Expert Guide to Diagnose and Speed Up Outlook
Microsoft 365 Admin Center – Complete Expert Guide for Modern IT Administrators
Proven Conditional Access Policy Best Practices for Stronger Cloud Security
