Ten Free Tools for IP, DNS and Email Checks

Six new free tools are live on reportedip.com: reverse DNS with forward confirmation, an RDAP abuse contact finder, an HTTP security header check, crawler verification, an ASN and network report, and MTA-STS, TLS-RPT and BIMI inside the existing email check. That makes ten free tools, none of which needs an account.

All ten are listed at reportedip.com/tools. The rest of this post is about the four checks behind them that are easy to implement and easy to implement wrong.

What the six new tools do

Tool	Input	What it answers
Reverse DNS	IPv4, IPv6 or hostname	Does the PTR record survive a forward check
Abuse Contact	IP or domain	Which mailbox is responsible for this address
Security Headers	Domain or URL	Which directive to change, weighted by effect
Bot Verification	IP, optional User-Agent	Is the self-declared crawler the real one
ASN Report	IP or AS number	How the whole network behaves, not one address
Email Security	Domain	SPF, DKIM, DMARC, DNSSEC, MTA-STS, TLS-RPT, BIMI

Why one A record is not enough for reverse DNS

A PTR record on its own proves nothing. Anyone who controls an address block can publish any name there, including mail.yourbank.com. The check that carries weight is forward-confirmed reverse DNS: resolve the PTR name back to addresses and see whether the original address is among them.

The common implementation error is to compare against the first A record only. Measured on 2026-09-20, 8.8.8.8 has the PTR name dns.google, and that name resolves to four addresses:

8.8.8.8      -> dns.google -> 8.8.8.8, 8.8.4.4,
                              2001:4860:4860::8888, 2001:4860:4860::8844
8.8.4.4      -> dns.google -> same four addresses
66.249.66.1  -> crawl-66-249-66-1.googlebot.com -> 66.249.66.1

A tool that stops at the first answer reports 8.8.4.4 as unconfirmed, because DNS returned 8.8.8.8 first. The full A and AAAA set has to be compared, and the comparison belongs in binary form through inet_pton(), never as a string. 2001:db8::1 and 2001:0db8:0000:0000:0000:0000:0000:0001 are the same address and differ in every character.

Crawler verification changed when the AI bots arrived

A User-Agent header is free text. Every large operator therefore publishes a way to verify its crawlers, and for two decades that way was forward-confirmed reverse DNS. That is no longer true for half of the crawlers worth checking.

Of the ten crawlers the bot check knows, five verify by DNS and five by a published address list:

Forward-confirmed reverse DNS: Googlebot, Bingbot, Applebot, YandexBot, Baiduspider
Published address ranges: DuckDuckBot, GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot

The split runs almost exactly along the line between classic search engines and the generation of AI crawlers. OpenAI, Perplexity and Anthropic document JSON files of address ranges and do not make PTR names part of their method. A check on 2026-09-20 found no PTR record at all on 20.171.207.1, inside the range OpenAI publishes for GPTBot.

The practical consequence: a verifier that only knows the DNS method will mark every AI crawler as unconfirmed, which is the same verdict it gives a forgery. The tool keeps the two apart and says which method applies to the operator in question. Google documents its own procedure in the Googlebot verification guide.

Why a report count alone says nothing about a network

The community database held 766,987 addresses and 6,933,661 reports across 19,827 networks and 225 countries on 2026-09-20. Ranking those networks by total reports produces a list of the largest hosting providers, which is a statement about their size and not about how they are run.

Network	Addresses known	Reports	Per address
AS14061 DigitalOcean	21,444	604,109	28.2
AS396982 Google Cloud	36,444	387,685	10.6
AS174 Cogent	365	238,668	653.9
AS47890 Unmanaged Ltd	260	169,449	651.7

DigitalOcean leads by total reports. Cogent sits two places lower with 365 known addresses, and each of them carries 23 times more reports than a DigitalOcean address does. Those are two different situations, and the total column hides the difference.

