Troubleshooting Microsoft 365 with DNS Filtering

Step 1: Why Microsoft 365 Is Affected by DNS Filtering

Microsoft 365 is not a single service running on a single domain. It is a massive ecosystem of interconnected services — Teams, SharePoint, OneDrive, Exchange Online, Outlook, Azure AD authentication, and more — each relying on dozens of domains and CDN endpoints. Microsoft publishes over 150 unique FQDNs and hundreds of IP ranges required for M365 to function.

This creates a unique challenge for DNS filtering:

• Frequent domain changes: Microsoft adds, removes, and rotates domains regularly. A domain that did not exist yesterday may be required for Teams to connect today. If a new domain has not been categorized yet, it may be blocked by default depending on your filter configuration.
• CDN and third-party domains: M365 services load resources from Akamai, Azure CDN, and other third-party infrastructure. These CDN domains serve multiple customers, and their categorization can be ambiguous — they may appear as "uncategorized" or even miscategorized.
• Authentication chains: Signing into any M365 service triggers a chain of DNS lookups across login.microsoftonline.com, login.live.com, Azure AD endpoints, and conditional access policy servers. If any link in this chain is blocked, authentication fails — often with vague error messages.
• Intermittent symptoms: Because M365 uses connection pooling and caching, issues may appear intermittent. A cached token works until it expires, then the renewal fails because the authentication domain is blocked. This creates the pattern of "it works sometimes but not always."

Step 2: Identify Which M365 Domains Are Blocked

The first step is determining whether DNS filtering is the cause and which specific domains are being blocked.

Check the CleanBrowsing Dashboard

If you have a paid CleanBrowsing account:

1. Log into your CleanBrowsing dashboard.
2. Navigate to Activity > Blocked Requests.
3. Filter by the time window when M365 issues occurred.
4. Search for Microsoft-related domains: microsoft, office, sharepoint, teams, outlook, live.com.

Any Microsoft domains appearing in the blocked list are your culprits.

Compare DNS Resolution

Test key M365 domains against CleanBrowsing and a public resolver side by side:

# Windows Command Prompt
nslookup outlook.office365.com 185.228.168.168
nslookup outlook.office365.com 8.8.8.8

# PowerShell — compare both resolvers
$domains = @(
    "outlook.office365.com",
    "login.microsoftonline.com",
    "teams.microsoft.com",
    "*.sharepoint.com"
)
foreach ($d in $domains) {
    $cb = (Resolve-DnsName -Name $d -Server 185.228.168.168 -ErrorAction SilentlyContinue).IPAddress
    $google = (Resolve-DnsName -Name $d -Server 8.8.8.8 -ErrorAction SilentlyContinue).IPAddress
    Write-Host "$d"
    Write-Host "  CleanBrowsing: $($cb -join ', ')"
    Write-Host "  Google DNS:    $($google -join ', ')"
    Write-Host ""
}

# macOS / Linux
for domain in outlook.office365.com login.microsoftonline.com teams.microsoft.com; do
    echo "--- $domain ---"
    echo "CleanBrowsing: $(dig +short @185.228.168.168 $domain)"
    echo "Google DNS:    $(dig +short @8.8.8.8 $domain)"
    echo ""
done

If a domain returns an IP through Google DNS but returns NXDOMAIN, a block page IP, or no response through CleanBrowsing, that domain is being filtered.

Step 3: Test M365 Connectivity from the Command Line

Microsoft provides a connectivity test tool, and you can also use built-in OS tools to diagnose specific services.

Test Teams Connectivity

# PowerShell — test Teams signaling endpoint
Test-NetConnection -ComputerName teams.microsoft.com -Port 443

# Test Teams media relay
Test-NetConnection -ComputerName 13.107.64.2 -Port 3478 -InformationLevel Detailed

# Resolve Teams-specific domains
Resolve-DnsName -Name teams.microsoft.com -Server 185.228.168.168
Resolve-DnsName -Name api.teams.skype.com -Server 185.228.168.168
Resolve-DnsName -Name teams.cdn.office.net -Server 185.228.168.168

Test SharePoint / OneDrive

# Replace "yourtenant" with your actual tenant name
# PowerShell
Test-NetConnection -ComputerName yourtenant.sharepoint.com -Port 443
Resolve-DnsName -Name yourtenant.sharepoint.com -Server 185.228.168.168
Resolve-DnsName -Name yourtenant-my.sharepoint.com -Server 185.228.168.168

# Command Prompt
nslookup yourtenant.sharepoint.com 185.228.168.168
nslookup yourtenant-my.sharepoint.com 185.228.168.168

Test Exchange Online / Outlook

# PowerShell
Resolve-DnsName -Name outlook.office365.com -Server 185.228.168.168
Resolve-DnsName -Name outlook.office.com -Server 185.228.168.168
Resolve-DnsName -Name attachments.office.net -Server 185.228.168.168

# Test SMTP (email delivery)
Resolve-DnsName -Name yourdomain.com -Type MX -Server 185.228.168.168

# Verify MX points to Microsoft
# Expected: yourdomain-com.mail.protection.outlook.com
nslookup -type=MX yourdomain.com 185.228.168.168

