Exchange Not Sending, Receiving, or Syncing, Real Fixes for 2026
Why This Is Happening
Here's the scenario I hear constantly: your Exchange hybrid deployment was working fine last week. Nobody touched anything. Then Monday morning rolls around, your Microsoft 365 users start complaining that free/busy lookups return nothing, mail sent to on-premises mailboxes bounces, and the Autodiscover service is just… silent. You check the obvious stuff, network connectivity, DNS, firewall rules, and everything looks fine on paper. So what gives?
Exchange hybrid deployments are genuinely complex beasts. You're stitching together two separate mail systems, your on-premises Exchange Server environment and Exchange Online in Microsoft 365, and making them behave like one. That means a lot of moving parts have to talk to each other over authenticated, encrypted channels using specific service endpoints. When any one of those endpoints breaks, the whole thing stops working in ways that look completely unrelated on the surface.
The most common culprit I've tracked down, over and over again, is a missing or broken handler mapping in IIS, specifically the svc-Integrated handler mapping. This one configuration piece is responsible for routing requests to .svc endpoints like MrsProxy.svc (used for mailbox moves) and Autodiscover.svc (used for federation and free/busy data). When it's gone, those endpoints throw an HTTP 405 Method Not Allowed error, and Exchange hybrid stops sending, receiving, or syncing mail correctly.
What makes this extra frustrating is that most other Exchange functions keep working. Regular Outlook profile setup via Autodiscover still succeeds. Web-based logins still work. So users and admins alike assume the problem is somewhere else entirely, a certificate issue, a DNS misconfiguration, a spam filter acting up. Meanwhile, the IIS logs are sitting there quietly reporting 405 0 1 on every POST to /EWS/mrsproxy.svc and nobody's looking at them.
This guide covers the real causes, the IIS handler mapping issue, federation trust failures, mail flow errors after certificate changes, and domain verification problems, and walks you through fixes that actually work. I've seen these exact errors on dozens of enterprise environments, and the fixes here are grounded in Microsoft's own documentation.
Whether your Exchange hybrid deployment is on Exchange Server 2010, 2013, 2016, or 2019, the underlying patterns are the same. Let's fix it. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep into IIS configuration and PowerShell, do this first. It resolves the majority of Exchange hybrid mail flow and sync failures I've encountered, and it takes about three minutes.
Open your IIS logs. On your on-premises Exchange hybrid server, navigate to C:\Inetpub\logs and pull up the most recent log file for the Default Web Site. Sort or search for entries containing 405. If you see lines like this:
<Date><Time> 10.10.10.1 POST /EWS/mrsproxy.svc - 443 test\admin 10.10.10.12 - 405 0 1…that's your smoking gun. The 405 Method Not Allowed on mrsproxy.svc or Autodiscover.svc tells you the svc-Integrated handler mapping is missing from IIS. This is fixable in one command.
Open a Command Prompt as Administrator on the Exchange hybrid server and run:
cd C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation
ServiceModelReg.exe -rThis command reinstalls the WCF handler mappings in IIS, including the svc-Integrated mapping that Exchange depends on. After it completes, restart IIS:
iisreset /noforceWait for IIS to fully restart, usually 30 to 60 seconds, then test your mail flow and free/busy lookups. In a significant number of cases, this is all it takes. Mail starts flowing, federation lookups return data, and mailbox moves succeed again.
If this didn't fully resolve the issue, or if the svc-Integrated handler mapping is present in IIS but Exchange is still not sending or receiving correctly, keep reading. The step-by-step section below covers the deeper fixes.
%windir%\system32\inetsrv\appcmd list config > C:\iis-backup.txt before making changes, it takes five seconds and gives you a reference point if something goes sideways. IIS configuration bugs are notoriously hard to diagnose without a before-and-after comparison.
This is where the diagnosis starts. The svc-Integrated handler mapping is a server-level IIS configuration that tells IIS how to process requests to Windows Communication Foundation (WCF) service endpoints, the .svc files that Exchange hybrid depends on.
Open Internet Information Services (IIS) Manager. You can find it by pressing Win + R, typing inetmgr, and hitting Enter. In the left-hand Connections pane, click your server name (the top-level node, not Default Web Site). In the center panel, double-click Handler Mappings.
Scroll through the list and look for an entry named svc-Integrated. It should be there. If it's missing entirely, that's your problem, go to Step 2 for the ServiceModelReg fix. If it's present at the server level but mail flow or free/busy is still broken, the issue may be at the virtual directory level, not the server level, and you'll continue to Step 3.
While you're here, also note the svc-Integrated-4.0 mapping if your environment is running .NET 4.x. Both entries matter depending on your Exchange version and .NET Framework configuration. Document what you see, this baseline matters for the steps ahead.
If everything looks correct in IIS Manager but problems persist, open a PowerShell window and run:
Get-WebHandler -PSPath 'IIS:\' | Where-Object { $_.Name -like '*svc*' }This queries the IIS configuration programmatically and can sometimes surface handler entries that the GUI obscures or fails to display correctly. You should see svc-Integrated in the output. If you don't, the fix in Step 2 is your next move.
If the svc-Integrated handler mapping is missing from IIS, the fix is to reinstall the WCF handler mappings using the ServiceModelReg.exe tool. This is a Microsoft-provided utility that ships with the .NET Framework and specifically handles registration of Windows Communication Foundation components in IIS.
Before you run anything, back up your current IIS configuration. In an elevated Command Prompt:
%windir%\system32\inetsrv\appcmd list config "Default Web Site" > C:\iis-defaultsite-backup.txtNow navigate to the WCF directory and run the registration command:
cd C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation
ServiceModelReg.exe -rThe -r flag tells it to reregister all WCF components. You'll see output as it processes, let it run to completion. On some systems this takes up to a minute. Do not close the window early.
After it finishes, restart IIS without forcing active connections to drop (which is gentler on any ongoing sessions):
iisreset /noforceGo back to IIS Manager and refresh the Handler Mappings view for your server. The svc-Integrated entry should now appear. Once confirmed, go back to your Exchange Online admin center or run the Get-FederationInformation PowerShell cmdlet to verify the fix:
Get-FederationInformation -DomainName yourdomain.comIf it returns federation data instead of throwing HTTP Error 405 Method Not Allowed, you're in business. If the error persists, proceed to Step 3.
Sometimes the svc-Integrated handler is present at the server level but missing or overridden at the virtual directory level. This is a subtler problem, and it specifically breaks Autodiscover-based federation and free/busy lookups while leaving everything else seemingly intact.
In IIS Manager, expand Default Web Site in the left pane and click on the Autodiscover virtual directory. Open Handler Mappings from the center panel.
Check whether svc-Integrated is listed here. If it's missing at this level even though it's present at the server level, the virtual directory has its own local override that's blocking inheritance.
Before changing anything, back up the web.config file for this virtual directory, you'll find it at a path like C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover\web.config (adjust the version number for your Exchange installation). Copy it somewhere safe.
In IIS Manager, with the Autodiscover virtual directory selected and Handler Mappings open, click Revert to Parent in the Actions pane on the right. Click Yes to confirm. This removes the local overrides and restores server-level inheritance.
Confirm that svc-Integrated now appears in the Autodiscover handler mappings. Then rebuild the Autodiscover virtual directory to a clean state. Open the Exchange Management Shell and run:
Remove-AutodiscoverVirtualDirectory "<ServerName>\Autodiscover (Default Web Site)"
New-AutodiscoverVirtualDirectory -WebSiteName "Default Web Site" -WSSecurityAuthentication:$TrueReplace <ServerName> with your actual Exchange server name. After these commands complete, open your backup web.config and copy any custom handler entries from within the <system.webServer> tags into the new web.config. Run iisreset /noforce and retest.
If rebuilding the Autodiscover virtual directory didn't fully restore functionality, you may need to manually verify, and if necessary, restore, the minimum handler entries in the Autodiscover web.config file. These handlers are what make the .svc, .asmx, and .xml endpoints work correctly for Exchange hybrid federation.
Open the web.config file for the Autodiscover virtual directory in a text editor (Notepad++ or VS Code work well here, Notepad on a long XML file is painful). Look inside the <system.webServer> section for a <handlers> block.
At minimum, the following four handlers must be present:
<handlers>
<add name="AutodiscoverAsmxHandler" path="*.asmx" verb="*"
type="System.ServiceModel.Activation.HttpHandler,
System.ServiceModel, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
preCondition="integratedMode,runtimeVersionv2.0" />
<add name="AutodiscoverXMLHandler" path="*.xml" verb="POST"
type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel,
Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
preCondition="integratedMode,runtimeVersionv2.0" />
<add name="AutodiscoverDiscoveryLegacyHandler" path="*.xml" verb="GET"
type="Microsoft.Exchange.Autodiscover.WCF.LegacyHttpHandler,
Microsoft.Exchange.Autodiscover, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
preCondition="integratedMode,runtimeVersionv2.0" />
<add name="AutodiscoverDiscoveryHandler" path="*.svc" verb="GET"
type="Microsoft.Exchange.Autodiscover.WCF.AutodiscoverDiscoveryHttpHandler,
Microsoft.Exchange.Autodiscover, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
preCondition="integratedMode,runtimeVersionv2.0" />
</handlers>If any of these are missing, add them manually. Save the file, then run iisreset /noforce. These handlers are what Exchange specifically needs for federation data exchange, free/busy lookups, and mailbox move operations. After restoring them, test with Get-FederationInformation again and check whether free/busy information now appears for on-premises users queried from Microsoft 365.
Once you've addressed the IIS handler issues, it's time to verify that Exchange is actually sending, receiving, and syncing correctly. Don't skip this, "IIS looks right now" doesn't automatically mean "mail flows correctly." You need to test each layer.
Start with federation. In the Exchange Management Shell on your on-premises server, run:
Get-FederationInformation -DomainName yourdomain.com -VerboseThis should return a clean federation information object with your domain's token issuer and endpoints. If it still throws a 405 or "Federation Information could not be received" error, the IIS fix hasn't fully taken effect, confirm that IIS was restarted and that the handler mappings are showing correctly.
Next, test free/busy from a Microsoft 365 user to an on-premises mailbox. The quickest way is to open Outlook as a Microsoft 365 user, create a new meeting, and add an on-premises user as an attendee. Check whether scheduling information appears. If it shows no data or shows hash marks, the federation trust or organization relationship is still broken.
Test mail flow in both directions. Send a message from a Microsoft 365 mailbox to an on-premises mailbox and vice versa. Check delivery times, hybrid mail should route internally and arrive quickly, not bounce through external MX records. If mail is being routed externally or bouncing, check your hybrid mail flow connectors in the Exchange Admin Center under Mail flow > Connectors.
Finally, check whether MrsProxy is reachable for mailbox moves by running:
Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer mail.yourdomain.com -Credentials (Get-Credential)A successful result confirms the MrsProxy.svc endpoint is responding correctly. If this fails, go back and verify the svc-Integrated handler is present in IIS and that the MrsProxy virtual directory's handler mappings are also inheriting correctly.
Advanced Troubleshooting
If you've worked through all five steps and Exchange is still not sending, receiving, or syncing the way it should, you're likely looking at one of a few less obvious scenarios. I've run into all of these in enterprise deployments, here's how to dig deeper.
Reading the IIS Logs Properly
The IIS logs at C:\Inetpub\logs are your most honest signal. Most admins glance at them and move on. Don't. Parse them properly. Open the most recent log file and filter for status codes 405, 403, and 550. Each combination tells a different story:
- 405 on /EWS/mrsproxy.svc, svc-Integrated handler missing (covered above)
- 403 on /EWS/mrsproxy.svc, authentication or permissions issue, often seen during mailbox move operations
- 405 on /Autodiscover/Autodiscover.svc, Autodiscover virtual directory handler issue
The sub-status codes matter too. 405 0 1 specifically is the WCF handler miss. 403 0 5 typically indicates SSL certificate mismatch.
Certificate Problems That Kill Mail Flow
Installing a new SSL certificate on your Exchange server is one of the most common ways to accidentally break hybrid mail flow. If you've changed your certificate recently and Exchange stopped sending or receiving mail shortly after, this is your culprit.
Verify that the new certificate covers all required Exchange service names, specifically your hybrid server's FQDN, the Autodiscover CNAME (autodiscover.yourdomain.com), and any custom mail flow FQDNs. In Exchange Management Shell:
Get-ExchangeCertificate | Format-List Thumbprint, Subject, CertificateDomains, Services, StatusThe certificate assigned to SMTP, IIS, and potentially POP/IMAP services must have a valid chain, must not be expired, and must cover the correct names. If you see the wrong certificate assigned, reassign it:
Enable-ExchangeCertificate -Thumbprint <ThumbprintValue> -Services SMTP,IISADSTS50011 and Federation Trust Failures
If you're seeing ADSTS50011 errors during Hybrid Configuration Wizard runs, this indicates a redirect URI mismatch in Azure AD, the reply URL registered for the Exchange hybrid application doesn't match what's being sent. This typically happens in environments where the Hybrid Configuration Wizard hasn't been run recently and the federation trust metadata has drifted.
Re-running the Microsoft 365 Hybrid Configuration Wizard (the modern web-based version, not the old Exchange Management Console wizard) resolves this in most cases. Download it from the Microsoft Download Center and run it against your environment, it refreshes the federation trust, updates organization relationships, and fixes connector configurations in one pass.
550 5.7.64 Relay Access Denied ATTR36
This NDR surfaces when mail from on-premises Exchange passes through Exchange Online Protection but the sending connector isn't configured to accept or relay for your domain. Check your inbound and outbound hybrid connectors in Exchange Admin Center > Mail flow > Connectors. The connector certificate must match the FQDN your Exchange server uses when sending, and the IP address sending the mail must be listed as a permitted sender on the inbound connector in Exchange Online.
If you've verified the IIS handler mappings, rebuilt the Autodiscover virtual directory, confirmed your certificates, rerun the Hybrid Configuration Wizard, and Exchange is still not sending, receiving, or syncing, it's time to escalate. Open a support case through the Microsoft Support portal with your IIS logs, the output of Get-FederationInformation, and the output of Get-HybridConfiguration. Having those three artifacts ready will cut your support call time dramatically. Microsoft's Exchange hybrid team can access your tenant diagnostics directly and identify issues that aren't visible from the on-premises side.
Prevention & Best Practices
The best Exchange hybrid fix is the one you never have to do. Most of the issues covered in this guide, the broken IIS handlers, the federation trust failures, the mail flow disruptions, are preventable with a handful of operational habits. Here's what I recommend to every organization running an Exchange hybrid deployment.
Monitor Your IIS Handler Mappings After Every Windows Update
Windows Updates that touch the .NET Framework can occasionally reset or overwrite IIS handler mappings. It doesn't happen often, but it happens, and it's always on a Monday morning after patch Tuesday. Build a simple check into your post-patch validation routine: after any .NET Framework update, open IIS Manager and verify the svc-Integrated handler is still present at the server level. It takes 30 seconds and can save you hours of frantic debugging.
Use the Modern Hybrid Configuration Wizard Regularly
The old Hybrid Configuration Wizard built into the Exchange Management Console is no longer supported for Exchange 2010, and it's the source of a surprisingly large number of lingering configuration issues. Use the Microsoft 365 Hybrid Configuration Wizard (the modern web-based version) at least once per year, or any time you make significant changes to your environment. It keeps federation trusts, organization relationships, and mail flow connectors fresh and consistent.
Track Certificate Expiry Proactively
Set a calendar reminder 60 days before your Exchange SSL certificate expires. Renewing a certificate is fast; dealing with broken mail flow because a certificate expired over the weekend is not. When you do renew, validate immediately that the new certificate is assigned to the correct services and covers all required FQDNs, don't assume the renewal process handled it automatically.
Keep Your IIS Configuration Backed Up
Schedule a weekly automated backup of your IIS configuration using the built-in backup feature. In an elevated Command Prompt:
%windir%\system32\inetsrv\appcmd add backup "WeeklyBackup"These backups are stored in %windir%\system32\inetsrv\backup and can be restored quickly if a configuration change goes wrong.
- After every .NET Framework update, verify the svc-Integrated handler mapping is still present in IIS Manager
- Set calendar reminders 60 days before your Exchange SSL certificate expiry date
- Run
Test-MigrationServerAvailabilitymonthly to catch MrsProxy issues before they become incidents - Review IIS logs weekly, five minutes of log scanning catches problems before users report them
Frequently Asked Questions
Why does Exchange say "Federation Information could not be received from the external organization"?
This error almost always means the Autodiscover.svc endpoint on your on-premises Exchange server returned a 405 Method Not Allowed response instead of federation data. The root cause is a missing svc-Integrated handler mapping in IIS. Follow Steps 1 and 2 in this guide, run ServiceModelReg.exe -r from the WCF directory, restart IIS, then retest with Get-FederationInformation. If the handler mapping is present but the error persists, check whether the Autodiscover virtual directory has a local override blocking inheritance.
My Exchange hybrid free/busy shows nothing for on-premises users, how do I fix it?
Free/busy lookups in a hybrid deployment rely on the Autodiscover service and the organization relationship between your on-premises Exchange organization and your Microsoft 365 tenant. If Autodiscover is broken, even slightly, free/busy returns nothing. Start by running Get-FederationInformation from Exchange Management Shell to see if the federation endpoint is responding. If that returns a 405 error, fix the IIS svc-Integrated handler as described in this guide. Also verify the organization relationship exists and has free/busy sharing enabled by running Get-OrganizationRelationship | Format-List.
Exchange was working fine and then stopped after I installed a Windows update, what happened?
Windows updates that include .NET Framework components can overwrite or reset IIS handler mappings, which removes the svc-Integrated entry that Exchange hybrid depends on. This is well-documented and happens periodically. The fix is to rerun ServiceModelReg.exe -r from C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation and then restart IIS with iisreset /noforce. After doing this, add a post-update validation step to your change management process, check IIS handler mappings every time you patch the server.
I'm getting "HTTP Error 405 Method Not Allowed" when running Get-FederationInformation, what does this mean exactly?
This error means the IIS server received the PowerShell cmdlet's HTTP request to the Autodiscover or EWS endpoint, but rejected the HTTP method used (typically POST or GET) because there's no handler configured to process requests to .svc files. It's not a firewall issue, the request reached IIS. It's a handler mapping issue inside IIS itself. The svc-Integrated handler mapping is missing, so IIS doesn't know what to do with service endpoint requests and returns 405. Reinstalling WCF handler mappings with ServiceModelReg.exe -r is the correct fix.
Can I still use the Hybrid Configuration Wizard in the Exchange Management Console for Exchange 2010?
No, Microsoft has officially deprecated and removed support for the Hybrid Configuration Wizard that was built into the Exchange Management Console in Exchange 2010. You should not use it. The replacement is the Microsoft 365 Hybrid Configuration Wizard, which is a separate web-based tool available from Microsoft's download center. It works with Exchange 2010 SP3 and later and is actively maintained. Using the old wizard can produce incomplete or broken configurations that are difficult to diagnose later. Always use the modern wizard.
Exchange is sending mail fine but mailbox moves to Exchange Online are failing with a 405 error, is this related?
Yes, absolutely related. Mailbox moves between on-premises Exchange and Exchange Online use the MrsProxy.svc endpoint, a WCF service endpoint that requires the exact same svc-Integrated handler mapping in IIS. Regular mail flow uses SMTP connectors and doesn't touch the svc endpoint, which is why you can have normal mail delivery working perfectly while mailbox moves fail with 405. Check your IIS logs at C:\Inetpub\logs for 405 errors on /EWS/mrsproxy.svc and follow the IIS handler fix in Steps 1 and 2 of this guide.