Blacklist-Prüfung des MX-Records: Eine praktische Anleitung

Sie haben gerade eine Kampagne gestartet, und die Bounce-Benachrichtigungen treffen bereits ein. In einigen Nachrichten wird ein RBL erwähnt, andere melden „Service unavailable; Client host blocked“, und die Platzierung im Posteingang ist ohne erkennbare Änderung am Text zurückgegangen. Bevor Sie die Kampagne neu schreiben oder die Warm-up-Einstellungen anpassen, führen Sie eine Blacklist-Prüfung von MX-Records durch.

Die Prüfung beantwortet eine eng gefasste, aber wichtige Frage: Sind die mit Ihrer Domain verbundenen Mailserver-IP-Adressen derzeit in öffentlichen DNS-basierten Blacklists aufgeführt? Dies ist kein vollständiges Urteil über die Zustellbarkeit, aber eine gelistete IP-Adresse kann dazu führen, dass ein empfangender Mail Transfer Agent eine Nachricht ablehnt, bevor Authentifizierung, Inhalt oder Engagement-Signale helfen können. Der praktische Ablauf ist im Prinzip einfach: MX-Records auflösen, jedes Ziel in eine IP-Adresse umwandeln, DNSBLs abfragen, die Antworten interpretieren und anschließend die Ursache untersuchen.

Warum eine Blacklist-Prüfung von MX-Records als Erstes durchgeführt werden sollte

Der Fehler tritt normalerweise zum denkbar schlechtesten Zeitpunkt auf. Ein Marketer bemerkt einen plötzlichen Rückgang zugestellter Nachrichten, ein Vertriebsteam meldet, dass Sequenzen zurückgewiesen werden, oder ein Kunde teilt mit, dass eine Transaktions-E-Mail nie angekommen ist. Die SMTP-Antwort kann einen Code wie 554 oder eine Formulierung wie „Service unavailable; Client host blocked“ enthalten, doch die Meldung erklärt selten die gesamte betriebliche Situation.

Hinter dieser Antwort kann der empfangende Server die verbindende IP-Adresse gegen eine DNS-basierte Blacklist geprüft haben. Wenn die IP-Adresse auf einer Liste erscheint, der der Anbieter des Empfängers vertraut, kann der empfangende Mail Transfer Agent die Verbindung mit einer 5xx-Antwort ablehnen. Die Nachricht erreicht nie die Phase, in der SPF, DKIM, Inhaltsqualität oder das Engagement der Empfänger das Ergebnis beeinflussen könnten.

Praktische Regel: Prüfen Sie, ob eine Mailserver-IP-Adresse blockiert ist, bevor Sie Zeit in die Optimierung von Betreffzeilen oder die Änderung des Versandvolumens investieren.

Eine Blacklist-Prüfung von MX-Records beginnt bei der Infrastruktur, die für den Empfang von E-Mails für die Domain verantwortlich ist. Eine Domain kann mehrere MX-Hosts veröffentlichen, und jeder Hostname kann zu einer oder mehreren IP-Adressen aufgelöst werden. MXToolbox beschreibt einen Ablauf, der die IP-Adresse jedes MX-Records gegen 105 DNS-basierte Blacklists prüft, während die Seite zu den Domain-Tools eine Abdeckung von 100+ Blacklist-Quellen beschreibt (MXToolbox). Diese Breite ist wichtig, da ein MX-Host unauffällig sein kann, während ein anderer einen Eintrag aufweist.

Die Diagnose-Reihenfolge, die Zeit spart

Wenn ein Bounce auf eine RBL hindeutet, gehe ich in dieser Reihenfolge vor:

1. Den betroffenen Pfad bestätigen. Feststellen, ob die abgewiesene Nachricht von der eigenen SMTP-Infrastruktur, einem gehosteten Anbieter oder einer gemeinsam genutzten Versandplattform stammt.
2. Jedes MX-Ziel auflösen. Nicht nur die Domain-Bezeichnung testen. Jeden Mail-Host und seine aufgelöste IP-Adresse ermitteln.
3. Mehrere DNSBLs abfragen. Ein einzelnes sauberes Ergebnis kann irreführend sein, wenn eine andere Liste einen relevanten Eintrag enthält.
4. Den Grund für den Eintrag dokumentieren. Ein Richtlinieneintrag, ein Befund zu einem offenen Relay und ein Eintrag als Spamquelle erfordern unterschiedliche Reaktionen.
5. Nach der Behebung erneut testen. Die Entfernung von Blacklist-Einträgen und DNS-Änderungen werden nicht immer überall gleichzeitig sichtbar.

