Wie E-Mail-Verifizierung funktioniert, Stufe für Stufe

Eine Liste voller toter Adressen kostet mehr als die Sendungen, die sie verschwendet. Jeder Hard Bounce signalisiert Gmail, Outlook und Yahoo, dass Sie nicht wissen, wem Sie schreiben, und das rechnen sie Ihrer Domain und Ihrer Versand-IP an. Kommt genug davon zusammen, landet die nächste Kampagne im Spam, auch bei den guten Adressen.

E-Mail-Verifizierung findet diese Adressen, bevor ein Postfachanbieter es tut. Dieser Ratgeber begleitet eine Adresse durch die vier Stufen, die ein Verifizierer der Reihe nach durchläuft, und zeigt, welchen Teil einer BounceIntel-API-Antwort jede Stufe füllt. Am Ende sollten Sie ein Ergebnis selbst lesen können, statt einem Etikett aus einem einzigen Wort zu vertrauen.

Was Verifizierung ist (und was nicht)

E-Mail-Verifizierung ist ein automatischer Test, ob eine Adresse gerade jetzt E-Mails empfangen kann. Sie stützt sich auf zwei Quellen: öffentliche DNS-Einträge und ein kurzes Gespräch mit dem Mailserver, der die Nachricht empfangen würde. Es wird keine E-Mail gesendet. Das Gespräch endet, bevor Inhalte übertragen werden, und die Person hinter der Adresse bekommt davon nichts mit.

Genauso klar sollte sein, was Verifizierung nicht beantworten kann:

• Ob ein Mensch das Postfach liest. Ein Postfach kann existieren und verwaist sein. Das beantworten Interaktionsdaten, nicht die Verifizierung.
• Ob die Adresse nächsten Monat noch funktioniert. Menschen wechseln den Job, Postfächer werden gelöscht. Ein Ergebnis beschreibt den Zeitpunkt der Prüfung, deshalb enthält jedes BounceIntel-Ergebnis score.freshness, von fresh bis expired.
• Ob eine Adresse eine Spamfalle ist. Domains, die bekanntermaßen Fallen betreiben, werden markiert, aber eine gut gemachte Falle sieht genau wie eine echte, funktionierende Adresse aus.
• Ob Sie jemandem schreiben dürfen. Das ist eine Frage der Einwilligung, und keine technische Prüfung kann sie beantworten.

Stufe 1: Syntax und Normalisierung

Die erste Stufe verlässt den Verifizierer nie. Sie teilt die Adresse am @ in einen lokalen Teil und eine Domain und prüft, ob beide korrekt aufgebaut sind. Eine Adresse, die hier scheitert, endet hier: keine DNS-Abfrage, keine Verbindung zu irgendeinem Server und ein Ergebnis is_reachable: "invalid" mit dem Begründungscode invalid_syntax und einem Score von 0.

Zwei Details entscheiden, ob eine ungewöhnliche Adresse durchkommt:

• Internationalisierte Domains wie münchen.de werden in ihre ASCII-Form umgewandelt (xn--mnchen-3ya.de), und alle weiteren Stufen arbeiten mit dieser Form.
• Nicht-ASCII-Zeichen im lokalen Teil wie bei josé@example.com gelten als ungültig. Die Zustellung an solche Adressen erfordert eine SMTP-Erweiterung, die die meisten empfangenden Server nicht anbieten, also bouncen sie in der Praxis.

Dieselbe Stufe liefert zwei Dinge, die Sie sofort nutzen können. syntax.normalized_email gibt die kanonische Form des Postfachs an: Bei Gmail ändern Punkte und alles nach einem + nichts am Ziel, daher wird [email protected] zu [email protected] normalisiert, und Dubletten in einer Liste fallen sofort auf. Liegt die Domain nur ein oder zwei Buchstaben neben einem bekannten Anbieter, schlägt syntax.suggestion die wahrscheinliche Korrektur vor (gmial.com wird zu gmail.com), und der Begründungscode possible_typo kommt hinzu.

Stufe 2: DNS- und MX-Einträge

Über MX-Einträge legt eine Domain fest, wohin ihre E-Mails gehen. Der Verifizierer fragt sie ab, und die Antwort landet in mx.records (die Mailserver der Domain) und mx.accepts_mail. Eine Domain ohne MX-Einträge hat kein Zustellziel, und das Ergebnis trägt den Begründungscode no_mx. Schon das fängt überraschend viele schlechte Adressen ab: abgelaufene Firmendomains, Tippfehler, die zufällig registriert sind, und erfundene Domains aus Anmeldeformularen.

