Exchange Online Email Delivery Fix Guide

Why Email Delivery Is Still the Number One Helpdesk Headache

Let's be honest — if you work on an IT helpdesk, you already know what's coming before you even open the ticket queue. "Where's my email?" "Why did my message bounce?" "The client says they never got my attachment." These questions land daily, and they need fast answers because stalled email means stalled business. There's really no way around it.

Microsoft Exchange Online handles billions of messages every day. It's incredibly robust, but that complexity means there are dozens of points where delivery can fail, get delayed, or quietly end up in quarantine. Your job is to navigate that maze quickly and give users clear answers.

That's exactly what this guide is for.

We'll walk through every major troubleshooting scenario you're likely to hit: running message traces in the Exchange Admin Center and PowerShell, decoding Non-Delivery Reports (NDRs), diagnosing SPF/DKIM/DMARC failures, auditing mail flow rules and connectors, managing quarantined messages, and dealing with the recent changes Microsoft has rolled out — including the deprecation of Get-MessageTrace in favor of Get-MessageTraceV2 and the new bulk sender authentication requirements.

Your First Move: Understanding the Email Delivery Pipeline

Before you can troubleshoot a delivery failure, you need a mental model of how email actually flows through Exchange Online. Every message passes through a pipeline of services, and a problem at any stage produces different symptoms. Getting this picture right saves you a ton of guesswork later.

The Exchange Online Mail Flow Pipeline

Submission — The sender composes and sends the message using Outlook, OWA, a mobile client, or an application sending via SMTP. The message gets submitted to Exchange Online's transport service.
Transport Rules (Mail Flow Rules) — The message is evaluated against any mail flow rules configured in the Exchange Admin Center. These rules can redirect, reject, modify headers, add disclaimers, or apply encryption.
Connector Routing — If outbound connectors are configured (common in hybrid environments or partner organizations), Exchange Online determines whether the message should route through a connector rather than the default MX-based delivery.
Exchange Online Protection (EOP) — The message passes through Microsoft's built-in protection stack: anti-malware scanning, anti-spam filtering, anti-phishing checks, and Safe Links/Safe Attachments if you've got Defender for Office 365 licensed.
DNS Resolution and Delivery — For outbound messages, Exchange Online does an MX lookup on the recipient's domain and attempts SMTP delivery. For inbound messages, the sender's mail server performs the MX lookup on your domain.
Recipient Mailbox — The message lands in the recipient's Inbox, Junk Email folder, Focused/Other tab, or gets quarantined — depending on protection verdicts and user rules.

When a user reports a missing email, your job is to figure out which stage failed. The tools in the following sections will help you pinpoint that stage quickly.

Message Trace: Your Primary Investigation Tool

Message trace is the single most important tool in your Exchange Online troubleshooting toolkit. Full stop. It shows you exactly what happened to a message as it passed through the service — whether it was delivered, failed, filtered, quarantined, or is still pending.

Using Message Trace in the Exchange Admin Center

The easiest way to run a message trace is through the Exchange Admin Center (EAC) at admin.exchange.microsoft.com. Navigate to Mail flow > Message trace and fill in the search criteria:

Senders — One or more sender email addresses
Recipients — One or more recipient email addresses
Time range — Default is the last 2 days; you can search up to 10 days for real-time traces
Delivery status — Filter by Delivered, Failed, Pending, Quarantined, Expanded, or FilteredAsSpam
Message ID — The unique Message-ID header value, handy when you've pulled it from email headers

For traces older than 10 days, you'll need to submit a Downloadable report (formerly called a Historical Search), which can pull data up to 90 days old. Fair warning — these reports are processed asynchronously and can take several hours to complete.

Reading Message Trace Results

Each message trace result shows key fields that tell the story of what happened:

Date — When the message was processed
Sender and Recipient — The envelope addresses
Subject — The message subject line
Status — The delivery outcome:
- Delivered — Message was successfully delivered to the recipient's mailbox
- Failed — Delivery failed and an NDR was generated
- Pending — Delivery is being attempted or retried
- Quarantined — Message was quarantined by EOP
- FilteredAsSpam — Message was flagged as spam and sent to Junk Email
- Expanded — Message was sent to a distribution group and expanded to individual recipients

