Was ist das Allererste, das man tun sollte, wenn die Zustellung plötzlich einbricht?

Verhindern Sie, dass es schlimmer wird. Pausieren oder drosseln Sie nicht kritische Bulk- und Werbeströme, lassen Sie Transaktionsmails auf ihrem eigenen Stream weiterlaufen und eröffnen Sie einen Vorfall mit einer benannten Leitung und einer Startzeit. Die Diagnose kommt erst danach, denn jede weitere Nachricht, die in eine beschädigte Reputation gesendet wird, vergrößert den Schaden.

Sollte ich den gesamten Versand stoppen?

In der Regel nicht. Passwort-Resets, Einmalcodes und Belege sind zeitkritisch, und Menschen warten darauf. Pausieren Sie die optionalen und riskanten Streams, schützen Sie die unverzichtbaren, und stoppen Sie nur dann alles, wenn das Problem ein Sicherheitsvorfall ist, etwa ein kompromittierter Zugang, über den Mails verschickt werden, die Sie nicht verfasst haben.

Wie unterscheide ich ein Reputationsproblem von einem technischen Fehler?

Ein technischer Fehler wie defektes DNS, ein abgelaufenes Zertifikat oder falsche Zugangsdaten beginnt meist zu einem exakten Zeitpunkt, betrifft alle Anbieter und zeigt eindeutige Fehlertexte. Ein Reputationsproblem zeigt sich meist zuerst bei ein oder zwei Anbietern in Form von Deferrals oder Platzierung im Spam-Ordner und wächst über Tage. Die Entscheidungstabelle in diesem Leitfaden hilft Ihnen, beides auseinanderzuhalten.

Warum sind Deferrals wichtig, wenn die Mail nicht abgelehnt wird?

Ein Deferral ist eine temporäre 4xx-Antwort, die bedeutet: später erneut versuchen. Anbieter nutzen sie oft, um einen Absender zu bremsen, dem sie noch nicht vertrauen. Wächst Ihre Warteschlange, können Nachrichten ablaufen, bevor sie zugestellt werden. Ein Deferral-Anstieg ist daher ein Frühwarnsignal, das Aufmerksamkeit verdient, bevor daraus Ablehnungen werden.

Kann allein ein Rückgang der Öffnungen auf einen Vorfall hindeuten?

Nicht für sich genommen. Die Mail Privacy Protection von Apple und das Blockieren von Bildern machen Öffnungsdaten unzuverlässig. Nutzen Sie Öffnungen daher als Hinweis und bestätigen Sie ihn mit Zustellungsereignissen, Klickdaten und Reputationsdaten im Stil von Postmaster. Ein Rückgang der Öffnungen zusammen mit mehr Platzierungen im Spam-Ordner ist überzeugender als ein Rückgang der Öffnungen allein.

Bei welchen Schwellenwerten sollten wir alarmieren?

Es gibt keine allgemeingültige Zahl. Gehen Sie von Ihrem eigenen Normalbereich über mehrere Wochen aus und alarmieren Sie bei einer deutlichen Abweichung, etwa wenn sich die Bounce-Rate oder die Beschwerderate gegenüber der Baseline verdoppelt oder eine von Ihren Mailbox-Anbietern veröffentlichte Grenze überschreitet. Die Beispielwerte in diesem Leitfaden sind Ausgangspunkte zum Anpassen, keine Standards.

Wie lange dauert die Wiederherstellung?

Das hängt von der Ursache und vom Anbieter ab. Ein korrigierter DNS-Eintrag kann sich innerhalb von Stunden erholen, während eine beschädigte Domain-Reputation Tage oder Wochen sorgfältigen Versands braucht, um wieder aufgebaut zu werden. Planen Sie eine schrittweise Erholung ein und messen Sie sie, statt Stakeholdern ein Datum zu versprechen.

Wer sollte bei einem Zustellbarkeitsvorfall in Bereitschaft sein?

Mindestens eine Incident-Leitung, ein technischer Untersucher, der Logs und DNS lesen kann, ein Absender- oder Kampagnenverantwortlicher, der weiß, was versendet wurde, und eine Kommunikationsperson, die Stakeholder und Support informiert. In einem kleinen Team kann eine Person zwei Rollen innehaben, die Rollen sollten aber trotzdem schriftlich festgehalten sein.

