E-mail blacklist check: wat lookup-tools je niet vertellen

Voer je verzend-IP door een lookup over meerdere lijsten en je krijgt een tabel met groene en rode rijen. Die tabel beantwoordt één smalle vraag: staat dit adres nu op een set publieke DNS-blocklists? Een e-mail blacklist check vertelt je niet of Gmail, Outlook of een zakelijke gateway je volgende bericht accepteert. Wie die twee als dezelfde vraag behandelt, maakt de meeste incidenttijdlijnen onduidelijk.

Dit artikel laat zien wat een check echt opvraagt, hoe je er zelf één draait met dig, welke resultaatcodes "schoon" betekenen en welke "je query is geweigerd", en hoe je het geheel in monitoring zet, zodat je het niet meer met de hand doet om twee uur 's nachts.

Een blacklistcheck is een DNS-query, meer niet

Elke DNS-blocklist (DNSBL) werkt op dezelfde manier. Je keert de octetten van het IPv4-adres om, plakt de zone van de lijst erachter en vraagt om een A-record. RFC 5782 legt de conventie vast: voor 192.0.2.99 tegen bad.example.com is de query 99.2.0.192.bad.example.com. Staat het adres op de lijst, dan krijg je een antwoord in het bereik 127.0.0.0/8. Staat het er niet op, dan krijg je geen record.

Dat is het hele mechanisme. De webtools waarin je een IP plakt, draaien tientallen van deze lookups parallel en zetten de antwoorden om in een overzicht.

# Staat 203.0.113.25 op Spamhaus ZEN?
dig +short 25.113.0.203.zen.spamhaus.org A

# Een lookup tegen een domeinlijst werkt hetzelfde, zonder omkering:
dig +short example.com.dbl.spamhaus.org A

Lege output betekent: niet gelist. Een antwoord 127.x.x.x betekent: gelist, en de laatste octetten vertellen welke sublijst heeft gematcht. Draai je het vanaf een machine die jij beheert, tegen je eigen resolver, dan kun je het scripten, loggen en er een alert op zetten.

Controleer het adres waarmee je mail vertrekt, niet het adres van je website

De eerste fout is het verkeerde IP opzoeken. Je marketingsite, je API en je uitgaande mailrelay zijn meestal drie verschillende adressen. Het adres dat ertoe doet, is het IP in de Received-header van een bericht dat echt in een mailbox is aangekomen.

Verstuur je via een ESP op gedeelde infrastructuur, dan is dat IP niet van jou, en de listing dus ook niet. Verstuur je vanaf een eigen dedicated IP, dan is het volledig van jou, inclusief wat de vorige gebruiker van dat bereik ermee deed.

Haal het verzend-IP uit een echt afgeleverd bericht, niet uit een instelling in een dashboard. Controleer daarna drie dingen apart: het verzend-IP, de envelop- en From-domeinen, en elk domein in je links, inclusief tracking- en uitschrijfhosts. URI-lijsten zoals URIBL en SURBL scoren de links in de berichttekst. Een schoon IP beschermt dus geen bericht dat naar een gelist domein verwijst.

Een schoon resultaat via een publieke resolver kan een weigering in vermomming zijn

Dit is de faalwijze die generieke checker-pagina's nooit noemen. Spamhaus beantwoordt geen queries die via publieke of open resolvers binnenkomen, en geeft dat aan met een retourcode in plaats van een listing. Spamhaus documenteert 127.255.255.254 als foutcode, geen reputatieresultaat, en zegt dat je er nooit mail mee mag weigeren.

Dat heeft twee gevolgen. Als je script elk 127.x-antwoord als "gelist" leest, dan zet een geweigerde query vanaf een cloudresolver je alarm af voor een listing die niet bestaat. Als je script "geen bruikbaar antwoord" als "schoon" leest, mis je stilzwijgend echte listings, want de weigering kan ook verschijnen als een leeg antwoord of NXDOMAIN.

De oplossing: draai lookups vanaf een host met een eigen recursieve resolver en goede reverse DNS, of gebruik de gratis querydienst waar Spamhaus gebruikers van publieke mirrors naartoe stuurt. Valideer daarna de zone voordat je iets erop vertrouwt. RFC 5782 schrijft voor dat IPv4-lijsten een vermelding voor 127.0.0.2 moeten hebben en er geen voor 127.0.0.1, dus test je opzet zo:

dig +short 2.0.0.127.zen.spamhaus.org A   # moet een 127.x-antwoord geven
dig +short 1.0.0.127.zen.spamhaus.org A   # moet niets teruggeven

Geven beide niets terug, dan is je resolverpad kapot of geweigerd. Repareer dat voordat je een resultaat ervan leest.

De meeste bezorgincidenten zijn geen blocklistincidenten

Bij elke bouncereview die we doen, is de eerste vraag wat de ontvangende server precies heeft gezegd, nog vóór we iets opzoeken. Een listing geeft een specifieke afwijzing. Reputatieproblemen bij een mailboxprovider geven een andere, en geen publieke lijst laat die zien.

De verzenddocumentatie van Google is hier duidelijk over. Een 550 5.7.1 kan betekenen dat het verzend-IP op een opgeschorte lijst staat, vaak door een slechte reputatie van een gedeeld IP, terwijl 5.7.26 wijst op mislukte authenticatie. Voor bulkafzenders eist Google SPF, DKIM en DMARC, geldige forward- en reverse DNS op het verzend-IP, TLS en een spamratio onder 0.30% in Postmaster Tools. De Gmail-verzendvereisten noemen 0.10% als aanbevolen doel.

Lees dat als volgorde van werkzaamheden. Als de bouncetekst een DNSBL-zone of -URL noemt, heb je een listingprobleem. Gaat het over reputatie, authenticatie of een snelheidslimiet, dan komt een blocklistcheck schoon terug en ben je een uur kwijt aan het bevestigen van iets wat niet klopt.

• Noemt een DNSBL-zone of -URL: je staat op die specifieke lijst. Draai de lookup en gebruik daarna de verwijderpagina van die lijst.

• 550 5.7.1 met woorden als "IP reputation": reputatie aan de kant van de provider, vaak op een gedeeld IP. Controleer Postmaster Tools en de trend in volume en klachten.

• 5.7.26: authenticatie is mislukt. Controleer de uitlijning van SPF, DKIM en DMARC.

• 4.7.28 of tekst over snelheid: je verstuurt sneller dan je huidige reputatie toelaat. Vertraag en bouw daarna weer langzaam op.

Sla de eenmalige webchecker over als je monitoring

Een eenmalige lookup vertelt je de stand op het moment dat je op enter drukte. Listings zijn vaak tijdelijk, en veel verschijnen na een piek die je zelf hebt veroorzaakt: een koude import, een blast om opnieuw toestemming te vragen, of een gecompromitteerd formulier dat iemand gebruikte om spam door te sturen.

De tools die geld vragen om je van "100 blacklists" af te halen, verkopen een dienst voor een probleem dat de meeste van die lijsten niet hebben. Veel lijsten in een brede multicheck hebben weinig invloed op grote mailboxproviders, en verwijdering gaat meestal gratis en zelfbediend via de eigen pagina van de operator. Elke rode rij najagen kost tijd die je beter besteedt aan de twee of drie lijsten die je ontvangers daadwerkelijk raadplegen.

Rangschik lijsten op het verkeer dat je verstuurt. Kijk welke ontvangers in je bounces voorkomen, zoek uit welke lijsten die ontvangers publiekelijk gebruiken, en houd die in de gaten. Al het andere is ruis die je maandelijks kunt nalopen.

Maak van de check een geplande taak met een alertdrempel

Dit is de minimale versie die standhoudt. Hij draait vanaf een host met een echte resolver, valideert eerst de zone en onderscheidt de drie uitkomsten: gelist, niet gelist en query geweigerd.

import socket

def dnsbl(ip: str, zone: str) -> str:
    rev = ".".join(reversed(ip.split(".")))
    try:
        answer = socket.gethostbyname(f"{rev}.{zone}")
    except socket.gaierror:
        return "not_listed"
    if answer.startswith("127.255.255."):
        return "refused"   # foutcode, geen reputatieresultaat
    return f"listed:{answer}"

# Controleer de zone voordat je erop vertrouwt (RFC 5782-testvermeldingen)
assert dnsbl("127.0.0.2", "zen.spamhaus.org").startswith("listed")
assert dnsbl("127.0.0.1", "zen.spamhaus.org") == "not_listed"

Draai de check elke 15 tot 60 minuten per verzend-IP en per verzenddomein, log elk resultaat met een tijdstempel en alarmeer alleen bij een overgang van not_listed naar listed. Alarmeer apart op refused, want dat betekent dat je monitoring blind is, niet dat je reputatie is veranderd.

