Ten Free Tools for IP, DNS and Email Checks

Five new free tools are live on reportedip.com: reverse DNS with forward confirmation, an RDAP abuse contact finder, a security header check, crawler verification and an ASN report, and the email check now also reads MTA-STS, TLS-RPT and BIMI. That makes ten free tools: nine run in the browser without an account, the tenth is the Honeypot Server you host yourself.

All nine browser tools are listed at reportedip.com/tools, and the free tools overview documents inputs, limits and data handling. The rest of this post is about the four checks behind the new tools that are easy to implement and easy to implement wrong.

Which free tools does ReportedIP offer?

Tool	Input	What it answers
DNS Checker	Domain	What resolvers around the world return for a record
Email Security Check	Domain	SPF, DKIM, DMARC, DNSSEC, MTA-STS, TLS-RPT, BIMI
DNSBL Blacklist Check	IPv4, IPv6 or domain	Which blacklists list this address
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
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
Security Headers	Domain or URL	Which directive to change, weighted by effect
What We Know About You	None	What a website learns from your request
Honeypot Server	A host you run	What is attacking systems right now

Reverse DNS, Abuse Contact, Bot Verification, ASN Report and Security Headers are new. The Honeypot Server is source-available under the Business Source License 1.1 and reports what it catches to the community database.

Why is one A record 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.

How do you verify a crawler like Googlebot or GPTBot?

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 crawler profiles 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 with ChatGPT-User, 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.

Should you block one address or the whole 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 ASN 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.

Where do you send an abuse report so it lands?

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 keeping a local copy 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.

How are security headers scored, and why is max-age=0 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. Every weight and its reason are on the tool scoring page.

What are the daily limits of the free tools?

The nine browser tools share one daily budget: 30 checks without an account, counted per IP address, and 100 checks when signed in, counted per user. The same budget covers the Tools API, 17 public endpoints under /wp-json/ridns/v1 that need no key.

130,865 of the 766,987 addresses in the database on 2026-09-20 were IPv6, which is why the blacklist check reverses IPv6 into the nibble format that RFC 5782 specifies. It queries twelve zones; nine of them answer for IPv6, and the other three say “not applicable” in the result instead of reporting a silent miss.

The DNS checker queries about 100 resolvers in more than 50 countries on six continents. Its migration monitor repeats a lookup until the new value shows up everywhere, at most once every 12 seconds per domain and record type.

Do the free tools store what you look up?

Yes, in two logs with different purposes. For statistics, each lookup is stored with what you entered (domain, IP address or AS number), a pseudonymous visitor hash and, if you are signed in, your user ID. These entries are kept for up to one year.

To prevent abuse, a second log keeps your full IP address together with the input and the result, and deletes it after 30 days. The counter behind the daily limit expires after one day. Only the DNS Checker caches results, for 90 seconds, so the same question asked twice inside that window gets the stored answer. Section 7a of the privacy policy has the details.

No tool contacts an address you enter, and no tool files a report on your behalf. The only exception to the first rule is Security Headers, which fetches the page you name because that is what it checks.

Questions we get about these checks

Does a failed forward confirmation mean the crawler is fake?

Only for crawlers whose operators publish PTR names. For Googlebot, Bingbot, Applebot, YandexBot and Baiduspider a failed check is a strong signal of a forgery. For GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot and DuckDuckBot it is expected, because those operators publish address lists, and the 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 run by the operator closest to the machine, with its own abuse mailbox, which is the one that can act on a report.

Is a network with many reports automatically bad?

Many reports alone do not make a network bad. Two of the densest networks in the data are the scanning services ONYPHE (226.1 reports per address) and Censys (265.8). They scan the internet on purpose. Reports per address show where abuse is concentrated; what it means still needs the operator’s context.

Can I run the free tools from a script?

Every browser tool is also a public REST endpoint, 17 in total, under /wp-json/ridns/v1, without key or account. The endpoints share the daily budget of the browser tools, so a script gets 30 checks a day per IP address. Parameters and responses are in the Tools API reference.

Where to go next

All free tools, no account required
Verification methods behind the checks in this post
IP delisting guide if your own address is listed
Honeypot Server webhooks for forwarding detections to your own systems
ReportedIP products for volume beyond the free budget

All database and DNS 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.