How to Fix Exchange Online

This is the single most overlooked root cause in Exchange Online troubleshooting. When your outbound mail gets rejected or lands in recipients' spam folders, broken DNS authentication records are the culprit more often than any Exchange configuration problem. I've walked into organizations where the SPF record was simply missing the include:spf.protection.outlook.com mechanism, a two-minute fix that had been causing NDRs for months.

Open PowerShell and run a quick check:

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

# Check DKIM selector records
Resolve-DnsName -Name selector1._domainkey.yourdomain.com -Type CNAME
Resolve-DnsName -Name selector2._domainkey.yourdomain.com -Type CNAME

Your SPF record must include include:spf.protection.outlook.com and should end with ~all or -all. If it's missing or malformed, log into your DNS provider and add or correct it. Changes can take up to 48 hours to propagate, but typically resolve within 30 minutes for most resolvers.

For DKIM, head to the Exchange admin center → Mail flow → DKIM. Both selectors (selector1 and selector2) should show Status: Enabled. If they show No DKIM keys saved for this domain, click Enable and then update the CNAME records in your DNS with the values Microsoft provides. Do not enable DKIM until those DNS records are published, you'll cause an immediate delivery failure.

DMARC is optional but increasingly important for deliverability. A minimal record looks like: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start with p=none to collect reports before enforcing.

Once your DNS records are correct, recheck with the Microsoft Remote Connectivity Analyzer at testconnectivity.microsoft.com, use the Outbound SMTP Email test. A passing result here means your outbound authentication chain is clean.

When Outlook clients show Disconnected, Trying to connect, or throw error 0x8004011D or Cannot start Microsoft Outlook. Cannot open the Outlook window, the problem is almost always in the Autodiscover chain or the MAPI-over-HTTPS configuration. Don't let users create new profiles or reinstall Outlook until you've confirmed the service endpoint is actually reachable.

Connect to Exchange Online PowerShell first:

Install-Module -Name ExchangeOnlineManagement -Force
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com

Then test Outlook connectivity for a specific user:

Test-OutlookConnectivity -ProbeIdentity OutlookMapiHttp.Probe -MailboxId user@yourdomain.com

Also check Autodiscover directly from the Remote Connectivity Analyzer. Go to testconnectivity.microsoft.com → Outlook Connectivity → Outlook Autodiscover. Enter the affected user's email and credentials. The tool walks through every step of the Autodiscover lookup chain and flags exactly where it fails, whether it's an SRV record missing, a 401 redirect loop, or a certificate name mismatch on a hybrid CAS server.

For hybrid environments, this is where things get messy. If your on-premises Exchange server is still published as the Autodiscover endpoint but users are in Exchange Online, you'll see Autodiscover returning on-premises settings for cloud mailboxes. Fix this by setting the on-premises Autodiscover service to redirect cloud-homed users:

# Run on-premises Exchange Management Shell
Set-ClientAccessServer -Identity "EXCH01" -AutoDiscoverServiceInternalUri https://autodiscover.yourdomain.com/autodiscover/autodiscover.xml

If the test passes but Outlook still won't connect on a specific machine, delete the existing Outlook profile (Control Panel → Mail → Show Profiles → select the profile → Remove) and create a new one. Sometimes the cached token in the credential store is corrupted. Open Credential Manager (Win + R → control keymgr.dll), find and delete any entries starting with MicrosoftOffice16 or msteams, then relaunch Outlook.

Mail not arriving is the most urgent Exchange Online troubleshooting scenario. It feels like email just vanished, and sometimes it literally did, if a transport rule is silently dropping messages. Here's how to find it fast.

In the Exchange admin center (admin.exchange.microsoft.com), go to Mail flow → Message trace → Start a trace. Set the time range to at least 4 hours before the reported problem. Enter the sender's email, the recipient's email, and click Search.

Read the Status column carefully:

• Delivered, Exchange delivered it. The problem is on the recipient's end (wrong folder, client filtering, mailbox rule).
• Failed, Delivery attempt failed. Click into the trace for the specific SMTP error code and action.
• Pending, Message is still in the transport queue. Could be a routing loop, slow connector, or Microsoft infrastructure delay.
• FilteredAsSpam, Anti-spam policy blocked it. Check Security → Email & collaboration → Policies & rules → Threat policies → Anti-spam.
• No messages found, Exchange never received the message. The problem is on the sending side, check the sender's outbox, their mail client logs, or their sending server's SMTP logs.