In dieser Stufe wird die Adresse auch mit dem abgeglichen, was über ihre Domain und ihren lokalen Teil bekannt ist:

• misc.is_disposable markiert Wegwerf-Postfachdienste (Begründungscode disposable).
• misc.is_role_account markiert gemeinsame Adressen wie info@ oder support@ (role_account).
• misc.is_spam_trap_domain markiert Domains, die bekanntermaßen Spamfallen betreiben (spam_trap).
• Kostenlose Anbieter für Privatkunden wie Gmail werden mit free_provider vermerkt.

Der MX-Host verrät außerdem den Postfachanbieter hinter der Domain, etwa Google Workspace oder Microsoft 365. Das ist für die nächste Stufe wichtig, denn jeder große Anbieter reagiert auf Verifizierung auf seine eigene Weise.

Stufe 3: die SMTP-Abfrage

Diese Stufe unterscheidet echte Verifizierung von einer bloßen Formatprüfung. Der Verifizierer verbindet sich über Port 25 mit einem der MX-Hosts der Domain und beginnt dasselbe Gespräch wie jeder sendende Server:

1. Er stellt sich mit EHLO vor.
2. Er nennt mit MAIL FROM einen Absender.
3. Er nennt mit RCPT TO die zu prüfende Adresse.
4. Er liest die Antwort des Servers zu diesem Empfänger und schließt die Verbindung.

Die eigentliche Nachricht, der DATA-Schritt, findet nie statt. Entscheidend ist, wie der Server auf Schritt 3 geantwortet hat:

• Angenommen (Antwort 250): smtp.is_deliverable ist true.
• Abgelehnt als unbekannter Nutzer: smtp.is_deliverable ist false, mit dem Begründungscode smtp_undeliverable.
• Abgelehnt, weil das Konto deaktiviert ist: smtp.is_disabled ist true (disabled_mailbox).
• Abgelehnt, weil das Postfach voll ist: smtp.has_full_inbox ist true (full_inbox).

Über dieselbe Verbindung fragt BounceIntel anschließend nach einem zweiten Empfänger: einer zufälligen, 15 Zeichen langen Adresse auf derselben Domain, die nicht existieren kann. Nimmt der Server auch diese an, ist smtp.is_catch_all gleich true. Warum das wichtig ist, lesen Sie weiter unten.

"smtp": {
  "can_connect_smtp": true,
  "is_deliverable": true,
  "is_disabled": false,
  "has_full_inbox": false,
  "is_catch_all": false
}

Nicht jeder Server antwortet eindeutig. Manche halten unbekannte Absender absichtlich mit einer vorübergehenden Ablehnung hin (Greylisting), manche drosseln, manche lehnen Verbindungen aus Netzen ab, die sie nicht kennen, und manche antworten schlicht nicht rechtzeitig. Nichts davon ist ein Urteil über die Adresse, und BounceIntel tut auch nicht so. Das Ergebnis wird unknown, und ein Begründungscode benennt, was passiert ist: transient_smtp, smtp_policy_block, smtp_timeout, smtp_network, smtp_ambiguous oder smtp_unreachable.

Stufe 4: Scoring und Begründungscodes

Die letzte Stufe macht aus allen Signalen der ersten drei etwas, mit dem Sie arbeiten können. score.score reicht von 0 bis 100 und entspricht einer Kategorie: 80–100 ist valid, 50–79 ist risky, 1–49 ist unknown und 0 ist invalid. score.confidence und score.confidence_level (high, medium, low oder very_low) zeigen, wie viele Belege hinter dieser Zahl stehen, und score.safe_to_send liefert die Ja-oder-Nein-Antwort.

Die Grundlage für Ihre Logik ist score.reason_codes. Das Feld listet jedes Signal, das das Ergebnis beeinflusst hat, als stabile Zeichenketten, auf die Ihr Code verzweigen kann, und score.sub_reason nennt das ausschlaggebende. Daneben empfiehlt bounce_risk.action, was zu tun ist (send, send_with_caution, verify_manually oder do_not_send), und bounce_risk.risk_factors erklärt diese Empfehlung, jeden Faktor mit seinem Gewicht.

Hier ein echtes Ergebnis für eine gemeinsame Support-Adresse auf einer Domain, die alle E-Mails annimmt, gekürzt auf die Scoring-Felder:

{
  "input": "[email protected]",
  "is_reachable": "risky",
  "score": {
    "score": 55,
    "category": "risky",
    "confidence_level": "low",
    "reason_codes": ["catch_all", "role_account", "catch_all_high_risk"],
    "sub_reason": "catch_all",
    "safe_to_send": false
  },
  "bounce_risk": {
    "action": "verify_manually",
    "risk_factors": [
      { "signal": "smtp_is_catch_all", "contribution": 20, "description": "Corporate catch-all mailbox" },
      { "signal": "is_role_account", "contribution": 10, "description": "Role-based mailbox" }
    ]
  }
}