Für eine umfassendere Posteingangsdiagnose nach der Blacklist-Prüfung verwenden Sie einen E-Mail-Zustellbarkeitstester für Teams. Der Unterschied ist wichtig: Die Blacklist-Prüfung von MX-Records identifiziert eine mögliche Infrastruktursperre, während ein Zustellbarkeitstest den umfassenderen Weg zum Posteingang untersucht.

MX-Einträge auflösen und die richtigen Mailserver-IP-Adressen abrufen

DNSBL-Abfragen zielen normalerweise auf IP-Adressen, nicht auf den sichtbaren Domainnamen. Das bedeutet, dass die erste technische Aufgabe darin besteht, die MX-Einträge der Domain den tatsächlichen Hosts zuzuordnen und diese Hosts anschließend den Adressen zuzuordnen.

Beginnen Sie mit einer direkten MX-Abfrage:

dig MX domain.com +short

Eine typische Antwort sieht so aus:

10 mail.domain.com.

Die Zahl ist die MX-Priorität. Niedrigere Werte werden bevorzugt, wenn mehrere Server verfügbar sind. Der darauf folgende Hostname ist das Ziel, das als Nächstes aufgelöst werden muss.

Sie können dieselbe Prüfung durchführen mit:

nslookup -type=mx domain.com

Die entsprechende Hostname-Abfrage lautet:

dig A mail.domain.com +short

oder:

nslookup -type=a mail.domain.com

Die Ausgabe liefert Ihnen die zu testende IPv4-Adresse oder die zu testenden IPv4-Adressen. Wenn der Host außerdem IPv6 veröffentlicht, prüfen Sie seinen AAAA-Eintrag separat. Einige DNSBLs indexieren IPv6 nicht auf dieselbe Weise wie IPv4. Daher beschreibt ein scheinbar eindeutiges IPv4-Ergebnis nicht automatisch den IPv6-Pfad.

Was Sie prüfen sollten, wenn das Ziel nicht Ihnen gehört

Ein MX-Eintrag kann auf Google, Proofpoint oder einen anderen gehosteten E-Mail-Anbieter verweisen. In dieser Situation gehört der MX-Host dem Anbieter, nicht Ihrem Unternehmen. Sie sollten die Dokumentation und den Support-Prozess des Anbieters prüfen, bevor Sie einen Eintrag als Fehler behandeln, den Sie direkt beheben können.

CNAME-Ketten sind eine weitere häufige Ursache für Verwirrung. Folgen Sie der Kette, bis Sie die Adress-Einträge erreichen, und bewahren Sie die Beziehung zwischen jedem MX-Hostnamen und seiner aufgelösten IP-Adresse. Fassen Sie nicht mehrere Ziele zu einem einzigen Domain-Status zusammen, da jeder Host ein anderes Ergebnis haben kann.

Ein praktisches Tool zum Prüfen von Mail-Exchange-Einträgen kann dabei helfen, die öffentliche DNS-Ansicht zu überprüfen. Befehlszeilenabfragen bleiben jedoch nützlich, da sie genau zeigen, was ein Resolver zum Zeitpunkt der Prüfung zurückgibt. Wiederholen Sie die Abfrage über mehr als ein Netzwerk, wenn das Ergebnis Produktionsentscheidungen beeinflusst. Zwischengespeicherte DNS-Daten, anbieterspezifische Resolver und kürzlich vorgenommene Infrastrukturänderungen können zu unterschiedlichen Beobachtungen führen.

DNSBLs abfragen und die Ergebnisse lesen

Nachdem du die aufgelösten MX-IPs gesammelt hast, frage jede Adresse gegen eine ausgewählte DNSBL-Sammlung ab. DNSBLs verwenden die Reverse-Oktett-Notation. Bei einer Beispieladresse wie 1.2.3.4 werden die Oktette vor dem Anhängen der Blacklist-Zone umgekehrt:

dig +short 1.2.3.4.zen.spamhaus.org
dig +short 1.2.3.4.b.barracudacentral.org
dig +short 1.2.3.4.dnsbl.sorbs.net

Die Antwort zeigt, ob diese Liste einen Eintrag für die IP enthält. Ein unauffälliges Ergebnis erscheint üblicherweise als NXDOMAIN oder als leere Antwort. Ein gelistetes Ergebnis gibt eine Adresse im Bereich 127.0.0.0/8 zurück, wobei der abschließende Code die Kategorie des Eintrags für diese DNSBL angibt.

Für Spamhaus werden häufig folgende Beispiele interpretiert:

