Catch-all-Adresse: Domain erkennen und den Status ok4all richtig lesen

CaptainVerify hat 2025 mehr als 126 Millionen E-Mail-Adressen geprüft. Rund 2,5 % des Volumens entfallen auf eine Catch-all-Domain. Bezogen allein auf Adressen mit Unternehmensdomain, ohne die Freemail-Anbieter, die knapp 75 % des geprüften Gesamtvolumens ausmachen, nähert sich der Anteil 11 %, also fast jeder 9. Geschäftsadresse. Diese Messung zählt Adressen. Die deutlich höheren Quoten, die anderswo kursieren, zählen Domains, was eine andere Einheit ist: Eine einzelne Catch-all-Domain kann in Ihrer Datenbank eine Handvoll Adressen tragen oder mehrere Hundert. Bei einer B2B-Datei mit 50.000 Kontakten sind das rund 5.500 Zeilen, deren Gültigkeit vor dem Versand offen bleibt.

Die Domain, die diese Adressen beherbergt, lässt sich mit einem SMTP-Befehl in wenigen Sekunden bestimmen. Die 2 Ebenen gehören getrennt behandelt: Die Erkennung der Domain ist ein reproduzierbarer technischer Test, die Entscheidung über den Versand hängt an Ihren Bounce-Schwellen.

Was ist eine Catch-all-Adresse?

Ein Catch-all ist eine Routing-Regel auf Domain-Ebene: Der empfangende Server nimmt Nachrichten an jedes Postfach der Domain an, ob deklariert oder nicht.

Die Regel sitzt in der Konfiguration der empfangenden Domain, hinter deren MX-Eintrag. Kein einzelnes Postfach trägt dieses Etikett. Der Ausdruck „Catch-all-Adresse“ kursiert als Abkürzung und meint jede Adresse, deren Domain diesen Auffangmodus anwendet.

Ein Beispiel macht die Mechanik greifbar. Die Domain beispiel.de deklariert david@beispiel.de und aktiviert ein Catch-all. Ein Absender tippt daivd@beispiel.de, 2 vertauschte Buchstaben. Auf einer gewöhnlichen Domain weist der Server diese Adresse beim RCPT TO zurück und schickt dem Absender einen dauerhaften Fehler, also eine SMTP-Ablehnung mit eigenem Fehlercode. Auf beispiel.de kommt die Nachricht durch, landet im Auffangpostfach und der Tippfehler bleibt unbemerkt.

Catch-all, Alias, Weiterleitung und Subadressierung auseinanderhalten

Ein Alias deklariert eine zusätzliche Adresse, die auf ein bestehendes Postfach zeigt. Eine Weiterleitung nimmt eine deklarierte Adresse und schickt deren Post an ein anderes Ziel. Die Subadressierung hängt ein Suffix hinter ein Pluszeichen, etwa david+presse@beispiel.de, das der Server auf das Basispostfach zurückführt. Diese 3 Mechanismen greifen auf Adressen, die der Server kennt. Alles außerhalb seiner Liste weist er ab. Das Catch-all greift nach dieser Liste, auf lokalen Teilen, die keine Regel deklariert.

Wozu dient eine Catch-all-Adresse?

Ein Catch-all fängt Post an falsch geschriebene Adressen ab und nimmt einem Angreifer die Antwort, die ihm verraten würde, welche Adressen auf der Domain existieren.

Der erste Nutzen ist banal. Tippfehler häufen sich bei zusammengesetzten Namen, Postfächer ausgeschiedener Mitarbeiter werden noch monatelang angeschrieben. Das Catch-all fängt diese Post auf.

Der zweite Nutzen ist defensiv. Ein Server, der auf unbekannte Adressen mit 550 antwortet, liefert ein kostenloses Orakel: Der Angreifer reicht eine Liste von Vornamen ein und behält die, die der Server annimmt. Die Catch-all-Domain antwortet allen mit 250 und sortiert für ihn nichts mehr vor.

