How to Optimise Your Network for Microsoft 365

Microsoft 365 has become the backbone of productivity for UK businesses of every size. From email and file storage to video conferencing, collaboration, and security — it touches virtually every aspect of daily operations. Yet far too many organisations invest in premium M365 licences only to find that Teams calls drop, SharePoint crawls, and Outlook takes an age to sync. The culprit is almost never Microsoft’s cloud infrastructure. It is your network.

The uncomfortable truth is that Microsoft 365 was designed for the modern internet, not for the legacy network architectures that most UK businesses still run. Traditional hub-and-spoke topologies, aggressive proxy inspection, under-provisioned broadband, and misconfigured DNS all conspire to throttle performance and frustrate users. The good news? With the right optimisations, the difference can be transformational — and most changes cost nothing beyond time and expertise.

This guide provides a comprehensive, practical roadmap for UK businesses looking to unlock the full potential of their Microsoft 365 investment. Whether you have 10 users or 500, these principles apply.

Why Your Network Architecture Matters for Microsoft 365

To understand why so many businesses struggle with M365 performance, you need to appreciate a fundamental shift in how enterprise software works. A decade ago, your applications lived on servers in your office or data centre. Network traffic stayed local, latency was measured in microseconds, and your internet connection was used mainly for email and web browsing.

Microsoft 365 flips this model entirely. Every document you open, every email you send, every Teams call you make, and every file you save travels across the public internet to Microsoft’s data centres and back again. Your internet connection is no longer a convenience — it is your primary application delivery mechanism. If the path between your users and Microsoft’s servers is slow, congested, or poorly routed, every single M365 application suffers.

Microsoft operates a vast global network with points of presence across the UK, including facilities in London, Cardiff, and Durham. The company has invested billions in ensuring that once traffic enters their network, performance is excellent. The challenge — and where most problems originate — is the “last mile” between your office and Microsoft’s front-door servers.

The Legacy Network Problem

Many UK businesses, particularly those with multiple sites, still use network architectures designed in the early 2000s. Traffic from branch offices is backhauled to a central headquarters or data centre over MPLS circuits, where it passes through centralised firewalls and proxy servers before reaching the internet. This made perfect sense when the internet was untrusted and applications were on-premises.

For Microsoft 365, this architecture is catastrophic. A user in your Manchester branch sending a Teams message to a colleague in the same room might see their traffic routed to London via MPLS, through a proxy server, out to the internet, across to Microsoft’s data centre, and back again. What should be a 15-millisecond round trip becomes 150 milliseconds or more — and for real-time applications like Teams voice and video, that delay is utterly destructive.

Microsoft’s Network Connectivity Principles

Microsoft publishes detailed guidance on how to optimise network connectivity for their cloud services. These are not vague suggestions — they are specific, measurable principles backed by extensive performance data. Every UK business running M365 should understand and implement them.

Principle 1: Identify and Differentiate M365 Traffic

Microsoft categorises all M365 network endpoints into three tiers: Optimise, Allow, and Default. This categorisation is critical because each tier requires different network treatment.

Category	Description	Endpoints	Recommended Treatment
Optimise	Most sensitive to network performance. Represents Teams media, Exchange Online, and SharePoint Online core traffic	~10 endpoints covering roughly 75% of M365 bandwidth	Bypass proxies, firewalls, and SSL inspection. Route directly to the internet via local egress
Allow	Important for M365 functionality but less sensitive to latency than Optimise traffic	~25 endpoints covering supporting M365 services	Can traverse proxies but should not be subject to SSL break-and-inspect
Default	General internet traffic that does not require special optimisation	All remaining M365-associated URLs	Treat as normal internet traffic through existing security stack

The key insight here is that you do not need to bypass your entire security infrastructure. Only the “Optimise” category — a small, well-defined set of endpoints — needs special treatment. This is a surgical change, not a wholesale abandonment of network security.

Principle 2: Allow Local Egress for M365 Connections

Every office should have a direct path to the internet for M365 traffic, rather than backhauling through a central location. This is the single most impactful change for multi-site organisations. When a user in your Birmingham office connects to Teams, their traffic should leave the building directly and reach Microsoft’s nearest front-door server — not travel to London first.

Principle 3: Avoid Network Hairpins

A “network hairpin” occurs when traffic is sent to an intermediate location that adds latency without adding value. Common hairpins in UK business networks include centralised proxy servers, cloud-based secure web gateways that route traffic to US data centres, VPN concentrators that force all traffic through a single tunnel, and DNS servers that resolve queries from a geographically distant location.

