Bekanntmachungen

Zehn kostenlose Tools für IP-, DNS- und E-Mail-Prüfungen

20. September 2026 · Patrick Schlesinger

Auf ReportedIP sind sechs neue kostenlose Tools verfügbar: Forward-confirmed reverse DNS, ein RDAP-Abuse-Kontakt-Finder, eine Überprüfung der HTTP-Security Header, eine Crawler-Verifizierung, ein ASN- und Netzwerkbericht sowie MTA-STS, TLS-RPT und BIMI im Rahmen des bestehenden Email Security Checks. Damit stehen nun insgesamt zehn kostenlose Tools zur Verfügung, für die jeweils kein Konto erforderlich ist.

Alle zehn sind unter reportedip.com/tools aufgeführt. Im weiteren Verlauf dieses Beitrags geht es um die vier dahinter stehenden Prüfungen, die zwar einfach umzusetzen sind, bei denen jedoch leicht Fehler unterlaufen können.

Was die sechs neuen Tools leisten

Werkzeug	Eingabe	Was diese Frage beantwortet
Reverse DNS	IPv4, IPv6 oder Hostname	Hält der PTR Record einer Vorwärtsprüfung stand?
Abuse-Kontakt	IP-Adresse oder Domain	Welches Postfach ist für diese Adresse zuständig?
Security-Header	Domain oder URL	Welche Richtlinie soll geändert werden, gewichtet nach ihrer Wirkung
Bot-Verifizierung	IP, optionaler User-Agent	Ist der selbsternannte Crawler der echte?
ASN-Report	IP- oder AS-Nummer	Wie sich das gesamte Netzwerk verhält, nicht eine einzelne Adresse
E-Mail-Sicherheitsprüfung	Domäne	SPF, DKIM, DMARC, DNSSEC, MTA-STS, TLS-RPT, BIMI

Warum ein A-Eintrag für Reverse DNS nicht ausreicht

A PTR Record allein beweist nichts. Jeder, der einen Adressblock kontrolliert, kann dort beliebige Namen veröffentlichen, einschließlich mail.yourbank.com. Ausschlaggebend ist die Forward-confirmed reverse DNS: Man löst den PTR-Namen in Adressen auf und prüft, ob die ursprüngliche Adresse darunter ist.

Ein häufiger Implementierungsfehler besteht darin, den Vergleich ausschließlich mit dem ersten A-Eintrag durchzuführen. Gemessen am 20.09.2026 8.8.8.8 weist der PTR-Name dns.google, und dieser Name lässt sich auf vier Adressen auflösen:

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 -> dieselben vier Adressen
66.249.66.1  -> crawl-66-249-66-1.googlebot.com -> 66.249.66.1

Ein Tool, das bereits bei der ersten Antwort den Vorgang beendet, Reports 8.8.4.4 als unbestätigt, da das DNS 8.8.8.8 zuerst zurückgegeben hat. Der vollständige A- und AAAA-Satz muss verglichen werden, und der Vergleich gehört in binäre Form über inet_pton(), nie als Zeichenkette. 2001:db8::1 und 2001:0db8:0000:0000:0000:0000:0000:0001 sind dieselbe Adresse und unterscheiden sich in jedem Zeichen.

Die Crawler-Überprüfung hat sich mit der Einführung der KI-Bots geändert

Ein „User-Agent“-Header besteht aus freiem Text. Jeder große Betreiber veröffentlicht daher eine Methode zur Überprüfung seiner Crawler, und zwei Jahrzehnte lang war diese Methode das Forward-confirmed reverse DNS. Dies trifft mittlerweile auf die Hälfte der Crawler, deren Überprüfung sinnvoll ist, nicht mehr zu.

Von den zehn Crawlern, die dem Bot-Check bekannt sind, überprüfen fünf die Daten über DNS und fünf anhand einer veröffentlichten Adressliste:

• Forward-confirmed reverse DNS: Googlebot, Bingbot, Applebot, YandexBot, Baiduspider
• Veröffentlichte Adressbereiche: DuckDuckBot, GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot

Die Trennung verläuft fast genau entlang der Grenze zwischen klassischen Suchmaschinen und der Generation der KI-Crawler. OpenAI, Perplexity und Anthropic dokumentieren JSON-Dateien mit Adressbereichen und beziehen PTR-Namen nicht in ihre Methode ein. Eine Überprüfung am 20.09.2026 ergab, dass kein PTR Record vorhanden ist. 20.171.207.1innerhalb des von OpenAI für GPTBot veröffentlichten Bereichs.

