15 Free Tools for DNS, Email and IP Checks

ReportedIP offers fifteen free tools for DNS, email and IP checks: fourteen run in the browser without an account, the fifteenth is the Honeypot Server you host yourself. Five of them are new since October 2026 and write mail records instead of reading them: SPF, DMARC, DKIM, MTA-STS with TLS-RPT, and BIMI.

All fourteen browser tools are listed at reportedip.com/tools, and the free tools overview documents inputs, limits and data handling. This post explains what each tool answers, how the mail generators fit together, and the checks behind the 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
SPF Generator	Domain or services	One SPF record with the real lookup count
DMARC Generator	Domain	A DMARC record per RFC 9989 with a plan to reject
DKIM Generator	Domain, selector	A key pair and its DNS record
MTA-STS Generator	Domain	Policy file, _mta-sts and TLS-RPT records
BIMI Generator	Domain, logo URL	The BIMI record, if DMARC allows it
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

The Honeypot Server is source-available under the Business Source License 1.1 and reports what it catches to the community database. Reverse DNS, Abuse Contact, Bot Verification, ASN Report and Security Headers were added on 2026-09-20, the five generators on 2026-10-19.

How do the five mail record generators work together?

Five of the fifteen tools write records instead of reading them. Each generator runs in the browser, so the record you build is not sent anywhere; only the buttons that load or check a published record ask our server. The Email Security Check links every finding to the generator that fixes it, and every generator links back with the domain filled in.

SPF Generator: builds v=spf1 from 34 mail, newsletter and help desk services and counts DNS lookups the way a receiver counts them, against the limit of 10 in RFC 7208.
DMARC Generator: follows RFC 9989, where pct is gone and np and t are new, and plans the steps from p=none to p=reject with dates.
DKIM Generator: creates an RSA or Ed25519 key pair with WebCrypto; the private key never leaves the browser.
MTA-STS Generator: reads the MX hosts and writes the policy file, the _mta-sts record and the TLS-RPT record in one pass.
BIMI Generator: writes default._bimi and checks first whether the DMARC policy lets a mailbox show the logo at all.

Before building them we measured the top 1,000 .de domains of the Tranco list on 2026-10-19 (list 467YX, queried through Cloudflare DNS over HTTPS). The numbers show what each generator is needed for:

Finding	Domains of 1,000
No SPF record	112
SPF over the limit of 10 lookups	17
SPF with 8 to 10 lookups, one service away from failing	144
No DMARC record	214
DMARC still at `p=none`	333
DMARC with `pct`, removed in RFC 9989	250
MTA-STS published	63
BIMI published	83, 9 of them behind `p=none`

333 of the 786 domains with DMARC still sit at p=none, which asks receivers to take no action on mail that fails. Nine domains publish a BIMI logo that no mailbox will show, because their DMARC policy is p=none. DKIM is missing from the table on purpose: without the selector a key cannot be queried, and guessing common selectors would not give a clean number.

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 fourteen 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 under /wp-json/ridns/v1, which needs no key. Building a record in a generator costs nothing; only loading or checking a published record counts.

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 checking tool is also a public REST endpoint 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. The generators need no endpoint for the record itself, they build it in the browser.

Is the DKIM private key sent to ReportedIP?

No. The DKIM Generator creates the key pair with the browser’s WebCrypto interface and offers the private key as a PEM download. Our server only sees a request when you check the published public key, and then only the domain and the selector.

Where to go next

All free tools, no account required
Email Security Check to find out which mail record to build first
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

Database and DNS figures were measured against production on 2026-09-20, the mail record figures on 2026-10-19 against the Tranco top 1,000 .de domains. Both carry their date so they can be checked against current data.