Früher oder später steht jeder B2B-Versender vor demselben Rätsel. Die Liste wurde verifiziert, die Adressen kamen in Ordnung zurück, und die Kampagne hat trotzdem gebounct. Sehr oft steckt eine Catch-all-Domain dahinter: ein Firmen-Mailserver, der zu jeder Adresse Ja sagt, sodass die Prüfung, die Ihre Absenderreputation schützen sollte, nichts Echtes zu melden hatte.
Dieser Ratgeber erklärt, was Catch-all bedeutet, warum Verifizierung nicht dahinterblicken kann, wie BounceIntel solche Adressen erkennt und bewertet und nach welchen Regeln Sie entscheiden, welche einen Versand wert sind.
Was Catch-all (Accept-all) bedeutet
Eine Catch-all-Domain, auch Accept-all genannt, ist eine Domain, deren Mailserver Nachrichten an jede beliebige Adresse dieser Domain annimmt. jane.doe@, j.doe@, sales-team@ und xq7k2@ werden gleich empfangen, egal ob es ein Postfach mit diesem Namen gibt.
Unternehmen richten das aus nachvollziehbar klingenden Gründen ein:
- Keine E-Mails verlieren. Ein Kunde, der den Namen eines Mitarbeiters falsch schreibt, erreicht trotzdem jemanden, weil unbekannte Adressen in einem gemeinsamen Postfach landen.
- Personalwechsel. E-Mails an ausgeschiedene Mitarbeiter kommen weiterhin irgendwo an, statt an Kunden zurückzugehen.
- Sicherheits-Gateways. Manche Filterdienste vor den Postfächern eines Unternehmens nehmen zuerst alles an und sortieren danach.
- Alte Konfigurationen, die sich seit Jahren niemand angesehen hat.
Catch-all-Konfigurationen sind auf Firmendomains verbreitet und bei den großen Anbietern für Privatkunden selten. Deshalb tritt das Problem vor allem in B2B-Listen auf.
Warum SMTP immer „Ja“ sagt
Echte E-Mail-Verifizierung beruht auf einer einzigen Frage per SMTP. Der Verifizierer verbindet sich mit dem Mailserver der Domain, nennt die Adresse mit RCPT TO und liest die Antwort. Ein normaler Server sucht das Postfach und nimmt es an oder lehnt es als unbekannt ab. Den kompletten Ablauf finden Sie unter Wie E-Mail-Verifizierung funktioniert.
Ein Catch-all-Server überspringt diese Suche oder verschiebt sie auf später. Er antwortet für jeden Empfänger mit 250, angenommen. Was danach mit einer echten Nachricht passiert, hängt von der Einrichtung ab:
- Sie wird in ein gemeinsames Postfach zugestellt, das vielleicht jemand liest.
- Sie wird angenommen und dann zurückgewiesen, Minuten oder Stunden später, als eigene Bounce-Nachricht, lange nachdem das Gespräch des Verifizierers beendet ist.
- Sie wird stillschweigend verworfen.
Der zweite Fall ist der gefährliche. Ein verspäteter Bounce zählt bei Ihrem E-Mail-Dienstleister trotzdem gegen Sie, und er zeigt Postfachanbietern trotzdem, dass Sie an nicht existierende Adressen schreiben. Ihr Verifizierungsbericht sah sauber aus, und Ihre Reputation hat trotzdem bezahlt.