Die praktische Konsequenz: Ein Prüfer, der lediglich die DNS-Methode kennt, wird jeden KI-Crawler als unbestätigt kennzeichnen, also genauso wie eine Fälschung. Das Tool unterscheidet zwischen beiden Fällen und gibt an, welche Methode für den jeweiligen Betreiber gilt. Google dokumentiert sein eigenes Verfahren im Leitfaden zur Googlebot-Verifizierung.

Warum die Anzahl der Reports allein nichts über ein Netzwerk aussagt

Die Community-Datenbank umfasste am 20.09.2026 766.987 Adressen und 6.933.661 Reports aus 19.827 Netzwerken und 225 Ländern. Eine Rangliste dieser Netzwerke nach der Gesamtzahl der Reports ergibt eine Aufstellung der größten Hosting-Anbieter, die Aufschluss über deren Größe gibt, nicht jedoch darüber, wie sie betrieben werden.

Netzwerk	Bekannte Adressen	Reports	Pro Adresse
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 liegt bei der Gesamtzahl der Reports an der Spitze. Cogent liegt mit 365 bekannten Adressen zwei Plätze dahinter, wobei jede dieser Adressen 23-mal mehr Reports aufweist als eine Adresse von DigitalOcean. Es handelt sich hierbei um zwei unterschiedliche Situationen, und die Spalte „Gesamt“ verschleiert diesen Unterschied.

Der Bericht stellt daher für jedes andere Netzwerk in den Daten zwei Kennzahlen gegenüber: wie viele Adressen dort bekannt sind und wie viele Reports jede einzelne davon enthält. Ein großer Anbieter nimmt bei der ersten Kennzahl einen hohen Rang ein und bei der zweiten einen niedrigen. Bei einem konzentrierten Netzwerk verhält es sich umgekehrt, und genau dieses Muster ist es, auf das man reagieren sollte. Die Sperrung eines gesamten Adressbereichs ist eine Entscheidung, die durch die zweite Zahl gestützt wird, nicht jedoch durch die erste.

RDAP gibt die engste Zuordnung zurück, nicht die breiteste

Eine Abuse-Meldung, die an den falschen Block gesendet wird, hat denselben Effekt wie gar keine Meldung. Eine einzelne Adresse befindet sich in der Regel innerhalb der Zuteilung eines Hosting-Anbieters, die wiederum Teil der Zuteilung eines Transit-Anbieters ist, welche wiederum zu einer regionalen Registry gehört. Nur der innerste Betreiber kann den Rechner aus dem Netzwerk entfernen.

Es gibt kein zentrales Verzeichnis des Adressraums. Die IANA veröffentlicht eine Bootstrap-Datei, die zugewiesene Präfixe der zuständigen Registry zuordnet, und diese ist kleiner, als die meisten Schätzungen vermuten lassen: ipv4.json betrug 5.629 Byte und ipv6.json 1.476 Byte, als sie am 20.09.2026 gemessen wurde; das Zwischenspeichern für einen Tag verursacht also keine Kosten.

Zwei Details entscheiden darüber, ob die Antwort verwertbar ist. Die Präfixübereinstimmung muss eine „Longest-Match“-Übereinstimmung sein und darf keine „First-Match“-Übereinstimmung sein, da ein kleiner Bereich innerhalb einer alten, großen Zuweisung häufig zu einer anderen Registry gehört als deren übergeordneter Bereich. Und die Missbrauchsadresse muss von der Kontaktentität stammen, die die Missbrauchsrolle innehat, und nicht von dem Kontakt, der in der RDAP-Antwort an erster Stelle erscheint. Das Tool gibt das Postfach, den Netzwerkblock, den Inhaber, das Land sowie einen Berichtsentwurf zurück, in den die bekannten Fakten bereits eingetragen sind. Von der Seite aus wird nichts gesendet.

Was bei der Header-Prüfung berücksichtigt wird und warum „max-age=0“ schlechter ist als gar nichts

In Header-Checklisten wird in der Regel jeder fehlende Header als ein roter Eintrag gewertet. Ein fehlender „Permissions-Policy“-Header stellt jedoch kein ebenso großes Problem dar wie ein fehlender „Content-Security-Policy“-Header, weshalb die Punktzahl gewichtet wird: CSP 25, HSTS 20, Framing-Schutz 15, X-Content-Type-Options 15, Referrer-Policy 10, Permissions-Policy 10 und 5 für die Offenlegung der Version durch Server oder X-Powered-By.