Die Kehrseite landet im Auffangpostfach. Eine Domain, die alles annimmt, zieht Wörterbuchangriffe an, also Massensendungen an kontakt@, admin@, service@, hr@ und einige Hundert Vornamen, bis etwas hängen bleibt. Das Aussortieren fällt dann dem Team zu, das dieses Postfach leert.

Wie erkennt man eine Catch-all-Domain?

Eine Catch-all-Domain erkennen Sie, indem Sie dem Server eine zufällig erzeugte Adresse vorlegen: Nimmt er eine unwahrscheinliche Adresse an, nimmt er auch alles andere an.

Der SMTP-Test Schritt für Schritt: MX, EHLO, MAIL FROM, RCPT TO

1. Die MX-Einträge der Domain auflösen und den mit dem niedrigsten Präferenzwert behalten, also den primären MX. Fehlt ein MX, fällt die Post auf den A-Eintrag der Domain zurück.
2. Eine Verbindung auf Port 25 zu diesem Server öffnen und mit EHLO grüßen, gefolgt von einem Hostnamen, der im DNS auflöst.
3. MAIL FROM mit leerem Envelope oder mit einer tatsächlich erreichbaren Testadresse ankündigen.
4. RCPT TO auf die zu prüfende Adresse senden, dann den Rückgabecode und den begleitenden Text notieren.
5. RCPT TO auf eine zufällige Adresse derselben Domain senden, etwa k7v29xq4m@beispiel.de.
6. Die Sitzung mit QUIT schließen, ohne je zum Befehl DATA überzugehen.

Das Signal liegt auf der Zufallsadresse, die erste Annahme dient nur der Kontrolle, dass sich die Sitzung normal verhält. Planen Sie ein RSET zwischen den 2 RCPT TO-Befehlen ein, denn viele Server kappen die Sitzung nach einem falschen Empfänger. Der Abbruch vor DATA vermeidet die Zustellung einer Nachricht und hinterlässt in den fremden Protokollen nur die Spur einer geöffneten Sitzung. Die sondierende IP braucht einen gültigen PTR-Eintrag, sonst liest sich eine Policy-Ablehnung fälschlich als ungültige Adresse.

250 OK gegen 550: die Antwort des Servers lesen

Die RFC 5321 vom Oktober 2008 legt die Regel in Abschnitt 3.3 fest: Der Server antwortet auf RCPT TO mit 550, wenn der Empfänger nicht zustellbar ist, mit einer Meldung wie „no such user“. Die RFC 3463 vom Januar 2003 präzisiert den zugehörigen erweiterten Code in Abschnitt 3.2: 5.1.1 meldet eine ungültige Zieladresse und einen endgültigen Fehlschlag. Ein 250 auf die Zufallsadresse belegt, dass die Domain beim RCPT TO alles annimmt. Ein Vorbehalt zählt: Manche vorgeschalteten Antispam-Gateways nehmen an dieser Stelle ebenfalls jeden Empfänger an, ohne ein Catch-all anzuwenden. Die weiter unten beschriebene verzögerte Ablehnung erzeugt dieselbe Antwort. Diese Codes betreffen den Envelope, für die Form der Adresse selbst gelten die RFC zur E-Mail-Syntax.

Was den Test verfälscht: geteilter MX, Greylisting, Tarpitting und verzögerte Ablehnung

Der geteilte MX steht bei den Fehlsignalen an erster Stelle. Hunderttausende Domains zeigen bei den großen Hostern auf dieselben Mailserver. Die Empfängerpolitik wird hinter diesem gemeinsamen MX Domain für Domain eingestellt, der Servername sagt also nichts über den Auffangmodus aus.

Greylisting erzeugt ein anderes Rauschen. Der Server antwortet beim ersten Kontakt mit einem temporären 4xx-Fehler und wartet auf einen neuen Versuch, bevor er sich festlegt. CaptainVerify wartet bis zu 30 Minuten und startet die Prüfung erneut, bevor ein Ergebnis feststeht. Adressen, die nach diesem zweiten Anlauf stumm bleiben, gehen in den Status unbekannt und werden wieder gutgeschrieben. Tarpitting gehört zur selben Familie: Der Server verlangsamt seine Antworten absichtlich, um Sonden zu entmutigen.