Combineer dit met de signalen waar blocklists achteraan lopen. De klachtenratio uit de Postmaster-dashboards, het bouncepercentage per ontvangend domein en het aantal uitgestelde leveringen per uur bewegen vóór een listing verschijnt. Zij vertellen je of je een verzending moet pauzeren. Als je logs en metrics al naar een monitoringstack stuurt, is het lookupresultaat gewoon weer een tijdreeks.

Voor deze workflow passen vier tools, afhankelijk van waar het pijnpunt zit.

Postmark is alleen voor transactionele mail, dus je wachtwoordresets delen geen verzendpad met de nieuwsbrief van iemand anders. Als je listings steeds terugleiden naar een buur op gedeelde infrastructuur, is het scheiden van transactionele en marketingverzending de structurele oplossing.

Resend is de developer-first optie als je een schone API wilt en een klein oppervlak om te instrumenteren. Het loont als je team toch al zijn eigen deliverability-checks script.

SendGrid heeft de langste staat van dienst op volume en biedt dedicated IP's, waardoor de reputatie en de blootstelling aan blocklists alleen van jou zijn. Sla het over als je de opwarmfase en de monitoring die dedicated IP's vragen niet kunt bemannen.

Better Stack is het stuk voor de geplande-taakkant: uptimechecks, alerting en on-call-routering voor het lookupscript hierboven, zodat een nieuwe listing bij een mens terechtkomt en niet in een logbestand.

Als je op een lijst staat, los eerst de oorzaak op voordat je verwijdering vraagt

Verwijderen zonder rootcause koopt je een paar dagen. De operator van een lijst die hetzelfde adres met hetzelfde gedrag ziet terugkeren, zet het er opnieuw op, en sommige operators escaleren bij herhaalde listings.

Werk in deze volgorde:

1. Stop of vertraag het verzenden vanaf het gelistte IP. Verder slecht verkeer verlengt de listing en voegt er nieuwe toe.

2. Lees het listingrecord van de lijstoperator. Veel vermelden het bewijs: een spamvalhit, een piek of een misbruikmelding van de relay.

3. Zoek de bron. Controleer formulierendpoints op misbruik als open relay, kijk naar recente lijstimporten en bekijk elke nieuwe integratie die de afgelopen week is gaan versturen.

4. Los de oorzaak op en gebruik daarna het verwijderproces van de operator. Sommige lijsten laten listings automatisch verlopen na een rustige periode.

5. Hervat op verminderd volume, eerst naar je meest betrokken ontvangers, en houd klachtenratio en uitstel een week lang in de gaten.

Ontbrekende reverse DNS is een terugkerende oorzaak. Google noemt geldige PTR-records in zijn verzendvereisten, en een verzend-IP zonder PTR wordt door veel ontvangers als laag vertrouwd gezien, nog voordat de inhoud is beoordeeld.

Bouw de lifecycle-flow rond het signaal, niet rond de lijst

Als je product activatie-, factuur- of beveiligingsmail verstuurt, is een listing een beschikbaarheidsincident voor die flows. Behandel het zo: stuur transactionele mail via een pad dat geïsoleerd is van het marketingvolume, en laat de triggerlaag de bezorgstatus kennen, zodat een vastgelopen activatiemail terugvalt op een prompt in de app.

Customer.io wordt vaak gecombineerd met een aparte bezorgprovider om precies deze reden: gedragstriggers en berichtlogica zitten op één plek, bezorging op een andere, en je kunt bezorging wisselen of splitsen zonder flows te herschrijven. De afweging is één systeem extra dat je observeerbaar moet houden.

Dat scheidingsprincipe is het deel dat het waard is om over te nemen, ook als je andere leveranciers kiest. Een blocklistgebeurtenis moet bepalen waar een bericht heen gaat, niet of je lifecycle-logica werkt.

Wat we deze week zouden inrichten

Drie dingen, op volgorde van opbrengst. Ten eerste een geplande lookup met zonevalidatie en een aparte toestand refused, draaiend vanaf een host met een eigen resolver. Ten tweede de uitsplitsing van je bounces per ontvangend domein, zodat je weet welke lijsten er voor jouw verkeer toe doen. Ten derde een schriftelijk runbook dat begint bij de bouncetekst en eindigt bij de verwijderstap, zodat wie er dienst heeft niet hoeft te improviseren.

Welk van je verzenddomeinen zou je een dag lang niet merken als het op een lijst stond?