Test Authentication

# These domains must resolve for any M365 login to work
# PowerShell
$authDomains = @(
    "login.microsoftonline.com",
    "login.live.com",
    "login.windows.net",
    "aadcdn.msauth.net",
    "aadcdn.msftauth.net"
)
foreach ($d in $authDomains) {
    $result = Resolve-DnsName -Name $d -Server 185.228.168.168 -ErrorAction SilentlyContinue
    if ($result) {
        Write-Host "[OK]    $d -> $($result.IPAddress -join ', ')" -ForegroundColor Green
    } else {
        Write-Host "[BLOCK] $d -> No response" -ForegroundColor Red
    }
}

# macOS / Linux
for domain in login.microsoftonline.com login.live.com login.windows.net aadcdn.msauth.net aadcdn.msftauth.net; do
    result=$(dig +short @185.228.168.168 $domain)
    if [ -n "$result" ]; then
        echo "[OK]    $domain -> $result"
    else
        echo "[BLOCK] $domain -> No response"
    fi
done

Step 4: Key Microsoft 365 Domains

The following domains are critical for M365 to function. If any of these are blocked, expect service disruptions. Use this as a reference when troubleshooting and allowlisting.

Authentication (Required for All M365 Services)

Teams

Exchange Online / Outlook

SharePoint / OneDrive

Shared Infrastructure

For the complete, up-to-date list of M365 endpoints, Microsoft maintains an official reference at Microsoft 365 URLs and IP address ranges in their documentation. This list is updated monthly and includes all required and optional endpoints organized by service.

Step 5: Allowlist M365 Domains in CleanBrowsing

Once you have identified the blocked domains, add them to your CleanBrowsing allowlist. See our dedicated How to Allowlist Domains guide for step-by-step dashboard instructions.

Recommended Approach

Rather than allowlisting individual FQDNs one at a time, we recommend allowlisting the top-level Microsoft domains that cover the broadest range of M365 services:

1. Log into your CleanBrowsing dashboard.
2. Navigate to Filters > Custom Allow List.
3. Add the following domains:

   login.microsoftonline.com
   login.live.com
   login.windows.net
   outlook.office365.com
   outlook.office.com
   teams.microsoft.com
   api.teams.skype.com
   attachments.office.net
   smtp.office365.com

4. If your organization uses SharePoint, also add your tenant-specific domains:

   yourtenant.sharepoint.com
   yourtenant-my.sharepoint.com

5. Click Save.
6. Clear your DNS cache on affected devices.

Flush DNS After Allowlisting

Changes take effect on CleanBrowsing's side almost immediately, but your devices may have cached the old (blocked) response. Flush the cache to force a fresh lookup:

# Windows Command Prompt
ipconfig /flushdns

# PowerShell
Clear-DnsClientCache

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

Step 6: Verify the Fix

After allowlisting and flushing DNS, confirm that M365 services are working correctly.

Quick Verification Script

# PowerShell — verify all critical M365 domains resolve through CleanBrowsing
$domains = @(
    "login.microsoftonline.com",
    "login.live.com",
    "outlook.office365.com",
    "teams.microsoft.com",
    "api.teams.skype.com",
    "attachments.office.net"
)

$allGood = $true
foreach ($d in $domains) {
    $result = Resolve-DnsName -Name $d -Server 185.228.168.168 -ErrorAction SilentlyContinue
    if ($result.IPAddress) {
        Write-Host "[PASS] $d -> $($result.IPAddress[0])" -ForegroundColor Green
    } else {
        Write-Host "[FAIL] $d -> NOT RESOLVING" -ForegroundColor Red
        $allGood = $false
    }
}

if ($allGood) {
    Write-Host "`nAll M365 domains are resolving correctly through CleanBrowsing." -ForegroundColor Cyan
} else {
    Write-Host "`nSome domains are still blocked. Check your allowlist." -ForegroundColor Yellow
}

Test Actual Service Connectivity

# PowerShell — test HTTPS connectivity to key M365 endpoints
$endpoints = @(
    @{Name="Outlook"; Host="outlook.office365.com"; Port=443},
    @{Name="Teams"; Host="teams.microsoft.com"; Port=443},
    @{Name="Auth"; Host="login.microsoftonline.com"; Port=443}
)

foreach ($ep in $endpoints) {
    $test = Test-NetConnection -ComputerName $ep.Host -Port $ep.Port -WarningAction SilentlyContinue
    if ($test.TcpTestSucceeded) {
        Write-Host "[PASS] $($ep.Name) ($($ep.Host):$($ep.Port))" -ForegroundColor Green
    } else {
        Write-Host "[FAIL] $($ep.Name) ($($ep.Host):$($ep.Port))" -ForegroundColor Red
    }
}

Ongoing Monitoring

Because Microsoft regularly adds new domains to the M365 ecosystem, intermittent issues may resurface when a new domain appears that has not yet been categorized. If M365 issues return after a period of working correctly:

• Check the CleanBrowsing dashboard for newly blocked Microsoft-related domains.
• Add the new domain to your allowlist.
• Contact support@cleanbrowsing.org with the blocked domain so we can update our categorization — this helps all CleanBrowsing users, not just your network.