Die verzögerte Ablehnung erschwert die Lesart zusätzlich. Der Server nimmt den Empfänger beim RCPT TO an und erzeugt einen Bounce, sobald er die Nachricht geschluckt hat. Der Test sieht ein sauberes 250, während der echte Versand einige Minuten später einen dauerhaften Fehler produziert.

Was der Status accept_all in einem Prüfbericht bedeutet

Der Status accept_all, in den Berichten von CaptainVerify ok4all genannt, zeigt an, dass die Domain alle Adressen annimmt und die Prüfung deshalb auf Domain-Ebene endet.

Die Dokumentation von CaptainVerify ordnet ok4all den riskanten Adressen zu und benennt die Wirkung ohne Umschweife: Die Bounce-Rate steigt, die Öffnungsrate sinkt. Der Bericht sagt also 2 Dinge in einer Zeile. Die Domain ist qualifiziert, die Person hinter der Adresse bleibt durch den Versand zu bestätigen.

Lässt sich eine Adresse auf einer Catch-all-Domain prüfen?

Das Protokoll entscheidet nicht, weil der Server allen Adressen der Domain dieselbe Antwort gibt. Möglich bleibt, eine Wahrscheinlichkeit zu schätzen und das Segment danach zu sortieren.

Sehen Sie zuerst nach, was hinter dem MX-Eintrag der Domain steckt. Zeigt er auf ein Security-Gateway, etwa Proofpoint, Mimecast, Barracuda oder Microsoft Defender für Office 365, antwortet das Gateway stellvertretend für die Domain, noch bevor das echte Postfach befragt wird. Der Status accept_all bildet dann eine Filterarchitektur ab statt einer vom Unternehmen gesetzten Auffangregel. Bei Großkunden kommt dieser Fall häufig vor.

Danach kommt die Form der Adresse. Auf einer Domain, deren Postfächer einer sichtbaren Konvention folgen, etwa vorname.nachname, trägt eine Adresse, die dieser Konvention entspricht, eine deutlich höhere Gültigkeitswahrscheinlichkeit als eine beliebige Zeichenfolge. Vergleichen Sie Ihre Zeilen untereinander: Was aus dem Muster fällt, geht ins Testsegment, der Rest bekommt Vorrang.

Ein Prüfdienst fügt schließlich eigene Signale hinzu: das Alter der Domain, die Reputation des Mailanbieters, die Größe der Organisation und die Historie früherer Sendungen. Daraus entsteht ein Vertrauenswert, mit dem sich ein Segment vor dem Versand ordnen lässt.

Ein Catch-all je nach Hoster einrichten oder abschalten

Der Schalter sitzt in der Administrationskonsole der Domain: Domänenmodus unter Microsoft 365, Routing-Regel unter Google Workspace, Standardadresse unter cPanel.

Google Workspace

Google Workspace bietet keine native Catch-all-Funktion. Google veröffentlicht dafür eine Hilfeseite zum Sammelpostfach und nennt den betreffenden Kontotyp Unrecognized oder Catch-all. Die Konfiguration läuft über eine Routing-Regel unter Apps, dann Gmail, dann Routing, mit der Aktion Change envelope recipient für inaktive und nicht erkannte Konten. Post an ein unbekanntes Postfach geht dann an eine benannte Sammeladresse. Zum Rückgängigmachen löschen Sie diese Routing-Regel: Die Domain weist unbekannte Empfänger sofort wieder ab.

Microsoft 365

Das Verhalten hängt vom Modus der akzeptierten Domäne ab, unter Mail flow, dann Accepted domains. Im Modus Authoritative weist die Domain unbekannte Empfänger ab und aktiviert das Directory-Based Edge Blocking, das die Nachricht an der Grenze des Dienstes stoppt. Der Modus Internal relay leitet Post an unbekannte Empfänger an einen anderen Server weiter und erzeugt damit faktisch ein Auffangverhalten.

cPanel