Click on any individual message to see the Message trace details, which reveal every event in the message's journey — including transport rule evaluations, connector routing decisions, and protection verdicts.

PowerShell Message Tracing with Get-MessageTraceV2

For more advanced or scripted investigations, PowerShell is indispensable. And here's something important: as of September 2025, Microsoft deprecated the original Get-MessageTrace cmdlet and replaced it with Get-MessageTraceV2. The new cmdlet offers enhanced filtering and can query up to 90 days of data (in 10-day windows).

First, connect to Exchange Online PowerShell:

# Install the module if you haven't already
Install-Module -Name ExchangeOnlineManagement -Force

# Connect to Exchange Online
Connect-ExchangeOnline -UserPrincipalName [email protected]

Now run some traces with Get-MessageTraceV2:

# Basic trace for a specific sender in the last 48 hours
Get-MessageTraceV2 -SenderAddress [email protected] -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date)

# Find all failed messages for a recipient
Get-MessageTraceV2 -RecipientAddress [email protected] -Status Failed -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date)

# Trace by Message ID (remove angle brackets)
Get-MessageTraceV2 -MessageId "[email protected]" -StartDate (Get-Date).AddDays(-5) -EndDate (Get-Date)

# Export results to CSV for analysis
Get-MessageTraceV2 -SenderAddress [email protected] -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) |
    Select-Object Received, SenderAddress, RecipientAddress, Subject, Status, Size |
    Export-Csv -Path "C:\Traces\sender-trace.csv" -NoTypeInformation

To drill into the specific events for a message, use Get-MessageTraceDetailV2:

# Get detailed events for a specific message
$trace = Get-MessageTraceV2 -MessageId "[email protected]" -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date)
$trace | Get-MessageTraceDetailV2 | Format-List Date, Event, Action, Detail

The detail events will show you exactly what happened at each stage — which transport rule fired, whether EOP flagged the message, what the spam confidence level (SCL) was, and where delivery ultimately succeeded or failed. I've personally found these detail events invaluable when tracking down those "it just vanished" scenarios.

Decoding Non-Delivery Reports (NDRs)

Non-Delivery Reports — also called bounce messages or Delivery Status Notifications (DSNs) — are the error messages Exchange Online sends back to the sender when a message can't be delivered. Learning to read NDR error codes quickly is one of those skills that'll make you the fastest resolver on your team.

Anatomy of an NDR

A modern Exchange Online NDR has three key sections:

Plain-language description — Microsoft now writes NDRs in everyday language, explaining what went wrong and suggesting fixes the sender can try
Diagnostic information — The SMTP error code and enhanced status code (e.g., 550 5.1.1)
Original message headers — Attached as a separate MIME part, useful for advanced troubleshooting

Common NDR Error Codes and What to Do

Error Code	Meaning	Helpdesk Action
`550 5.1.1`	Recipient address doesn't exist	Verify the email address with the user. Check for typos. If the recipient is internal, confirm the mailbox exists in the admin center.
`550 5.1.10`	Recipient not found (invalid address)	Similar to 5.1.1 but often means a missing or disabled recipient object in Entra ID. Check the user account status.
`550 5.2.1`	Mailbox full	The recipient's mailbox has exceeded its storage quota. If internal, check and increase the mailbox quota or ask the user to clean up.
`550 5.4.1`	Recipient rejected — relay not permitted	Common in hybrid environments. Verify the inbound connector and accepted domain configuration.
`550 5.7.1`	Message rejected — auth or permission failure	The recipient's server rejected the message. Often an SPF or DMARC failure. Check your domain's DNS authentication records.
`550 5.7.15`	Access denied — authentication requirements not met	New in 2025. This means your domain fails Microsoft's bulk sender authentication requirements (SPF, DKIM, or DMARC not passing).
`550 5.7.23`	SPF validation failed	The recipient's server performed an SPF check and your domain failed. Review your SPF record to make sure all sending sources are authorized.
`550 5.7.708`	Tenant has exceeded sending limits	Your tenant has been rate-limited due to excessive outbound email. Investigate potential compromised accounts or misconfigured applications.
`421 4.7.0`	Temporary connection issue	The remote server temporarily refused the connection. Usually transient — Exchange Online retries automatically. If persistent, check the destination server's status.