• 127.0.0.2, auf der Spamhaus-SBL gelistet
• 127.0.0.9, auf der SBL CSS gelistet
• 127.0.0.10, auf der PBL gelistet

Der Code ist nur der Ausgangspunkt. Öffne die eigene Lookup-Seite der DNSBL und lies die aktuelle Erklärung. Notiere die genaue Zone, IP, Kategorie und den Zeitstempel, statt nur „LISTED“ in ein Ticket zu kopieren.

Häufige DNSBL-Antwortcodes und ihre Bedeutung

Eine Einstufung als Spam-Quelle verdient bei ausgehenden E-Mails sofortige Aufmerksamkeit, da sie auf Missbrauch durch die sendende Infrastruktur hindeuten kann. Ein Befund zu einem offenen Relay weist auf ein Serverkonfigurationsproblem hin. Eine Kategorie mit schlechter Reputation kann auf vergangenes Verhalten, Shared Hosting oder Signale zurückzuführen sein, die in der aktuellen Kampagne nicht offensichtlich sind.

Behandle nicht jeden Treffer als gleich wichtig. Mehrere Einträge mit geringer Auswirkung bei einem Anbieter können etwas völlig anderes bedeuten als ein einzelner Eintrag auf einer DNSBL, die ein großer Mailbox-Anbieter aktiv abfragt. Für eine konsolidierte Abfrage kannst du die IP-Blacklist mit BillionVerify prüfen und anschließend schwerwiegende Befunde anhand der eigenen Erklärung und Entfernungspolitik der jeweiligen Liste validieren.

Warum ein sauberes Blacklist-Ergebnis dennoch eine schlechte E-Mail-Zustellbarkeit bedeuten kann

Ein sauberes DNSBL-Ergebnis belegt lediglich, dass die abgefragten öffentlichen Listen keine Auflistung für die getestete IP zurückgegeben haben. Es beweist nicht, dass ein Mailbox-Provider dem Absender vertraut, dass die Authentifizierung übereinstimmt oder dass Empfänger die Nachrichten wünschen.

Die Platzierung im Posteingang lässt sich besser als Zusammenspiel mehrerer gemeinsam bewerteter Ebenen verstehen:

• IP-Reputation spiegelt den bisherigen Versandverlauf, Beschwerdemuster und Änderungen des Versandvolumens wider.
• Domain-Reputation verknüpft die From-Domain mit der damit verbundenen Infrastruktur und dem zugehörigen Verhalten.
• Authentifizierung umfasst die SPF-, DKIM- und DMARC-Authentifizierung sowie deren Übereinstimmung.
• Provider-spezifische Filterung wendet die internen Reputations-, Inhalts- und Engagement-Modelle des jeweiligen Mailbox-Providers an.

Eine DNSBL-Antwort ist nahezu binär: gelistet oder sauber. Die Platzierung im Posteingang ist eine gewichtete Entscheidung, die aus vielen Signalen gebildet wird, sodass die beiden Ergebnisse deutlich voneinander abweichen können.

Ein realistisches Szenario: sauber, aber gefiltert

Angenommen, die MX-IP ist in den öffentlichen DNSBLs sauber. Gmail kann die Kampagne dennoch als Spam einstufen, wenn sich die IP-Reputation des Absenders verschlechtert hat, die Beschwerdeaktivität gestiegen ist oder das Versandmuster der Domain inkonsistent wirkt. Eine DKIM-Signatur kann außerdem technisch gültig sein und dennoch die Übereinstimmungsbeziehung verfehlen, die DMARC bewertet. Beispielsweise kann die Nachricht eine lockere Header-Konfiguration verwenden, während sich die sichtbare From-Domain von der Domain im DKIM-Wert d= unterscheidet. Die Signatur besteht die kryptografische Überprüfung, doch die Identitätsbeziehung kann die Übereinstimmung weiterhin verfehlen.

Deshalb sollte ein sauberes Blacklist-Ergebnis die nächsten Prüfungen auslösen und den Vorfall nicht abschließen. Prüfen Sie Authentifizierungsberichte, provider-spezifische Reputationsdaten, Bounce-Klassifizierungen, Beschwerdesignale und das Engagement der Empfänger. Für umfassendere operative Hinweise zur Reduzierung bösartiger Nachrichten und zur Stärkung von E-Mail-Kontrollen bieten diese IT Cloud Global-Tipps zur Phishing-Prävention nützlichen Sicherheitskontext.

Ein separater BillionVerify-IP-Reputationsprüfer kann neben DNSBL-Tests eingesetzt werden, wenn Sie den Status öffentlicher Listen von einer umfassenderen IP-Reputation unterscheiden müssen. BillionVerify ist ein professioneller E-Mail-Verifizierungsdienst, der ein Problem lösen soll: Schlechte E-Mail-Daten kosten Unternehmen Geld.

