Startseite › Ratgeber

Blacklist-Monitoring: Skripte, API und Webhook-Alarme

Veröffentlicht 2026-11-03 ／ Aktualisiert 2026-11-03 ／ Von Yuki Nakazawa

Blacklist-Monitoring bedeutet, mehrere DNS-Blocklisten (DNSBLs) regelmäßig nach Ihren sendenden IPs und Domains abzufragen und nur dann Alarm zu schlagen, wenn sich ein Ergebnis ändert. Wer einen Eintrag bemerkt, sobald er entsteht, und nicht erst, wenn Kunden zurückgekommene Mails melden, gewinnt Zeit, die Ursache zu finden und die Entfernung zu beantragen, bevor sich der Schaden ausweitet.

Praktisch gibt es zwei Wege: ein kleines dig-und-cron-Skript selbst betreiben oder die Prüfungen per API und Webhooks einem Dienst überlassen. In beiden Fällen entscheiden zwei Details darüber, ob die Überwachung die Wahrheit sagt: Abfragen über öffentliche Resolver werden von Listen wie Spamhaus abgelehnt und liefern irreführende Antworten, und Fehlercodes dürfen niemals als Einträge gezählt werden.

Die hier zitierten Regeln der Listenbetreiber beruhen auf deren offiziellen Seiten mit Stand 11/2026. Richtlinien ändern sich; prüfen Sie sie daher, bevor Sie sich auf ein Setup verlassen. Hintergrundwissen zur Funktionsweise von DNSBLs finden Sie unter was eine DNSBL (RBL) ist.

Festlegen, was überwacht wird und welche Listen

Notieren Sie zuerst die Objekte, die Sie tatsächlich überwachen müssen.

• Sendende IP-Adressen. Das sind die Adressen, von denen Ihr Mailserver oder Ihr E-Mail-Anbieter tatsächlich versendet. Website und Mail laufen oft über verschiedene Rechner; bestätigen Sie die Adresse daher in den Received-Headern einer von Ihnen gesendeten Nachricht. Wenn Sie über IPv6 versenden, überwachen Sie auch diese Adressen.
• Domains. Die Domain in Ihrer Absenderadresse (From) und alle Domains, die in Links in Ihren Nachrichten vorkommen. Domains werden gegen Domain-Blocklisten geprüft, die von IP-Listen getrennt sind.

Das Abfrageformat ist in RFC 5782 festgelegt. Bei IPv4 drehen Sie die Oktette um und hängen die Zone der Liste an; aus 192.0.2.99 wird also 99.2.0.192, gefolgt vom Zonennamen. Bei IPv6 wird die Adresse als 32 Hex-Nibbles in umgekehrter Reihenfolge geschrieben. Eine Domain wird einfach vor die Zone gesetzt. Ein gelisteter Eintrag liefert einen A-Record, üblicherweise im Bereich 127.0.0.0/8; ein nicht gelisteter liefert NXDOMAIN. Das RFC merkt außerdem an, dass Listen einen TXT-Record mit dem Grund der Listung veröffentlichen sollten.

Überwachen Sie mehrere Listen statt nur einer, denn nicht alle Empfänger nutzen dieselben. Was ein Rückgabecode bedeutet, unterscheidet sich je nach Betreiber; unser Leitfaden zu DNSBL-Rückgabecodes behandelt die gängigen Codes.

Warum öffentliche Resolver falsche Antworten liefern

Ein häufiger Fehler bei selbstgebauter Überwachung ist das Abfragen über einen öffentlichen Resolver wie Google Public DNS (8.8.8.8) oder Cloudflare (1.1.1.1). Die offizielle FAQ von Spamhaus zur DNSBL-Nutzung erklärt, was dann passiert:

• Die kostenlose Nutzung der Spamhaus-DNSBLs setzt voraus, dass die Nutzung nichtkommerziell ist und die Abfragen weder von einem öffentlichen oder offenen Resolver noch von einer IP mit generischem Reverse DNS kommen.
• Über kostenlose offene Resolver wie Google Public DNS erhalten Abfragen in den meisten Fällen eine Antwort „nicht gelistet“ (NXDOMAIN). Mit anderen Worten: Eine gelistete IP kann sauber aussehen.
• Abfragen über einen öffentlichen Resolver können auch 127.255.255.254 erhalten. Das ist ein Fehlercode, kein Eintrag. Ebenso bedeutet 127.255.255.252 einen Tippfehler im DNSBL-Namen und 127.255.255.255 eine übermäßige Zahl von Abfragen. Spamhaus stellt klar, dass diese Codes nicht so verstanden werden dürfen, als sei das abgefragte Objekt gelistet.
• Resolver, die NXDOMAIN-Antworten umschreiben, liefern stattdessen eine IP-Adresse, sodass Sie nie das korrekte NXDOMAIN sehen.

Die wichtigste Empfehlung der FAQ lautet, einen eigenen DNS-Resolver zu betreiben. Für Nutzer, die bei einem öffentlichen Resolver bleiben müssen, verweist Spamhaus auf seinen Data Query Service (DQS); welche Nutzung kostenlos ist, entnehmen Sie dessen Bedingungen. Die FAQ schlägt dig txt whoami.fastly.net vor, um zu sehen, welchen Resolver Sie tatsächlich nutzen.

RFC 5782 sieht eine eingebaute Plausibilitätsprüfung vor: Eine IPv4-Liste muss einen Eintrag für 127.0.0.2 enthalten und darf 127.0.0.1 nicht enthalten, und Clients sollten diese Testeinträge regelmäßig prüfen, um sicherzustellen, dass die Liste funktioniert. Im Beispiel von Spamhaus liefert 2.0.0.127.zen.spamhaus.org die Werte 127.0.0.10, 127.0.0.4 und 127.0.0.2, während 1.0.0.127.zen.spamhaus.org NXDOMAIN liefert. Eine Überwachung sollte dies zuerst testen und den Durchlauf verwerfen, wenn der Test fehlschlägt.

Option 1: ein dig-und-cron-Skript

Hier ein minimales Skript, das eine IPv4-Adresse gegen Spamhaus ZEN und SpamCop prüft (bl.spamcop.net, das laut SpamCop-Dokumentation für eine gelistete IP 127.0.0.2 liefert). Ersetzen Sie Adresse und Zonen durch Ihre eigenen.

#!/bin/sh
# Eigenen rekursiven Resolver abfragen (z. B. unbound auf demselben Host), niemals einen öffentlichen
RESOLVER=127.0.0.1
IP=192.0.2.10
ZONES="zen.spamhaus.org bl.spamcop.net"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')

q() {
  out=$(dig +time=3 +tries=1 @"$RESOLVER" "$1" A) || { echo ERR; return; }
  case "$out" in
    *"status: NOERROR"*) a=$(printf '%s\n' "$out" | awk '$4=="A"{print $5}'); echo "${a:-NX}" ;;
    *"status: NXDOMAIN"*) echo NX ;;
    *) echo ERR ;;
  esac
}

for Z in $ZONES; do
  # Löst der Testeintrag 127.0.0.2 nicht zu einem Listungscode auf, diesem Durchlauf nicht vertrauen
  case "$(q "2.0.0.127.$Z")" in
    127.255.255.*|NX|ERR) echo "$Z ERROR test-entry"; continue ;;
    127.*) ;;
    *) echo "$Z ERROR test-entry"; continue ;;
  esac
  A=$(q "$REV.$Z")
  case "$A" in
    NX)            echo "$Z CLEAN" ;;
    ERR)           echo "$Z ERROR no-answer" ;;
    127.255.255.*) echo "$Z ERROR $A" ;;
    127.*)         echo "$Z LISTED $A" ;;
    *)             echo "$Z ERROR unexpected $A" ;;
  esac
done

Was das Skript tut:

• Nur der Status NXDOMAIN zählt als sauber, 127.255.255.x ist ein Fehler, und jedes andere 127.x ist ein Eintrag. Alles außerhalb von 127.0.0.0/8 wird als Anomalie behandelt, etwa durch einen umschreibenden Resolver.
• Ein Timeout lässt dig mit einem Wert ungleich null enden, SERVFAIL und REFUSED dagegen mit 0. Keiner dieser Fälle wird als sauber gewertet; das Skript protokolliert einen Fehler.
• Rückgabecodes sind listenspezifisch. Manche Listen verwenden zum Beispiel 127.0.0.1, um anzuzeigen, dass eine Abfrage abgelehnt wurde; lesen Sie daher die Dokumentation jeder Liste, die Sie hinzufügen, und erweitern Sie die case-Anweisung bei Bedarf.

Lassen Sie dann cron jeden Durchlauf mit dem vorherigen vergleichen und nur bei einer Änderung eine Mail senden:

# Beispiel: stündlich ausführen, Mail nur senden, wenn sich die Ausgabe vom letzten Durchlauf unterscheidet
0 * * * * /usr/local/bin/dnsbl-watch.sh > /var/tmp/dnsbl.now 2>&1; cmp -s /var/tmp/dnsbl.now /var/tmp/dnsbl.prev || mail -s "DNSBL status changed" you@example.com < /var/tmp/dnsbl.now; mv /var/tmp/dnsbl.now /var/tmp/dnsbl.prev

Das stündliche Intervall ist nur ein Beispiel. Spamhaus bietet kostenlosen Zugang bei geringem Volumen und nichtkommerzieller Nutzung; Clients, die die Schwelle für das Abfragevolumen überschreiten, benötigen eine kostenpflichtige Option. Prüfen Sie die Bedingungen jeder Liste, wenn die Zahl der überwachten IPs wächst. Die FAQ rät außerdem, Befehle mehrmals auszuführen, um zu bestätigen, dass die Ergebnisse gleich bleiben.

Option 2: Batch-API und Webhooks des DNSBL Checkers

Wenn Sie keinen Resolver und keine Auswertungsregeln je Liste pflegen möchten, können Sie die Prüfungen einem Dienst überlassen. Im Folgenden die v1-API dieser Website, beschränkt auf das, was die Serverimplementierung tatsächlich tut. Die Referenz finden Sie unter /en/api-docs, Schlüssel werden auf der Mitgliederseite unter /account ausgegeben. Für die Registrierung genügt eine E-Mail-Adresse; Sie melden sich über einen per E-Mail gesendeten Link an.

Authentifizierung und Limits

• Schlüssel beginnen mit dnsbl_ und werden nur einmal direkt nach der Ausgabe angezeigt; gespeichert wird nur ein Hash. Eine Neuausgabe macht den vorherigen Schlüssel ungültig.
• Senden Sie den Schlüssel bei jeder Anfrage im Header X-API-Key. Nur HTTPS; einfaches http:// wird auf https:// umgeleitet, rufen Sie also von Anfang an https:// auf.
• Die Limits liegen bei 1.000 Prüfungen pro Tag (ein Ziel zählt als eine), 100 Zielen pro Batch und 50 Monitor-Registrierungen. Über dem Tageslimit erhalten Sie 429 mit daily_limit_exceeded und einem Zeitstempel resets_at.

Batch-Prüfungen

Senden Sie ein Array targets mit Domainnamen oder IP-Adressen an POST /api/v1/batch:

curl -X POST https://dnsblchecker.com/api/v1/batch \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"targets":["example.com"]}'

Muss noch ein Ziel geprüft werden, lautet die Antwort 202 mit einer batch_id. Fragen Sie GET /api/v1/batch/{batch_id} alle paar Sekunden ab, bis status den Wert done hat (gekürztes Beispiel; Zahlen und Listenname dienen nur der Veranschaulichung und sind kein echtes Ergebnis):