• max-age=0 wird strenger geahndet als ein fehlender HSTS-Header. Dies ist die dokumentierte Vorgehensweise, um HSTS zu deaktivieren, sodass jeder Besucher bei seiner nächsten ersten Anfrage wieder auf normales HTTP umgeleitet wird. Eine Website, die den Header nie gesendet hat, hat zumindest nie etwas versprochen.
• frame-ancestors gilt als Schutz vor Framing. Es ist der festgelegte Ersatz für „X-Frame-Options“, und eine Website, die diesen Header korrekt setzt, sollte nicht dafür abgewertet werden, dass sie den älteren Header weglässt.
• Jeder Befund nennt die zu ändernde Anweisung, nicht nur die fehlende Kopfzeile.

Die E-Mail-Prüfung folgt dem gleichen Prinzip. Die Authentifizierung entscheidet darüber, ob jemand anderes E-Mails unter Ihrer Domain versenden darf; daher werden für DMARC 25 Punkte, für SPF und DKIM jeweils 20 Punkte, für DNSSEC 15 Punkte, für MTA-STS 12 Punkte und für TLS-RPT 8 Punkte vergeben. BIMI erhält aufgrund seiner Konzeption 0 Punkte: Es handelt sich um ein Logo, das keinen Einfluss darauf hat, ob eine Nachricht als vertrauenswürdig eingestuft wird. Einzelheiten finden Sie in den Integrations-Doku.

IPv6, Einschränkungen und welche Daten gespeichert werden

130.865 der 766.987 Adressen in der Datenbank sind IPv6-Adressen, weshalb die Blacklist-Prüfung IPv6-Adressen nun in das in RFC 5782 festgelegte Nibble-Format umwandelt. Neun der zwölf kuratierten Listen liefern Ergebnisse für IPv6; die übrigen drei werden ausschließlich für IPv4 abgefragt und geben dies im Ergebnis an, anstatt einen stillen Fehltreffer zu melden.

Der DNS Checker führt Abfragen bei 101 aktiven Resolvern in 52 Ländern auf 6 Kontinenten durch. Alle zehn Tools teilen sich ein tägliches Kontingent: 30 Abfragen für Besucher ohne Konto, 100 für angemeldete Nutzer, gezählt pro Adresse. Die Abfragen werden nicht mit Ihrer Adresse verknüpft gespeichert, und kein Tool nimmt Kontakt mit der von Ihnen abgefragten Adresse auf.

Fragen, die uns zu diesen Schecks gestellt werden

Bedeutet eine fehlgeschlagene Weiterleitungsbestätigung, dass es sich bei dem Crawler um einen gefälschten handelt?

Nicht für sich genommen. Das bedeutet, dass die DNS-Methode nichts gefunden hat, was dies bestätigen könnte. Für Googlebot, Bingbot, Applebot, YandexBot und Baiduspider ist dies ein starkes Signal, da diese Betreiber PTR-Namen veröffentlichen. Für GPTBot, PerplexityBot, ClaudeBot und DuckDuckBot ist dies zu erwarten, und die Adressliste ist die anzuwendende Methode.

Warum weicht der Abuse-Kontakt von den Angaben in WHOIS ab?

WHOIS liefert Freitext und in der Regel die umfassendste Zuweisung. RDAP liefert strukturierte Daten, und die Abfrage folgt der Kette bis hinunter zur spezifischsten Zuweisung. Dabei handelt es sich in der Regel um einen kleineren Block mit einer anderen, näher gelegenen Mailbox.

Ist ein Netzwerk mit vielen Reports automatisch schlecht?

Nr. Zwei der dichtesten Netzwerke in den Daten sind die Scan-Dienste ONYPHE (226,1 Reports pro Adresse) und Censys (265,8). Sie generieren Reports, weil sie das Internet gezielt scannen, nicht weil sie kompromittiert wurden. Die Anzahl der Reports pro Adresse zeigt, wo sich Missbrauch konzentriert; was dies bedeutet, muss noch im Kontext des Betreibers betrachtet werden.

Wie geht es nun weiter?

• Alle zehn kostenlosen Tools, ohne Registrierung
• So bekommen Sie eine Adresse wieder von einer Liste herunter wenn Sie davon betroffen sind
• API Reference für dieselben Daten, auf denen die Tools basieren

Alle Zahlen in diesem Beitrag wurden am 20.09.2026 anhand der Produktionszahlen ermittelt und sind mit diesem Datum angegeben, damit sie mit den aktuellen Daten abgeglichen werden können.