When you run into an unfamiliar NDR code, Microsoft's official NDR documentation is your quickest reference — they maintain a comprehensive list with specific remediation steps for each code.

Email Authentication: SPF, DKIM, and DMARC

Email authentication failures are one of the fastest-growing categories of delivery problems, especially since Microsoft's May 2025 enforcement of stricter sender requirements. Understanding these three protocols isn't optional anymore for helpdesk professionals — it's become core knowledge.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses and services are authorized to send email on behalf of your domain. It's configured as a TXT record in your domain's DNS.

# Example SPF record for a Microsoft 365 tenant
v=spf1 include:spf.protection.outlook.com include:_spf.google.com ip4:203.0.113.50 -all

Common SPF issues that cause delivery failures:

Missing include statements — If you use a third-party service (marketing platform, CRM, helpdesk tool) that sends email as your domain, its sending infrastructure must be included in your SPF record
Too many DNS lookups — SPF allows a maximum of 10 DNS lookups. Exceeding this limit causes SPF to fail with a permerror. Use SPF flattening tools or consolidate includes to stay under the limit
Using ~all instead of -all — While soft fail (~all) is more forgiving, hard fail (-all) provides stronger protection and clearer signals to receiving servers

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing messages, letting the recipient's server verify that the message hasn't been tampered with in transit and genuinely came from your domain.

To enable DKIM in Exchange Online:

Navigate to Microsoft Defender portal > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM
Select your domain and click Sign messages for this domain with DKIM signatures

Add the two CNAME records provided by Microsoft to your DNS:

selector1._domainkey.contoso.com  CNAME  selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.contoso.com  CNAME  selector2-contoso-com._domainkey.contoso.onmicrosoft.com

After DNS propagation (this can take up to 48 hours, so be patient), enable DKIM signing in the portal

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication checks fail. It's also configured as a DNS TXT record:

# DMARC record with reject policy and reporting
_dmarc.contoso.com  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100"

DMARC policies progress through three levels:

p=none — Monitor only. No enforcement. Start here to collect reports without impacting mail flow
p=quarantine — Failing messages go to junk/spam. A good intermediate step
p=reject — Failing messages get rejected outright. The strongest protection but requires confidence that all legitimate sending sources pass SPF or DKIM

Microsoft's 2025 Bulk Sender Requirements

Since May 5, 2025, Microsoft requires all high-volume senders (5,000+ messages per day to Outlook.com, Hotmail.com, and Live.com addresses) to pass all three authentication checks — SPF, DKIM, and DMARC. Messages that fail get rejected with error code 550 5.7.15. This brings Microsoft in line with similar requirements Google and Yahoo rolled out in early 2024.

For helpdesk teams, this means you'll increasingly see bounce-backs from external contacts whose organizations haven't updated their DNS records. When a user reports that emails from a specific external sender are bouncing, check whether the sender's domain has valid SPF, DKIM, and DMARC records using MXToolbox or the Resolve-DnsName PowerShell cmdlet:

# Check SPF record
Resolve-DnsName -Name contoso.com -Type TXT | Where-Object { $_.Strings -match "v=spf1" }

# Check DMARC record
Resolve-DnsName -Name _dmarc.contoso.com -Type TXT

# Check DKIM selector
Resolve-DnsName -Name selector1._domainkey.contoso.com -Type CNAME

Mail Flow Rules and Connectors: The Silent Troublemakers

Some of the hardest delivery problems to diagnose are caused by mail flow rules and connectors — and the reason is simple: they operate silently in the background, completely invisible to end users. When a message trace shows a message as "Delivered" but the user swears they never got it, or when messages get unexpectedly redirected, mail flow rules are often the culprit.

I've seen entire teams spend hours chasing phantom delivery issues that turned out to be a forgotten transport rule from three years ago. So, let's dig into how to audit these.

