E-Mail-Verifizierung in TOM: was Grün, Gelb und Rot wirklich bedeuten

Die Kurzfassung

Zwei Dinge fallen sofort auf. Erstens ist das Mapping geordnet: TOM liest die Score-Bänder von oben nach unten, sodass jede Adresse in genau einer Zeile landet. Zweitens stecken hinter drei Ampeln sieben Urteile — Rot deckt vier verschiedene Situationen ab (unknown, disposable, risky, invalid), die aus völlig unterschiedlichen Gründen scheitern. Der Rest dieses Leitfadens zerlegt jedes davon.

Vor der Farbe: was Verifizierung wirklich prüft

Die Ampel ist der letzte Schritt einer sechsstufigen Pipeline. Die Stufen zu kennen lohnt sich, weil jede Farbe eigentlich eine Aussage darüber ist, wo die Adresse gescheitert oder durchgekommen ist:

1. Syntaxprüfung. Ist die Adresse wohlgeformt (ein @, gültiger lokaler Teil und Domain)? Eine fehlerhafte Adresse kommt nie über diese Stufe hinaus — sie wird invalid mit Reason invalid_syntax.
2. Domainprüfung. Existiert die Domain und löst sie im DNS auf? Eine tote oder unregistrierte Domain wird invalid (no_mx_records, oder spf_reject_all, wenn die Domain eingehende Mail explizit ablehnt).
3. MX-Record-Prüfung. Veröffentlicht die Domain Mailserver, die E-Mails empfangen können? Keine MX-Records heißt: Es existiert kein Postfach — wieder invalid.
4. Disposable-Erkennung. Steht die Domain auf der Liste mit über 5.000 bekannten temporären E-Mail-Anbietern (Mailinator, 10MinuteMail, Guerrilla Mail und ähnliche, täglich aktualisiert)? Ein Treffer wird disposable, egal ob die Mailbox technisch existiert.
5. SMTP-Prüfung. Der entscheidende Schritt: BillionVerify verbindet sich mit dem Empfänger-Mailserver und fragt per RCPT TO, ob die konkrete Mailbox existiert. Ein 250 OK bestätigt sie (valid); ein 550 user unknown beendet sie (invalid, mailbox_not_found). Alles Uneindeutige — Timeouts, Greylisting, Rate-Limits, blockierte Probes — wird unknown oder catchall.
6. Score-Berechnung. Alle Stufenergebnisse werden zu einem Confidence-Score von 0.0 bis 1.0 kombiniert. Die SMTP-Bestätigung trägt das meiste Gewicht (etwa 30 %), gefolgt von MX-Records, Domain-Existenz, Disposable-Status und Reputationssignalen.

Über dieser Pipeline liegen zwei orthogonale Erkennungen: Rollenmuster (ist das ein geteiltes Postfach?) und Reputationsprüfung gegen die Spamhaus Domain Blocklist (ist diese Domain eine bestätigte Spam-, Phishing-, Malware- oder Botnet-Quelle?). Sie erzeugen die Urteile role bzw. risky.

Grün: valid

Grün ist das einzige Urteil, das die einzelne Mailbox bestätigt, nicht nur die Domain. Die Syntax ist gültig, die Domain existiert, MX-Records sind veröffentlicht, die Adresse ist nicht disposable, und der empfangende Server hat den Empfänger explizit akzeptiert. Die Confidence ist hoch — in BillionVerifys Skala ist das das Band 0.9–1.0, „highly confident valid“.

Was tun: ohne Zögern in Cold-Kampagnen aufnehmen. Grüne Adressen sind das Rückgrat jedes Versands; die Qualitätsschwelle pro Kampagne in TOM existiert genau dafür, ihren Anteil hoch zu halten.

Gelb: catch-all

Catch-all ist eine Eigenschaft der Domain, nicht der Adresse. Kleine Firmen und selbst gehostete Setups konfigurieren ihren Mailserver — oder ein Sicherheits-Gateway wie Mimecast oder Proofpoint im Accept-all-Modus, oder ein Microsoft 365 Internal Relay — oft so, dass er jeden Empfänger annimmt statt unbekannte abzuweisen. Die SMTP-Konversation beweist daher nichts darüber, ob marco@ dort wirklich funktioniert.

Typische Reason-Codes hinter einem Catch-all sind catch_all_domain (Zufallsprobe akzeptiert), catch_all_deliverable (Catch-all-Domain, bei der die konkrete Adresse ebenfalls 250 OK meldete), gateway_accept_all und m365_internal_relay. Weiterleitungs-Alias-Dienste (SimpleLogin, Firefox Relay, Duck.com) und manche regionale Consumer-Domains landen ebenfalls hier.