Die Funktion heißt Default Address. Standardmäßig gibt sie dem Absender während der SMTP-Sitzung einen Fehler zurück, das genaue Gegenteil eines Catch-all. Die beiden anderen Optionen leiten die Post unbekannter Adressen an ein bestehendes Postfach oder verwerfen sie stillschweigend. Die Dokumentation von cPanel kennzeichnet das stille Verwerfen selbst als Not Recommended, aus einem grundsätzlichen Grund: Der Absender erfährt nie, dass seine Nachricht verschwunden ist.

Womit sich ein Catch-all ersetzen lässt

Der Ausweg führt über deklarierte Adressen statt über eine Auffangregel. Legen Sie Aliase für die häufigsten Tippfehler Ihrer Domainnamen an und behalten Sie ein allgemeines Kontaktpostfach, das tatsächlich gelesen wird. Die Subadressierung übernimmt das Tracking Ihrer Formulare, ohne die Zahl der Postfächer zu vergrößern. Die Domain bekommt wieder eine saubere Empfängerliste. Ihre Korrespondenten erhalten sofort einen Fehler, wenn sie sich vertippen.

Catch-all mit oder ohne Bounce

Hinter dieser Frage stecken 2 verschiedene Konfigurationen. Das Catch-all nimmt den unbekannten Empfänger beim RCPT TO an und legt die Nachricht in ein Auffangpostfach, ganz ohne Bounce. Die verzögerte Ablehnung nimmt ebenfalls beim RCPT TO an und erzeugt dann einen Unzustellbarkeitsbericht, nachdem sie die Nachricht geschluckt hat.

Dieser zweite Modus kostet alle Beteiligten etwas. Wenn der ursprüngliche Envelope gefälscht ist, was bei Spam die Norm ist, geht der Unzustellbarkeitsbericht an einen unbeteiligten Dritten, dessen Adresse als Köder gedient hat. Das Phänomen trägt einen Namen, Backscatter. Es füttert die Blocklisten. Wer es versteht, sortiert auch die eigenen Rückläufer sauberer, zwischen Hard Bounce und Soft Bounce.

Sollten Sie Catch-all-Adressen in Ihre Kampagnen aufnehmen?

Der Versand an Catch-all-Adressen treibt die Bounce-Rate hoch und drückt die Öffnungsrate, 2 Kurven, die die Versanddienste beobachten, um über das Weitere zu entscheiden. Auf diesem Weg verschlechtert sich Ihr Ruf als Absender, Nachricht für Nachricht.

Das reale Risiko: Bounce-Schwelle, Beschwerderate, Absenderreputation und Spam-Fallen

Die Bounce-Schwellen kommen von den Versandplattformen. Amazon SES stellt den Zähler ab 5 % Bounce unter Beobachtung und kann den Versand bei 10 % aussetzen. Die Microsoft-Dokumentation zu Dynamics 365 Customer Insights, aktualisiert im August 2026, unterscheidet 2 Ebenen: Eine akzeptable Bounce-Rate bleibt in den meisten Fällen unter 2 %. Das Produkt selbst toleriert bis zu 8 %, bevor es reagiert. Die 2 % gehören damit zur guten Praxis, die 8 % zur tatsächlich angewandten Schwelle. Nehmen wir wieder die Datei mit 50.000 Kontakten und ihren rund 5.500 Catch-all-Zeilen. Kommt die Hälfte davon zurück, überschreitet der Zähler die 5 %, noch bevor der Rest der Datenbank gezählt ist, also oberhalb der Marke, die eine Kontoprüfung auslöst. Die Schwellen unterscheiden sich anschließend von Anbieter zu Anbieter.

Die Beschwerdeschwellen kommen von den Mailanbietern und werden getrennt gezählt. Die Google-Regeln für Absender, gültig seit dem 1. Februar 2024, verlangen eine Beschwerderate unter 0,10 % und setzen bei 0,30 % eine Grenze, die nie erreicht werden darf, für jeden Absender von mehr als 5.000 Nachrichten pro Tag an Gmail. Der Sender Hub von Yahoo verlangt, unter 0,3 % zu bleiben. Diese 2 Akteure veröffentlichen Beschwerdeschwellen, keine Bounce-Schwellen.