Principle 4: Ensure DNS Resolution Is Local

This is perhaps the most underappreciated optimisation. Microsoft uses DNS responses to direct your M365 traffic to the nearest front-door server. If your DNS resolver is in a different region to your users, Microsoft will route traffic to the wrong front door, adding significant latency.

For example, if your office is in Leeds but your DNS queries are resolved by a server in London, Microsoft may direct your M365 traffic to a London front door rather than a closer one. The fix is straightforward: ensure DNS resolution occurs as close to the user as possible.

Bandwidth Requirements for Microsoft 365

One of the most common questions UK businesses ask is “how much bandwidth do we need for Microsoft 365?” The answer depends heavily on which M365 services you use and how many concurrent users you have.

Bandwidth Consumption by Service

For a typical UK SME with 50 users, we generally recommend a minimum of 100 Mbps symmetrical dedicated internet connectivity, with 200 Mbps or above being ideal if Teams video conferencing is used heavily. Remember that M365 traffic must share your internet connection with all other cloud services, web browsing, and any other internet-dependent applications.

Bandwidth Planning Formula

A practical rule of thumb for planning M365 bandwidth is to assume that at peak times, roughly 30–40% of your users will be on Teams calls simultaneously, with another 20–30% actively syncing files or working in SharePoint. For a 50-user office, this translates to:

• 15–20 concurrent Teams calls (mix of audio and video): approximately 20–50 Mbps
• 10–15 users syncing files: approximately 5–20 Mbps
• 50 users with Outlook, background sync: approximately 5–10 Mbps
• Headroom for other internet traffic: 20–30 Mbps
• Total recommended: 80–110 Mbps minimum at peak

Always build in at least 30% headroom above your calculated peak requirement. Network performance degrades non-linearly as utilisation approaches capacity — once you regularly exceed 70% utilisation, latency and jitter spike dramatically.

Internet Connectivity Options for UK Businesses

The type of internet connection you use matters enormously for M365 performance. Not all broadband is created equal, and for cloud-dependent businesses, the cheapest option is rarely the most cost-effective.

For businesses with more than 20 M365 users, we strongly recommend a dedicated leased line as the primary connection, ideally with FTTP broadband as a failover circuit. The cost difference — typically £200–£400 per month for a 100 Mbps leased line versus £40–£80 for FTTP broadband — is insignificant compared to the productivity cost of unreliable connectivity.

Connection Type	Typical Speed	Contention	Monthly Cost	Installation Time	Best For
FTTC Broadband	40–80 Mbps down / 10–20 Mbps up	Up to 50:1	£30–£60	1–2 weeks	Micro-businesses (1–5 users)
FTTP Broadband	100–900 Mbps down / 50–115 Mbps up	Up to 20:1	£40–£120	1–3 weeks	Small offices (5–20 users)
Ethernet First Mile (EFM)	10–35 Mbps symmetrical	1:1	£150–£250	4–8 weeks	Offices needing guaranteed bandwidth on copper
Dedicated Leased Line	100 Mbps–10 Gbps symmetrical	1:1	£200–£800+	6–12 weeks	Businesses with 20+ M365 users
SD-WAN (bonded)	Variable, aggregated from multiple lines	Mixed	£250–£600	2–6 weeks	Multi-site businesses needing resilience

Optimising DNS for Microsoft 365

DNS resolution is the invisible foundation of M365 performance, yet it is one of the most frequently misconfigured elements. Every time a user opens Outlook, clicks a SharePoint link, or joins a Teams meeting, their device performs multiple DNS lookups to find the correct Microsoft server. If those lookups are slow or resolve to a suboptimal location, every subsequent operation is penalised.

DNS Best Practices

• Use local DNS resolvers — Your DNS resolver should be geographically close to your users. If you use a centralised DNS server at head office, branch office users may be directed to distant Microsoft front-door servers. Consider using well-peered public resolvers like Cloudflare (1.1.1.1) or Google (8.8.8.8) as forwarders at each site.
• Avoid DNS forwarding chains — Each additional hop in a DNS forwarding chain adds latency. Your local DNS server should resolve M365 domains directly, not forward to another internal server which then forwards to yet another.
• Disable DNS response caching manipulation — Some security appliances and proxy servers modify DNS TTL values or cache responses longer than intended. Microsoft uses short TTLs to dynamically route traffic, so tampering with these values degrades performance.
• Ensure split-DNS is correctly configured — If you use split-DNS (different resolution for internal versus external queries), verify that M365 domains are resolved externally, not intercepted by internal DNS zones.