Warum Gelb und nicht Grün? Weil das Bounce-Risiko strukturell höher ist: Sie schreiben an eine Adresse, die der Verifizierer nicht einzeln bestätigen konnte. Warum Gelb und nicht Rot? Weil viele Catch-all-Adressen echte Menschen in echten Firmen sind — sie alle zu verwerfen würde legitime Prospects wegwerfen, gerade im SMB-Segment.

Gelb: role-based

Eine Feinheit aus der Dokumentation: Rollenadressen erben den Reason-Code ihrer zugrunde liegenden SMTP-Prüfung — es gibt keine eigenen Reason-Codes für diesen Status. Eine Rollenadresse, die SMTP bestanden hat, zeigt reason: smtp_deliverable, genau wie eine grüne Adresse. Das Flag role (is_role: true) unterscheidet sie.

Nicht alle Rollenadressen tragen dasselbe Risiko. Als Faustregel aus BillionVerifys Referenz:

Warum Gelb? Die Mailbox existiert, also wäre Rot falsch — aber eine Cold Email an info@ konkurriert mit jeder anderen eingehenden Nachricht dieser Firma, und manche Anbieter schränken Rollenadressen grundsätzlich ein. Für transaktionale Mail in Ordnung; für Cold Outreach bewusst einsetzen und mit niedrigeren Antwortraten rechnen.

Rot: unknown

Unknown ist das am häufigsten missverstandene Urteil, weil „unknown“ neutral klingt, während TOM Rot zeigt. Das Rot ist Absicht: Eine Adresse, deren Gültigkeit nicht bestätigt werden kann, trägt dasselbe Versandrisiko wie eine schlechte, bis das Gegenteil bewiesen ist. Darum führt TOM Sie zu sauberem Cold Outreach und blockiert rote Adressen, statt Sie einen Bounce riskieren zu lassen.

Häufige Ursachen fallen in zwei Gruppen:

• Temporär und wiederholbar — lohnt eine erneute Prüfung: smtp_timeout, smtp_rate_limited, smtp_greylisted (inklusive der Mimecast-Variante), Proofpoint-Async-Lookups, temporäre Ablehnungen von Google und Microsoft 365, DNS-Timeouts und transiente interne Fehler.
• Strukturell und nicht wiederholbar — ein Retry ändert nichts am Ergebnis: Anbieter, die SMTP-Probes per Policy blockieren (Apple iCloud, Microsoft-Consumer-Mail, Proton, Tuta, japanische Carrier-Domains), Server, die die Probe-Verbindung blocklistet haben, fehlerhaft ausgerichtete DMARC-Konfigurationen, überfüllte oder deaktivierte Mailboxen sowie Konten, die für den Verzicht auf SMTP-Verifizierung konfiguriert sind.

Praktische Regel: einmal nach einer Pause erneut verifizieren — Greylisting und Rate-Limits lösen sich oft auf, und die Adresse kann grün oder gelb werden und damit auswählbar. Solange sie unknown bleibt, ist sie standardmäßig ausgeschlossen und kann keiner Cold-Kampagne hinzugefügt werden.

Rot: disposable und risky

Disposable (is_disposable: true, Reason disposable_domain) umfasst Mailinator, 10MinuteMail, Guerrilla Mail, TempMail und Tausende kleinere Generatoren. Diese Adressen interagieren fast nie, werden oft für Spam oder Betrug genutzt und signalisieren einen Lifetime-Value nahe null — besonders schädlich in Registrierungsflüssen.

Risky ist das Urteil, das in den meisten Zusammenfassungen fehlt, und verdient daher eine vollständige Erklärung. Es bedeutet, die Mailbox akzeptiert Mail höchstwahrscheinlich (is_deliverable: true), aber die Empfängerdomain steht in der Spamhaus Domain Blocklist wegen Spam, Phishing, Malware-Verbreitung oder Botnet-Command-and-Control. Das Array risk_reasons sagt Ihnen, welches davon: spamhaus_dbl_spam, spamhaus_dbl_phish, spamhaus_dbl_malware oder spamhaus_dbl_botnet_cc. Dorthin zu senden kann Ihre eigene Versandreputation beschädigen, daher lautet die empfohlene Aktion wie bei Disposable: von der Liste entfernen. Ein Retry ändert ein Risky-Ergebnis nie.

Eine Beruhigung aus der Dokumentation: Domains, die Spamhaus als missbrauchte legitime Seiten einstuft — eine normale Firmenwebsite, die kompromittiert wurde — erzeugen nie ein Risky-Ergebnis. Eine gehackte Website heißt nicht, dass die Mailboxen dieser Firma schlecht sind.

Rot: invalid

Invalid ist das sicherste negative Urteil (Score um 0.1). Typische Reason-Codes: invalid_syntax (fehlerhafte Adresse), no_mx_records (Domain ohne Mailserver), spf_reject_all (Domain lehnt eingehende Mail explizit ab), mailbox_not_found (Server meldete 550 / user unknown) und host_not_found (der MX-Host selbst ist unerreichbar).

