Warum verschickt meine App plötzlich keine E-Mails mehr?

Sieh zuerst ins Protokoll des Anbieters, nicht in dein eigenes

Das Verwirrende an diesem Fehler ist, dass nichts kaputt aussieht. Dein Code lief, die Versandfunktion kehrte zurück, keine Ausnahme wurde geworfen, und deine eigenen Protokolle zeigen Nachrichten, die hinausgehen. Das liegt daran, dass dein Anwendungsprotokoll festhält, was dein Code zu tun beschlossen hat, und das Protokoll des Anbieters festhält, was mit der Nachricht geschehen ist. Wenn beide sich widersprechen, hat der Anbieter recht. Öffne dessen Aktivitätsansicht und filtere auf das Zeitfenster, in dem der Versand aufhörte: Normalerweise siehst du entweder Stille ab einem Zeitstempel, was heißt, dass dein Code aufgehört hat aufzurufen, oder eine Reihe von Ablehnungen mit angehängtem Grund, was heißt, dass er aufgerufen hat und abgewiesen wurde.

Tu das, bevor du Code änderst, einen API-Schlüssel tauschst oder irgendetwas erneut versendest. Jede dieser Handlungen erschwert die Diagnose, und eine davon verschlimmert das Problem: Ein Schwall erneuter Sendungen gegen ein Konto, das wegen Volumen ohnehin schon markiert ist, ist der klassische Weg, eine vorübergehende Pause in eine dauerhafte zu verwandeln.

Die vier Dinge, die den Versand tatsächlich stoppen

Ungefähr in der Reihenfolge, wie oft sich das eine oder andere als Antwort herausstellt:

• Ein Tariflimit, in das du hineingewachsen bist Tägliche und monatliche Versandobergrenzen sind die häufigste Ursache und die, die sich am ungerechtesten anfühlt, weil sich an deinem System nichts geändert hat — deine Anmeldungen haben sich geändert. Das Limit fällt an einem Dienstag, der wie jeder andere Dienstag aussieht, und verworfen wird, was zuletzt in der Warteschlange stand: meist Benachrichtigungs- und Lebenszyklus-Mail und nicht die Login-Mails vom Vormittag.
• Eine Pause durch den Anbieter Anbieter stoppen Konten bei plötzlichen Volumenänderungen, bei einer Hard-Bounce-Rate über einem Schwellwert und bei Spam-Beschwerden. Hier kommt in der Regel tatsächlich eine Warn-E-Mail — an die Adresse, die bei der Kontoerstellung hinterlegt war, und die in einem kleinen Team oft längst niemandes Posteingang mehr ist.
• Kaputte Domain-Authentifizierung SPF-, DKIM- und DMARC-Einträge liegen im DNS und gehen deshalb kaputt, wenn sich das DNS ändert: ein Registrarwechsel, ein Eintrag, der ersetzt statt ergänzt hat, eine abgelaufene Verifizierung, ein rotierter Signaturschlüssel. Das verschlechtert sich, bevor es aufhört: Erst scheitert die Zustellung bei einem Postfachanbieter, dann steigt die Bounce-Rate, dann kommt die Pause.
• Dein eigener Code ruft nicht mehr auf Eine Umgebungsvariable, die in einer Umgebung fehlt, ein leise gestorbener Queue-Worker, ein Feature-Flag, das nach einem Deploy aus blieb, ein SDK-Update, das ein Pflichtfeld geändert hat. Zeigt das Anbieterprotokoll Stille statt Ablehnungen, ist das dein Zweig, und die Antwort steht in deiner Deploy-Historie und nicht im Dashboard des Anbieters.

Lies den Körper, nicht den Statuscode

Das ist es, was aus einem Zehn-Minuten-Vorfall einen Drei-Tage-Vorfall macht, und wir haben diesen Fehler in unserem eigenen System mehr als einmal gemacht. Ein abgelehnter Aufruf kommt nicht verlässlich als Fehler an. Er kommt als HTTP 200 mit dem Fehlschlag im Antwortkörper, und Code, der nur den Statuscode prüft, verbucht einen Erfolg. Wir sind genau dieser Form bei mehreren verschiedenen Anbietern begegnet: Einer antwortet mit 200 und einem falschen Erfolgskennzeichen im Körper, wenn einem Token eine Berechtigung fehlt; ein anderer nahm einen Social-Beitrag an, meldete im Körper einen Validierungsfehler, und unser System — das nur den Umschlag las — verbuchte den Beitrag als veröffentlicht und teilte das der Kundin so mit. Veröffentlicht worden war nichts.

Die Regel, die daraus entstand, ist kurz und gilt für E-Mail wie für alles andere: Betrachte einen Versand nur dann als erfolgreich, wenn der Antwortkörper sagt, dass der Anbieter ihn angenommen hat, protokolliere die Begründung des Anbieters im Wortlaut, wenn er es nicht tut, und alarmiere auf diese Zeichenkette statt auf deine eigene Zusammenfassung davon. Die Statuszeile beschreibt das Gespräch mit der API. Der Körper beschreibt die E-Mail.

Dieselbe Disziplin deckt die Ratenbegrenzung ab. Ein Anbieter, der mit 429 antwortet, sagt dir etwas Nützliches und Vorübergehendes, und Code ohne Backoff macht daraus dauerhaften Verlust, weil die Nachricht verworfen und nie erneut versucht wird. Wir liefen länger ohne dieses Backoff, als wir hätten sollen, und was das Problem schließlich zutage förderte, war kein Alarm. Es war jemand, der nachgesehen hat.

Mach den nächsten Fall laut

Die Korrektur, auf die es ankommt, ist nicht, das Limit zu erhöhen, sondern es zu bemerken, bevor du es erreichst — und der Alarm gehört auf das Verhältnis, nicht auf die Stückzahl. „Wir haben 80% des heutigen Kontingents bis 14 Uhr verbraucht“ ist handlungsfähig; „wir haben 100 Nachrichten verschickt“ bedeutet nichts mehr, sobald der Tarif wechselt. Unser eigenes Volumen überschritt hundert Nachrichten am Tag, während die Anmeldungen wuchsen, gegen eine Obergrenze des kostenlosen Tarifs von exakt hundert: rund 107 an dem Tag, an dem wir endlich nachsahen, nachdem wir Anfang derselben Woche bei 99 von 100 gestanden hatten. Kein Teil des Systems sagte ein Wort. Der Tarifwechsel war die leichte Hälfte. Der Alarm, den wir uns selbst noch schuldeten, war die Hälfte, auf die es ankam, und dass er fehlte, lag daran, dass die Obergrenze nie in die Nähe gekommen war und deshalb niemand sie als bewegliche Zahl gedacht hatte.

Zwei weitere Dinge lohnen sich, solange du ohnehin hier bist. Halte einen zweiten Weg ins Konto bereit für den Fall, dass eine E-Mail mit einem Login nicht ankommt, aus genau den Gründen in unserem Beitrag darüber, warum Magic-Link-Logins scheitern. Und trenne die Mail, die ein Login oder einen Beleg trägt, von der Mail, die eine Kampagne trägt — mindestens nach Versanddomain, besser nach Anbieter — damit ein Kampagnenversand, der eine Beschwerdeschwelle auslöst, dir nicht die Passwort-Zurücksetzungen mitreißt. Was in welchen Strom gehört, behandelt unser Beitrag über Lebenszyklus-E-Mails. Beim Bau von AgentCeres — dem AI Growth Officer auf agentceres.com — haben wir die Reihenfolge auf die teure Art gelernt: Die Nachrichten, um die eine Kundin tatsächlich gebeten hat, schützt man zuerst.