{
  "batch_id": 1, "status": "done", "created": "2026-11-03 09:10:41", "count": 1, "pending": 0,
  "results": [
    {
      "target": "example.com", "type": "domain",
      "status": "done", "verdict": "listed",
      "checked_at": "2026-11-03 09:12",
      "lists_checked": 80, "listed_count": 1, "error_count": 4,
      "listed_on": [
        { "list": "ZapBL RHSBL", "zone": "rhsbl.zapbl.net", "response": "127.0.0.2" }
      ]
    }
  ]
}

• verdict ist listed, wenn mindestens eine Liste einen Eintrag meldet, sonst clean. Listen mit Timeout oder mit einem Fehlercode wie 127.255.255.x werden in error_count gezählt und nie als Eintrag.
• Ein Batch liefert ein gespeichertes Ergebnis, wenn eines aus den letzten 30 Tagen vorliegt. Achten Sie bei geplanter Überwachung daher immer auf checked_at.
• Fehlerhafte Ziele kommen mit Begründung in rejected zurück und werden nicht gezählt. Wenn Sie eine URL übergeben, wird nur der Hostname verwendet. Reine Dokumentationsbereiche wie 192.0.2.0/24 werden abgelehnt; testen Sie daher mit einer echten sendenden IP.

Überwachung per Webhook

Registrieren Sie mit POST /api/v1/monitors ein target und eine callback_url. Jedes registrierte Ziel wird dann einmal täglich ohne Cache geprüft (die erste Prüfung erfolgt innerhalb von etwa einem Tag nach der Registrierung), und ein JSON-POST wird nur bei der ersten Prüfung (monitor.initial) und bei einem Wechsel des Ergebnisses zwischen „listed“ und „clean“ (monitor.status_changed) an Ihre URL gesendet.

curl -X POST https://dnsblchecker.com/api/v1/monitors \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"target":"example.com","callback_url":"https://your-app.example/hooks/dnsbl"}'

• Das signing_secret in der Antwort wird nur einmal angezeigt. Jede Zustellung trägt einen Header X-DNSBL-Signature: sha256=..., den HMAC-SHA256 des unveränderten Bodys mit diesem Secret als Schlüssel. Prüfen Sie ihn auf Ihrer Seite.
• callback_url muss https auf Port 443 verwenden und zu einer öffentlichen IP auflösen; Weiterleitungen werden nicht verfolgt, und das Timeout beträgt 10 Sekunden. Stellen Sie aufwendige Verarbeitung also in eine Warteschlange und antworten Sie schnell.
• Liefert Ihr Endpunkt etwas anderes als 2xx oder schlägt die Verbindung fehl, wird die Zustellung bei der nächsten täglichen Prüfung erneut versucht. Der Grund erscheint als last_delivery_error in GET /api/v1/monitors, und DELETE /api/v1/monitors/{monitor_id} entfernt einen Monitor.

import hmac, hashlib
expected = "sha256=" + hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
ok = hmac.compare_digest(expected, request.headers.get("X-DNSBL-Signature", ""))

Alarme gestalten: Häufigkeit, mehrere Listen, Fehlalarme

Eine Überwachung ist nur nützlich, wenn ihre Alarme nach ein paar Monaten noch gelesen werden. Eine, die ständig anschlägt, wird bald ignoriert.

Häufigkeit

• Trennen Sie, wie oft Sie abfragen, davon, wie oft Sie benachrichtigen. Fragen Sie nach Zeitplan ab, aber benachrichtigen Sie nur bei einer Zustandsänderung. Eine tägliche Entwarnung lässt den einen Alarm untergehen, auf den es ankommt.
• RFC 5782 sagt, dass die TTLs einer Liste widerspiegeln sollten, wie schnell sich die Liste ändert, und dass Listen von Spamquellen TTLs von Minuten verwenden können. Wählen Sie Ihr Intervall in dem Wissen, dass manche Einträge schnell entstehen und wieder auslaufen.
• Intensives Abfragen kann gegen die Nutzungsbedingungen einer Liste verstoßen oder Ihnen statt echter Antworten 127.255.255.255 (übermäßige Abfragen) einbringen.

