Microsoft 365 connection filter: how to use the IP Allow List safely

The IP Allow List is the oldest and bluntest way to tell Microsoft 365 "trust this server." It still works, and there are a few jobs it's right for. But Microsoft now ranks it fourth of five allow methods, and a common reason admins reach for it, a filtering gateway in front of Microsoft 365, is the one case where it does the most harm. This guide covers how it works, how to edit it, its limits and safer alternatives, at the time of writing (November 2026).

What is the connection filter policy in Microsoft 365?

The connection filter policy is a Microsoft 365 anti-spam policy that allows or blocks inbound email by the IP address of the server delivering it. Every tenant has it as a default policy named Connection filter policy (Default), which the Defender portal shows as Always on with priority Lowest. Microsoft Learn lists three parts:

• IP Allow List: "Skip spam filtering for all incoming messages from the specified source IP addresses or IP address ranges."
• IP Block List: "Block all incoming messages from the specified source IP addresses or IP address ranges." These messages are rejected, aren't marked as spam, and get no other filtering.
• Safe list: "a dynamic allowlist that requires no customer configuration," built from subscriptions to non-Microsoft lists. You can only turn it on or off; you can't see or edit the servers on it.

The connection filter works on the source IP, the address of the server that connected to Microsoft 365. It doesn't look at the From address at all. That makes it fast and simple, and also means anything sent through a listed server is trusted, no matter who it claims to be from.

What does the IP Allow List actually skip?

The IP Allow List skips spam filtering only. Microsoft is explicit: "All incoming messages are still scanned for malware and high confidence phishing." Microsoft's allowlist guidance adds that, without other verification such as mail flow rules, mail from these sources also skips sender authentication (SPF, DKIM and DMARC), which "creates a high risk of attackers successfully delivering email that would otherwise be filtered." Secure by default also means the bypass isn't guaranteed. Microsoft calls the allow list bypass "an input, not a final decision", which secure by default "evaluates" and "might not honor."

Microsoft also documents two cases where mail from a listed IP is still spam filtered, both about how Microsoft's datacenters are organized. If an IP in your list is also used in another organization's on-premises, IP-based inbound connector in the same datacenter forest, or the first server to handle the message is in a different forest from your tenant, filtering can still happen. The documented workaround is a mail flow rule that sets Bypass spam filtering for those IPs.

How to tell if the IP Allow List was applied

Open the message headers and find X-Forefront-Antispam-Report. Microsoft's anti-spam header reference defines two values that matter:

• IPV:CAL: "The message skipped spam filtering because the source IP address was in the IP Allow List."
• SFV:SKI: also means the source IP was on the IP Allow List.

An example header (values illustrative, address from the documentation range):

X-Forefront-Antispam-Report: CIP:203.0.113.25;CTRY:US;LANG:en;IPV:CAL;SFV:SKI;H:mail.example.net;DIR:INB;...

CIP is the connecting IP, which is exactly the address you'd add to the list. Paste a header into the Microsoft 365 Spam Header Decoder to read every field, or see Microsoft 365 spam headers explained.

When should you use the IP Allow List?

Use the IP Allow List only when a sender's mail is wrongly filtered, the sender doesn't authenticate its mail well, and it sends from IP addresses that belong to it alone. Microsoft's allowlist guidance ranks the options "from most recommended to least recommended":

Microsoft says to "only consider other allow methods" if you can't use the Tenant Allow/Block List for some reason. Reasonable cases for the IP Allow List:

• A partner's dedicated mail server or a line-of-business application with a fixed IP that you control or contract for, whose mail keeps landing in Junk.
• A sender that doesn't publish SPF, DKIM or DMARC, so an authenticated allow entry can't work. Microsoft suggests pairing a sender-domain mail flow rule with an IP Allow List entry for exactly this, and recommends "an IP address range of /24 or less (less is better)."

When not to use it:

• Shared or consumer infrastructure. Microsoft says: "Don't use IP address ranges that belong to consumer services (for example, outlook.com) or shared infrastructures." That covers bulk email platforms, shared web hosting and cloud provider ranges: anyone else on those IPs gets your trust too. See shared vs dedicated IPs.
• Phishing simulations and SecOps mailboxes. Use the advanced delivery policy.
• Your own devices sending to your users. Printers and apps that relay through Microsoft 365 should use a connector or SMTP submission; see scan to email in Microsoft 365.
• A filtering gateway in front of Microsoft 365. See the next section.

If you also run Google Workspace, its closest equivalent is covered in Google Workspace spam allowlists and approved senders.

Why shouldn't you add your email gateway's IPs?

If your MX record points to a filtering service that relays mail to Microsoft 365, every message arrives from the service's IPs. Putting those IPs on the IP Allow List tells Microsoft to skip spam filtering for all of it, including spoofed and phishing mail the gateway let through.

Worse, the safety net shrinks. Microsoft's secure by default page says secure by default "applies only when the MX record for your domain points to Microsoft 365." If MX points elsewhere, overrides including "source IP addresses allowed by the connection filter policy" "can result in the delivery of messages detected as high confidence phishing by anti-spam policies."