Auditing Mail Flow Rules

Exchange Online supports up to 300 mail flow rules per organization. Over time, rules pile up as different admins create them for various purposes, and conflicting or outdated rules can cause genuinely mysterious delivery problems.

To review all active mail flow rules:

# List all mail flow rules with their priority and state
Get-TransportRule | Select-Object Name, Priority, State, Mode | Format-Table -AutoSize

# Export detailed rule information for review
Get-TransportRule | Select-Object Name, Priority, State, Conditions, Actions, Exceptions |
    Export-Csv -Path "C:\Audit\transport-rules.csv" -NoTypeInformation

# Find rules that redirect or delete messages (common causes of "missing" emails)
Get-TransportRule | Where-Object {
    $_.RedirectMessageTo -ne $null -or
    $_.DeleteMessage -eq $true -or
    $_.RejectMessageReasonText -ne $null
} | Select-Object Name, Priority, RedirectMessageTo, DeleteMessage

Pay special attention to rules that:

Delete messages silently — The DeleteMessage action removes messages without sending an NDR, making them appear to vanish into thin air
Redirect to another address — Messages may be going to a compliance mailbox or an old address that nobody monitors anymore
Set SCL to -1 — This bypasses spam filtering entirely, which can be intentional but also risky if applied too broadly
Add disclaimers or modify headers — Malformed disclaimers can corrupt message formatting or trigger false positives on the receiving end

Troubleshooting Connectors

Connectors define how email flows between Exchange Online and external systems — whether that's an on-premises Exchange server in a hybrid deployment, a third-party email gateway, or a partner organization. Misconfigured connectors are a surprisingly common source of delivery failures in hybrid environments.

To validate your connectors:

# List all connectors
Get-InboundConnector | Select-Object Name, Enabled, ConnectorType, SenderDomains
Get-OutboundConnector | Select-Object Name, Enabled, ConnectorType, RecipientDomains

# Test an outbound connector
Test-OutboundConnector -Identity "To On-Premises" -Recipients [email protected]

Common connector issues include:

Expired or mismatched TLS certificates — If a connector requires TLS and the partner's certificate has expired, mail flow fails with a 450 4.4.101 or similar error
Incorrect smart host configuration — The connector points to an IP address or hostname that's no longer valid
Sender filtering misconfiguration — Inbound connectors may restrict which source IP addresses or domains are accepted, and changes on the sending side can break this
Enhanced filtering for connectors (skip listing) — If you route inbound mail through a third-party gateway, you need to configure enhanced filtering so the original sender IP is preserved for accurate spam evaluation

Quarantine Management and Protection Policies

When users report they're expecting an important email that never showed up, one of the first places to check (right after message trace) is the quarantine. Exchange Online Protection and Defender for Office 365 quarantine messages flagged as malware, high-confidence phishing, spam, or that match specific policy rules.

Checking Quarantine in the Defender Portal

Navigate to Microsoft Defender portal > Email & collaboration > Review > Quarantine. From here you can:

Search for quarantined messages by sender, recipient, subject, or date range
View the quarantine reason (spam, phish, malware, transport rule, etc.)
Release messages to the recipient's inbox
Report false positives to Microsoft to improve future filtering accuracy

PowerShell Quarantine Management

# View quarantined messages for a specific recipient
Get-QuarantineMessage -RecipientAddress [email protected] -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date)

# Release a quarantined message
Release-QuarantineMessage -Identity "quarantine-id-here" -ReleaseToAll

# Bulk release all quarantined messages from a trusted sender
Get-QuarantineMessage -SenderAddress [email protected] |
    Release-QuarantineMessage -ReleaseToAll

Tuning Anti-Spam Policies

If legitimate messages keep getting quarantined (false positives), you may need to tweak your anti-spam policies. Microsoft offers three tiers of preset security policies:

Standard protection — Balanced filtering with fewer false positives. Works well for most users
Strict protection — More aggressive filtering. Best for high-value targets like executives and finance teams
Built-in protection — The default baseline that applies Safe Links and Safe Attachments when no custom policy exists

For ongoing false positive issues, try these targeted adjustments rather than weakening your overall spam policy:

Tenant Allow/Block List (TABL) — Add specific sender addresses or domains that should always be allowed. This is Microsoft's recommended approach for trusted senders
Advanced delivery policies — Configure third-party phishing simulation tools and SecOps mailboxes that need to bypass filtering
User submissions — Encourage users to report false positives via the Report Message add-in. It helps Microsoft improve their models and can automatically tune your tenant's filtering

Zero-hour Auto Purge (ZAP)

ZAP is a feature that catches things after the fact — it retroactively removes malicious messages that have already been delivered to mailboxes. If spam or phishing intelligence gets updated after a message was delivered, ZAP can move it to Junk Email or quarantine it. It's enabled by default and should generally stay on.

However, ZAP can occasionally cause confusion when users report that a message "disappeared" from their inbox hours after it arrived. When investigating this kind of scenario, check whether ZAP was involved:

# Check if ZAP took action on messages to a specific user
Get-MessageTraceV2 -RecipientAddress [email protected] -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) |
    Get-MessageTraceDetailV2 | Where-Object { $_.Detail -match "ZAP" }

Shared Mailboxes, Distribution Groups, and Microsoft 365 Groups

Email delivery issues involving shared mailboxes and groups are among the most frequently escalated helpdesk tickets — and honestly, it's because the troubleshooting steps differ enough from individual mailbox issues to throw people off.

Shared Mailbox Delivery Issues

Common problems with shared mailboxes:

Mailbox full — Shared mailboxes have a 50 GB limit without a license. When the mailbox approaches capacity, you'll see 550 5.2.1 NDRs. Either clean up the mailbox or assign an Exchange Online Plan 2 license for auto-expanding archives

Auto-mapping not working — Users with Full Access permissions should see the shared mailbox automatically in Outlook, but this relies on Autodiscover. If it fails, try removing and re-adding the permission:

# Remove and re-add Full Access permission with auto-mapping
Remove-MailboxPermission -Identity [email protected] -User [email protected] -AccessRights FullAccess -Confirm:$false
Add-MailboxPermission -Identity [email protected] -User [email protected] -AccessRights FullAccess -AutoMapping $true

