E-Mail-Bounce-Klassifizierung aufbauen

Ein Bounce ist die Art und Weise, wie Ihnen ein Mailserver in einem dreistelligen Code mitteilt, warum er Ihre Nachricht nicht angenommen hat. Diese Codes korrekt zu klassifizieren macht den Unterschied zwischen dem Unterdrücken einer wirklich toten Adresse und dem Wegwerfen einer, die bei einem erneuten Versuch zugestellt worden wäre. Dieser Leitfaden baut einen Bounce-Klassifizierer auf und zeigt, wie Sie dieselbe Klassifizierung vor dem Versand durchführen statt danach.

Die kurze Antwort#

Die erste Ziffer des SMTP-Codes entscheidet über die Aktion: 5xx ist ein permanenter Fehler — unterdrücken Sie ihn — und 4xx ist temporär — versuchen Sie es erneut. Die entscheidende Verfeinerung ist der Enhanced-Status-Code: Ein 5.7.x ist ein Policy- oder Reputations-Block (der Server weist Sie ab, statt die Mailbox zu beurteilen), den Sie nicht als tote Adresse behandeln dürfen. Ein Verifizierer wendet dieselbe Logik auf eine Mailbox-Sonde an, sodass Sie eine Adresse klassifizieren können, bevor überhaupt ein echter Bounce entsteht.

Die zwei Dimensionen eines Bounce#

Jeder Bounce hat zwei Eigenschaften, die es zu trennen lohnt:

• Permanenz — ist dies endgültig (5xx, ein Hard Bounce) oder temporär (4xx, ein Soft Bounce)? Das entscheidet über Unterdrücken vs. Erneut versuchen.
• Gegenstand — beurteilt der Server die Mailbox („kein solcher Nutzer") oder Ihren Absender („Ihre IP steht auf einer Blockliste")? Eine permanente Ablehnung Ihres Absenders sieht aus wie ein Hard Bounce, darf aber nicht wie einer behandelt werden — den Empfänger zu unterdrücken behebt nichts, denn das Problem ist Ihre Reputation.

Der Leitfaden zu SMTP-Antwortcodes behandelt die vollständige Grammatik; bei der Klassifizierung geht es darum, sie in eine Aktion zu übersetzen.

Ein Bounce-Klassifizierer#

Hier ist ein Klassifizierer, der den SMTP-Code und den optionalen Enhanced-Code liest und eine Aktion zurückgibt. Er behandelt den Fall, den die meisten naiven Klassifizierer übersehen — den als 5xx getarnten Policy-Block:

/**
 * Classify a bounce into an action.
 * @param {number} code      basic SMTP code, e.g. 550
 * @param {string} [enhanced] enhanced status code, e.g. "5.1.1"
 */
export function classifyBounce(code, enhanced) {
  const cls = Math.floor(code / 100); // 2, 4, or 5

  // Policy / reputation block: the server is refusing YOU, not the mailbox.
  // Suppressing the recipient would be treating the wrong problem.
  if (enhanced?.startsWith("5.7") || enhanced?.startsWith("4.7")) {
    return { type: "policy", action: "review", note: "sender reputation, not the mailbox" };
  }

  if (cls === 5) {
    // Permanent: no such user, disabled, or the domain won't relay.
    return { type: "hard", action: "suppress", reason: "rejected_email" };
  }

  if (cls === 4) {
    // Temporary: full mailbox, greylisting, or a rate limit.
    const fullMailbox = code === 452 || enhanced === "4.2.2";
    return {
      type: "soft",
      action: "retry",
      reason: fullMailbox ? "full_mailbox" : "timeout",
    };
  }

  return { type: "unknown", action: "retry" };
}

classifyBounce(550, "5.1.1"); // { type: "hard",   action: "suppress" }
classifyBounce(452);          // { type: "soft",   action: "retry", reason: "full_mailbox" }
classifyBounce(554, "5.7.1"); // { type: "policy", action: "review" }  ← don't suppress

Die hier eingebettete Regel: Unterdrücken Sie nur saubere Mailbox-Ablehnungen. Ein 5.7.x bedeutet, dass Sie Ihre Versandreputation reparieren müssen; den Empfänger zu unterdrücken verbirgt das Signal, ohne irgendetwas zu lösen.

Klassifizieren Sie vor dem Bounce, nicht danach#

