Wat is een DNSBL (RBL)? Zo werken DNS-blacklists
Een DNSBL (DNS-based blacklist, ook wel DNS-blocklist of RBL genoemd) is een lijst met IP-adressen of domeinnamen die een lijstbeheerder als bron van spam of misbruik beschouwt, gepubliceerd zodat iedereen die met een gewone DNS-lookup kan raadplegen. Mailservers zoeken elke verbindende afzender op in een of meer DNSBL's en weigeren het bericht vervolgens, accepteren het of tellen het resultaat mee in een spamscore.
Deze gids legt uit hoe een DNSBL-lookup werkt (omgekeerde IP-adressen, A- en TXT-records, het nibble-formaat voor IPv6), wat het verschil is tussen IP-gebaseerde en domeingebaseerde lijsten, hoe ontvangers de antwoorden in de praktijk gebruiken, hoe blacklists verschillen van whitelists, waarom adressen worden gelist en welke plaats een listing inneemt als uw e-mail niet wordt afgeleverd. De gids is gebaseerd op RFC 5782 en de officiële documentatie van grote lijstbeheerders zoals die er in november 2026 uitzag.
Wat DNSBL en RBL betekenen
RFC 5782, "DNS Blacklists and Whitelists", gebruikt de overkoepelende term DNSxL voor een DNS-zone waarvan de records hosts op een lijst aanduiden. Een blacklist is een DNSBL; een whitelist is een DNSWL. Beide zijn op dezelfde manier opgebouwd. Alleen de betekenis die een ontvanger aan een match geeft, verschilt.
RBL staat voor Real-time Blackhole List. Volgens de RFC werd de eerste lijst van dit type in 1997 gestart en raakte die onder deze naam bekend. Strikt genomen verwijst RBL naar die oorspronkelijke lijst en haar opvolger, en de RFC merkt op dat de term in de Verenigde Staten een geregistreerd dienstmerk is. In het dagelijks gebruik worden "RBL" en "DNSBL" echter vrijwel door elkaar gebruikt, dus "wat is een RBL" en "wat is een DNSBL" komen in feite op dezelfde vraag neer.
RFC 5782 is een informatief document (Informational), geen internetstandaard. Het is opgesteld door de IRTF Anti-Spam Research Group en geeft de consensus van die groep weer over werkwijzen die de interoperabiliteit tussen DNS-blacklists en -whitelists verbeteren. Het beschrijft of adviseert geen beleid voor het toevoegen of verwijderen van adressen; de RFC gaat ervan uit dat dit in een apart document wordt behandeld. In de praktijk bepaalt elke beheerder zijn eigen beleid voor listen en delisten.
Zo werkt een DNSBL-lookup
Een DNSBL-lookup is een gewone DNS-query, dus voor een handmatige controle is geen speciale software nodig: alles wat een naam kan resolven, kan een lijst bevragen. Lijstbeheerders kunnen wel gebruiksvoorwaarden stellen. De publieke servers van Spamhaus zijn bijvoorbeeld alleen gratis voor niet-commercieel gebruik met een laag volume, en queries via publieke resolvers worden niet betrouwbaar beantwoord (zie hieronder).
IPv4: het adres omdraaien en de zone toevoegen
Voor een IPv4-adres schrijft u de vier octetten in omgekeerde volgorde en voegt u de zonenaam van de lijst toe. De structuur is ontleend aan reverse DNS. In het voorbeeld van RFC 5782 wordt 192.0.2.99 tegen een lijst op bad.example.com gecontroleerd door het volgende op te zoeken:
99.2.0.192.bad.example.comHet A-record zegt "gelist", het TXT-record zegt waarom
- A-record. Elke gelistte vermelding moet een A-record hebben. Volgens de conventie is de waarde 127.0.0.2. De waarde is een signaal, geen adres, en mag niet als adres worden gebruikt; lijsten gebruiken het bereik 127.0.0.0/8 zodat een per ongeluk gebruikte waarde geen ongewenst netwerkverkeer veroorzaakt.
- Niet gelist. Staat het adres niet op de lijst, dan zijn er geen records voor, en geeft de query normaal gesproken NXDOMAIN terug.
- TXT-record. Een DNSBL hoort een TXT-record te publiceren met de reden voor de listing. Clients moeten het A-record controleren en mogen ook het TXT-record controleren.
- Verschillende waarden voor verschillende sublijsten. Een gecombineerde lijst kan verschillende waarden 127.0.0.x teruggeven om aan te geven welke sublijst een match gaf, of meerdere A-records tegelijk. De betekenis verschilt per lijst, dus lees altijd de documentatie van de beheerder. Onze gids over DNSBL-retourcodes behandelt de gangbare codes.
Vanuit een terminal (de zone is hier een voorbeeld):
dig +short 99.2.0.192.bad.example.com A
dig +short 99.2.0.192.bad.example.com TXTTestvermeldingen
RFC 5782 vereist dat IPv4-lijsten een vermelding voor 127.0.0.2 bevatten en geen vermelding voor 127.0.0.1. Van clients wordt verwacht dat ze deze testvermeldingen controleren voordat ze een zone vertrouwen, en dat ze geen zone gebruiken die er onjuist op antwoordt.
IPv6: het nibble-formaat
Een IPv6-adres wordt volledig uitgeschreven als 32 hexadecimale cijfers en daarna per cijfer (per nibble) omgedraaid, met een punt tussen elk cijfer, gevolgd door de zone van de lijst. Het voorbeeld uit de RFC, voor 2001:db8:1:2:3:4:567:89ab op ugly.example.com:
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ugly.example.comIPv6-lijsten moeten de testvermelding ::FFFF:7F00:2 bevatten (127.0.0.2 als IPv4-mapped adres) en mogen ::FFFF:7F00:1 niet bevatten. Niet elke lijst ondersteunt IPv6, dus controleer de documentatie van de beheerder voordat u op een IPv6-lookup vertrouwt.
IP-gebaseerde en domeingebaseerde lijsten
Lijsten zijn grofweg in twee soorten te verdelen, afhankelijk van wat ze bevatten.
| Type | Opgezochte naam | Wat ontvangers meestal controleren |
|---|---|---|
| IP-gebaseerd | Omgekeerd IP-adres plus de zone | Het IP-adres van de verbindende server; IP-adressen in Received-headervelden |
| Domeingebaseerd (RHSBL) | Domeinnaam plus de zone | De HELO-naam, het MAIL FROM-domein, domeinen in links in de berichttekst |
In het domeinvoorbeeld van RFC 5782 wordt invalid.edu tegen doms.example.net gecontroleerd door invalid.edu.doms.example.net op te zoeken. Domeingebaseerde lijsten worden soms RHSBL (right-hand-side blacklist) genoemd. Hun testvermeldingen gebruiken gereserveerde namen: de lijst moet TEST bevatten en mag INVALID niet bevatten.
De Spamhaus Domain Blocklist (dbl.spamhaus.org) is een veelgebruikt voorbeeld, en de documentatie ervan noemt een paar praktische punten:
- De lijst bevat alleen domeinen. Een query met een IP-adres geeft altijd een code "gelist" terug, dus de lijst mag niet als algemene IP-DNSBL worden ingesteld. Spamhaus raadt ZEN (zen.spamhaus.org) aan voor IP-lookups.
- U kunt een volledige hostnaam opvragen; die geeft een match als het domein van de host gelist is.
- Tijdens de SMTP-sessie wordt de lijst gecontroleerd tegen de HELO-string en het MAIL FROM-domein. Nadat het bericht is geaccepteerd, wordt gecontroleerd op domeinen in de headers en de tekst, zoals URL's en contactadressen.
Het praktische gevolg: een schoon verzendend IP-adres garandeert geen aflevering. Een gelist verzenddomein, of een gelist domein waarnaar in het bericht wordt gelinkt, kan nog steeds tot een blokkade leiden.
Hoe ontvangende servers DNSBL's gebruiken
RFC 5782 beschrijft de gangbare opzet. Een mailserver controleert bij elke inkomende SMTP-verbinding een ingestelde reeks DNSxL's. Een treffer op een blacklist leidt ertoe dat de verbinding wordt geweigerd; een treffer op een whitelist leidt tot acceptatie. Als alternatief gaan de resultaten naar een scorefunctie die ze samen met andere signalen weegt. Filters die na ontvangst van het bericht draaien, halen de te testen IP-adressen meestal uit de Received-headervelden of uit URI's in de tekst.
Weigeren of scoren?
Die keuze ligt bij de ontvanger. De eigen FAQ van SpamCop noemt de lijst een agressief hulpmiddel en raadt aan vermoedelijke spam te labelen of om te leiden, of de lijst als één factor in een score te gebruiken, in plaats van mail direct te weigeren. Instellingen om te weigeren worden daar beschreven als informatie voor beheerders die geen subtielere aanpak kunnen gebruiken.
Valkuilen waarvoor ontvangers worden gewaarschuwd
- U besteedt een oordeel uit. Met een DNSxL legt u een deel van het beheer van uw server bij de lijstbeheerder. Volgens de RFC moet u nagaan of het beleid van de lijst strookt met uw eigen beleid.
- Opgeheven lijsten. Een beheerder die een lijst opheft, kan een wildcard installeren die elk adres listet. Aan de hand van de bovengenoemde testvermeldingen merkt een client dit op.
- Caching. Servers mogen resultaten cachen, maar moeten TTL's respecteren en verlopen records weggooien.
- Publieke resolvers. Volgens de FAQ van Spamhaus geven queries via Google Public DNS in de meeste gevallen "niet gelist" terug, waardoor echte listings worden gemist. Codes in 127.255.255.x zijn fouten, zoals 127.255.255.254 voor een query via een geblokkeerde publieke resolver, en mogen niet als "gelist" worden gelezen. Spamhaus merkt op dat sommige servers hierdoor ten onrechte alle mail weigeren, en raadt aan een eigen resolver te draaien.
Dit is een van de redenen waarom twee controletools het over hetzelfde adres oneens kunnen zijn: ze stellen hun vraag mogelijk via verschillende resolvers.
Blacklists en whitelists (DNSBL en DNSWL)
Een DNSBL en een DNSWL worden op dezelfde manier bevraagd, maar een match betekent het tegenovergestelde. Volgens RFC 5782 gebruiken netwerkbeheerders DNSBL's doorgaans om verkeer te blokkeren en DNSWL's om verkeer bij voorrang te accepteren. Dezelfde lijst kan in de ene context zelfs als blacklist dienen en in een andere als whitelist.
| Aspect | DNSBL (blacklist) | DNSWL (whitelist) |
|---|---|---|
| Doel | Weigeren of afwaarderen | Accepteren of pluspunten geven |
| TXT-record | Hoort de listing toe te lichten | Minder nuttig, omdat SMTP een client niet kan vertellen waarom die is geaccepteerd; sommige lijsten publiceren er toch een |
| Waarde van het A-record | Gelist of niet, en welke sublijst | Kan een reputatie- of betrouwbaarheidsscore bevatten |
dnswl.org (list.dnswl.org) is een voorbeeld van een whitelist. Volgens de documentatie hebben antwoorden de vorm 127.0.x.y, waarbij x een categorie is en y een vertrouwensniveau van 0 (geen) tot 3 (hoog). Er wordt voorgesteld gelistte hosts greylisting en blacklistcontroles te laten overslaan, hosts met gemiddeld en hoog vertrouwen spamfiltering te laten overslaan, en virusscans nooit over te slaan. Hoeveel een vermelding op een whitelist vrijstelt, blijft de beslissing van de ontvanger.
Veelvoorkomende redenen waarom een IP-adres of domein wordt gelist
Elke beheerder bepaalt zijn eigen criteria, en veel beheerders houden de precieze aanleidingen geheim. De onderstaande redenen komen uit de gepubliceerde documentatie van de beheerders.
- Spammeldingen en spamtraps. De SpamCop Blocking List bevat IP-adressen die mail hebben verstuurd die door gebruikers van SpamCop is gemeld, waarbij mail naar spamtraps (adressen die door spammers zijn verzameld of aangemaakt) zwaarder weegt. Volgens de FAQ duurt een listing zonder verdere meldingen slechts 24 uur, en worden adressen automatisch verwijderd wanneer de meldingen stoppen.
- Geïnfecteerde of gecompromitteerde apparaten. De Spamhaus XBL listet IP-adressen automatisch op basis van aanwijzingen zoals malware, "gratis VPN"-apps die verkeer van derden via het apparaat doorsturen, deelname aan brute-force-aanvallen of pogingen om mail met gestolen inloggegevens te relayen. Blijft de oorzaak bestaan, dan wordt het IP-adres bij de volgende verbinding opnieuw gelist.
- Verkeerde configuratie en slecht lijstonderhoud. De Spamhaus CSS noemt HELO-namen die niet overeenkomen met de forward DNS, gecompromitteerde websites en CMS-installaties, onveilige configuraties en slecht onderhouden mailinglijsten. Er staat dat de oorzaak vóór verwijdering moet worden gevonden en verholpen.
- Beleidslistings. De Spamhaus PBL omvat adresruimte, vaak voor breedband bij particulieren, die geen mail rechtstreeks hoort te versturen. Volgens Spamhaus is een PBL-listing niet het gevolg van iets wat de eindgebruiker heeft gedaan; van mail uit zulke ranges wordt verwacht dat die via een geauthenticeerde SMTP-server wordt verstuurd.
- Gedeelde infrastructuur. Bij shared hosting kan het verzendgedrag van een andere klant het IP-adres raken dat u gebruikt. Zie wat u kunt doen als een IP-adres van shared hosting op een blacklist staat.
Welke rol DNSBL's spelen als e-mail niet aankomt
Een DNSBL-listing is één mogelijke oorzaak van niet-afgeleverde mail, niet de enige. Verkeerde adressen, volle mailboxen, problemen aan de kant van de ontvanger en ontbrekende authenticatie kunnen ook bounces veroorzaken. Speelt er een lijst mee, dan noemt de bouncemelding die vaak of bevat die een URL om op te zoeken.
- Lees de bounce. Noteer de antwoordcode en een eventuele lijstnaam of URL in de tekst.
- Bepaal uw verzendende IP-adres en domein. Gebruik de Received-regels in de headers, of vraag het aan de beheerder van de server.
- Controleer de grote lijsten in één keer. Gebruik de blacklistchecker en bevestig een eventuele treffer daarna op de eigen lookuppagina van de beheerder.
- Verhelp de oorzaak. Loop de oorzaken hierboven na. Verzoeken die worden ingediend voordat de oorzaak is verholpen, eindigen meestal in een nieuwe listing.
- Volg de procedure van die beheerder. Sommige lijsten vervallen vanzelf, sommige werken met een verwijderingsverzoek, en sommige accepteren alleen verzoeken van de eigenaar van het netwerk. De beslissing over delisten ligt altijd bij de lijstbeheerder, en een verzoek is geen belofte van verwijdering.
Ontvangers passen ook hun eigen filtering toe, dus mail komt mogelijk niet meteen weer door op het moment dat een listing afloopt. Voor de volledige stappen bij het oplossen, zie e-mail op een blacklist: zo leest u de bounce, en voor authenticatie SPF, DKIM en DMARC instellen. Lukt het niet om zelf de oorzaak te vinden, dan kunt u ons om hulp vragen.
Wij brengen u in contact met dienstverleners die verwijderingsverzoeken, consultancy en advies verzorgen (vanaf JPY 50,000). Over verwijdering beslist de beheerder van elke lijst; die kan niet worden beloofd.
Hulp vragenDeze website kan een doorverwijzingsvergoeding ontvangen van de vermelde dienstverleners. About
Veelgestelde vragen
Is een RBL hetzelfde als een DNSBL?
In de praktijk wel. RBL was de naam van de oorspronkelijke lijst die in 1997 werd gestart, en RFC 5782 gebruikt DNSBL als algemene term. Tegenwoordig gebruiken de meeste mensen de twee woorden door elkaar.
Een lookup gaf 127.0.0.2 terug. Wat betekent dat?
Volgens de conventie uit RFC 5782 betekent 127.0.0.2 dat het adres gelist is. Gecombineerde lijsten gebruiken verschillende waarden voor verschillende sublijsten, en sommige waarden, zoals de codes 127.255.255.x van Spamhaus, zijn fouten en geen listings. Raadpleeg de documentatie van de beheerder voor de precieze betekenis.
Als ik op een DNSBL sta, komt dan al mijn e-mail terug?
Niet per se. Elke ontvanger kiest zelf welke lijsten hij gebruikt en of hij bij een treffer weigert of alleen punten aan een spamscore toevoegt. Daarom kan mail aan sommige ontvangers mislukken terwijl mail aan andere nog wel aankomt.
Kunnen IPv6-adressen tegen een DNSBL worden gecontroleerd?
RFC 5782 definieert een IPv6-formaat waarbij het volledige adres per hexadecimaal cijfer wordt omgedraaid. Niet elke lijst ondersteunt IPv6, dus controleer of de lijst die voor u van belang is IPv6 ondersteunt.
Betekent een vermelding op een whitelist dat mijn mail nooit wordt gefilterd?
Nee. Een vermelding op een whitelist is een signaal dat de ontvanger naar eigen inzicht mag gebruiken. dnswl.org stelt bijvoorbeeld voor alleen bij vermeldingen met gemiddeld en hoog vertrouwen spamfiltering over te slaan, en virusscans nooit over te slaan.
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: Domain Blocklist (DBL)
- Spamhaus: Exploits Blocklist (XBL)
- Spamhaus: Combined Spam Sources (CSS)
- Spamhaus: Policy Blocklist (PBL)
- SpamCop FAQ: What is the SpamCop Blocking List (SCBL)?
- SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
- dnswl.org: Return codes and recommended usage
Gerelateerde handleidingen
Zo leest u DNSBL-retourcodes: wat 127.0.0.2 betekent volgens RFC 5782, codes van Spamhaus, SpamCop en UCEPROTECT, foutcodes en NXDOMAIN of SERVFAIL.
Door een blacklist geblokkeerd? Lees de bouncecode, controleer de oorzaken op volgorde, zie welke vermeldingen tellen en vraag correct om verwijdering.
Op een Spamhaus-lijst? Zie op welke lijst u staat (ZEN, PBL, XBL, CSS, SBL, DBL), wat de retourcodes betekenen en hoe u per lijst verwijdering aanvraagt.