Brauchen wir bei einem kleinen Vorfall eine Nachbetrachtung?

Ja, eine kurze. Schon ein halbseitiges Protokoll darüber, was passiert ist, warum, und welche Leitplanke es beim nächsten Mal abfängt, macht aus einem schlechten Tag eine dauerhafte Verbesserung. Halten Sie sie schuldzuweisungsfrei, damit Menschen Fakten offen teilen.

Runbook Zustellbarkeitsvorfall: Plötzlicher Einbruch

Ein Runbook für Zustellbarkeitsvorfälle ist der schriftliche Plan, dem Ihr Team folgt, wenn die Zustellung plötzlich einbricht: Bounces schnellen hoch, Mails hängen in Warteschlangen, Beschwerden steigen oder Kunden sagen, dass Nachrichten nie ankommen. Die Schritte vorab festzulegen ist wichtig, denn in der ersten Stunde wird der meiste Schaden entweder eingedämmt oder verschlimmert. Dieser Leitfaden gibt uns ein praxistaugliches Runbook: eine 30-Minuten-Triage, eine Entscheidungstabelle, zu sammelnde Belege, Schritte zur Wiederherstellung, Nachrichtenvorlagen, ein Review-Format und Leitplanken.

30 minZielfenster für Eindämmung und erste Klassifizierung

2zu trennende Streams: geschützte Transaktionsmails und pausierbarer Bulk

5Symptomfamilien in unserer Entscheidungstabelle

4Bereitschaftsrollen, die vor einem Vorfall benannt werden sollten

Was als Zustellbarkeitsvorfall gilt

Nicht jeder Einbruch ist ein Vorfall. Normaler Traffic schwankt mit Kalender, Zielgruppe und Inhalt. Wir sprechen von einem Vorfall, wenn eine wichtige Kennzahl schnell ihren Normalbereich verlässt und die Ursache nicht offensichtlich ist: Bounce-Rate, Deferral-Volumen, Beschwerderate, Zustellzeit für wichtige Nachrichten oder Inbox-Platzierung bei einem großen Mailbox-Anbieter. Früh zum Runbook zu greifen kostet wenig. Zu warten kostet Reputation.

Legen Sie Ihre Schweregrade vorab schriftlich fest. Ein einfaches Schema mit drei Stufen funktioniert gut: ein Beobachtungsfall niedriger Stufe, den eine Person überwacht, ein Standardvorfall mit benannter Leitung und stündlichen Updates sowie ein kritischer Vorfall, bei dem Transaktionsmails wie Passwort-Resets oder Zahlungsbelege betroffen sind oder ein Zugang kompromittiert sein könnte. Die untenstehenden Definitionen sind Beispiele zum Anpassen, kein Standard.

Stufe	Beispielauslöser (auf Ihren Traffic abstimmen)	Reaktion
Beobachtung	Eine Kennzahl liegt bei einem einzelnen Versand außerhalb ihres üblichen Bereichs	Verantwortliche Person prüft innerhalb einer Stunde und notiert Erkenntnisse
Vorfall	Eine Kennzahl verdoppelt sich gegenüber der Baseline, oder ein großer Anbieter verzögert oder lehnt einen großen Teil der Mails ab	Runbook öffnen, Leitung benennen, nicht kritischen Bulk pausieren, Stakeholder stündlich informieren
Kritisch	Transaktionsmails verzögert oder abgelehnt, vermutete kompromittierte Zugangsdaten oder ein Blocklist-Eintrag auf einer wichtigen Sende-IP oder Domain	Vollständiges Runbook, alle vier Rollen besetzt, Update alle 30 Minuten bis zur Eindämmung

Die ersten 30 Minuten: Triage und Eindämmung

Das Ziel der ersten halben Stunde ist nicht, die Ursache zu finden. Es geht darum, das Wachsen des Schadens zu stoppen und das Problem so gut zu klassifizieren, dass klar ist, wo man suchen muss. Arbeiten Sie diese Schritte der Reihe nach ab und halten Sie die Zeit jedes Schritts fest.

