Verify Bingbot IP Addresses
Against Reverse DNS and Microsoft's Published List

Why Do Microsoft's Own Checks Disagree About Bingbot?

Most crawler operators give you one way to verify. Microsoft gives you three, which sounds generous until they return different answers about the same address.

1. The documented reverse DNS procedure. Resolve the address, confirm the hostname ends in search.msn.com, then forward-resolve that hostname and confirm it returns the address you started with.
2. The published range file at bing.com/toolbox/bingbot.json.
3. The Verify Bingbot tool, a web form where you paste an address and Microsoft returns a verdict. It exists in two places — the public URL, and inside Bing Webmaster Tools under Diagnostics & Tools — and both return the same answer.

One note on sourcing before the interesting part. Microsoft's verification help page renders entirely in JavaScript, so it cannot be read by a plain fetch and could not be quoted directly here. The two-step procedure above is taken from Microsoft's own community forum, where its guidance is reproduced verbatim, and cross-checked against the behaviour of the published range file. Where this page says "Microsoft documents", that is the chain.

Site owners have reported traffic from 40.77.202.0/24 that fails the first check outright — no usable hostname comes back at all — while the same subnet appears in the published file and is accepted as a valid Bingbot address by Microsoft's own tool. That subnet is still in the file today; it was confirmed present when this page was written.

Which one should you trust?

Neither, exclusively — but the shape of the evidence is not symmetrical.

A reverse DNS pass is conclusive on its own. Nobody outside Microsoft can make its nameservers resolve a search.msn.com hostname to an address Microsoft does not control, so when that check passes the question is settled regardless of what the list says. This tool treats it that way.

A reverse DNS failure is much weaker than it looks, because it fails in several ordinary ways: a subnet with no PTR records configured, a slow authoritative nameserver, a resolver that timed out. None of those mean forgery. Meanwhile the published list is Microsoft's own written statement about its own infrastructure — stale, but deliberate.

So the working rule is: pass on either check and you can act on it; fail on one while passing the other and you should look at behaviour rather than reach for a firewall rule. For the general method behind all of this, applied across nineteen operators, the universal bot verifier explains forward-confirmed reverse DNS in full.

The list is current-state, not historical

Worth knowing if you are working through old logs. The published file describes the addresses Microsoft uses now. An address Bingbot used last year and has since given up does not appear in it, and this tool will report it as not on the list — which is true, and misleading, at the same time.

For a request that arrived this morning that distinction does not matter. For a log entry from eighteen months ago it matters a great deal, and no free tool solves it: identifying a retired crawler address needs a historical record that nobody publishes openly. If your analysis depends on old entries, treat a miss on an old timestamp as unresolved rather than as a finding.

One more thing about the list: it carries a creation date of 3 January 2024 and has not been revised since. That is over two and a half years, and the stalest published crawler file of any major operator. Google's equivalent changes within days. A Bingbot IP that is missing from a file that old is barely evidence of anything.

What Should You Do Instead of Blocking Bingbot?

Almost every request to block Bingbot is really a request to reduce crawl load, and Microsoft gives you two ways to do that without leaving the index.

Crawl-delay in robots.txt

Bingbot honours the Crawl-delay directive, which Google ignores entirely. It is a non-standard extension, so support varies by crawler, but where it is honoured it is the simplest lever available — a single line telling the crawler to wait between requests.

Crawl Control in Bing Webmaster Tools

The more precise option, under Configuration → Crawl Control in Bing Webmaster Tools. It lets you set crawl rates per hour of the day, so you can push Bingbot's activity into your quiet periods rather than throttling it uniformly. That matters if your load problem is concentrated rather than constant.

When one address at a time is not enough

The most common complaint about every Bingbot verifier, Microsoft's included, is that it takes one address. A blocklist review or a week of log analysis produces hundreds, and clicking through them individually is not a plan. Microsoft's tool has no public API, so there is nothing to automate against.

A dedicated bulk verifier is the right answer and it is on our build list rather than live, so this page is not going to pretend otherwise or send you to a page that does not exist yet. Two things help in the meantime. Paste the CIDR range into the tool above rather than individual addresses — crawler traffic clusters into subnets, so one range check often settles dozens of log lines at once. And check the user-agent string alongside the address, because a forged request usually gets one of the two wrong.

Submit a sitemap rather than waiting

Throttling reduces how often Bingbot arrives, which makes it matter more that it finds the right pages when it does. Submitting an XML sitemap through Bing Webmaster Tools, or referencing it from robots.txt, points the crawler straight at what you want indexed instead of leaving it to discover pages by following links. On a throttled crawl budget that difference is the whole game.

Keeping AI crawlers out is a different job from reducing load. The crawler blocker builds robots.txt and firewall rules from live vendor ranges, and it treats search crawlers separately from training ones for exactly the reasons set out above.

And if you are auditing more than Microsoft, the sibling pages cover the operators whose rules work differently: Googlebot across five categories, OpenAI's four separate crawlers, and Perplexity, where a non-match means three different things.