Entscheiden Sie im Code anhand der Empfehlung und bewahren Sie die Begründungscodes für die Person auf, die die Adresse später prüft:

const { bounce_risk, score } = await res.json();

if (bounce_risk.action === "do_not_send") {
  suppress(email, score.reason_codes);
} else if (bounce_risk.action === "verify_manually") {
  queueForReview(email, score.reason_codes);
} else {
  accept(email);
}

Das Scoring berücksichtigt außerdem die Historie Ihres eigenen Kontos mit der Adresse aus den letzten 180 Tagen. Deshalb kann eine wiederholte Prüfung mit mehr Konfidenz zurückkommen als die erste.

Der blinde Fleck Catch-all

Stufe 3 hat eine Grenze, die kein Verifizierer umgehen kann. Manche Domains sind so eingerichtet, dass sie E-Mails an jede Adresse annehmen, ob es sie gibt oder nicht. Fragen Sie deren Server nach jane.doe@, sagt er Ja; fragen Sie nach einer Folge zufälliger Zeichen, sagt er wieder Ja. Das SMTP-Gespräch beweist, dass die Domain E-Mails annimmt. Es kann nicht beweisen, dass das Postfach existiert, um das es Ihnen geht.

Genau dafür gibt es die Abfrage mit der zufälligen Adresse. Wird sie angenommen, stuft BounceIntel das Ergebnis als risky statt safe ein, ergänzt den Begründungscode catch_all und bewertet das Risiko mit einem Schweregrad-Code (catch_all_low_confidence, catch_all_medium_confidence oder catch_all_high_risk), gestützt auf Belege wie die Einrichtung der Domain und Namensschemata, die in diesem Unternehmen bereits verifiziert wurden. Ein Verifizierer, der solche Adressen „gültig“ nennt, beschreibt die Höflichkeit des Servers, nicht das Postfach.

Was „safe / risky / invalid / unknown“ bedeutet

is_reachable fasst alles oben Beschriebene in einem Wort zusammen. Der kostenlose Checker auf dieser Website zeigt dieselben vier Werte, mit übersetzten Bezeichnungen.

Zwei Fehler passieren hier leicht. unknown ist eine Aussage über einen Server zu einem bestimmten Zeitpunkt, nicht über die Adresse. Wer diese Adressen löscht, wirft also gute Kontakte weg. Und risky umfasst sehr unterschiedliche Fälle: Ein volles Postfach ist meist vorübergehend, eine Wegwerfadresse wird dagegen nie einem Kunden gehören. Das Etikett ist eine Zusammenfassung. Die Entscheidung gehört zu bounce_risk.action und score.reason_codes.

Echtzeit oder Massenverifizierung

Die vier Stufen sind in beiden Fällen dieselben. Es ändert sich nur der Zeitpunkt.

Die Verifizierung in Echtzeit, eine Adresse nach der anderen mit POST /v1/check_email, gehört an die Stelle, an der eine Adresse in Ihre Systeme gelangt: Anmeldeformulare, Checkout, Kontaktformulare, ein Vertriebsmitarbeiter, der etwas ins CRM tippt. Die Person ist noch da, also lässt sich ein von syntax.suggestion erkannter Tippfehler sofort beheben, statt nächste Woche zum Bounce zu werden. Rufen Sie die API von Ihrem Server auf, nie aus Browser-Code mit Ihrem Schlüssel, und behandeln Sie unknown als „annehmen und später erneut prüfen“, damit ein langsamer Mailserver nie eine echte Anmeldung blockiert.

Die Massenverifizierung, mit POST /v1/bulk oder einem CSV-Upload im Dashboard, gehört vor einen Versand: ein Newsletter an eine lange ungenutzte Liste, ein Import von einer Messe oder aus einem neuen CRM oder eine regelmäßige Prüfung einer alten Datenbank. Jede Zeile kommt mit denselben Feldern zurück. Listen veralten, weil Menschen den Job wechseln, also prüfen Sie alles, was seit einigen Monaten nicht verifiziert wurde, bevor Sie es anschreiben.

Eine Adresse prüfen und das Ergebnis lesen

Alles, was der Checker anzeigt, stammt aus derselben API, die Ihr Code aufrufen würde. Die API-Dokumentation beschreibt jedes Feld der Antwort, die Massenverifizierung deckt ganze Listen ab, und die Preise zeigen, was ein Tarif mit API-Zugang kostet.