Send As vs. Send on Behalf — Users get confused about which permission they have (and honestly, the names don't help). Send As makes the email appear to come from the shared mailbox. Send on Behalf shows "User on behalf of Shared Mailbox." Verify with:
```
# Check Send As permissions
Get-RecipientPermission -Identity [email protected] | Select-Object Trustee, AccessRights

# Check Send on Behalf permissions
Get-Mailbox -Identity [email protected] | Select-Object GrantSendOnBehalfTo
```

Distribution Group Delivery Issues

Distribution groups come with their own set of gotchas:

External senders blocked — By default, distribution groups only accept mail from internal senders. If external partners need to email the group, you need to flip this setting:
```
# Allow external senders to email a distribution group
Set-DistributionGroup -Identity "Sales Team" -RequireSenderAuthenticationEnabled $false
```
Nested group expansion limits — Exchange Online supports nested distribution groups but has limits on expansion depth. Deeply nested groups can cause delivery delays or failures
Moderated groups causing delays — If a group has moderation enabled, messages sit in a queue until a moderator approves them. Users often report this as "slow delivery" without realizing moderation is the bottleneck:
```
# Check if a group is moderated
Get-DistributionGroup -Identity "Sales Team" | Select-Object ModerationEnabled, ModeratedBy
```

Outbound Sending Limits and Compromised Account Response

Exchange Online enforces several sending limits to protect the service and prevent abuse. You need to know these limits when users report they can't send email — and especially when the reason turns out to be a compromised account.

Current Exchange Online Sending Limits

Limit Type	Value	Notes
Recipients per day	10,000	Total unique recipients across all messages in a 24-hour rolling window
Recipients per message	500	Maximum recipients in To, Cc, and Bcc combined
Message size limit	150 MB	Includes message body, headers, and all attachments after Base64 encoding
Attachment size limit	150 MB	Combined size of all attachments
External Recipient Rate (ERR)	2,000 per 24 hours	New — enforcement begins October 2026. Limits external recipients specifically

When a user hits a sending limit, they'll receive an NDR with error code 550 5.7.708 or get blocked from sending temporarily. You can check the user's recent sending volume:

# Check how many messages a user sent in the last 24 hours
Get-MessageTraceV2 -SenderAddress [email protected] -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
    Measure-Object | Select-Object Count

Handling Compromised Accounts

If a user's account has been compromised and used to send spam, Exchange Online will often block the account from sending entirely. The user will see errors like "Your message couldn't be sent" or "You've been blocked from sending email." Here's the response playbook:

Confirm the compromise — Check the sign-in logs in the Entra ID portal for suspicious locations, devices, or IP addresses
Reset the password immediately and revoke all active sessions
Enable MFA if it's not already enabled (and honestly, it should always be enabled)

Review and remove any malicious inbox rules — Attackers frequently create inbox rules to hide their activity:

# Check for suspicious inbox rules
Get-InboxRule -Mailbox [email protected] | Select-Object Name, Description, Enabled, DeleteMessage, MoveToFolder, ForwardTo, RedirectTo

# Remove a malicious rule
Remove-InboxRule -Mailbox [email protected] -Identity "suspicious-rule-name" -Confirm:$false

Check for mail forwarding — Attackers also set up forwarding to exfiltrate email:

# Check for forwarding rules
Get-Mailbox -Identity [email protected] | Select-Object ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

Unblock the account — In the Microsoft Defender portal, navigate to Email & collaboration > Review > Restricted entities and remove the user from the blocked senders list

Building a Troubleshooting Workflow for Your Helpdesk

With all these tools and techniques in your back pocket, it helps to have a structured workflow that your entire team can follow. Here's a decision tree that covers the most common scenarios.

Step 1: Gather Information

When a user reports an email delivery problem, collect these details upfront — before you touch any admin console:

Sender and recipient email addresses (exact addresses, not display names)
Approximate date and time the email was sent
Whether the sender received a bounce-back / NDR (and its contents if yes)
Whether the problem affects one recipient or multiple
Whether the problem is ongoing or a one-time occurrence

Step 2: Run a Message Trace

Use the EAC or Get-MessageTraceV2 to search for the message. The trace status tells you where to focus:

Delivered — The message reached the mailbox. Check the user's Junk Email folder, Focused/Other tab, or Outlook rules that may have moved it
Failed — Read the NDR error code and follow the guidance in the NDR section above
Quarantined — Check the quarantine in the Defender portal. Release if it's a false positive
FilteredAsSpam — The message went to Junk Email. Check if the user's Junk Email settings or an anti-spam policy caused it
Pending — Exchange Online is still attempting delivery. Usually transient but can indicate DNS or remote server issues
No results found — The message may not have been sent at all. Verify with the sender. If inbound, the sender's mail server may not have been able to connect to your MX records

Step 3: Check Transport Rules and Connectors

If the message trace shows delivery but the user says they don't have it, or if the trace shows unexpected routing, review mail flow rules and connector configuration.

Step 4: Verify DNS and Authentication Records

For outbound delivery failures, especially to external recipients, verify SPF, DKIM, and DMARC records for your domain. For inbound failures, check the sending domain's records.

Step 5: Escalate with Data

If the issue persists after these steps, escalate to your Exchange Online administrator or Microsoft support with the message trace results, NDR codes, and any relevant PowerShell output. Having this data ready dramatically speeds up resolution — trust me, support engineers love tickets that come with actual evidence.

Essential PowerShell Commands Quick Reference

Here's a consolidated reference of the most useful PowerShell commands for email delivery troubleshooting. Bookmark this — you'll come back to it often.

# ═══════════════════════════════════════════════════
# CONNECT TO EXCHANGE ONLINE
# ═══════════════════════════════════════════════════
Connect-ExchangeOnline -UserPrincipalName [email protected]

# ═══════════════════════════════════════════════════
# MESSAGE TRACING
# ═══════════════════════════════════════════════════
# Trace by sender
Get-MessageTraceV2 -SenderAddress [email protected] -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date)