Minuten 0 bis 5: ausrufen. Eröffnen Sie einen gemeinsamen Kanal, benennen Sie die Incident-Leitung und notieren Sie, wann das Problem zum ersten Mal bemerkt wurde und wann es vermutlich begann. Verwenden Sie für alle Zeitstempel UTC, damit Logs, Berichte und Personen an verschiedenen Orten zusammenpassen.
Minuten 5 bis 10: Transaktionsmails schützen. Prüfen Sie, dass Passwort-Resets, Einmalcodes und Belege weiterhin zugestellt werden, indem Sie einige Testnachrichten an Postfächer senden, die Sie bei den großen Anbietern kontrollieren. Schlagen sie fehl, behandeln Sie den Vorfall als kritisch.
Minuten 10 bis 15: den Rest pausieren oder drosseln. Pausieren Sie Werbekampagnen, Newsletter und jede geplante Automatisierung, die warten kann. Senken Sie bei Streams, die sich nicht vollständig pausieren lassen, die Senderate. Löschen Sie Mails in der Warteschlange noch nicht, denn sie sind Beweismaterial.
Minuten 15 bis 25: klassifizieren. Lesen Sie Bounce-, Deferral- und Beschwerdezahlen nach Mailbox-Anbieter für den letzten Tag im Vergleich zur Vorwoche. Wählen Sie mit der untenstehenden Entscheidungstabelle die wahrscheinlichste Ursachenfamilie.
Minuten 25 bis 30: Arbeit verteilen und das erste Update senden. Geben Sie jedem Untersucher eine konkrete Frage und senden Sie ein kurzes internes Update mit den bisher bekannten Fakten und dem Zeitpunkt des nächsten.

Wenn Transaktionsmails auf einem eigenen Stream, einer eigenen Domain und einem eigenen IP-Pool laufen, wird diese Triage deutlich einfacher, weil Sie Werbung pausieren können, ohne Belege anzufassen. Falls Sie das noch nicht umgesetzt haben, lesen Sie Transaktions- und Marketing-E-Mail-Streams trennen und machen Sie daraus ein Projekt, sobald der Vorfall vorbei ist.

Eine Regel für die erste Stunde: Ändern Sie jeweils nur eine Sache und notieren Sie sie mit der Uhrzeit. Wenn drei Personen gleichzeitig DNS, Inhalt und Senderate ändern, kann niemand sagen, welche Änderung geholfen hat.

Entscheidungstabelle von Symptom zu Ursache

Mit dieser Tabelle machen Sie aus dem, was Sie sehen, die erste Prüfung. Sie nennt wahrscheinliche Ursachen, keine Gewissheiten, und mehrere können zugleich auftreten. Die erste Spalte zeigt, was Ihre Dashboards anzeigen. Die zweite sagt, welche Frage zu stellen ist. Die dritte verweist auf die Prüfung, die es bestätigt oder ausschließt.