Microsoft's supported setup is different. Its anti-malware FAQ says that if you route mail elsewhere first, "you need to enable Enhanced Filtering for Connectors so Microsoft 365 can use the true message source in filtering decisions." Follow configuring Enhanced Filtering for Connectors, then block direct delivery to your tenant so attackers can't skip the gateway.

How do you add an IP to the IP Allow List?

In the Microsoft Defender portal

1. Go to Email & collaboration > Policies & rules > Threat policies > Anti-spam, or https://security.microsoft.com/antispam.
2. Select Connection filter policy (Default) by clicking the row, not the check box.
3. In the flyout, select Edit connection filter policy.
4. Under Always allow messages from the following IP addresses or address range, type an entry and press Enter. Valid formats: a single IP (192.168.1.1), a range (192.168.0.1-192.168.0.254) or a CIDR block with a mask from /24 to /32 (192.168.0.1/25). Microsoft's examples use private addresses; use the sender's real public IP.
5. Confirm the entry appears as a separate item, then select Save.
6. Leave Turn on safe list as you found it unless you have a reason to change it (see below).
7. Send a test message from the allowed server and check the headers for IPV:CAL.

Microsoft lists the permissions as Organization Management or Security Administrator to modify the policy. If an entry doesn't appear, refresh, or check in PowerShell.

With PowerShell

The cmdlet is Set-HostedConnectionFilterPolicy in Exchange Online PowerShell. Use the hash table form so you don't wipe the list:

# View the current lists
Get-HostedConnectionFilterPolicy -Identity Default | Format-List IPAllowList,IPBlockList,EnableSafeList

# Add one entry and remove an old one, keeping the rest (example addresses)
Set-HostedConnectionFilterPolicy -Identity Default -IPAllowList @{Add="203.0.113.10";Remove="198.51.100.7"}

# Empty the IP Allow List
Set-HostedConnectionFilterPolicy -Identity Default -IPAllowList $null

Microsoft warns that the plain form, -IPAllowList 192.168.1.10,192.168.1.23, will "overwrite any existing entries." Export the list before editing.

What are the IP Allow List limits?

These limits come from Microsoft's configuration page:

For ranges larger than /24 (masks /1 to /23), Microsoft documents a mail flow rule that sets Bypass spam filtering for the range, but adds, "we don't recommend using mail flow rules," and that messages are blocked anyway if an IP in the range is on Microsoft's or other blocklists. Trusting that much address space is rarely sensible.

To trust only some domains sent from one IP, Microsoft describes adding the IP to the allow list plus a mail flow rule that sets SCL 0 for that IP, except for the domains you trust. It then cautions that SCL 0 "might no longer reliably return those domains to filtering." Treat that pattern as unreliable.

What about the safe list and the IP Block List?

Turn on safe list lets a dynamic list, which Microsoft builds from "subscriptions to various non-Microsoft lists," skip spam filtering for its senders. You can't see or edit which servers are on it. In the portal it's a check box. The current Set-HostedConnectionFilterPolicy reference describes the EnableSafeList parameter only as "reserved for internal Microsoft use," and neither page states a default, so check your tenant's value with the PowerShell command above. Our advice, not a Microsoft recommendation: leave it off, because you can't audit what it trusts.

The IP Block List rejects all mail from listed IPs before any other filtering, and those messages "aren't available in message trace." That makes it hard to troubleshoot later. For one abusive server it's fine; for anything else, prefer the Tenant Allow/Block List. To check whether an IP is already on public blocklists, use the Blacklist Checker.

How do you audit an existing IP Allow List?

Inherited tenants often have years of entries nobody remembers. Microsoft says to "regularly review the entries in the IP Allow List" and remove the ones you no longer need. It also warns that if you allow an address behind a network address translation (NAT) gateway, you need to know every server in the NAT pool, because "IP addresses and NAT participants can change." Our suggested checklist:

1. Export the list with Get-HostedConnectionFilterPolicy.
2. For each entry, run a reverse DNS (PTR) lookup and record who owns it.
3. Remove any range belonging to a consumer mail service, a bulk email platform, a shared host or your own gateway.
4. Search message trace for recent mail from each IP. An entry with no traffic in 90 days is a candidate for removal.
5. Replace entries for senders who now pass DMARC with a Tenant Allow/Block List entry, or with no entry at all.
6. Write down an owner and a review date for each entry you keep.

Our anti-spam policies guide covers the inbound anti-spam settings that sit alongside the connection filter.

Next steps

• Check your connection filter today and look for gateway, shared or consumer ranges on the IP Allow List.
• If you use a filtering service, replace any allow entry for it with Enhanced Filtering for Connectors.
• Use the Microsoft 365 Spam Header Decoder to confirm why a specific message skipped or hit spam filtering.
• If you're adding a filtering layer in front of Microsoft 365, see how iBlockSpam connects to Microsoft 365 with an inbound connector rather than an allow list.