Firewall and Proxy Configuration

Your firewall and proxy infrastructure is almost certainly the biggest bottleneck for M365 traffic. These devices were designed to inspect and filter internet traffic — a perfectly reasonable function for general web browsing. But subjecting latency-sensitive M365 traffic to deep packet inspection, SSL decryption, and proxy authentication creates devastating performance problems.

What to Bypass

Microsoft’s “Optimise” category endpoints should bypass the following network functions:

• SSL/TLS inspection — M365 traffic is already encrypted with TLS 1.2 or 1.3 between the client and Microsoft’s servers. Decrypting and re-encrypting this traffic adds 50–100ms of latency per connection and creates certificate trust issues, particularly for Teams.
• Web proxy servers — Forcing M365 traffic through a proxy server adds an extra network hop, proxy processing time, and authentication overhead. Many proxies also struggle with the volume of concurrent connections that M365 generates.
• Network intrusion detection/prevention — IDS/IPS inspection of M365 traffic adds latency with minimal security benefit, since Microsoft already operates extensive threat detection on their own network.
• Data loss prevention (DLP) appliances — If you need DLP for M365, use Microsoft’s built-in DLP capabilities within the M365 Compliance Centre rather than inline network DLP, which degrades performance.

Firewall Connection Capacity

A frequently overlooked issue is firewall connection table exhaustion. Microsoft 365 applications maintain numerous persistent connections — a single Outlook client can hold 20–30 concurrent connections, and Teams can use even more. A 50-user office might require 2,000–4,000 concurrent connections just for M365 traffic.

Many entry-level and mid-range firewalls from manufacturers like SonicWall, WatchGuard, and Fortinet have connection table limits that can be exhausted by M365 traffic, particularly during “thundering herd” scenarios when all users reconnect simultaneously (such as after a brief internet outage or at the start of the working day). When the connection table fills, new connections are dropped, and M365 applications fail unpredictably.

Check your firewall’s maximum concurrent session count and ensure it comfortably exceeds your estimated M365 connection requirements. As a rule of thumb, allow at least 50 concurrent sessions per M365 user for the firewall’s connection table.

Optimising for Microsoft Teams

Teams is by far the most network-sensitive M365 application. While Outlook and SharePoint can tolerate moderate latency with only minor user experience degradation, Teams voice and video calls deteriorate rapidly when network conditions are anything less than optimal.

Teams Network Requirements

Metric	Audio Calls	Video Calls (HD)	Screen Sharing	Large Meetings
Bandwidth (per user)	100–300 Kbps	2.5–4.0 Mbps	1.0–2.0 Mbps	4.0–8.0 Mbps
Latency (one-way)	< 50ms	< 50ms	< 50ms	< 50ms
Jitter	< 30ms	< 30ms	< 30ms	< 30ms
Packet Loss	< 1%	< 1%	< 1%	< 1%

Quality of Service (QoS) Configuration

Quality of Service is the practice of prioritising certain types of network traffic over others. For Teams, this means ensuring that voice and video packets are given priority over less time-sensitive traffic like file downloads or web browsing.

Microsoft recommends the following DSCP (Differentiated Services Code Point) markings for Teams traffic:

Traffic Type	Source Port Range	DSCP Value	DSCP Class
Audio	50000–50019	46	Expedited Forwarding (EF)
Video	50020–50039	34	Assured Forwarding (AF41)
Application Sharing	50040–50059	18	Assured Forwarding (AF21)

To implement QoS, you need to configure port ranges in the Teams admin centre, deploy Group Policy settings to mark packets with the correct DSCP values on Windows endpoints, and ensure your network switches and routers honour these markings. QoS is most effective on your internal LAN and across managed WAN connections — once traffic reaches the public internet, DSCP markings are typically stripped by ISPs.

Media Optimisation for Teams

Teams media traffic (voice, video, and screen sharing) uses UDP by default, which is more efficient for real-time communications than TCP. However, some corporate firewalls block or restrict UDP traffic, forcing Teams to fall back to TCP. This fallback significantly degrades call quality because TCP’s retransmission mechanism introduces additional latency.

Ensure your firewall allows outbound UDP traffic on ports 3478–3481 to Microsoft’s media relay servers. These connections use TURN and STUN protocols and are essential for optimal Teams media quality, particularly for calls that traverse NAT boundaries.

VPN and Remote Worker Optimisation