Symptom	Umfang	Wahrscheinliche Ursachen	Erste Prüfungen
Bounce-Anstieg (5xx-Ablehnungen)	Alle Anbieter, beginnend zu einem exakten Zeitpunkt	Defekte Authentifizierung, abgelaufener oder entfernter DNS-Eintrag, falsche Zugangsdaten, Versand von einer nicht verifizierten Domain	DNS-Einträge für SPF, DKIM und DMARC; jüngste DNS- oder Anbieteränderungen; Fehlertext in den Bounce-Antworten
Bounce-Anstieg (5xx-Ablehnungen)	Ein Anbieter	Richtlinienblockade oder Reputationseintrag bei diesem Anbieter, plötzliche Änderung von Volumen oder Inhalt	Bounce-Text dieses Anbieters, dessen Postmaster-Daten, jüngste Versandhistorie zu diesem Anbieter
Bounce-Anstieg mit „Unknown user“-Fehlern	Überwiegend eine Kampagne oder ein Import	Veraltete, gekaufte oder falsch geschriebene Adressen, die einer Liste hinzugefügt wurden	Quelle der Liste, Alter der Adressen, Validierungsergebnisse
Deferral-Anstieg (4xx)	Ein oder zwei Anbieter	Ratenbegrenzung, frühe Reputationsbedenken, zu viele Verbindungen	Deferral-Text, aktuelle Senderate und Parallelität, Alter der Warteschlange
Deferral-Anstieg (4xx)	Alle Anbieter	Netzwerk- oder DNS-Probleme auf Ihrer Seite, TLS-Fehler, Ressourcenlimits auf den Sendeservern	Timeouts und TLS-Fehler in den Logs, DNS-Auflösung von den Sende-Hosts aus
Beschwerdeanstieg	Eine Kampagne oder ein Segment	Unerwartete Zielgruppe, unklare Anmeldequelle, schwer auffindbarer Abmeldelink	Segmentdefinition, Anmeldequelle, Sichtbarkeit des Abmeldelinks, Feedback-Loop-Daten
Öffnungen und Klicks sinken, Bounces unverändert	Ein Anbieter	Mails landen im Spam-Ordner, ohne dass es eine Ablehnung gibt	Postmaster-Daten, Ergebnisse von Seed- oder Panel-Test-Postfächern, jüngste Änderungen an Inhalt oder Volumen
Öffnungen und Klicks sinken, Bounces unverändert	Alle Anbieter	Probleme mit der Tracking-Domain, Bildblockierung, defekte Links oder eine geänderte Messung	Zertifikat und DNS der Tracking-Domain, Linktests, jüngste Änderungen an Vorlagen
Mails aus unbekannten Quellen erscheinen in DMARC-Berichten als Absender Ihrer Domain	Erscheint in Aggregatberichten	Spoofing oder ein vergessenes Drittwerkzeug, das in Ihrem Namen sendet	Quellen in den DMARC-Aggregatberichten, Liste der zugelassenen Absender, Zugriffslogs für Ihre Sende-Zugangsdaten

Zwei Muster verdienen besondere Sorgfalt. Ein plötzlicher Anstieg des Volumens, den Sie nicht geplant haben, zusammen mit einem Beschwerdeanstieg kann auf ein kompromittiertes Konto oder einen geleakten Schlüssel hindeuten, der in Ihrem Namen sendet. Das ist zuerst ein Sicherheitsvorfall und erst danach ein Zustellbarkeitsvorfall. Und ein Problem bei nur einem Anbieter ist oft eine Reputationsfrage bei genau diesem Anbieter, während ein Problem bei allen Anbietern, das in einer bestimmten Minute begann, meist auf etwas hindeutet, das Sie geändert haben oder das abgelaufen ist. Zur Vertiefung der einzelnen Familien erklärt unser Leitfaden zu SMTP-Bounce-Codes, wie man 4xx- und 5xx-Antworten liest, und die Checkliste zur Fehlersuche bei Spam-Ordner-Problemen behandelt Platzierungsprobleme Schritt für Schritt.

Belege, die Sie sichern sollten, bevor Sie etwas ändern

Belege verschwinden schnell. Logs rotieren, Warteschlangen leeren sich und Berichte werden überschrieben. Sichern Sie zuerst, beheben Sie danach. Legen Sie alles in einem gemeinsamen Ordner ab, dessen Name die Startzeit des Vorfalls enthält, und notieren Sie die Zeitzone jedes Exports.

