Home › Handleidingen

Blacklistmonitoring: scripts, een API en webhookmeldingen

Gepubliceerd 2026-11-03 ／ Bijgewerkt 2026-11-03 ／ Door Yuki Nakazawa

Blacklistmonitoring betekent dat u volgens een schema meerdere DNS-blocklists (DNSBL's) bevraagt voor uw verzendende IP-adressen en domeinen, en alleen een melding geeft wanneer een resultaat verandert. Als u een listing opmerkt op het moment dat die ontstaat, en niet pas wanneer klanten teruggestuurde mail melden, hebt u tijd om de oorzaak te vinden en verwijdering aan te vragen voordat de schade zich uitbreidt.

Er zijn twee praktische manieren: zelf een klein dig- en cronscript draaien, of de controles via een API en webhooks aan een dienst overlaten. In beide gevallen bepalen twee details of de monitor de waarheid vertelt: queries via publieke resolvers worden door lijsten zoals Spamhaus geweigerd en leveren misleidende antwoorden op, en foutcodes mogen nooit als listings worden geteld.

De regels van de lijstbeheerders die hier worden aangehaald, zijn gebaseerd op hun officiële pagina's zoals die er in november 2026 uitzagen. Beleid verandert, dus controleer de regels voordat u op een opzet vertrouwt. Voor achtergrond over de werking van DNSBL's, zie wat een DNSBL (RBL) is.

Bepaal wat u bewaakt en welke lijsten u bevraagt

Noteer eerst welke objecten u echt moet bewaken.

• Verzendende IP-adressen. Dit zijn de adressen waarvandaan uw mailserver of e-mailprovider werkelijk verstuurt. Uw website en uw mail vertrekken vaak vanaf verschillende machines, dus bevestig het adres in de Received-headers van een bericht dat u hebt verstuurd. Verstuurt u via IPv6, monitor dan ook die adressen.
• Domeinen. Het domein in uw From-adres en alle domeinen die in links in uw berichten voorkomen. Domeinen worden gecontroleerd tegen domeinblocklists, die los staan van IP-lijsten.

Het queryformaat is vastgelegd in RFC 5782. Voor IPv4 draait u de octetten om en voegt u de zone van de lijst toe, dus 192.0.2.99 op een lijst wordt 99.2.0.192 gevolgd door de zonenaam. Voor IPv6 wordt het adres geschreven als 32 hexadecimale nibbles in omgekeerde volgorde. Een domein wordt simpelweg vóór de zone geplaatst. Een gelistte vermelding geeft een A-record terug, volgens de conventie in 127.0.0.0/8; een niet-gelistte geeft NXDOMAIN terug. De RFC merkt ook op dat lijsten een TXT-record horen te publiceren met de reden voor een listing.

Bewaak meerdere lijsten in plaats van één, omdat niet alle ontvangers dezelfde gebruiken. Wat elke retourcode betekent, verschilt per beheerder; onze gids over DNSBL-retourcodes behandelt de gangbare codes.

Waarom publieke resolvers verkeerde antwoorden geven

Een veelgemaakte fout bij zelfgebouwde monitoring is queries versturen via een publieke resolver zoals Google Public DNS (8.8.8.8) of Cloudflare (1.1.1.1). De officiële FAQ van Spamhaus over DNSBL-gebruik legt uit wat er dan gebeurt:

• Gratis gebruik van de DNSBL's van Spamhaus vereist dat het gebruik niet-commercieel is en dat queries niet afkomstig zijn van een publieke of open resolver, of van een IP-adres met generieke reverse DNS.
• Via gratis open resolvers zoals Google Public DNS krijgen queries in de meeste gevallen een antwoord "niet gelist" (NXDOMAIN). Met andere woorden: een gelist IP-adres kan schoon lijken.
• Queries via een publieke resolver kunnen ook 127.255.255.254 terugkrijgen. Dat is een foutcode, geen listing. Evenzo betekent 127.255.255.252 een typefout in de naam van de DNSBL, en 127.255.255.255 een buitensporig aantal queries. Spamhaus stelt dat deze codes niet mogen worden opgevat alsof het bevraagde object gelist is.
• Resolvers die NXDOMAIN-antwoorden herschrijven, geven in plaats daarvan een IP-adres terug, zodat u nooit de juiste NXDOMAIN te zien krijgt.

De belangrijkste aanbeveling in de FAQ is een eigen DNS-resolver te draaien. Voor gebruikers die bij een publieke resolver moeten blijven, verwijst Spamhaus naar zijn Data Query Service (DQS); controleer in de voorwaarden wat gratis is. De FAQ stelt dig txt whoami.fastly.net voor om te zien welke resolver u werkelijk gebruikt.

RFC 5782 voegt een ingebouwde controle toe: een IPv4-lijst moet een vermelding voor 127.0.0.2 bevatten en mag 127.0.0.1 niet bevatten, en clients horen deze testvermeldingen periodiek te controleren om te bevestigen dat de lijst werkt. In het voorbeeld van Spamhaus geeft 2.0.0.127.zen.spamhaus.org 127.0.0.10, 127.0.0.4 en 127.0.0.2 terug, terwijl 1.0.0.127.zen.spamhaus.org NXDOMAIN teruggeeft. Een monitor hoort dit eerst te testen en de run te verwerpen als de test mislukt.

Optie 1: een dig- en cronscript

Hier is een minimaal script dat één IPv4-adres controleert tegen Spamhaus ZEN en SpamCop (bl.spamcop.net, dat volgens de documentatie van SpamCop 127.0.0.2 teruggeeft voor een gelist IP-adres). Vervang het adres en de zones door uw eigen.

#!/bin/sh
# Bevraag uw eigen recursieve resolver (bijv. unbound op dezelfde host), nooit een publieke
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
  # Geeft de testvermelding 127.0.0.2 geen listingcode, vertrouw deze run dan niet
  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

Wat het script doet:

• Alleen de status NXDOMAIN telt als schoon, 127.255.255.x is een fout, en elke andere 127.x is een listing. Alles buiten 127.0.0.0/8 wordt behandeld als afwijking, zoals een resolver die antwoorden herschrijft.
• Bij een time-out eindigt dig met een exitcode ongelijk aan nul, terwijl SERVFAIL en REFUSED met 0 eindigen. Geen van deze gevallen wordt als schoon behandeld; het script registreert een fout.
• Retourcodes verschillen per lijst. Sommige lijsten gebruiken bijvoorbeeld 127.0.0.1 om aan te geven dat een query is geweigerd, dus lees de documentatie van elke lijst die u toevoegt en breid zo nodig het case-statement uit.

Laat cron vervolgens elke run vergelijken met de vorige en alleen mail versturen als er iets is veranderd:

# Voorbeeld: elk uur uitvoeren, alleen mailen als de uitvoer afwijkt van de vorige run
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

Het interval van een uur is slechts een voorbeeld. Spamhaus biedt gratis toegang voor niet-commercieel gebruik met een laag volume, en clients die de drempel voor het queryvolume overschrijden, hebben een betaalde optie nodig; controleer de voorwaarden van elke lijst naarmate het aantal bewaakte IP-adressen groeit. De FAQ raadt ook aan opdrachten een paar keer uit te voeren om te bevestigen dat de resultaten gelijk blijven.

Optie 2: de batch-API en webhooks van DNSBL Checker

Wilt u liever geen resolver en verwerkingsregels per lijst onderhouden, dan kunt u de controles door een dienst laten uitvoeren. Hieronder staat de v1-API van deze site, beperkt tot wat de serverimplementatie daadwerkelijk doet. De referentie staat op /en/api-docs en sleutels worden uitgegeven op de ledenpagina op /account. Voor aanmelden is alleen een e-mailadres nodig, en u logt in via een link die per e-mail wordt verstuurd.

Authenticatie en limieten

• Sleutels beginnen met dnsbl_ en worden één keer getoond, direct na uitgifte; alleen een hash wordt opgeslagen. Een nieuwe sleutel uitgeven maakt de vorige ongeldig.
• Stuur de sleutel bij elk verzoek mee in de header X-API-Key. Alleen HTTPS; gewoon http:// wordt doorgestuurd naar https://, dus roep vanaf het begin https:// aan.
• De limieten zijn 1.000 controles per dag (één doel telt als één), 100 doelen per batch en 50 monitorregistraties. Boven de daglimiet krijgt u 429 met daily_limit_exceeded en een tijdstempel resets_at.

Batchcontroles

Stuur een array targets met domeinnamen of IP-adressen naar 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"]}'

Moet er nog een doel worden gecontroleerd, dan is het antwoord 202 met een batch_id. Vraag GET /api/v1/batch/{batch_id} om de paar seconden op totdat status de waarde done heeft (verkort voorbeeld; de getallen en de lijstnaam zijn ter illustratie, geen echt resultaat):

{
  "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 is listed als minstens één lijst een listing meldt, anders clean. Lijsten die een time-out gaven of met een foutcode zoals 127.255.255.x antwoordden, worden geteld in error_count en nooit als listing.
• Een batch geeft een opgeslagen resultaat terug als er een van de afgelopen 30 dagen bestaat. Kijk bij geplande monitoring dus altijd naar checked_at.
• Ongeldige doelen komen terug in rejected met een reden en worden niet meegeteld. Geeft u een URL op, dan wordt alleen de hostnaam gebruikt. Ranges die alleen voor documentatie bedoeld zijn, zoals 192.0.2.0/24, worden geweigerd, dus test met een echt verzendend IP-adres.

Monitoring met webhooks

Registreer een target en een callback_url met POST /api/v1/monitors. Elk geregistreerd doel wordt daarna één keer per dag gecontroleerd zonder de cache te gebruiken (de eerste controle vindt binnen ongeveer een dag na registratie plaats), en er wordt alleen een JSON-POST naar uw URL gestuurd bij de eerste controle (monitor.initial) en wanneer het oordeel omslaat tussen listed en clean (monitor.status_changed).

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"}'

• Het signing_secret in het antwoord wordt maar één keer getoond. Elke aflevering bevat een header X-DNSBL-Signature: sha256=..., de HMAC-SHA256 van de onbewerkte body met dat geheim als sleutel. Verifieer die aan uw kant.
• callback_url moet https op poort 443 zijn en naar een publiek IP-adres verwijzen; redirects worden niet gevolgd en de time-out is 10 seconden, dus zet zwaar werk in een wachtrij en antwoord snel.
• Geeft uw endpoint iets anders terug dan 2xx, of mislukt de verbinding, dan wordt de aflevering bij de volgende dagelijkse controle opnieuw geprobeerd. De reden verschijnt als last_delivery_error in GET /api/v1/monitors, en DELETE /api/v1/monitors/{monitor_id} verwijdert een 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", ""))

Meldingen ontwerpen: frequentie, meerdere lijsten en vals alarm

Een monitor is alleen nuttig als mensen de meldingen na een paar maanden nog lezen. Een monitor die voortdurend afgaat, wordt al snel genegeerd.

Frequentie

• Scheid hoe vaak u bevraagt van hoe vaak u meldt. Bevraag volgens een schema, maar meld alleen bij een statuswijziging. Een dagelijks bericht dat alles in orde is, doet de ene melding die ertoe doet ondersneeuwen.
• RFC 5782 zegt dat de TTL's van een lijst moeten weerspiegelen hoe snel de lijst verandert, en dat lijsten met spambronnen TTL's van minuten kunnen gebruiken. Kies uw interval in het besef dat sommige listings snel verschijnen en weer vervallen.
• Intensief bevragen kan de gebruiksvoorwaarden van een lijst schenden of u 127.255.255.255 (buitensporig aantal queries) opleveren in plaats van echte antwoorden.

Meerdere lijsten

• Vermeld in elke melding de naam van de lijst. Lijsten verschillen in hoeveel ontvangers ze gebruiken, dus u kunt direct melden voor de lijsten die voor uw ontvangers het zwaarst wegen en de rest bundelen in een overzicht.
• De webhook hierboven gaat alleen af wanneer het oordeel omslaat tussen listed en clean. Is een doel al gelist en verschijnt het daarna op een tweede lijst, dan wordt er geen event verstuurd. Houd last_listed_count in GET /api/v1/monitors in de gaten, of voer een batch uit en lees listed_on, om dat geval op te vangen.

False positives en tijdelijke antwoorden

• Registreer fouten apart van listings. Spamhaus waarschuwt beheerders om mail niet te weigeren of te filteren op basis van zijn foutcodes; dezelfde logica geldt voor monitoring. Een time-out of een antwoord 127.255.255.x mag nooit een listingmelding veroorzaken.
• Om niet op één vreemd resultaat te reageren, meldt u pas na twee opeenvolgende identieke resultaten, of bevraagt u een paar minuten later opnieuw voordat u iets verstuurt.
• Blijven fouten aanhouden, vermoed dan een gewijzigde resolver of een wijziging aan de kant van de lijst, en kijk eerst naar het resultaat van de testvermelding.
• Een particulier IP-adres op de Spamhaus PBL is een beleidslisting, geen beschuldiging: het betekent dat het adres geen mail rechtstreeks hoort te versturen. Bepaal per lijst wat als melding telt (zie verwijdering bij Spamhaus).

Wat u doet als er een listing wordt gedetecteerd

1. Bevestig de listing. Controleer de eigen lookuppagina van de beheerder en noteer de naam van de lijst, het tijdstip en een eventuele getoonde reden.
2. Verhelp eerst de oorzaak. Zoek naar gecompromitteerde accounts, misbruikte webformulieren, geïnfecteerde machines, slecht lijstonderhoud en niet-overeenkomende reverse DNS (PTR) of HELO-namen. Verwijdering aanvragen terwijl de oorzaak blijft bestaan, leidt meestal tot een nieuwe listing.
3. Volg de verwijderingsprocedure van die lijst. De beslissing over delisten ligt bij elke lijstbeheerder, en een verzoek indienen is geen belofte dat de listing wordt opgeheven. Beheert u het IP-adres niet zelf, zoals bij shared hosting, neem dan contact op met uw hostingprovider of ISP.
4. Laat de monitor het resultaat bevestigen. Ontvangers gebruiken ook eigen filters, dus houd de aflevering in de gaten nadat het oordeel weer op clean staat.

Voor een eenmalige controle van een IP-adres of domein gebruikt u de blacklistchecker. Is het opsporen van de oorzaak of het afhandelen van de verzoeken meer dan u aankunt, dan kunt u ons om hulp vragen. Voor het volledige stappenplan als mail terugkomt, zie e-mail die door blacklists wordt geblokkeerd.

Veelgestelde vragen

Gebruikte officiële pagina's

De feiten in dit artikel zijn bij publicatie gecontroleerd aan de hand van de officiële pagina's hieronder. Beleid en werkwijze kunnen zonder aankondiging veranderen. Controleer daarom de officiële pagina's voordat u ergens belangrijks op vertrouwt.

• 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?

Gerelateerde handleidingen

Alle handleidingen →