Bleibt das Thema Spam-Fallen. Spamhaus hat den Zyklus im Februar 2022 dokumentiert: Eine aufgegebene Adresse antwortet oft 12 Monate oder länger mit einem dauerhaften Fehler, dann schaltet die Domain sie als Falle scharf. Eine Datenbank, die seit 2 Jahren ohne Reinigung liegt, enthält also statistisch Adressen, die inzwischen ihre Natur geändert haben.

Die Unsicherheit vor dem Versand verringern

Die vorherige Prüfung der Liste übernimmt die erste Sortierung. Sie zieht die ungültigen Adressen heraus und isoliert die ok4all in einem eigenen Segment. Zurück bleibt eine Basis, auf der der Bounce wieder vorhersehbar wird. Sehen Sie danach auf die Herkunft der Sammlung: Eine Liste, die über Single Opt-in oder Double Opt-in entstanden ist, erzeugt deutlich weniger Bounces als eine gekaufte Datei. Sehen Sie zuletzt auf das Alter, denn der von Spamhaus beschriebene Zyklus läuft über alle schlafenden Adressen.

Nach dem ersten Versand über das Engagement validieren

Das ok4all-Segment behandeln Sie wie einen Test. Versenden Sie zuerst an 5 bis 10 % des Segments. Messen Sie Bounce und Öffnung, dann vergleichen Sie diese 2 Werte mit denen der übrigen Kampagne. Ein geringer Abstand erlaubt es, den Anteil beim nächsten Versand zu erhöhen. Ein deutlicher Abstand zeigt ein Segment, das liegen bleibt oder überarbeitet gehört.

Nach 2 Sendungen ohne Öffnung und ohne Klick hat eine Catch-all-Adresse ihre Nutzlosigkeit bewiesen und fliegt aus der Liste. Isolieren Sie vor Ihrer nächsten Kampagne die ok4all-Zeilen einer Stichprobe Ihrer Datenbank und vergleichen Sie deren Bounce-Rate mit der des Rests: Das Urteil steht in einer Stunde und wiegt schwerer als jede Schätzung.

Häufige Fragen

Ist eine Catch-all-Domain erkennbar?

Ja, in wenigen Sekunden. Ein RCPT TO auf eine zufällige Adresse der Domain genügt: Eine 250 auf eine unwahrscheinliche Adresse verrät den Auffangmodus. Die Gültigkeit jeder einzelnen Adresse bleibt mit diesem Test offen.

Welcher Anteil einer B2B-Datenbank ist betroffen?

Von mehr als 126 Millionen Adressen, die CaptainVerify 2025 geprüft hat, kamen rund 2,5 % als Catch-all zurück. Betrachtet man allein die Unternehmensdomains, steigt der Anteil auf knapp 11 %. Eine B2B-Datenbank mit 100.000 Kontakten enthält also rund 11.000 Zeilen dieser Art, die vor dem Versand zu isolieren sind.

Schützt ein Catch-all vor Spam?

Es erhöht den empfangenen Spam, weil jede erfundene Adresse auf der Domain ein Postfach findet. Sein Nutzen liegt woanders: Der Server antwortet auf unbekannte Adressen nicht mehr mit 550 und nimmt dem Angreifer das Orakel, mit dem er die gültigen Adressen aufzählen könnte.

Sollte man Catch-all-Adressen aus der Liste löschen?

Das reine Löschen rechtfertigt sich, wenn Ihre Versandplattform eine niedrige Bounce-Schwelle anwendet, etwa die 5 %, die bei Amazon SES eine Kontoprüfung auslösen. Auf einer dedizierten IP, die Sie selbst steuern, bleiben ein getrenntes Segment und ein Versand in Chargen eine vernünftige Option.

Was tun mit dem Status unbekannt in einem Bericht?

Er meldet einen Server, der trotz des automatischen zweiten Anlaufs innerhalb von 30 Minuten stumm geblieben ist. CaptainVerify schreibt diese Prüfungen wieder gut. Ein neuer Durchlauf zu einem späteren Zeitpunkt bringt in der großen Mehrheit der Fälle eine Entscheidung.