# Trace by recipient and status
Get-MessageTraceV2 -RecipientAddress [email protected] -Status Failed -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date)

# Get detailed trace events
Get-MessageTraceV2 -MessageId "[email protected]" -StartDate (Get-Date).AddDays(-5) -EndDate (Get-Date) |
    Get-MessageTraceDetailV2

# ═══════════════════════════════════════════════════
# QUARANTINE
# ═══════════════════════════════════════════════════
Get-QuarantineMessage -RecipientAddress [email protected]
Release-QuarantineMessage -Identity "id-here" -ReleaseToAll

# ═══════════════════════════════════════════════════
# MAILBOX DIAGNOSTICS
# ═══════════════════════════════════════════════════
# Check mailbox size
Get-MailboxStatistics -Identity [email protected] | Select-Object DisplayName, TotalItemSize, ItemCount

# Check inbox rules
Get-InboxRule -Mailbox [email protected] | Format-List Name, Enabled, DeleteMessage, MoveToFolder, ForwardTo

# Check forwarding
Get-Mailbox -Identity [email protected] | Select-Object ForwardingAddress, ForwardingSmtpAddress

# ═══════════════════════════════════════════════════
# MAIL FLOW RULES & CONNECTORS
# ═══════════════════════════════════════════════════
Get-TransportRule | Select-Object Name, Priority, State | Format-Table -AutoSize
Get-InboundConnector | Select-Object Name, Enabled, ConnectorType
Get-OutboundConnector | Select-Object Name, Enabled, ConnectorType

# ═══════════════════════════════════════════════════
# DNS AUTHENTICATION CHECKS
# ═══════════════════════════════════════════════════
Resolve-DnsName -Name contoso.com -Type TXT | Where-Object { $_.Strings -match "v=spf1" }
Resolve-DnsName -Name _dmarc.contoso.com -Type TXT
Resolve-DnsName -Name selector1._domainkey.contoso.com -Type CNAME

# ═══════════════════════════════════════════════════
# DISCONNECT WHEN DONE
# ═══════════════════════════════════════════════════
Disconnect-ExchangeOnline -Confirm:$false

Staying Current: Recent and Upcoming Changes

Microsoft never stops evolving Exchange Online. Here are the most impactful recent changes your helpdesk team needs to be aware of:

September 2025 — Get-MessageTrace deprecated. The original Get-MessageTrace and Get-MessageTraceDetail cmdlets have been replaced by Get-MessageTraceV2 and Get-MessageTraceDetailV2. Update all your scripts and documentation accordingly.
May 2025 — Bulk sender authentication enforcement. Domains sending 5,000+ messages per day to Microsoft consumer email addresses (outlook.com, hotmail.com, live.com) must pass SPF, DKIM, and DMARC. Non-compliant messages get rejected with 550 5.7.15.
October 2026 — External Recipient Rate (ERR) limit. A new limit of 2,000 external recipients per 24-hour period will be enforced. Organizations sending high-volume external communications will need to move to dedicated bulk email services.
Ongoing — New Outlook for Windows migration. The new Outlook client handles email connectivity differently from classic Outlook. Some delivery symptoms (delays, sync issues, missing messages) may actually be client-side rather than server-side. Always check which Outlook version the user is running before diving deep into server-side troubleshooting.

From Reactive to Proactive

Email delivery troubleshooting doesn't have to be a guessing game. With the structured approach outlined in this guide — message tracing, NDR analysis, authentication verification, mail flow rule auditing, and quarantine management — you can diagnose most email delivery problems in minutes rather than hours.

But the best helpdesk teams don't just react — they get ahead of problems. Consider setting up proactive monitoring: scheduled PowerShell scripts that alert you to unusual sending patterns, regular audits of mail flow rules and connectors, and periodic DNS authentication checks. Build a knowledge base article for your users covering common self-service steps (like checking Junk Email folders and double-checking recipient addresses) to reduce ticket volume before it hits the queue.

Email will remain the backbone of business communication for years to come. The ability to quickly resolve delivery issues is one of the most valuable skills a helpdesk professional can develop. Master these tools, follow the workflow, and you'll be the person your team turns to when email goes sideways.