The shift to hybrid working means that a significant proportion of your M365 traffic now originates from home workers connecting via VPN. If your VPN is configured to tunnel all traffic through the corporate network (full tunnel), remote workers’ M365 performance will be dreadful — their traffic travels from home to your office, through your firewall, and out to the internet, adding substantial latency to every operation.

Split Tunnelling for M365

The solution is split tunnelling: configuring your VPN to send M365 traffic directly from the user’s device to Microsoft’s servers, while still routing corporate network traffic through the VPN tunnel. Microsoft classifies this as the single most impactful optimisation for remote workers and provides specific guidance on implementing it safely.

Split tunnelling for M365 is secure because:

• M365 traffic is encrypted end-to-end with TLS 1.2/1.3 — the VPN tunnel adds no meaningful additional security
• The traffic is destined for well-known, verified Microsoft IP ranges, not arbitrary internet destinations
• Microsoft provides regularly updated endpoint lists that can be used to define split tunnel rules precisely
• Microsoft’s own security infrastructure (Defender, Conditional Access, Azure AD) protects M365 access regardless of the network path

Most modern VPN solutions — including Cisco AnyConnect, Fortinet FortiClient, Palo Alto GlobalProtect, and Microsoft’s own Always On VPN — support split tunnelling based on destination IP ranges. Configure them to exclude Microsoft’s “Optimise” category endpoints from the VPN tunnel.

Wi-Fi Network Optimisation

In many UK offices, the wireless network is the weakest link in the M365 performance chain. Consumer-grade routers, poorly planned access point placement, and interference from neighbouring networks all contribute to unreliable Wi-Fi that cripples Teams calls and makes SharePoint sluggish.

Wi-Fi Best Practices for M365

• Use Wi-Fi 6 (802.11ax) or Wi-Fi 6E access points — These standards offer dramatically better performance in dense environments with many concurrent users, which is exactly the scenario in a modern office.
• Deploy enterprise-grade access points — Solutions from vendors like Ubiquiti, Cisco Meraki, Aruba, or Ruckus provide centralised management, seamless roaming between access points, band steering, and proper QoS support. A three-pack of enterprise APs (approximately £500–£1,200) will transform M365 performance compared to a single consumer router.
• Prioritise 5 GHz and 6 GHz bands — The 2.4 GHz band is chronically congested in UK office buildings. Configure band steering to push capable devices onto 5 GHz or 6 GHz, where there is more spectrum and less interference.
• Conduct a wireless site survey — Do not guess where to place access points. A professional site survey (or even a basic one using free tools like Ekahau HeatMapper) ensures adequate coverage without excessive overlap or dead zones.
• Enable WMM (Wi-Fi Multimedia) — This is the wireless equivalent of QoS. It prioritises voice and video traffic over bulk data transfers. Most enterprise access points enable this by default, but verify it is active.
• Separate IoT and guest devices — Printers, smart displays, and guest devices should be on separate VLANs and SSIDs to prevent them from consuming bandwidth and airtime that your M365 users need.

Monitoring and Troubleshooting M365 Network Performance

Optimisation is not a one-time project — it requires ongoing monitoring to identify and resolve issues before they impact users. Fortunately, Microsoft provides several powerful tools specifically for this purpose.

Built-In Microsoft Tools

• Microsoft 365 Network Connectivity Test (connectivity.office.com) — A free browser-based tool that tests your connection to Microsoft’s network from your current location. It measures latency, identifies the front-door server, checks DNS resolution, and provides specific recommendations.
• Microsoft 365 Admin Centre — Network Connectivity — Available under Health > Network Connectivity in the admin centre. This provides an ongoing network assessment score for each office location, based on aggregated telemetry from M365 clients in your organisation.
• Teams Call Quality Dashboard (CQD) — An essential tool for any organisation using Teams for voice and video. CQD provides detailed analytics on call quality, including metrics on packet loss, jitter, latency, and round-trip time. It can identify problematic subnets, locations, and even individual endpoints.
• Microsoft Service Health Dashboard — Before investigating your own network, always check whether Microsoft is experiencing service issues. The Service Health Dashboard in the M365 admin centre shows current and recent incidents affecting M365 services.

Third-Party Monitoring

For more comprehensive network visibility, consider tools like:

• PRTG Network Monitor — Monitors bandwidth utilisation, latency, and connection health across your network infrastructure. Particularly useful for identifying congestion points.
• ThousandEyes — Now part of Cisco, this provides end-to-end visibility into the network path between your offices and M365 data centres, including internet routing and ISP performance.
• ENow Mailscape — Specialised monitoring for Exchange Online that tracks mail flow, client connectivity, and synchronisation performance.

