There is an alert most Microsoft 365 teams have quietly stopped reading.
It fires in the morning. A user in Warsaw, or Manchester, or Lisbon appears to have opened a document from a datacenter in Virginia. Sometimes Washington. Sometimes Dublin, Singapore and all four in the same hour. You check with the user. They were at their desk. You close the ticket.
Then it fires again the next morning, for someone else.
Eventually somebody adds an exception, or drops the severity, or moves the rule to a dashboard nobody opens. That is the real damage. Not the wasted hour, but a whole category of detection getting switched off because it produced garbage.
The garbage has a specific cause, and your rule isn't it.
Microsoft's own infrastructure is in your logs
A Microsoft 365 audit event carries an address field. Most tools read it as "the IP of the person who did this."
For a large share of events it isn't. It's the address of the Microsoft server that carried out the operation.
This isn't a bug. It follows from how the platform works. A lot of what happens in a tenant is not a user pressing a button in a browser. It's a service acting on a user's behalf, in a datacenter, sometimes well after the fact:
- Server-side mailbox operations. Permission changes, delegate access, retention actions, and rules that run in the service rather than in Outlook.
- Background SharePoint and OneDrive work. Sync-driven changes, service-initiated moves, and operations that finish after the user's session has ended.
- Copilot and AI interactions. The user types a prompt. A service reads the files. The read gets recorded from wherever that service runs.
- Compliance machinery. eDiscovery, retention, DLP evaluation and legal hold, all of which run entirely inside Microsoft.
- Application and daemon activity. Anything acting with application permissions has no user IP to record, because there was no user connection in the first place.
In every one of those cases, the honest answer to "where did this come from?" is "a Microsoft datacenter." That happens to be true. It just isn't the answer your detection was asking for.
What it does to your detections
The damage isn't spread evenly. It lands on exactly the detections people care about most.
Impossible travel turns into noise. The classic check compares two events and asks whether a human could have moved between them in the time available. Feed it one real sign-in from Warsaw and one relayed event from Virginia and it reports a transatlantic flight in four minutes, every day, for every user who has a mailbox rule or uses Copilot. The detection is working fine. Its inputs are wrong.
Geo-fencing inverts. A rule that says "alert on activity outside our operating countries" becomes a rule that alerts on Microsoft. The countries in your allow-list are the ones your staff sit in. The countries Microsoft serves your tenant from can be completely different, and they change.
Enrichment costs money. If you ship audit logs to a SIEM with paid geo-IP enrichment, you're paying to resolve Microsoft's own address ranges over and over, then paying again to store the result.
And then the worst outcome, which is suppression. The natural response to a noisy geographic rule is to suppress datacenter traffic, or foreign traffic, or both. That is the exact suppression an attacker benefits from. Credential theft gets operated from wherever the attacker is, and more and more often that means a hosting provider. Which is to say, a datacenter.
You end up with the one filter you can't afford: a rule that hides the real thing because it was tuned to hide the fake one.
Why "just ignore datacenter IPs" is the wrong fix
It's the obvious fix and it's a trap.
Nothing in the shape of an address distinguishes "Microsoft's datacenter" from "a datacenter." Both are hosting infrastructure. Both sit far from your office. Both resolve to a country you don't operate in. A suppression written by hand on Tuesday, based on the addresses you happened to see last week, covers a fraction of the ranges and then expires quietly without telling anyone.
Two different things have to be separated, and only one of them can be suppressed:
| What you see | What it means | What to do |
|---|---|---|
| Microsoft's own infrastructure | The platform acted on a user's behalf | Label it. Never read it as the user's location |
| Any other hosting provider | Something ran from rented infrastructure | Investigate. This is a real signal |
That distinction is the entire job. Collapse it and you either drown in false positives or blind yourself to the true ones.
The two things that actually fix it
First, recognise Microsoft's infrastructure properly.
Microsoft publishes its service address ranges. They cover IPv4 and IPv6, and they change. Recognising them means maintaining that list, not hard-coding six prefixes someone pasted into a rule two years ago. Traffic that matches gets labelled as what it is, platform origin, and shown neutrally rather than as suspicious foreign hosting. It stays visible. It just stops pretending to be a person.
Second, use Microsoft's own location signal when it's there.
This is the part most teams don't know about, and it's the more valuable half.
Microsoft often records the user's real country alongside the relayed address. The connection came from a Microsoft server. The record still knows which country the user was in. Where that signal exists it beats the address, because the address describes the relay and the signal describes the human.
The effect is immediate. A file previewed by someone sitting in Poland reads as Poland, even though the underlying connection came from a Microsoft server in the United States. The daily phantom alert stops firing, and it stops for the right reason: you now know where the user was, rather than having told the rule to look away.
The line you must not cross
There's a version of this fix that makes things much worse, and it's easy to write by accident.
Don't build anything that reasons "foreign-looking activity is probably just Microsoft." The fix has to key on Microsoft's infrastructure, meaning specific, maintained, verifiable ranges, and on Microsoft's explicit location signal. It must never key on "this looks like a datacenter" or "this country is unusual," because a real sign-in from an unexpected country is the compromise you're trying to catch.
The test is simple and worth running against whatever you build. If an attacker signed in to one of your accounts from a rented server in another country right now, would your relay handling hide it? Anything other than a flat no means you've written a suppression rule with a nicer name on it.
What good looks like
A short checklist you can run against your current setup this week.
- Count it first. Over the last thirty days, what share of your audit events carry an address inside Microsoft's own ranges? On most tenants the number surprises people, and it tells you how much of your geographic detection has been running on relay noise.
- Label, don't drop. Platform-origin events are legitimate evidence of what the service did on a user's behalf. Keep them, mark them, and exclude them from location logic only.
- Check whether you're already receiving the country signal. If your pipeline flattens audit records to a fixed set of columns, the real-country field is often the one that gets dropped on the way in. It's free and you may already be throwing it away.
- Turn the detection back on. Impossible travel and geo-fencing are good detections and they were never the problem. Once the inputs are clean, re-enable them and watch the volume. It should fall by an order of magnitude, and the survivors should be worth reading.
- Separate "Microsoft" from "datacenter" in every view. If your tooling shows one badge for both, you can't triage. They point to opposite conclusions.
How 1Security handles it
Location Intelligence resolves every action's network address into a stable place: country, city, and the network that owns the connection. It does both of the things above by default.
Microsoft's own networks are recognised across IPv4 and IPv6 and labelled as Microsoft origin, styled neutrally rather than as suspicious hosting. Where Microsoft supplies the user's real country alongside a relayed address, that signal is trusted over the relay, so the event reads as the country the person was actually in.
Everything else keeps its edge. A sign-in through a commercial VPN, the Tor network or a hosting provider gets classified as exactly that, on the user's activity, where it's one of the strongest early indicators of a stolen session. No rule to write, and no suppression that could hide it.
It runs on a standard Microsoft 365 licence. Enrichment happens locally and privately, so no IP data goes to a third-party lookup service, and there's no E5, Entra ID P2 or premium sign-in log prerequisite.
Frequently asked questions
Does this mean my audit logs are unreliable? No. They're precise about what they record. The mistake is reading one field as something it never claimed to be. The address field describes the connection that performed the operation, and sometimes that connection belongs to Microsoft.
Which operations are affected? Broadly, anything that runs server-side rather than inside a user's session: mailbox permission and rule changes, background SharePoint and OneDrive activity, Copilot interactions, compliance and retention machinery, and anything running with application permissions. Interactive browser sign-ins usually carry the real client address.
Can I just filter these events out of my SIEM? You can, and you'll lose real evidence. They record genuine actions on real data. Label them and exclude them from location logic. Don't delete them.
Does Microsoft always tell me the user's real country? No. Often, not always. When the signal is missing, the honest answer is that the location for that event is undetermined. Reporting it as unknown is correct. Inventing a location from the relay address isn't.
Does fixing this need premium licensing? No. Recognising Microsoft's address ranges and reading a field that already sits in the records you receive costs nothing beyond the engineering to do it properly.