Mehrere Listen

• Nennen Sie in jedem Alarm den Namen der Liste. Listen unterscheiden sich darin, wie viele Empfänger sie nutzen; Sie könnten also bei den für Ihre Empfänger wichtigsten Listen sofort alarmieren und den Rest in einer Sammelmeldung bündeln.
• Der oben beschriebene Webhook löst nur aus, wenn das Ergebnis zwischen „listed“ und „clean“ wechselt. Ist ein Ziel bereits gelistet und erscheint dann auf einer zweiten Liste, wird kein Ereignis gesendet. Beobachten Sie last_listed_count in GET /api/v1/monitors oder führen Sie einen Batch aus und lesen Sie listed_on, um diesen Fall zu erfassen.

Fehlalarme und vorübergehende Antworten

• Protokollieren Sie Fehler getrennt von Einträgen. Spamhaus warnt Betreiber davor, Mails aufgrund seiner Fehlercodes abzuweisen oder zu filtern; dieselbe Logik gilt für die Überwachung. Ein Timeout oder eine Antwort 127.255.255.x sollte niemals einen Listungsalarm auslösen.
• Um nicht auf ein einzelnes merkwürdiges Ergebnis zu reagieren, alarmieren Sie erst nach zwei aufeinanderfolgenden gleichen Ergebnissen oder fragen Sie einige Minuten später erneut ab, bevor Sie etwas senden.
• Halten Fehler an, vermuten Sie eine Änderung am Resolver oder auf Seiten der Liste und sehen Sie sich zuerst das Ergebnis des Testeintrags an.
• Eine private IP auf der Spamhaus PBL ist ein Richtlinien-Eintrag, kein Vorwurf: Er bedeutet, dass von der Adresse keine Mails direkt versendet werden sollen. Legen Sie je Liste fest, was als Alarm zählt (siehe Entfernung bei Spamhaus).

Was tun, wenn ein Eintrag erkannt wird

1. Bestätigen Sie ihn. Prüfen Sie die Abfrageseite des Betreibers und notieren Sie Listenname, Zeitpunkt und einen etwaigen angezeigten Grund.
2. Beheben Sie zuerst die Ursache. Suchen Sie nach kompromittierten Konten, missbrauchten Webformularen, infizierten Rechnern, schlechter Listenpflege und unpassendem Reverse DNS (PTR) oder HELO-Namen. Wer die Entfernung beantragt, solange die Ursache besteht, wird meist erneut gelistet.
3. Folgen Sie dem Entfernungsverfahren der jeweiligen Liste. Die Entscheidung über eine Entfernung liegt beim jeweiligen Listenbetreiber, und ein Antrag ist keine Zusage, dass der Eintrag aufgehoben wird. Wenn Sie die IP nicht kontrollieren, etwa bei Shared Hosting, wenden Sie sich an Ihren Hoster oder ISP.
4. Lassen Sie die Überwachung das Ergebnis bestätigen. Empfänger setzen auch eigene Filter ein; behalten Sie die Zustellung daher im Auge, nachdem das Ergebnis wieder auf „clean“ steht.

Für eine einmalige Prüfung einer IP oder Domain nutzen Sie den Blacklist-Checker. Wenn Ursachensuche oder Anträge Ihre Kapazitäten übersteigen, können Sie uns um Hilfe bitten. Den vollständigen Ablauf der Fehlersuche bei zurückkommenden Mails finden Sie unter E-Mails, die von Blacklists blockiert werden.

Häufige Fragen

Verwendete offizielle Seiten

Die Angaben in diesem Artikel wurden zum Zeitpunkt der Veröffentlichung anhand der unten aufgeführten offiziellen Seiten geprüft. Richtlinien und Verhalten können sich ohne Ankündigung ändern. Prüfen Sie daher die offiziellen Seiten, bevor Sie sich in wichtigen Fragen darauf verlassen.

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Using our public mirrors? Check your return codes now
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?

Verwandte Ratgeber

Alle Ratgeber →