Der Haken an der Bounce-Klassifizierung ist, dass sie reaktiv ist — Sie erfahren erst, dass eine Adresse tot ist, indem Sie an sie senden und dabei Ihre Reputation schädigen. Die Verifizierung führt dieselbe Klassifizierung auf einer SMTP-Sonde statt auf einem echten Versand durch, sodass Sie das Urteil ohne den Bounce erhalten. Die Urteils- und Grund-Codes lassen sich direkt auf dieselben Aktionen abbilden:

const ACTION_BY_REASON = {
  accepted_email:    "keep",     // deliverable
  rejected_email:    "suppress", // hard bounce confirmed by probe
  invalid_email:     "suppress", // bad syntax
  invalid_domain:    "suppress", // no mail route
  low_quality:       "suppress", // disposable
  low_deliverability: "segment", // catch-all or full mailbox — send carefully
  timeout:           "retry",    // greylisted / no answer yet
  unavailable_smtp:  "retry",    // couldn't reach the server
  unknown:           "retry",
};

// From a verification result row:
const action = ACTION_BY_REASON[row.reason] ?? "retry";

Derselbe Entscheidungsbaum, nur zeitlich vorgezogen. Die Adressen, die hart gebounct wären, kommen als undeliverable zurück und werden vor dem Versand unterdrückt; die unknown-Adressen erhalten einen erneuten Versuch statt einer Vermutung.

In den Kreislauf einbinden#

In welche Richtung Sie es auch ausführen, das Ergebnis fließt an einen Ort — Ihre Unterdrückungsliste:

• Reaktiv: Parsen Sie die Bounce-Webhooks Ihres ESP, führen Sie classifyBounce aus und unterdrücken Sie die harten, während Sie für die weichen erneute Versuche einplanen.
• Proaktiv: Führen Sie einen Massen-Verifizierungsauftrag aus, rufen Sie die Ergebnisse mit include=results ab, ordnen Sie jeden reason über ACTION_BY_REASON zu und wenden Sie die Aktionen an — der Export-Verifizieren-Unterdrücken-Kreislauf, den die ESP-Bereinigungsleitfäden pro Plattform durchgehen.

Beides zu behalten ist ideal: Verifizieren Sie proaktiv, um die meisten Bounces zu verhindern, und klassifizieren Sie die verbleibenden Bounces reaktiv, um die Adressen zu erwischen, die seither unbrauchbar geworden sind.

Häufig gestellte Fragen#

Was ist der Unterschied zwischen einem Hard und einem Soft Bounce, im Code?#

Die SMTP-Klasse: 5xx ist ein Hard Bounce (permanent — unterdrücken), 4xx ist ein Soft Bounce (temporär — erneut versuchen). Die eine Falle ist ein 5.7.x Enhanced-Code, der ein permanenter Policy-Block gegen Ihren Absender ist und keine tote Mailbox — klassifizieren Sie ihn gesondert und beheben Sie die Reputation, statt den Empfänger zu unterdrücken.

Wie oft sollte ich einen Soft Bounce erneut zustellen, bevor ich ihn unterdrücke?#

Es gibt keine allgemeingültige Zahl, doch ein gängiges Muster ist, eine soft bouncende Adresse über einige aufeinanderfolgende Versände hinweg erneut anzusteuern und sie auf unterdrückt hochzustufen, wenn sie sich nie erholt — was ungefähr dem entspricht, was Mailbox-Provider und ESPs intern tun. Volle Postfächer leeren sich oft von selbst, daher verdienen Soft Bounces eine Geduld, die ein Hard Bounce nicht verdient.

Kann ich Adressen klassifizieren, bevor ich an sie sende?#

Ja — genau das ist Verifizierung. Eine SMTP-Mailbox-Sonde erzeugt dieselben Signale wie ein Bounce, zugeordnet zu einem Urteil aus deliverable | risky | undeliverable | unknown mit einem Grund-Code, sodass Sie die toten Adressen unterdrücken können, bevor sie überhaupt bouncen. Die ACTION_BY_REASON-Zuordnung oben verwandelt diese Urteile in dieselben Aktionen Unterdrücken/Erneut versuchen/Behalten.

Möchten Sie die Urteile, gegen die Sie klassifizieren können? Der kostenlose Tarif enthält 100 Credits, und die API-Referenz dokumentiert die Grund-Codes und den /jobs-Ergebnis-Endpunkt, aus dem der proaktive Kreislauf liest.