Das folgende Video liefert zusätzlichen Kontext dazu, wie Reputation und Filterung die Zustellung beeinflussen:

Triage und Behebung, wenn eine MX-IP gelistet ist

Eine Listung ist ein Vorfall, keine Diagnose. Beginnen Sie damit, Beweise zu sichern, bevor Sie DNS ändern oder eine Entfernung beantragen. Erfassen Sie die getestete IP, die genaue DNSBL-Zone, den zurückgegebenen Code, den angegebenen Grund für die Listung und den Zeitpunkt der Abfrage.

Die Abfolge der Behebung

1. Verantwortliche Liste identifizieren. Öffnen Sie die Lookup-Seite der DNSBL und überprüfen Sie, ob das Ergebnis aktuell ist. Prüfen Sie, ob der Eintrag für eine sendende IP, einen eingehenden MX-Host, einen Bereich oder eine Richtlinienkategorie gilt.
2. Richtlinie zur Entfernung lesen. Spamhaus, Barracuda und SORBS verwenden keine identischen Verfahren. Einige Einträge werden entfernt, nachdem das zugrunde liegende Verhalten beendet wurde, während andere eine ausdrückliche Anfrage oder einen vom Provider verwalteten Prozess erfordern.
3. Zuerst die Ursache beheben. Prüfen Sie den Reverse-DNS und stellen Sie sicher, dass die IP über einen geeigneten PTR verfügt. Verschärfen Sie SPF, sodass nur aktuelle Versandquellen autorisiert werden. Rotieren Sie die DKIM-Schlüssel, wenn Sie eine Kompromittierung vermuten, und prüfen Sie aktuelle Kampagnen auf Spam-Trap- oder Aktivitäten mit ungültigen Empfängern.
4. Korrektur dokumentieren. Speichern Sie die relevanten PTR-, SPF- und DKIM-Lookup-Ausgaben, Serveränderungen, Maßnahmen zur Kontosicherheit und Aufzeichnungen zur Listenbereinigung.
5. Anfrage stellen, sobald dies zulässig ist. Verwenden Sie das offizielle Portal der DNSBL, legen Sie präzise Nachweise vor und vermeiden Sie wiederholte Einsendungen, die die Ursache nicht beheben.
6. Nach der geltenden Abkühlzeit erneut abfragen. Bestätigen Sie eine klare Antwort, bevor Sie zum normalen Versandvolumen zurückkehren. Die Entfernung aus einer Liste kann sich asynchron verbreiten. Testen Sie daher bei hohen geschäftlichen Auswirkungen mehr als einmal.

Beantragen Sie keine Entfernung, solange der Missbrauch noch aktiv ist. Eine Listung, die nach der Entfernung erneut erscheint, verursacht in der Regel ein schwierigeres Betriebsproblem als das ursprüngliche Ereignis.

Häufige Ursachen für Listungen und erforderliche Korrekturen

Wenn der MX-Eintrag auf einen gehosteten Provider verweist, senden Sie die Nachweise an diesen Provider, statt Infrastruktur zu ändern, die Sie nicht kontrollieren. Ihr Team sollte den Vorfall dennoch dokumentieren und den Status des Providers überwachen, da ein gemeinsam genutzter oder ausgelagerter E-Mail-Pfad mehrere Domains gleichzeitig beeinträchtigen kann.

Vergleich von Tools und Skripten für Blacklist-Prüfungen von MX-Records

Das richtige Tool hängt davon ab, ob Sie einen einzelnen Vorfall untersuchen oder eine wiederholbare Kontrolle aufrechterhalten. Eine Weboberfläche ist für einen Marketer, der einen einzelnen Bounce bearbeitet, schnell, während eine Befehlszeilenschleife nützlicher ist, wenn Änderungen an der Infrastruktur einen automatisierten Test auslösen sollen.

MXToolbox SuperTool bietet einen praktischen Web-Workflow für Ad-hoc-Diagnosen und kann eine breite Auswahl an DNSBL-Quellen prüfen. MultiRBL ist nützlich, wenn Sie eine umfassende kostenlose Abdeckung benötigen und mehrere IPs übermitteln möchten. Der eigene Checker von Spamhaus ist wichtig, wenn das Ergebnis Spamhaus-Zonen betrifft, da seine Erklärung und Richtlinie die maßgebliche Referenz für diese Einträge sind.

