Governance & Security
From the field archive · Learned in 2020
From IP Allow-Lists to Service Tags: How Network Rules for Dynamics 365 Changed
Why the old "CRM IP list" stopped being the answer, how I helped firewall teams switch to Azure service tags, and what the network controls look like today.
In the summer of 2020 I kept getting the same email from firewall teams: "Our CRM IP whitelist needs updating. Where's the new list?" The honest answer was that the old Dynamics-specific IP article had been retired. The addresses were now Azure addresses, published as service tags, and that changed how the rules had to be written.
Microsoft Learn's "Power Platform URLs and IP address ranges" page now lists the service tags to allow. AzureCloud is needed for all Power Platform and Dynamics 365 services, with regional variants. PowerPlatformPlex covers Dataverse sandbox plug-ins calling external services, and PowerPlatformInfra represents the infrastructure that hosts Power Platform services. Learn says not to allowlist an environment's currently resolved IPs, because they change. IPv6 has been supported since April 2024. For inbound control there's now an IP firewall for Dataverse in Managed Environments. For private outbound traffic there's Azure Virtual Network support.
The requests haven't stopped in 2026. They've just moved to Copilot Studio and agents. This post is the 2020 version of the story. The 2026 follow-up is Your Network Team Wants an IP List. Here's What to Give Them Instead.
01Why the old IP list went away
Dynamics 365 runs on shared Azure infrastructure. The addresses it uses belong to Azure regions, not to your organization, and they change as Microsoft adds capacity. A hand-maintained list of "CRM IPs" was always going to go stale.
Service tags fix the maintenance problem. A service tag is a named group of IP prefixes that Microsoft manages and updates. You can use it directly in Azure network security groups, Azure Firewall and some Azure services, or pull the ranges into an on-premises firewall.
What service tags don't fix is trust. Learn says plainly that in most scenarios you shouldn't allow traffic from all Azure IPs, because those ranges include other Azure customers. A tag tells you traffic came from a region of Azure. It doesn't tell you it came from your tenant.
An allow-list built on shared cloud ranges is a coarse filter. Authentication is still the lock on the door.
02The requests I answered in 2020 and 2021
Looking back at my mail, the requests fell into a few patterns. My answers were short. The thinking behind them is what I'd keep.
| The request | What I told them |
|---|---|
| "Update our CRM IP whitelist." | The old IP article is retired and the addresses are Azure-based. Use the downloadable Azure IP Ranges and Service Tags file instead. |
| "Which IPs do our Dynamics organizations use?" | Try the regional AzureCloud tags for the region where your environments live, rather than the global tag. |
| "We want to restrict our Azure app to Dynamics traffic." | Use the app's access restrictions with service tags instead of pasting in every IP. Then talk about what else should protect it. |
| "Approve this firewall request for a project." | Which cloud solution needs it, and where does it run? If it isn't in Azure, it needs the IP ranges and the URLs for the portal and the environment. |
| "What ranges does Azure DevOps use?" | Azure DevOps publishes its own allowed IP and URL guidance. Don't assume Dynamics ranges cover it. |
| "Our connection keeps failing." | Check whether the published ranges are actually allowed before debugging the app. |
An enterprise customer had built an integration on Azure App Service and wanted it to accept calls only from Dynamics 365. Their plan was to paste every published IP range into the app's rules. I pointed them to App Service access restrictions, which accept service tags, and to the service tags overview. The catch: there was no Dynamics-specific tag for that traffic. The closest fit was regional AzureCloud, which is broad. So I brought in an Azure networking specialist to talk through the use case with them. What I took from it: when the only tag that fits is that broad, the network rule can't be the main control. The endpoint needs its own authentication, and the IP rule becomes a second layer.
A customer's project team sent over a firewall request with no context. I wrote back that I didn't understand it yet: which cloud solution needs this, and where is it hosted? In my experience, half of these requests go away once you ask that. The other half become much smaller, because you're opening one direction for one system, not "everything Dynamics."
03Then vs now
| Topic | 2020 | 2026 |
|---|---|---|
| Where the ranges live | Azure IP Ranges and Service Tags JSON file | Same file, published weekly, plus the Service Tag Discovery API |
| Which tag for Dynamics 365 | Regional AzureCloud, in practice | Learn lists AzureCloud for all services, plus AzureSignalR, MicrosoftAzureFluidRelay, OneDsCollector and PowerPlatformPlex for specific features |
| Platform-specific tags | Limited | PowerPlatformInfra and PowerPlatformPlex, both with regional scope |
| IP versions | IPv4 | IPv4 and IPv6. IPv6 ranges are in the service tag files. |
| Restricting who reaches Dataverse | Conditional Access and the customer's own network | IP firewall for Dataverse in Managed Environments, with audit-only mode |
| Private outbound calls | On-premises data gateway | Azure Virtual Network support, plus the gateway |
04Using service tags properly
If your firewall needs IP-based rules, service tags are still the right source. Here's how I recommend using them.
- Use the regional tag. Pick the tag for your environment's Azure region, for example AzureCloud.<region>, not the global one. Note that a few regions use non-standard names in the file.
- Automate the refresh. The JSON files are updated weekly. Each tag has a changeNumber that increases when its ranges change. New addresses aren't used in Azure for at least a week, which gives an automated job time to catch up. A manual copy-paste won't keep up.
- Prefer the API where you can. Learn treats the Service Tag Discovery API as the source of truth. It can lag the file by up to four weeks for new tags.
- Don't allowlist resolved IPs. Learn is explicit: an environment's current IP addresses can change. Allow the published tag ranges instead.
- Include IPv6. If your network prefers IPv6, rules that only cover IPv4 will fail in confusing ways.
- Keep authentication on the endpoint. The tag is shared with other tenants in that region.
AzureCloud is very broad. Allowing it inbound to a sensitive endpoint lets in a large share of Azure. If that's your only control, you haven't really restricted anything. Use it for outbound proxy rules and user-side connectivity, and look at the private options below for anything sensitive.
05Inbound: the IP firewall
IP firewall for Dataverse
The question in 2020 was usually "how do we let Dynamics reach us?" The reverse question, "how do we make sure only our offices reach Dynamics?", now has a native answer. The IP firewall checks the source address of every request to Dataverse in real time and rejects anything outside your allowed ranges. It covers interactive and non-interactive access, so a stolen token used from another network gets blocked.
What to know before you turn it on
- It's a Managed Environments feature, and there are additional licensing requirements. Check the current Learn article.
- Audit-only mode is on by default when you set it up. Learn recommends running it for at least a week and reviewing the logs before enforcing.
- You can allow up to 200 ranges in CIDR format, including IPv6, and choose service tags that bypass the restriction.
- Leave "Microsoft trusted services" and "all application users" allowed unless you've tested without them. Turning both off can break things like Power Automate flows.
- If flows stop working after you enable it, allow the managed connector service tags.
- You can configure it once at the environment group level.
06Outbound: where to go next
Most of my 2020 conversations were about outbound traffic: Dynamics, plug-ins or connectors calling a customer's system behind a firewall. In 2020 the main options were service tag rules or the on-premises data gateway. Today there's a better default for many cases: Azure Virtual Network support. You delegate a subnet in your own VNet, supported workloads call out from it, and an Azure NAT gateway gives partners one public IP address that you own.
I cover VNet support, the gateway, tenant isolation and endpoint filtering in detail in the 2026 follow-up, Your Network Team Wants an IP List. For where network rules fit alongside data policies and environment strategy, see Environment Strategy and DLP: What I Recommend.
07Checklist
- Retire any hand-maintained "Dynamics IP list" and any rules based on resolved environment IPs.
- Use regional service tags from Learn's Power Platform IP page, refreshed automatically.
- Cover IPv6 as well as IPv4.
- For every firewall request, write down the system, the direction and who owns it.
- Put authentication on every endpoint that accepts traffic from cloud ranges.
- Pilot the Dataverse IP firewall in audit-only mode for at least a week, then enforce.
- Evaluate VNet support for private or fixed-IP outbound needs.
Where I'd start
Find the oldest firewall rule that mentions Dynamics or CRM and ask who owns it and what it's for. If it's a static list, replace it with regional service tags and a scheduled refresh. Then decide whether you actually need an inbound filter on Dataverse, and if so, turn on the IP firewall in audit-only mode. The question I asked in 2020 still works: which system, which direction, and where does it run?
Happy to go deeper on any of this.
— K.G
→ Read the 2026 follow-up: "Your Network Team Wants an IP List"
Sources
- Microsoft Learn: Power Platform URLs and IP address ranges (updated Aug 2026)
- Microsoft Learn: Azure service tags overview (updated Sep 2026)
- Microsoft Learn: IP firewall in Power Platform environments
- Microsoft Learn: Azure App Service access restrictions
- Microsoft Learn: Allowed IP addresses and domain URLs (Azure DevOps)
- Microsoft Learn: Microsoft Azure Virtual Network support overview
Get new posts by email
Provider: your email provider