SD-WAN: A Modern Approach for Multi-Site Businesses

For UK businesses with multiple offices, Software-Defined WAN (SD-WAN) offers an elegant solution to many of the network challenges described in this guide. SD-WAN technology intelligently routes traffic across multiple internet connections based on application requirements, providing automatic failover, traffic prioritisation, and direct internet breakout at each site.

Key benefits of SD-WAN for M365:

• Automatic M365 traffic identification and prioritisation — leading SD-WAN platforms recognise M365 traffic and route it via the optimal path without manual configuration
• Local internet breakout — each site sends M365 traffic directly to the internet rather than backhauling through a central location
• Connection bonding and failover — combines multiple cheaper broadband connections for resilience, automatically rerouting traffic if one link fails
• Centralised policy management — network policies for all sites can be managed from a single dashboard
• Significant cost savings — SD-WAN can replace expensive MPLS circuits with commodity broadband while maintaining or improving performance

For a UK business with five branch offices, replacing MPLS with SD-WAN typically saves £2,000–£5,000 per month while delivering better M365 performance. The initial investment in SD-WAN appliances (approximately £500–£2,000 per site plus £50–£150 per site per month for licensing) pays for itself within months.

Implementation Roadmap: Priority Order of Optimisations

Not every optimisation carries equal weight. Based on our experience working with hundreds of UK businesses, here is the order in which we recommend implementing changes, ranked by impact and ease of implementation.

Common M365 Network Problems and Quick Fixes

Before embarking on a full network overhaul, check whether any of these common issues are affecting your environment. Many can be resolved in minutes.

Symptom	Likely Cause	Quick Fix
Teams calls break up or drop	Jitter or packet loss on Wi-Fi; UDP blocked by firewall	Switch to wired Ethernet for critical calls; ensure UDP 3478–3481 is open
Outlook is slow to sync	DNS resolving to distant Microsoft front door; proxy latency	Test with connectivity.office.com; bypass proxy for Optimise endpoints
SharePoint files take ages to open	Bandwidth contention; SSL inspection adding latency	Check bandwidth utilisation at peak times; exclude M365 from SSL inspection
OneDrive sync constantly pausing	Firewall connection table full; proxy authentication timeouts	Check firewall session count; bypass proxy for OneDrive traffic
Teams shows “poor network quality” warning	High latency (> 100ms) or packet loss (> 2%)	Run Teams network assessment tool; check for network congestion
M365 apps intermittently disconnect	ISP instability; dual-WAN failover misconfigured	Monitor ISP uptime; ensure failover does not change source IP
Remote workers report worse performance than office	Full-tunnel VPN; home broadband upload limitations	Implement split tunnelling for M365 traffic; advise on minimum home broadband specs

What About Copilot and AI Features?

As Microsoft rolls out Copilot and other AI-powered features across the M365 suite, network requirements are evolving further. These AI features rely on real-time communication with Microsoft’s cloud infrastructure, and their responsiveness is directly tied to network latency. While Microsoft has not published specific additional bandwidth requirements for Copilot, the latency and connection quality requirements are at least as stringent as those for Teams.

Organisations planning to adopt Copilot (currently priced at approximately £25 per user per month) should ensure their network optimisations are in place before deployment. There is little point investing in premium AI-powered productivity tools if your network cannot deliver the low-latency connectivity they need to function effectively.

Conclusion: Network Optimisation Is an Investment, Not a Cost

The gap between a poorly optimised and a well-optimised network for Microsoft 365 is not subtle. It is the difference between Teams calls that consistently work and calls that regularly fail. Between SharePoint that feels responsive and SharePoint that feels broken. Between staff who are productive and staff who spend their days waiting for applications to respond.

Most of the optimisations described in this guide cost nothing beyond knowledge and configuration time. DNS changes, proxy bypass rules, split tunnelling, and QoS settings are all configuration changes on equipment you already own. Even where investment is needed — a better internet connection, enterprise Wi-Fi, or SD-WAN — the return on investment is rapid when measured against the productivity cost of poor M365 performance across your entire workforce.

For UK businesses that have made Microsoft 365 central to their operations, network optimisation is not optional. It is the foundation on which your entire cloud productivity strategy rests. Get it right, and M365 delivers everything Microsoft promises. Get it wrong, and you will spend your days fielding complaints about slow email, dropped calls, and unreliable file access — none of which are Microsoft’s fault.