MXToolbox Blacklist Monitor eignet sich für Teams, die Warnmeldungen für überwachte MX-Hosts wünschen, statt eine manuelle Abfrage durchzuführen. Ein Bash-Workflow bietet Ihnen die größte Kontrolle. Lösen Sie die MX-Ziele auf, lösen Sie deren Adressdatensätze auf, durchlaufen Sie eine kuratierte DNSBL-Liste und behandeln Sie NXDOMAIN als unauffällig, während Sie eine A-Record-Antwort als möglichen Eintrag protokollieren. In CI oder cron kann diese Ausgabe ein Ticket erstellen, ohne dass sich jemand an die Prüfung erinnern muss.

Tools zur Prüfung von MX-Record-Blacklists im Vergleich

Die Breite der Abdeckung ist nicht der einzige Kompromiss. Eine große Liste kann Rauschen erzeugen, während eine kuratierte Liste ein anbieterspezifisches Signal übersehen kann. Auch die Latenz von Warnmeldungen ist wichtig, ebenso wie die Frage, ob Ihr Team außerhalb der Geschäftszeiten auf eine Warnmeldung reagieren kann. Für Listenhygiene und die Auswahl eines Verifizierungstools konsultieren Sie BillionVerifys Liste von Verifizierungstools als separate Informationsquelle und nicht als Ersatz für die Überwachung der Infrastruktur.

Aufbau eines wiederholbaren Monitoring- und Verifizierungs-Workflows

Eine einmalige Abfrage findet das heutige Problem. Ein Runbook verhindert, dass dasselbe Problem bis zur nächsten Kampagne bestehen bleibt.

Führen Sie wöchentlich einen DNSBL-Sweep für jede aufgelöste MX-IP durch. Führen Sie täglich einen SPF-, DKIM- und DMARC-Alignment-Test durch, da die Authentifizierung nach einer Änderung bei einem Provider, CRM oder einer Automatisierung beeinträchtigt werden kann. Führen Sie monatlich ein Reverse-DNS-Audit durch, um veraltete PTR-Einträge, außer Betrieb genommene Hosts oder Änderungen bei der Infrastrukturverantwortung zu erkennen.

Legen Sie klare Eskalationsregeln fest. Eine einzelne bestätigte Listung sollte den zuständigen On-Call-Verantwortlichen für die Zustellbarkeit alarmieren. Ein Rückgang der Posteingangsplatzierung um 5 % sollte eine gründlichere Reputationsprüfung auslösen, einschließlich Authentifizierungs-Alignment, Beschwerdesignalen, Inhaltsänderungen und anbieterspezifischer Daten.

Dieselbe Monitoring-Pipeline sollte auch die Listenqualität schützen. Wenn Bounce-Adressen oder nicht verifizierte Kontakte auftauchen, übergeben Sie sie vor dem nächsten Versand einem E-Mail-Verifizierungsprozess. MX-Prüfungen zeigen, ob eine Domain für den Empfang von E-Mails konfiguriert ist, beweisen jedoch nicht, dass ein bestimmtes Postfach existiert. Verifizierungs-Workflows kombinieren häufig MX-Lookup, SMTP-Prüfung und Catch-all-Verarbeitung, da ein Catch-all-Server E-Mails für jeden lokalen Teil akzeptiert und eine einfache SMTP-Prüfung dadurch nicht zwischen einem echten Postfach und einem erfundenen unterscheiden kann (Prospeo). Wenn kein MX-Eintrag vorhanden ist, ist die Domain im Allgemeinen nicht für den Empfang von E-Mails konfiguriert, sodass Adressen unter dieser Domain wahrscheinlich zurückgewiesen werden (Marketing Tech News).

Ein knappes Montags-Runbook umfasst: MX auflösen, jeden DNSBL abfragen, die Authentifizierung überprüfen, Bounce-Adressen verifizieren und die Ergebnisse mit Zeitstempeln protokollieren. Diese Reihenfolge hält die Gesundheit des Mailservers und die Hygiene der Empfängerdaten in derselben operativen Schleife, ohne eine Diagnose mit einer anderen zu verwechseln.

BillionVerify kombiniert E-Mail-Verifizierung für Einzelprüfungen, die Bereinigung umfangreicher Listen und Echtzeit-API-Workflows. So können Teams riskante Adressen erkennen, bevor sie die Absenderreputation schädigen. Verwenden Sie die Ergebnisse zusammen mit Ihrem MX- und DNSBL-Monitoring und besuchen Sie anschließend BillionVerify, um zu bewerten, wie es zu Ihrer Kampagne, Ihrem CRM oder Ihrem Prozess zur Verifizierung von Anmeldungen passt.