Beleg	Was er uns sagt	So erfassen Sie ihn
Ereignis-Logs der letzten 7 Tage	Anzahl akzeptierter, verzögerter, gebouncter und beanstandeter Mails nach Anbieter, Stream und Kampagne	Export aus Ihrem MigoSMTP-Dashboard, per API oder über Webhooks; die genauen Optionen entnehmen Sie Ihrem MigoSMTP-Konto oder der API-Dokumentation
Rohe Bounce- und Deferral-Antworten	Der genaue Wortlaut, mit dem Anbieter das Problem erklären	Kopieren Sie pro Anbieter eine Stichprobe jeder unterschiedlichen Meldung samt erweitertem Statuscode
Vollständige Header zugestellter und im Spam-Ordner gelandeter Testnachrichten	Authentifizierungsergebnisse, Routing und eventuelle Filterurteile	Senden Sie Tests an Postfächer, die Sie kontrollieren, und speichern Sie jeweils den Originalquelltext
DMARC-Aggregatberichte	Welche Quellen in Ihrem Domainnamen senden und ob SPF und DKIM bestehen und ausgerichtet sind	Holen Sie die Berichte der letzten 7 bis 14 Tage und vergleichen Sie sie mit dem Vorzeitraum
Postmaster-Daten der Mailbox-Anbieter	Reputationssignale für Domain und IP, Spam-Rate und Authentifizierungsergebnisse, soweit der Anbieter sie veröffentlicht	Screenshot oder Export der Dashboards für die betroffenen Domains
Blocklist- und DNS-Prüfungen	Ob Sende-IPs oder Domains gelistet sind und ob die Einträge heute korrekt sind	Fragen Sie die wichtigsten von Ihnen genutzten Blocklists ab und lösen Sie Ihre SPF-, DKIM-, DMARC-, Reverse-DNS- und Tracking-Einträge auf
Änderungshistorie	Was rund um den Startzeitpunkt ausgerollt, bearbeitet oder umgestellt wurde	Fragen Sie das ganze Team: Code-Releases, DNS-Änderungen, neue Tools, Listenimporte, Vorlagenänderungen

Schnelle DNS-Prüfungen lassen sich von jedem Terminal aus durchführen. Die folgenden Befehle verwenden eine erfundene Domain und einen erfundenen Selector, um das Muster zu zeigen; ersetzen Sie sie durch Ihre eigenen Werte.

# Is the SPF record still published and valid?
dig +short TXT example.com

# Is the DKIM key for the selector still published?
dig +short TXT selector1._domainkey.example.com

# What DMARC policy is published?
dig +short TXT _dmarc.example.com

# Does the sending IP have the expected reverse DNS name?
dig +short -x 192.0.2.25

Zum Lesen von Headern folgen Sie unserem Leitfaden zum Lesen von E-Mail-Headern für die Fehlersuche bei Zustellung und Authentifizierung. Zu Reputations-Dashboards erklärt der Artikel zu den Google Postmaster Tools, was die Signale bedeuten und wie Sie sie einrichten, bevor Sie sie brauchen.

Schritte zur Eindämmung und Wiederherstellung

Die Eindämmung stoppt den Schaden. Die Wiederherstellung bringt das Volumen sicher zurück. Es sind getrennte Phasen, und wer sie vermischt, entfacht das Feuer erneut. Nehmen Sie pausierte Streams nicht wieder auf, nur weil die Kennzahlen eine Stunde lang besser aussehen.

Eindämmungsmaßnahmen nach Ursache

Authentifizierungsfehler: Stellen Sie den DNS-Eintrag wieder her oder korrigieren Sie ihn, bestätigen Sie mit einer Testnachricht, dass SPF, DKIM und DMARC bestehen und ausgerichtet sind, und nehmen Sie den Versand erst dann wieder auf.
Kompromittierte Zugangsdaten oder ein kompromittiertes Konto: Deaktivieren und ersetzen Sie die Zugangsdaten, prüfen Sie, was gesendet wurde, informieren Sie den Kontoinhaber und folgen Sie Ihrem Sicherheitsprozess. Das Rotieren von Schlüsseln behandelt unsere Anleitung zur API-Schlüssel-Sicherheit.
Schlechte Liste oder schlechtes Segment: Entfernen Sie das Segment, unterdrücken Sie Adressen, die gebounct sind oder sich beschwert haben, und verfolgen Sie nach, wie die Adressen in die Liste gelangten, damit es nicht wieder passiert.
Problem mit Inhalt oder Link: Ziehen Sie die Vorlage zurück, entfernen Sie den verdächtigen Link oder Anhang und testen Sie die überarbeitete Version, bevor sie erneut versendet wird.
Blocklist-Eintrag: Klären Sie zuerst, warum es zum Eintrag kam, beheben Sie diese Ursache und folgen Sie dann dem Delisting-Verfahren der jeweiligen Liste. Die Schritte behandelt unser Leitfaden zur Blocklist-Entfernung.
Ratenbegrenzung durch den Anbieter: Reduzieren Sie Parallelität und Nachrichten pro Verbindung für diesen Anbieter und lassen Sie die Warteschlange in dem Tempo abfließen, das er erlaubt.