Wie Verifizierer das erkennen
Da der Server zur echten Adresse Ja sagt, fragt der Verifizierer nach einer Adresse, die mit Sicherheit nicht existiert. BounceIntel tut das über dieselbe SMTP-Verbindung, die es für die eingereichte Adresse genutzt hat: Es sendet ein zweites RCPT TO für einen zufälligen, 15 Zeichen langen lokalen Teil auf derselben Domain. In keinem der beiden Fälle wird eine Nachricht gesendet.
- Wird die zufällige Adresse abgelehnt, prüft der Server Postfächer tatsächlich, und seine Annahme Ihrer Adresse hat Aussagekraft.
- Wird die zufällige Adresse angenommen, ist die Domain catch-all, und die Annahme Ihrer Adresse sagt nichts über dieses Postfach aus.
Bei einigen Postfachanbietern, deren Server sich bekanntermaßen eigen verhalten, wird die Abfrage übersprungen, und stattdessen gelten anbieterspezifische Regeln.
In der API-Antwort sieht ein erkanntes Catch-all so aus. Es ist ein echtes Ergebnis für einen erfundenen Namen auf unserer eigenen Domain, die E-Mails an jede Adresse annimmt:
{
"input": "[email protected]",
"is_reachable": "risky",
"smtp": {
"can_connect_smtp": true,
"is_deliverable": true,
"is_catch_all": true,
"is_disabled": false,
"has_full_inbox": false
},
"score": {
"reason_codes": ["catch_all", "catch_all_high_risk"],
"catch_all": {
"severity": "high",
"confidence": 55,
"factors": ["catch_all:corporate_domain", "website:present", "auth_records:present"]
}
},
"bounce_risk": { "action": "verify_manually" }
}
Beachten Sie smtp.is_deliverable: true. Der Server hat die Adresse tatsächlich angenommen, und genau diese Antwort darf man nicht für bare Münze nehmen.
Warum „gültig“ hier eine Lüge ist
Viele Verifizierungstools melden eine angenommene Catch-all-Adresse als gültig oder zustellbar, weil der Server technisch gesehen Ja gesagt hat. Doch der Server sagt dasselbe über einen echten Mitarbeiter und über einen Namen, den Sie sich vor dreißig Sekunden ausgedacht haben. Ein Etikett, das beiden dieselbe Antwort gibt, ist keine Information. Es ist eine Vermutung, die sich als Ergebnis ausgibt.
Der Schaden ist absehbar. Eine Liste besteht die Verifizierung, die Bounce-Rate steigt trotzdem, und der Verifizierer bekommt die Schuld. Am schlimmsten ist es bei geratenen Listen, wenn jemand [email protected] für jeden Namen auf einer Website erzeugt oder eine Datei solcher Adressen gekauft hat. Auf einer Catch-all-Domain „besteht“ jede geratene Adresse die Prüfung, und die Liste sieht bis zum Versand perfekt aus.
BounceIntel stuft eine Catch-all-Adresse nie als sicher ein. is_reachable ist risky, score.safe_to_send ist false, und der Begründungscode catch_all sagt, warum. So kann kein Teil Ihres Codes sie mit einem bestätigten Postfach verwechseln.
Catch-alls bewerten und send_with_caution
Jede Catch-all-Adresse riskant zu nennen ist ehrlich, aber für sich genommen wenig hilfreich: Im B2B kann ein großer Teil einer völlig ordentlichen Liste auf Catch-all-Domains liegen. Deshalb bewertet BounceIntel jede Adresse anhand der Belege um sie herum und fasst das in score.catch_all zusammen, als severity (low, medium oder high), als confidence-Wert und mit den factors, die dahinterstehen.
Der Ausgangspunkt hängt von der Domain ab. Eine Firmendomain startet mit hohem Schweregrad, ein kostenloser Anbieter für Privatkunden mit niedrigem. Die Belege verschieben ihn dann:
| Beleg | Wirkung | Faktor |
|---|---|---|
| Ihr Konto hat diese Adresse in 180 Tagen mindestens 3-mal sauber zurückbekommen | Schweregrad sinkt auf niedrig | tenant_history:safe_repeat |
| Mindestens 5 andere Adressen mit demselben Namensschema wurden in 180 Tagen in Ihrem Konto auf dieser Domain verifiziert | Schweregrad sinkt auf niedrig | pattern:…:verified_matches |
| 2 bis 4 solcher Adressen | Hoch wird zu mittel | pattern:some_verified_matches |
| Die Domain ist mindestens ein Jahr alt | Hoch wird zu mittel | domain_age:established |
| Die Domain hat keine Website | Schweregrad wird hoch | website:missing |
| SPF oder DMARC fehlt | Schweregrad wird hoch | auth_records:weak |
Der Schweregrad wird zusätzlich als Begründungscode ausgegeben, auf den Sie verzweigen können: catch_all_low_confidence, catch_all_medium_confidence oder catch_all_high_risk. Die Empfehlung in bounce_risk.action folgt dann dem Gesamtrisiko der Adresse. Eine Catch-all-Adresse mit guten Belegen kommt meist als send_with_caution zurück, eine mit wenigen Belegen als verify_manually, und eine, die zusätzlich andere schlechte Signale trägt, etwa eine Rollenadresse auf einer Domain ohne Website, als do_not_send.
send_with_caution meint genau das. Die Adresse ist wahrscheinlich in Ordnung, und trotzdem sollte der Versand so erfolgen, dass der Schaden begrenzt bleibt, falls nicht.
B2B-Regeln: behalten oder sperren
Die Verifizierung liefert Ihnen die Belege. Was Sie mit einer Catch-all-Adresse tun, ist eine Grundsatzentscheidung, und es lohnt sich, sie aufzuschreiben, damit das ganze Team sie gleich anwendet. Diese Regeln empfehlen wir.
Behalten Sie die Adresse und senden Sie in einem eigenen Segment an sie, wenn:
- sie aus einem Formular stammt, das die Person selbst ausgefüllt hat, idealerweise mit Double-Opt-in, oder aus einem echten Gespräch;
- der Kontakt in den letzten Monaten geöffnet, geklickt oder geantwortet hat;
- ihr Schweregrad
lowodermediumist oder sie einem Namensschema folgt, das in diesem Unternehmen bereits verifiziert wurde; - sie zu einer namentlich bekannten Person auf einer Domain mit Website und eingerichtetem SPF oder DMARC gehört.
Sperren Sie sie, wenn:
- es eine Rollenadresse wie
info@odersales@auf einer kalten Liste ist, bei der die Codescatch_allundrole_accountgemeinsam auftreten; - sie geraten, per Scraping gesammelt oder gekauft wurde, egal was ein Verifizierer dazu sagt;
- ihr Schweregrad
highist und Sie keine Interaktionshistorie mit ihr haben; - sie auch nur einmal hart gebounct ist. Wiederholen Sie einen Hard Bounce nie.
Wenn Sie an Catch-all-Adressen senden:
- Halten Sie sie in einem eigenen Segment, getrennt von Ihren bestätigten Adressen, damit ein Problem begrenzt bleibt.
- Beginnen Sie mit einer kleinen Charge und prüfen Sie die Bounce-Rate, bevor Sie den Rest senden.
- Halten Sie an und prüfen Sie, wenn die Bounces steigen, statt das ganze Segment hinauszuschicken.
- Entfernen Sie jeden Hard Bounce sofort, aus allen Listen.
- Verifizieren Sie das Segment vor der nächsten Kampagne erneut, denn die Belege zu Namensschemata, auf denen die Bewertung beruht, wachsen mit jeder Prüfung.
Prüfen Sie selbst eine Catch-all-Adresse
Lesen Sie in Ihrem eigenen Code smtp.is_catch_all aus der Antwort von POST /v1/check_email oder aus jeder Zeile eines Bulk-Jobs und steuern Sie anhand von score.catch_all.severity und bounce_risk.action. Die API-Dokumentation beschreibt jedes Feld, und die Massenverifizierung zeigt, wie Sie eine ganze Liste durch dieselben Prüfungen schicken.

