Fix: Claude MCP Server Blocked by Microsoft 365 Conditional Access Policy

A client recently reached out because Claude could not access their Microsoft 365 data. Every time they tried to search emails or use the M365 MCP connector in Claude, it would fail with a Conditional Access error. The initial sign-in to Claude worked fine, but the moment Claude tried to read their mailbox or files, it was blocked. The issue went back and forth for over a week, with several attempted fixes that only worked temporarily, before the team identified the real root cause and applied a permanent solution.

Symptoms

When connecting Claude to Microsoft 365 using the M365 MCP connector, users may encounter the following errors:

Your organization’s access policy blocks the MCP server. Contact your IT admin to adjust the policy for this connector.

Ask your IT admin to allow the Claude/Anthropic app through your org’s Conditional Access policy

Conditional Access is blocking again. Same issue – needs a permanent fix, not a one-off bypass.

The initial OAuth sign-in to Claude may succeed, but subsequent attempts to access M365 data (searching emails, reading files, querying calendar) fail. The error code in Entra sign-in logs is AADSTS53003, and the MCP connector may report mcp_token_exchange_failed.

Cause

This issue occurs in tenants that use a geo-blocking Conditional Access policy (for example, “Block Untrusted Countries” or “Allow Approved Countries Only”) that restricts sign-ins to specific countries like Australia.

When a user connects Claude to M365, two things happen:

1. Initial authentication – The user signs in from their browser in Australia. This succeeds because their IP is in the allowed country.
2. On-Behalf-Of (OBO) token exchange – After the user authenticates, Claude’s MCP server (hosted by Anthropic in the United States) uses an OBO token flow to call Microsoft Graph on the user’s behalf. This token exchange originates from Anthropic’s US-based infrastructure, which triggers the geo-blocking policy.

The key insight is that the block does not happen at the initial sign-in. It happens when Claude’s server-side infrastructure exchanges the token to access Graph APIs. This is why the user sees the connection succeed initially but then fail when Claude tries to actually read data.

The two enterprise apps involved are:

• M365 MCP Client for Claude – App ID: 08ad6f98-a4f8-4635-bb8d-f1a3044760f0
• M365 MCP Server for Claude – App ID: 07c030f6-5743-41b7-ba00-0a6e85f37c17

Resolution

There are several approaches to fixing this. We cover the common mistakes first, then the recommended permanent fix.

Approach 1: Exclude Claude App IDs Only (Partial Fix)

Adding the two Claude app IDs to the exclusion list of your geo-blocking CA policy will fix the initial authentication, but will not fix the OBO token exchange. The Graph API call still originates from Anthropic’s US IPs and will be blocked.

Result: User can sign in, but Claude still cannot access M365 data. Not recommended as a standalone fix.

Approach 2: Allow the Entire United States (Not Recommended)

Adding the United States as an allowed country in the geo-blocking policy will resolve the issue, but this is a significant security trade-off. It opens the tenant to sign-in attempts from every IP in the US, which defeats the purpose of geo-blocking.

Result: Works, but unacceptable security risk. Do not use this approach.

Approach 3: Create a Separate “Allow US for Claude Only” Policy (Unreliable)

Creating a new CA policy that allows US sign-ins exclusively for the Claude apps can work in theory but has proven unreliable in practice. Policy evaluation order, conflicting deny rules, and the OBO flow can cause intermittent failures.

Result: Inconsistent. May work temporarily then break again.

Approach 4: Exclude Claude Apps + Anthropic IP Range (Recommended)

The permanent fix combines two changes in your geo-blocking Conditional Access policy:

Step 1: Exclude the Claude app IDs from the policy

1. Open Microsoft Entra admin centre > Protection > Conditional Access
2. Edit your geo-blocking policy (e.g. “Block Untrusted Countries”)
3. Go to Target resources > Exclude
4. Select Select excluded cloud apps
5. Add both:
   • M365 MCP Client for Claude (08ad6f98-a4f8-4635-bb8d-f1a3044760f0)
   • M365 MCP Server for Claude (07c030f6-5743-41b7-ba00-0a6e85f37c17)
6. Save the policy

Step 2: Create a Named Location for Anthropic’s IP range

1. In Conditional Access > Named locations, click + IP ranges location
2. Name it something clear, e.g. “Anthropic Claude MCP (Outbound IPs)”
3. Add Anthropic’s published outbound IP range: 160.79.104.0/21
4. This covers 160.79.104.0 through 160.79.111.255 (2,048 addresses)
5. Save the named location

Step 3: Exclude the Named Location from your geo-blocking policy

1. Edit your geo-blocking policy again
2. Under Conditions > Locations > Exclude
3. Add the “Anthropic Claude MCP (Outbound IPs)” named location
4. Save the policy

Allow 15 to 20 minutes for the policy changes to propagate, then ask the user to retry their Claude M365 connection.

Important Notes

• IP range source: Anthropic publishes their outbound IP addresses at docs.anthropic.com/en/api/ip-addresses. If Claude stops working in the future, check whether the IP range has changed and update the Named Location accordingly.
• Admin consent required: Both Claude enterprise apps need admin consent granted in the tenant before the MCP connector will work. If the apps do not appear in Enterprise Applications, the user needs to initiate a connection from Claude first, which will trigger an admin consent request.
• This is a targeted fix: Only Anthropic’s specific /21 IP range is trusted, not the entire United States. This preserves the security posture of the geo-blocking policy while allowing the OBO token exchange to complete.
• Multiple CA policies: If the tenant has more than one geo-blocking policy (e.g. one from GCIT and one from the customer’s own security baseline), you may need to apply the exclusions to each policy.
• Propagation delay: Conditional Access changes can take 15 to 20 minutes to take effect. If the user reports it is still failing immediately after the change, ask them to wait and retry.

Related Resources

• Anthropic Outbound IP Addresses
• Microsoft Entra Conditional Access: Location Conditions
• How to: Require access from specific locations
• Model Context Protocol (MCP) Documentation