# E-Mail Bounce Rate: Messung, Benchmarks und Gegenmaßnahmen URL: https://notificationharbor.com/de/journal/e-mail-bounce-rate-messen-benchmarks-massnahmen Type: blog Locale: de Published: 2026-11-03 Updated: 2026-11-03 --- > Die E-Mail Bounce Rate ist Bounces geteilt durch Sendungen, doch Nenner, Bounce-Typ und Stream verändern das Ergebnis. So messen Sie sie und worauf Sie alarmieren sollten. Ihre E-Mail Bounce Rate ist der Anteil gesendeter Nachrichten, den der empfangende Server abgelehnt hat. Bei einer gesunden Liste sollten harte Bounces unter 1 % bleiben, ab 2 % beginnen Sie mit der Untersuchung, und ab 5 % behandeln Sie es als Incident. Die meisten Teams lesen eine einzige Zahl aus dem Dashboard und übersehen dabei, dass Nenner, Bounce-Typ und Zeitfenster die Antwort jeweils verändern. Der Rest dieses Beitrags dreht sich zuerst darum, die Zahl richtig zu messen, und erst danach darum, was Sie dagegen tun. ## Die Formel ist einfach. Uneinig ist man sich beim Nenner. Die Bounce Rate ergibt sich aus den bounced Nachrichten, geteilt durch die gesendeten Nachrichten, mal 100. Manche ESPs teilen stattdessen durch die zugestellten Nachrichten. Dadurch wirkt die Rate größer, weil zugestellte Nachrichten die Bounces bereits ausschließen. Prüfen Sie, welche Variante Ihr Provider ausweist, bevor Sie die Zahl mit einem Benchmark vergleichen. Amazon SES berechnet seine Bounce Rate zum Beispiel nur aus harten Bounces, gemessen an dem, was über das Konto gesendet wurde. Das ist wichtig. Ein Dashboard, das harte und weiche Bounces mischt, zeigt eine höhere Zahl als die, nach der Ihr Provider Sie bewertet. Legen Sie eine Definition fest und schreiben Sie sie neben die Kennzahl, notfalls in den Titel des Dashboards. Wir rechnen harte Bounces geteilt durch gesendete Nachrichten, pro Sending-Domain, über 24 Stunden und über 7 Tage. Wenn zwei Personen im Team für dieselbe Woche unterschiedliche Werte nennen, vergleichen Sie zuerst den Nenner. ![Schreibtisch mit Notizbuch-Skizze einer steigenden Linie neben einer Tastatur](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/0de2bf-img1.webp) ## Harte, weiche und blockierte Bounces sind drei verschiedene Signale Ein harter Bounce ist ein dauerhafter Fehler. Die Adresse existiert nicht, die Domain lässt sich nicht auflösen oder das Postfach wurde geschlossen. SMTP meldet ihn mit einem enhanced Status Code der Klasse 5.x.x, definiert in [RFC 3463](https://datatracker.ietf.org/doc/html/rfc3463). Ein weicher Bounce ist ein vorübergehender Fehler: ein volles Postfach, ein Server, der gerade nicht erreichbar ist, eine zu große Nachricht. Diese kommen mit 4.x.x-Codes zurück, und ein sauber arbeitender Sender versucht es erneut. Die dritte Kategorie verstecken Dashboards am liebsten. Ein Block ist eine 5.x.x-Ablehnung, die nichts über die Adresse aussagt, aber viel über Sie: eine gelistete IP, eine fehlgeschlagene Authentifizierungsprüfung, ein Filter für Inhalt oder Reputation. Wer einen Block als harten Bounce zählt, hält seine Liste für schmutzig, obwohl das Sending-Setup das Problem ist. Verzichten Sie auf Reports mit einer einzigen Zeile „Bounces“. Teilen Sie sie in drei Reihen auf, sonst bereinigen Sie eine Liste, die nie das Problem war. ## Was gilt 2026 als gute Bounce Rate? Es gibt keinen veröffentlichten Einheitswert, und das sollten Sie wissen, bevor Sie eine Zahl zitieren. Gmail und Yahoo veröffentlichen Schwellen für Spam-Beschwerden, nicht für Bounces. Google verlangt laut seinen [Richtlinien für Absender](https://support.google.com/a/answer/81126) von Bulk-Sendern, die Spam-Rate in Postmaster Tools unter 0.10 % zu halten und nie 0.30 % zu erreichen. Die Arbeitswerte für Bounces stammen von ESPs und aus der Praxis. Die folgenden Schwellen nutzen wir als Alarmstufen, nicht als Garantien eines Mailbox-Anbieters. Harte Bounce Rate pro Domain über 24 Stunden und unser Umgang damit: - **Unter 0.5 %:** normal für eine engagierte, verifizierte Liste. - **0.5 % bis 1 %:** beobachten und die Quellen neuer Adressen prüfen. - **1 % bis 2 %:** untersuchen und das Segment mit der höchsten Rate pausieren. - **2 % bis 5 %:** Massenversand aus diesem Stream stoppen und den Import oder das Formular finden, das dahintersteckt. - **Über 5 %:** Incident. Amazon SES setzt Konten auf diesem Niveau unter Prüfung. Die letzte Zeile ist eine dokumentierte Grenze. In seiner [Dokumentation zum Reputation-Dashboard](https://docs.aws.amazon.com/ses/latest/dg/reputationdashboardmessages.html) schreibt Amazon SES, dass ein Konto mit einer Bounce Rate von 5 % oder mehr unter Prüfung gestellt wird und der Versand pausiert werden kann, wenn die Rate dauerhaft über 10 % liegt. Andere Provider nutzen andere Werte und Formulierungen. Lesen Sie deshalb Ihren eigenen Vertrag. ## Segmentieren Sie zuerst: Eine Gesamtrate verdeckt den fehlerhaften Stream Ein Gesamtwert von 0.8 % für das Konto kann einen transaktionalen Stream bei 0.1 % und einen Re-Engagement-Import bei 6 % enthalten. Der Mittelwert wirkt akzeptabel, während der zweite Stream die Sending-Domain still beschädigt. Berechnen Sie die Rate pro Stream, pro Quelle und pro Empfänger-Domain. Vier Schnitte finden die meisten Probleme: - **Nach Stream.** Transaktionale, Lifecycle- und Bulk-Kampagnen dürfen nie eine gemeinsame Zahl teilen. - **Nach Anmeldequelle.** Formulare, API-Anmeldungen, CSV-Importe und Partnerlisten haben sehr unterschiedliche Adressqualität. - **Nach Empfänger-Domain.** Ein Spike bei einem einzelnen Anbieter deutet meist auf eine Ablehnungsrichtlinie hin, nicht auf eine schmutzige Liste. - **Nach Alter der Adresse.** Adressen, die vor mehr als 12 Monaten erfasst wurden, bouncen häufiger als frische. Das ist kein Reporting-Detail. Der Unterschied liegt darin, ob Sie einen Validierungsfehler im Formular in einer Stunde beheben oder aus Panik eine gesunde Liste bereinigen. ![Laptop mit Terminal-Logstream und markierten Zeilen in einem abgedunkelten Raum](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/98b212-img2.webp) Ein fünfter Schnitt lohnt sich, sobald die anderen stehen: nach sendender IP oder Domain. Betreiben Sie eine dedizierte IP für transaktionale Mails und einen geteilten Pool für Kampagnen, zeigt ein Spike auf einem davon, wo Sie suchen müssen, noch bevor Sie eine Logzeile öffnen. ## Bounce-Events vom Provider lesen, ohne Daten zu verlieren Jeder ernstzunehmende ESP stellt Bounces als Events bereit, über einen Webhook, ein Topic oder eine Events-API. Behandeln Sie diesen Feed als Quelle der Wahrheit und schreiben Sie ihn in einen eigenen Speicher. Dashboards aggregieren und verlieren später genau die Details, die Sie für eine Analyse brauchen. Speichern Sie für jedes Event sechs Felder: Message-ID, Empfänger, Bounce-Typ, den enhanced Status Code, den Diagnosetext und den Zeitstempel. Mit diesen sechs beantworten Sie fast jede Frage, die in einer Nachbetrachtung auftaucht. `{ "event": "bounce", "message_id": "msg_01H9", "recipient": "user@example.com", "bounce_type": "permanent", "status": "5.1.1", "diagnostic": "550 5.1.1 user unknown", "stream": "lifecycle", "ts": "2026-11-02T09:14:03Z" }`Machen Sie den Handler idempotent und schlüsseln Sie ihn über die Event-ID des Providers plus die Message-ID. Provider wiederholen Webhooks. Ein doppeltes Hard-Bounce-Event, das einen Zähler zweimal erhöht, verzerrt Ihre Rate und kann eine Adresse unterdrücken, die eigentlich in Ordnung ist. Postmark und Resend trennen die Bounce-Typen in ihren Events und lassen sie pro Message-Stream abrufen. Dadurch ist die Aufteilung nach Stream, wie oben beschrieben, günstig umzusetzen. ## Die Suppression-Regel leistet die meiste Arbeit Der wirkungsvollste Hebel ist die automatische Unterdrückung. Nach einem harten Bounce senden Sie an diese Adresse dauerhaft nicht mehr, und zwar auf Anwendungsebene, nicht nur über die Liste des Providers. Die meisten ESPs unterdrücken harte Bounces selbst. Die Lücke entsteht, wenn Sie den Provider wechseln, zwei parallel betreiben oder ein System Mails verschickt, das die Suppression-Liste nie liest. Eine eigene Tabelle, geschlüsselt über eine normalisierte Adresse, schließt diese Lücke. Bei weichen Bounces zählen Sie statt einzelner Events. Unser Standard: Unterdrückung nach drei aufeinanderfolgenden weichen Bounces über mindestens sieben Tage. Ein Postfach, das eine Woche voll war, ist für Lifecycle-Zwecke praktisch verloren. Löschen Sie bounced Adressen nicht aus Ihrer Nutzertabelle. Markieren Sie sie mit Status Code und Datum. Eine gelöschte Zeile kann nicht zeigen, dass dieselbe Adresse im letzten Quartal zweimal gebounct hat. Sie brauchen den Datensatz, um zu verhindern, dass dieselbe Adresse beim nächsten CSV-Import wieder auftaucht. Genau so wird eine „bereinigte“ Liste am häufigsten wieder schmutzig. ![Leere Briefumschläge auf einem Tisch, drei davon in einer Ablage ausgesondert](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/dc3638-img3.webp) ## Warum die Rate plötzlich steigt: die üblichen Ursachen, nach Häufigkeit sortiert Wenn sich die Rate bewegt, suchen Sie die Ursache in dieser Reihenfolge. Die ersten drei erklären die meisten Spikes. - **Ein neuer Import.** Eine CSV aus einer Veranstaltung, von einem Partner oder aus einem alten CRM-Export. Prüfen Sie die Bounce Rate nach Quelle, bevor Sie irgendetwas anderes tun. - **Ein Anmeldeformular ohne Validierung.** Tippfehler wie gmial.com und Wegwerf-Domains. Eine Syntax- und MX-Prüfung beim Absenden entfernt die meisten davon, und eine Bestätigungsmail entfernt den Rest, bevor er in einem Lifecycle-Flow als Versand zählt. - **Eine Änderung beim Versand.** Eine neue IP, eine neue Domain oder ein Warm-up, das zu schnell hochgefahren wurde und statt harter Bounces Blocks erzeugt. - **Ein Authentifizierungsbruch.** SPF-, DKIM- oder DMARC-Alignment schlägt nach einer DNS-Änderung fehl. - **Eine Ablehnungsrichtlinie des Providers.** Eine Empfänger-Domain hat ihre Filter verschärft. Ihre Rate steigt nur dort. Die Diagnose ist die Verteilung der Status Codes, gruppiert nach Stream und Empfänger-Domain, im selben Zeitfenster wie der Spike. Ein Anstieg bei 5.1.1 (Benutzer unbekannt) weist auf die Liste. Ein Anstieg bei 5.7.x weist auf Richtlinie, Authentifizierung oder Reputation. Diese brauchen gegensätzliche Maßnahmen, deshalb speichern Sie den Code. ## Worauf wir alarmieren würden Ein Alarm auf dem Tagesdurchschnitt kommt zu spät. Ein fehlerhafter Import kann in einer Stunde 40,000 Nachrichten verschicken. Alarmieren Sie deshalb über ein rollierendes Fenster. - Harte Bounce Rate über 1 % in den letzten 1,000 Sendungen eines beliebigen Streams. - Eine einzelne Empfänger-Domain über 5 % bei mindestens 200 Sendungen in einer Stunde. - Eine Zahl von 5.7.x-Blocks, die Ihre normale Basislinie deutlich übersteigt. Verbinden Sie die ersten beiden mit einer Pause des betroffenen Streams und nicht mit einer Seite an einen Menschen. Ein Mensch kann danach untersuchen. Die Pause schützt Ihre Reputation in den nächsten zehn Minuten. Exportieren Sie die Rate in das Monitoring, das Sie bereits betreiben, ob Grafana, Datadog oder eine Eigenlösung, und behalten Sie das Stream-Label an der Zeitreihe, damit die Aufteilung den Export überlebt. Für das Reporting nach oben nutzen Sie die harte Bounce Rate pro Stream über 7 Tage, ergänzt um die Anzahl der Blocks. Weiche Bounces gehören in die Engineering-Sicht, wo sie nützlich sind, nicht in die Management-Sicht, wo sie Verwirrung stiften. Berichten Sie nie allein die Gesamtzahl des Kontos, denn sie bewegt sich aus Gründen, die im Raum niemand erklären kann. Wenn jemand nur eine Zahl verlangt, nennen Sie die harte Bounce Rate des transaktionalen Streams. Dort kostet ein Fehler einen Passwort-Reset oder eine Rechnung, und dort lässt sich am saubersten ablesen, ob Ihre Infrastruktur gesund ist. Der nächste konkrete Schritt ist klein: Ziehen Sie die Bounce-Events der letzten 30 Tage, gruppieren Sie nach Stream und Status Code, und schauen Sie, welche Zeile Sie nicht erwartet haben. ## FAQ ### Was ist eine gute E-Mail Bounce Rate? Bei harten Bounces ist unter 1 % eine vernünftige Obergrenze für eine engagierte Liste, und unter 0.5 % ist bei verifizierten Adressen üblich. Gmail und Yahoo veröffentlichen keinen offiziellen Bounce-Schwellenwert. Diese Werte sind deshalb Arbeitsgrenzen für Alarme und keine Regeln der Mailbox-Anbieter. ### Wie berechnet man die E-Mail Bounce Rate? Teilen Sie die bounced Nachrichten durch die gesendeten Nachrichten und multiplizieren Sie mit 100. Manche ESPs teilen stattdessen durch die zugestellten Nachrichten, was einen höheren Wert ergibt. Prüfen Sie den Nenner, bevor Sie die Zahl mit einem Benchmark vergleichen. ### Ab welcher Bounce Rate wird mein Konto gesperrt? Das hängt vom Provider ab. Amazon SES stellt ein Konto bei einer Bounce Rate von 5 % unter Prüfung und kann den Versand pausieren, wenn die Rate dauerhaft über 10 % liegt. Andere ESPs setzen eigene Grenzen, prüfen Sie deshalb die Bedingungen Ihres Anbieters. ### Zählen weiche Bounces zur Bounce Rate? Das hängt vom Provider ab. Manche zählen nur harte Bounces, so wie Amazon SES. Führen Sie weiche Bounces in einer eigenen Reihe, damit ein vorübergehendes Postfachproblem nicht die Zahl verzerrt, die über Ihren Kontostatus entscheidet. ### Wie senke ich meine E-Mail Bounce Rate schnell? Unterdrücken Sie jede hart gebouncte Adresse auf Anwendungsebene, validieren Sie Adressen bei der Anmeldung mit einer Syntax- und MX-Prüfung und stoppen Sie den Import oder die Quelle mit der höchsten Rate. Die Quelle zu beheben ist wirksamer, als die ganze Liste zu bereinigen. ### Ist eine Blockierung dasselbe wie ein harter Bounce? Nein. Ein Block ist eine 5.x.x-Ablehnung, die durch Ihre IP, Ihre Domain-Reputation oder Ihre Authentifizierung verursacht wird, nicht durch eine ungültige Adresse. Wer ihn als harten Bounce zählt, lässt die Liste schlechter aussehen, obwohl das Sending-Setup das Problem ist.