Ein gestufter Wiederherstellungsplan

Nehmen Sie zuerst die aktivsten und jüngsten Abonnenten wieder auf, mit einem Bruchteil des normalen Volumens.
Halten Sie jede Stufe mindestens einen vollen Tag lang, um Rückmeldungen der Anbieter abzuwarten, und länger bei Anbietern, die Daten verzögert melden.
Erhöhen Sie das Volumen nur, solange Bounce-, Deferral- und Beschwerderaten auf oder unter Ihrer Baseline vor dem Vorfall bleiben.
Verschlechtert sich ein Signal, gehen Sie auf die vorherige Stufe zurück, statt die Position zu halten.
Holen Sie kältere Segmente zuletzt zurück und erwägen Sie eine Reaktivierungsrunde oder die Entfernung von Kontakten, die lange nicht interagiert haben.
Erklären Sie die Wiederherstellung erst, wenn die Signale bei vollem Volumen über einen zu Beginn vereinbarten Zeitraum gesund bleiben.

Dieselbe vorsichtige Steigerung beschreiben wir für neue Infrastruktur in unserem Warm-up-Artikel, und sie gilt auch hier. Betrachten Sie die Wiederherstellung als kleinere Version des Warm-ups, mit Ihrem besten Traffic zuerst.

Kommunikationsvorlagen

Gute Kommunikation senkt die Zahl der Rückfragen, die diejenigen unterbrechen, die das Problem beheben. Halten Sie Nachrichten kurz, sachlich und regelmäßig. Schreiben Sie, was bekannt ist, was nicht, was wir tun und wann das nächste Update kommt. Vermeiden Sie Schuldzuweisungen und versprechen Sie keine Behebungszeit, die Sie nicht kontrollieren. Passen Sie den erfundenen Text unten an Ihren eigenen Ton an.

Internes Stakeholder-Update

Subject: Email delivery incident - update 1 (14:30 UTC)

Status: Investigating, contained.
Impact: Promotional emails to one large mailbox provider are being
delayed or filtered. Order confirmations and password resets are
being delivered normally in our tests.
Actions taken: Promotional sends paused at 14:10 UTC. Evidence
collection in progress. No changes made to DNS yet.
Next steps: Review provider responses and authentication reports.
Needed from you: Please do not schedule new campaigns until we confirm.
Next update: 15:30 UTC or sooner if anything changes.
Incident lead: [name]

Nachricht für Support und kundennahe Teams

Subject: For support: delayed or missing marketing emails

What customers may report: Some people have not received recent
newsletters or promotions.
What we know: We are investigating a delivery problem affecting one
mailbox provider. Account and transactional emails are working.
What to say: We are aware that some emails are delayed and are working
on it. Please ask the customer to check their spam folder and to add
our sending address to their contacts.
What not to say: Do not name a cause or promise a time until the
incident lead confirms.
Escalate to the incident lead if: a customer reports missing password
reset or payment emails.
Next update: 16:00 UTC.

Ein durchgespieltes Beispiel mit erfundenen Zahlen

Ein Team versendet normalerweise etwa 200.000 Werbe-E-Mails und 15.000 Transaktions-E-Mails pro Tag. Die normale Bounce-Rate liegt bei rund 0,6 Prozent, die normale Beschwerderate bei rund 0,05 Prozent. An einem Dienstag um 09:00 UTC geht eine Kampagne an 80.000 Kontakte hinaus. Um 09:40 zeigt das Dashboard 2.400 Hard Bounces aus dieser Kampagne, also 3 Prozent, und ein großer Anbieter verzögert den Großteil der übrigen Nachrichten.

Um 09:45 öffnet der diensthabende Untersucher das Runbook. Um 09:55 ist der Werbe-Stream pausiert und es ist bestätigt, dass Test-Belege zugestellt werden. Die Entscheidungstabelle verweist auf einen Bounce-Anstieg mit „Unknown user“-Fehlern, konzentriert auf eine Kampagne. Die Prüfung der Listenhistorie zeigt, dass 30.000 der 80.000 Adressen zwei Tage zuvor aus einer alten Event-Tabelle importiert und nie validiert wurden. Etwa 2.000 der 2.400 Bounces stammen aus diesem Import.

