Exchange Online Not Sending, Receiving, or Syncing, Real Fixes for 2026

Why This Is Happening

I've seen this exact scenario play out more times than I can count: you sync your organization's users to Exchange Online, everything looks fine in the admin portal, and then the help desk starts lighting up. Emails bounce. Replies go to the wrong address. Someone's calendar stopped syncing three days ago and they just noticed. Your CEO can't release a message from quarantine. And the error messages Microsoft gives you? Cryptic at best.

Exchange Online not sending, receiving, or syncing properly isn't usually one problem, it's a category of related problems that share common root causes. Understanding which bucket your issue falls into is half the battle.

The most common culprits I've traced these issues back to are:

• Unverified domains in Microsoft 365. This is the silent killer. When you have a domain that hasn't been fully verified in your Microsoft 365 tenant, Exchange Online falls back to routing mail through your *.onmicrosoft.com address. Users see a primary SMTP address like jane@contoso.onmicrosoft.com instead of jane@contoso.com, and recipients start bouncing mail back with NDRs.
• Incorrect administrator role assignments. Trying to manage Exchange Online via PowerShell without the right role group membership throws an "Access is denied" wall that stops everything cold, including bulk fixes that admins need to run to resolve the underlying mail flow problems.
• The RemotePowerShellEnabled flag being set to False. This one is subtle. A single parameter on a user account silently blocks all remote PowerShell connections, generating a "Bad Request" error that looks like a network or credential issue but isn't.
• Remote mailbox objects not being ACLable. In hybrid environments where you've provisioned mailboxes using New-RemoteMailbox, on-premises users can't assign delegate access or folder permissions to cloud mailbox users, which breaks shared workflows teams depend on.
• Quarantine release failures on Mac/Safari. Users on Macs with Safari get prompted for a client certificate when releasing quarantined messages, and because the certificate doesn't exist, they're completely blocked.

What makes Exchange Online troubleshooting frustrating is that Microsoft's error messages are written for engineers who already know the answer. "554 5.4.14 Hop Count exceeded, possible mail loop ATTR34" doesn't tell a help desk tech anything actionable. Neither does "Access is denied" when the real problem is a missing role assignment.

I'm going to walk you through every major scenario, starting with the fix that resolves the majority of Exchange Online sending and receiving problems, then going deeper for the edge cases. Browse all Microsoft fix guides →

The Quick Fix, Try This First

If users in your organization are getting non-delivery reports (NDRs) and the bounce messages reference your *.onmicrosoft.com address, or if their primary SMTP address is showing up wrong in the global address list, the fix is almost always the same: you have one or more unverified domains in Microsoft 365.

Here's exactly what to do:

1. Sign in to the Microsoft 365 admin center at admin.microsoft.com with a Global Administrator account.
2. In the left navigation, go to Settings > Domains.
3. Look for any domain listed with a status other than Healthy. You might see "Setup incomplete" or a yellow warning icon.
4. Click on the affected domain name, then click Continue setup.
5. Follow the wizard to add the required DNS records, typically a TXT record for verification, plus MX and CNAME records for mail flow. Your DNS provider's control panel is where you actually add these.
6. Once DNS propagates (give it up to 48 hours, though it's usually under an hour with modern providers), return to the Domains page and confirm the status shows Healthy.

After the domain is verified, Exchange Online will automatically correct the primary SMTP address assignments for synced users. You may need to trigger a delta sync from your on-premises Azure AD Connect server to push the updates faster:

Start-ADSyncSyncCycle -PolicyType Delta

Run that from a PowerShell session on your Azure AD Connect server. Within minutes, the corrected addresses should propagate to Exchange Online and mail flow should resume normally.

If users are still getting the NDR "554 5.4.14 Hop Count exceeded, possible mail loop ATTR34" even after domain verification, that error specifically means Exchange is detecting a routing loop. This usually clears up once the correct MX records are in place and verified. Double-check that your MX records point to *.mail.protection.outlook.com and not to an on-premises server that's forwarding back to the cloud.

Advanced Troubleshooting

When the standard fixes above don't resolve Exchange Online not sending, receiving, or syncing, the problem is usually deeper, hybrid configuration issues, mail flow rule conflicts, or connector misconfiguration. Here's how to dig further.

Analyzing NDR Error Codes

Exchange Online generates specific SMTP error codes when mail can't be delivered. The NDR "554 5.4.14 Hop Count exceeded, possible mail loop ATTR34" specifically tells you that a message has bounced back and forth too many times between servers. In practice, this almost always means your MX records point to an on-premises server that's forwarding to Exchange Online, while Exchange Online is trying to deliver back on-premises, creating a loop.

Check your mail flow connectors in the Exchange admin center under Mail flow > Connectors. If you have an outbound connector sending mail from Exchange Online to your on-premises server, verify the routing conditions are correct and that you're not accidentally routing all mail on-premises when it should deliver directly from the cloud.

Investigating with Message Trace

The single most powerful tool for Exchange Online mail delivery troubleshooting is Message Trace. In the Exchange admin center, go to Mail flow > Message trace. You can search by sender, recipient, message ID, or date range and see exactly what Exchange Online did with each message, including which connector was used, what rules fired, and where delivery failed.

For messages older than 10 days, use the "Extended message trace" option. The results take up to an hour to generate but go back 90 days. Filter by the NDR status to quickly isolate all failed deliveries in a given time window.

Checking Transport Rules and Safe Links

Transport rules (mail flow rules) can silently block or redirect messages without generating a traditional NDR. Go to Mail flow > Rules in the Exchange admin center and look for rules that might be matching your affected senders or recipients. Temporarily disable rules one at a time and test to isolate whether a rule is interfering with delivery.

In environments with Microsoft Defender for Office 365, Safe Links URL rewriting can sometimes cause issues with mail clients that don't handle redirected URLs cleanly. Check your Safe Links policies under Security > Policies & rules > Threat policies > Safe Links.

PowerShell Diagnostics for Mail Flow

Once you have Exchange Online PowerShell access working, these commands are your best friends for diagnosing delivery issues:

# Check if a specific mailbox can receive mail
Get-Mailbox -Identity user@contoso.com | Select PrimarySmtpAddress, EmailAddresses, HiddenFromAddressListsEnabled

# Check accepted domains
Get-AcceptedDomain | Select DomainName, DomainType, Default

# Review mail flow connectors
Get-InboundConnector | Select Name, Enabled, TlsSenderCertificateName
Get-OutboundConnector | Select Name, Enabled, SmartHosts, RecipientDomains

If Get-AcceptedDomain shows your custom domain with a type of "Authoritative" and the Default flag is True, Exchange Online considers itself the final destination for that domain. If the MX record doesn't point here, you'll get the mail loop NDR.

Prevention & Best Practices

Most Exchange Online sending, receiving, and syncing problems are preventable. The organizations I've seen suffer the least downtime around Exchange Online are the ones that treat it as an ongoing operational concern rather than a "set it and forget it" service. Here's what that looks like in practice.

Monitor domain verification status proactively. When you add a new domain to Microsoft 365, set a calendar reminder to verify its status 48 hours after adding it. DNS propagation delays mean domains sometimes silently fall back to unverified status if a TTL expires and the record isn't refreshed correctly. A monthly check of your Domains page in the admin center costs you five minutes and can prevent a full morning of mail delivery failures.

Document your mail flow connectors. Every connector in Exchange Online should have a clear description of what it does, who set it up, and why. Undocumented connectors get forgotten, then modified by a well-meaning admin who doesn't realize they're looking at a critical hybrid transport path. Write the purpose in the connector's Description field, Exchange Online stores it and displays it right there in the admin center.

Use the minimum necessary PowerShell access. Don't put everyone who needs Exchange management access into Organization Management. Create a more restricted role group for day-to-day tasks. This reduces the blast radius when credentials are compromised and keeps your audit logs readable.

In hybrid environments, enable ACLable objects at the start. Run Set-OrganizationConfig -ACLableSyncedObjectEnabled $True before your first batch of mailbox migrations, not after users start complaining that delegate access is broken. Retrofitting this setting to existing mailboxes is more work than getting it right upfront.

Set up Service Health alerts. Microsoft 365 has its own service health dashboard at admin.microsoft.com/adminportal/home#/servicehealth. You can subscribe to email alerts for Exchange Online incidents. When Microsoft's own infrastructure has an issue affecting mail flow, you want to know about it from Microsoft, not from an angry executive's IT ticket.

Frequently Asked Questions