The report therefore places two figures against every other network in the data: how many addresses are known there, and how many reports each of them carries. A large provider ranks high on the first and low on the second. A concentrated network does the opposite, and that is the pattern worth acting on. Blocking a whole range is a decision the second figure supports and the first one does not.

RDAP returns the narrowest allocation, not the widest

An abuse report sent to the wrong block is the same as no report. A single address usually sits inside a hosting provider’s allocation, which sits inside a transit provider’s allocation, which belongs to a regional registry. Only the innermost operator can take the machine off the network.

There is no central directory of address space. IANA publishes a bootstrap file that maps allocated prefixes to the responsible registry, and it is smaller than most estimates suggest: ipv4.json was 5,629 bytes and ipv6.json 1,476 bytes when measured on 2026-09-20, so caching it for a day costs nothing.

Two details decide whether the answer is usable. The prefix match has to be longest-match rather than first-match, because a small range inside an old large allocation often belongs to a different registry than its parent. And the abuse address has to come from the contact entity carrying the abuse role, not from whichever contact appears first in the RDAP response. The tool returns the mailbox, the network block, the holder, the country and a report draft with the known facts already filled in. Nothing is sent from the page.

What the header check weighs, and why max-age=0 is worse than nothing

Header checklists tend to treat every missing header as one red mark. A missing Permissions-Policy is not the same size of problem as a missing Content-Security-Policy, so the score is weighted: CSP 25, HSTS 20, framing protection 15, X-Content-Type-Options 15, Referrer-Policy 10, Permissions-Policy 10, and 5 for version disclosure through Server or X-Powered-By.

max-age=0 is flagged harder than a missing HSTS header. It is the documented way to switch HSTS off, so every visitor is released back to plain HTTP on their next first request. A site that never sent the header at least never promised anything.
frame-ancestors counts as framing protection. It is the specified replacement for X-Frame-Options, and a site that sets it correctly should not be marked down for dropping the older header.
Every finding names the directive to change, not just the header that is missing.

The email check follows the same idea. Authentication decides whether someone else can send mail as your domain, so DMARC counts 25 points, SPF and DKIM 20 each, DNSSEC 15, MTA-STS 12 and TLS-RPT 8. BIMI scores 0 by design: it is a logo, and it changes nothing about whether a message is trusted. Details are in the integration docs.

IPv6, limits and what is stored

130,865 of the 766,987 addresses in the database are IPv6, which is why the blacklist check now reverses IPv6 into the nibble format that RFC 5782 specifies. Nine of the twelve curated lists answer for IPv6; the other three are queried for IPv4 only and say so in the result instead of reporting a silent miss.

The DNS checker runs against 101 active resolvers in 52 countries on 6 continents. All ten tools share one daily budget: 30 checks for visitors without an account, 100 for signed-in users, counted per address. Queries are not stored against your address, and no tool contacts the address you look up.

Questions we get about these checks

Does a failed forward confirmation mean the crawler is fake?

Not on its own. It means the DNS method found nothing to confirm. For Googlebot, Bingbot, Applebot, YandexBot and Baiduspider that is a strong signal, because those operators publish PTR names. For GPTBot, PerplexityBot, ClaudeBot and DuckDuckBot it is expected, and the address list is the method that applies.

Why does the abuse contact differ from what WHOIS shows?

WHOIS returns free text and usually the widest allocation. RDAP returns structured data, and the lookup follows the chain down to the most specific allocation. That is normally a smaller block with a different, closer mailbox.

Is a network with many reports automatically bad?

No. Two of the densest networks in the data are the scanning services ONYPHE (226.1 reports per address) and Censys (265.8). They generate reports because they scan the internet on purpose, not because they are compromised. Reports per address show where abuse is concentrated; what it means still needs the operator’s context.

Where to go next

All ten free tools, no account required
How to get an address delisted if you are on the receiving end
API reference for the same data behind the tools

All figures in this post were measured against production on 2026-09-20 and are stated with that date so they can be checked against the current data.