Die Eindämmung ist einfach: Die gebouncten Adressen unterdrücken, den nicht validierten Import aus allen Segmenten entfernen und vor jeder weiteren Verwendung durch eine Validierung schicken. Das Team nimmt den Stream am nächsten Morgen mit 10 Prozent des normalen Volumens an seine aktivsten Kontakte wieder auf, steigert ihn über die folgenden Tage auf 25, 50 und 100 Prozent, solange die Bounce-Rate unter 1 Prozent bleibt, und bestätigt die Wiederherstellung nach drei sauberen Tagen bei vollem Volumen. Die Nachbetrachtung ergänzt eine Leitplanke: Jeder neue Import muss die Validierung bestehen und von Kampagnen ferngehalten werden, bis eine benannte Person ihn freigibt. Der Vorfall kostete einen pausierten Tag und einige verzögerte Kampagnen statt einer langen Reputationsreparatur.

Leitplanken und Alarmschwellen zum Anpassen

Die meisten Vorfälle werden von Kunden entdeckt, weil niemand auf die richtige Zahl geachtet hat. Leitplanken verlegen die Entdeckung nach vorn. Die Werte unten sind Beispiele, die die Form eines sinnvollen Alarms zeigen sollen. Sie sind keine allgemeingültigen Standards, und die richtigen Zahlen hängen von Ihrer Zielgruppe, Ihren Anbietern und Ihrer Historie ab. Messen Sie Ihre eigene Baseline über mehrere Wochen und legen Sie dann Schwellen relativ dazu fest. Prüfen Sie die aktuellen Absenderrichtlinien der Mailbox-Anbieter, die für Sie wichtig sind, auf veröffentlichte Grenzwerte, und lesen Sie unseren Leitfaden zu den zu messenden Kennzahlen, um zu entscheiden, was Sie erfassen.

Signal	Beispielalarm (auf Ihre Baseline abstimmen)	Empfohlene automatische Aktion
Hard-Bounce-Rate pro Kampagne	Warnung oberhalb des 2-Fachen Ihrer Baseline, Stopp oberhalb des 4-Fachen oder wenn Ihre eigene absolute Grenze überschritten wird	Kampagne pausieren und Verantwortliche alarmieren
Beschwerderate pro Anbieter	Warnung bei der Hälfte der von einem Anbieter veröffentlichten Grenze, Alarmierung bei drei Vierteln davon	Segment pausieren und Anmeldequelle prüfen
Deferral-Anteil pro Anbieter	Warnung, wenn Deferrals einen Anteil überschreiten, den Sie normalerweise nie sehen, zum Beispiel 10 Prozent über 15 Minuten	Senderate zu diesem Anbieter senken
Alter der Warteschlange für Transaktionsmails	Warnung, wenn die älteste Nachricht länger als einige Minuten wartet	Diensthabenden Untersucher alarmieren
Sendevolumen	Warnung, wenn das stündliche Volumen ein Vielfaches des für diese Stunde Üblichen überschreitet	Auf kompromittierte Zugangsdaten oder außer Kontrolle geratene Jobs prüfen
DNS- und Zertifikatszustand	Tägliche Prüfung, dass SPF-, DKIM-, DMARC- und Tracking-Einträge aufgelöst werden; Warnung Wochen vor Zertifikatsablauf	Ticket zur Behebung eröffnen, bevor es ausfällt
Neue Listenimporte	Verwendung in Kampagnen sperren, bis sie validiert und freigegeben sind	Benannte Freigabe im Workflow verlangen

Über Alarme hinaus sollten Sie strukturelle Leitplanken ergänzen: getrennte Streams, Sendelimits pro Kampagne, eine Rückstellung für neue Quellen und eine feste verantwortliche Person für jede Domain und jede IP. Auch Raten- und Wiederholungsverhalten spielt eine Rolle; das erklärt der Leitfaden zu Ratenlimits, Wiederholungen und Backoff in unserem Help Center.