Hier gibt es kein „vielleicht“ und keine Retry-Logik, die hilft: Eine invalide Adresse bouncet jedes Mal. In Cold Outreach sind das reine Kosten — ein Bounce, ein Reputationsschaden und ein Prospect, der nie existiert hat.

Score vs. Status: was entscheidet die Farbe?

Beides — und sie widersprechen sich nie. Jeder Status trägt einen festen Score, sodass beide Lesarten gleichwertig sind:

Sehen Sie den Score als maschinenlesbare Form des Status und die Farbe als menschenlesbare Form des Scores. TOM wertet die Bänder von oben nach unten aus — die erste Schwelle, die der Score erreicht, gewinnt — darum kann eine Adresse immer nur eine Ampel haben. Das Flag is_deliverable folgt derselben Logik: true für valid (und technisch für risky), false für invalid, null für unknown und catch-all, wo die Zustellbarkeit ehrlich unbestimmt ist.

Was Sie mit jeder Farbe in TOM tun

Verifizierung nützt nur, wenn sie verändert, was Sie senden. In TOM tut sie das per Design: Rote Adressen sind standardmäßig ausgeschlossen und können nicht für eine Cold-Kampagne ausgewählt werden — Sie zu sauberem Cold Outreach zu führen heißt, Sie nicht an Adressen senden zu lassen, die sicher bouncen würden. Grüne und gelbe sind auswählbar; die Qualitätsschwelle pro Kampagne entscheidet dann, wie viel Gelb ein Versand enthalten darf.

In TOM spielt sich das an drei Stellen ab: Die Ampel pro Adresse sagt Ihnen, was jeder Kontakt wert ist, die Mindestqualitätsschwelle pro Kampagne hält den Grün-Anteil über alle auswählbaren Adressen hoch, und der Pre-Flight-Check vor dem Start stoppt eine Kampagne, deren Listenqualität die Domain verbrennen würde. Rote Adressen erreichen diesen Punkt nie — sie werden vor der Auswahl herausgefiltert. Verifizierungsguthaben verfallen nie, daher kostet es nichts extra, eine unknown-Adresse nächste Woche erneut zu prüfen — oder eine Liste zu bereinigen, die 90 Tage ungenutzt lag — und eine Adresse, die grün oder gelb wird, wird auswählbar.

Wenn das Ergebnis überrascht: Reason-Codes

Jedes Urteil kommt mit einem Feld reason — einem stabilen String-Identifier, der erklärt, warum die Adresse ihren Status bekommen hat. Wenn eine Ampel falsch wirkt, schauen Sie dort nach. Die nützlichsten zum Wiedererkennen:

• Sieht rot aus, Sie erwarteten grün: mailbox_not_found (Tippfehler in der Adresse oder ausgeschiedener Mitarbeiter), no_mx_records (Domain ohne Mail), smtp_blocked oder smtp_unverifiable (der Anbieter verweigert Probes — üblich bei iCloud, Microsoft-Consumer-Mail, Proton und Tuta).
• Sieht gelb aus, Sie erwarteten grün: catch_all_domain oder gateway_accept_all (die Domain akzeptiert alles), oder ein geerbtes smtp_deliverable gepaart mit is_role: true (ein funktionierendes, aber geteiltes Postfach).
• Festhängend auf unknown: prüfen Sie, ob der Reason wiederholbar ist (smtp_timeout, smtp_rate_limited, smtp_greylisted, google_rate_limit, dns_timeout) oder strukturell (smtp_unverifiable, carrier_blocked, mailbox_full). Nur die erste Gruppe bessert sich bei Retry.
• Score 0.3 ohne offensichtliche Ursache: prüfen Sie risk_reasons. Ein Eintrag spamhaus_dbl_* heißt, die Domain ist blocklistet — die Adresse ist nicht „niedrige Qualität“, sie ist aktiv gefährlich für Ihre Reputation.

Zwei Begleitflags helfen bei der Segmentierung jenseits der Zustellbarkeit: is_free (Gmail, Yahoo, Outlook — nützlich für B2B- vs. B2C-Scoring und Betrugserkennung) und smtp_check (ob die tiefe SMTP-Probe wirklich lief, oder das Urteil auf Domain-Heuristiken beruht).

FAQ

Dieser Leitfaden ist Teil des TOM-Blogs. Verifizierungsstatus und Scores folgen der BillionVerify-Verification-Types-Dokumentation und der Verification-Reasons-Referenz. Verwandte Lektüre: die 12 Cold-Email-Frameworks, 12 Cold-Email-Software-Alternativen im Vergleich und Warmup als Plattformverhalten.