If the trace shows a transport rule action (like DeleteMessage or Redirect), go to Mail flow → Rules and review every rule that could match the sender/recipient combination. Sort by priority, higher-priority rules run first and can prevent lower rules from executing entirely.

For messages stuck in the outbound queue going to external recipients, check if your tenant's outbound connector is misconfigured. Run this in Exchange Online PowerShell:

Get-OutboundConnector | Format-List Name, Enabled, SmartHosts, UseMxRecord, TlsSettings, ConnectorType

If UseMxRecord is False and the SmartHosts value points to a dead or misconfigured relay, that's your culprit. Either fix the smart host address or set UseMxRecord back to True for internet delivery.

Authentication failures are behind a huge portion of Exchange Online troubleshooting cases, and they're getting more common as Microsoft tightens down on Basic Auth (which was fully disabled for Exchange Online in October 2022). If your users see Password incorrect prompts that loop, Need password in Outlook's status bar, or MFA prompts that never complete, this is the section you need.

First, verify Modern Authentication is enabled on your tenant:

Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com
Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled

The value must be True. If it's False, enable it:

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

On the client side, confirm the Outlook client supports Modern Auth. Outlook 2013 requires a registry key that Microsoft doesn't set by default:

# Run in Registry Editor or via PowerShell as admin
# For 32-bit Office on 64-bit Windows:
New-ItemProperty -Path "HKCU:\Software\Microsoft\Office\15.0\Common\Identity" -Name "EnableADAL" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKCU:\Software\Microsoft\Office\15.0\Common\Identity" -Name "Version" -Value 1 -PropertyType DWORD -Force

For Outlook 2016 and later, Modern Auth is on by default, but Conditional Access policies can still block it. Go to entra.microsoft.com → Protection → Conditional Access → Sign-in logs. Filter by the affected user and look for Failure entries. The Conditional Access tab inside each log entry will show you exactly which policy triggered and what condition caused the block, usually it's a device compliance requirement, a location restriction, or an MFA requirement that the client isn't satisfying.

Token cache corruption is also common after password resets. Have the user open Credential Manager (search in Start menu), go to Windows Credentials, and delete every entry containing outlook, office, mso, or microsoftoffice. Then restart Outlook and sign in fresh. This clears the stale OAuth tokens that are causing the loop.

Shared mailbox access failures, delegate send-on-behalf errors, and calendar delegation breakdowns are incredibly common Exchange Online troubleshooting tickets. The symptoms vary, Outlook shows You don't have permission to access this mailbox, or the delegate can open the mailbox but not send from it, or Send As works but Send on Behalf doesn't. Each of these is a different permission layer.

Start by auditing the actual permissions on the mailbox in question:

# Full mailbox access (for shared mailboxes, opened as additional account)
Get-MailboxPermission -Identity sharedmailbox@yourdomain.com | Where-Object { $_.IsInherited -eq $false } | Format-Table User, AccessRights

# Send As permission (appears to come FROM that mailbox)
Get-RecipientPermission -Identity sharedmailbox@yourdomain.com | Format-Table Trustee, AccessRights

# Send on Behalf permission (shows "on behalf of" in recipient header)
Get-Mailbox -Identity sharedmailbox@yourdomain.com | Select-Object GrantSendOnBehalfTo

If the user is missing from the output, add them:

# Add full access
Add-MailboxPermission -Identity sharedmailbox@yourdomain.com -User user@yourdomain.com -AccessRights FullAccess -InheritanceType All -AutoMapping $true

# Add Send As
Add-RecipientPermission -Identity sharedmailbox@yourdomain.com -Trustee user@yourdomain.com -AccessRights SendAs

# Add Send on Behalf
Set-Mailbox -Identity sharedmailbox@yourdomain.com -GrantSendOnBehalfTo @{Add="user@yourdomain.com"}

One thing that catches people off guard: AutoMapping (the feature that automatically opens a shared mailbox in Outlook when you have Full Access) requires the -AutoMapping $true flag and only works when the user profile was created after the permission was granted. If a user had their profile set up before they received Full Access, remove and re-add the permission with AutoMapping enabled, then delete and recreate the Outlook profile. The mailbox will appear in the left nav automatically after a few minutes.

For calendar delegation issues specifically, check the calendar sharing policy applied to the mailbox. In the Exchange admin center, go to Organization → Sharing and verify the Default Sharing Policy includes Calendar sharing with all domains at the appropriate permission level. Internal delegation problems are sometimes caused by the Default sharing policy being overly restrictive.