Bereitschaftsrollen

Ein Runbook funktioniert am besten, wenn die Rollen bekannt sind, bevor der Pager klingelt. In einem kleinen Unternehmen kann eine Person mehrere Rollen ausfüllen, aber jede Rolle sollte eine benannte Person und eine Vertretung haben.

Rolle	Verantwortung	Macht nicht
Incident-Leitung	Ruft den Vorfall aus und schließt ihn, trifft Entscheidungen, legt Update-Zeiten fest	Jede Untersuchung persönlich durchführen
Technischer Untersucher	Liest Logs, Header und DNS, testet Korrekturen, schlägt Eindämmung vor	Produktionseinstellungen ändern, ohne die Leitung zu informieren
Absender- oder Kampagnenverantwortlicher	Weiß, was an wen und warum gesendet wurde; pausiert und startet Streams wieder	Den Versand ohne Zustimmung der Leitung wieder aufnehmen
Kommunikationsperson	Sendet Updates an Stakeholder und Support, führt die Zeitleiste	Über Ursachen spekulieren

Nachbetrachtung des Vorfalls

Führen Sie die Nachbetrachtung innerhalb weniger Tage durch, solange Erinnerungen und Logs frisch sind. Halten Sie sie schuldzuweisungsfrei: Ziel ist herauszufinden, was im System das Problem durchgelassen hat, nicht wer auf den Knopf gedrückt hat. Für die meisten Vorfälle genügt ein einseitiges Protokoll.

Zusammenfassung: was passiert ist und welche Auswirkungen es hatte, in zwei oder drei Sätzen.
Zeitleiste: wann es begann, wann es erkannt, wann es eingedämmt und wann es behoben wurde. Alles in UTC.
Ursache und beitragende Faktoren: die direkte Ursache und die Lücken, die es ermöglichten oder die Erkennung verlangsamten.
Was gut lief: Schritte, die funktioniert haben und beibehalten werden sollten.
Maßnahmen: jeweils mit Verantwortlichem und Termin, etwa ein neuer Alarm, ein Validierungsschritt, eine DNS-Prüfung oder ein geänderter Freigabeablauf.
Nachverfolgung: ein Termin, an dem bestätigt wird, dass die Maßnahmen umgesetzt und die Kennzahlen stabil sind.

Checkliste für Vorfälle

Vorfall ausgerufen, Leitung benannt, Startzeit in UTC festgehalten.
Transaktionsmails mit Testnachrichten geprüft und auf eigenem Stream belassen.
Nicht kritische Bulk- und Werbeströme pausiert oder gedrosselt.
Symptom mit der Entscheidungstabelle klassifiziert: Bounce, Deferral, Beschwerde oder Rückgang der Interaktion; ein Anbieter oder alle.
Belege gesichert: Ereignis-Logs, rohe Antworten, Header, DMARC-Berichte, Postmaster-Daten, Blocklist- und DNS-Prüfungen.
Änderungshistorie vom ganzen Team zusammengetragen.
Ursache behoben und vor jedem Wiederanlauf mit einer Testnachricht verifiziert.
Wiederherstellung gestuft ab aktiven Kontakten mit reduziertem Volumen, mit vereinbarten Erfolgskriterien.
Updates an Stakeholder und Support planmäßig versendet.
Nachbetrachtung durchgeführt, Maßnahmen zugewiesen, Leitplanken und Alarme aktualisiert.

MigoSMTP bietet Versand, Logs und Ereignisse, die bei mehreren dieser Schritte helfen. Die genauen Details zu den für Sie verfügbaren Berichten, Webhooks und Steuerungen entnehmen Sie Ihrem MigoSMTP-Konto oder der API-Dokumentation.

Möchten Sie bei einem Vorfall eine zweite Meinung? Sagen Sie uns, was Ihre Dashboards zeigen, welche Anbieter betroffen sind und was sich zuletzt geändert hat, und wir helfen Ihnen, das Runbook durchzuarbeiten.

Support kontaktieren

Runbook für Zustellbarkeitsvorfälle: So reagieren Sie auf einen plötzlichen Einbruch