Microsoft 365 network connectivity principles
How to architect network traffic for Microsoft 365 — local egress, optimisation, and the network connectivity principles Microsoft publishes.
Microsoft publishes a clear set of Network Connectivity Principles for Microsoft 365. They run counter to many traditional enterprise network designs — and they're written from years of customer support data on what makes Microsoft 365 feel fast or slow.
The four principles
1. Identify Microsoft 365 traffic
The first job is knowing which traffic is Microsoft 365. Microsoft publishes the Microsoft 365 IP and URL list — a regularly-updated catalogue of every endpoint, categorised by:
- Optimize — must-be-fast endpoints (Teams media, Exchange Online primary traffic).
- Allow — important endpoints (most Microsoft 365 services).
- Default — less critical endpoints that can be treated as general web traffic.
The list is published as JSON via the Microsoft 365 IP Address Web Service.
2. Egress Microsoft 365 traffic locally
The historical pattern was to backhaul all corporate internet traffic through a central datacentre (for inspection, central egress, legacy reasons). For Microsoft 365 this is the worst possible thing you can do:
- Adds latency.
- Doesn't take advantage of Microsoft's global network entry points.
- Defeats Microsoft's traffic optimisation.
The principle: egress Microsoft 365 traffic locally at every branch and remote-user location. Let users' traffic hit Microsoft's edge directly via local internet.
3. Avoid network hairpins
Even when traffic egresses locally, avoid sending it through a remote inspection point before reaching Microsoft. A common anti-pattern: branch traffic egresses locally but routes through a corporate proxy hosted in another country before reaching Microsoft 365 — a hairpin that adds latency and breaks Microsoft's geo-aware routing.
If you must inspect Microsoft 365 traffic, do it locally or skip inspection for the Optimize and Allow categories.
4. Assess bypass for Microsoft 365 traffic
For each layer of network inspection — firewall, IPS, proxy, SSL inspection — consider bypassing Microsoft 365 Optimize endpoints:
- They're already authenticated and encrypted.
- They're known and validated by Microsoft.
- Inspection adds latency and breaks features (especially Teams media).
- Microsoft already has Defender for Office 365 and Defender XDR to detect threats.
For most enterprises, this means split tunnelling on the VPN — Microsoft 365 Optimize traffic goes direct, everything else through the VPN.
Implementing the principles
For modern enterprises, the right architecture:
- SD-WAN or direct internet access at every branch.
- Split tunnel VPN for remote users, with Microsoft 365 optimised endpoints excluded from the tunnel.
- Local DNS resolution with proximity to the user.
- Quality of Service (QoS) marking on Teams media for prioritisation.
- Inspection bypass for Microsoft 365 Optimize endpoints.
Microsoft's own tools
- Microsoft 365 Network Connectivity dashboard in the admin center — performance signals from real user traffic.
- Microsoft 365 connectivity test tool at
connectivity.office.com— point-in-time test from a specific location. - Teams Network Planner — capacity planning for Teams media.
Special cases
- Teams media is especially sensitive to latency, jitter, packet loss. Don't backhaul Teams media. Don't inspect it.
- SharePoint and OneDrive sync uses large data volumes; bandwidth, not latency, is the constraint.
- Exchange Online is more forgiving of latency than Teams.
- Power BI report performance can be latency-sensitive for interactive use.
Most performance complaints about Microsoft 365 trace back to a network that violates these principles. Getting the network right is rarely the IT team's first instinct — but it's almost always the highest-leverage fix.