Ein Passwort-Reset muss ankommen, solange der Link noch gültig ist. Eine Quittung muss die richtige Bestellung beschreiben, ohne nach einem erneuten Versuch ein zweites Mal zu erscheinen.
Diese Anforderungen beginnen in Ihrer Anwendung und bestehen fort, nachdem der E-Mail-Dienst die Nachricht angenommen hat.
Was sollte eine transaktionale Nachricht enthalten?
Geben Sie dem Empfänger die Information oder Aktion, die das auslösende Ereignis erfordert. Eine Quittung bestätigt eine Bestellung. Eine Reset-Nachricht bietet einen Weg, den Zugang wiederherzustellen.
Verwenden Sie einen erkennbaren Absendernamen. Formulieren Sie einen Betreff, der das Ereignis identifiziert. Leiten Sie Antworten an eine Adresse weiter, die Ihr Team überwacht, wenn der Workflow Support erfordert.
Verwenden Sie für eine beispielhafte Quittung einen Betreff wie Receipt for order 8472. Fügen Sie die Bestellreferenz, die gekauften Artikel und einen Supportkontakt hinzu. Setzen Sie bei einer Reset-Nachricht die Reset-Aktion an den Anfang und nennen Sie den Ablaufzeitpunkt.
Testen Sie sowohl HTML- als auch Nur-Text-Inhalte. Prüfen Sie, ob die Hauptaktion auf einem schmalen Bildschirm und bei deaktivierten Bildern verständlich bleibt.
Trennen Sie Werbung von notwendigen Kontonachrichten. Transaktionale versus Marketing-E-Mails erklärt, wie der Nachrichtenzweck Empfängerkontrollen und Versandrichtlinien beeinflusst.
Wie sollten Sie Absender authentifizieren und trennen?
Authentifizieren Sie die Absenderdomain vor dem produktiven Versand. Gmails Absenderanforderungen verlangen SPF oder DKIM für alle Absender an persönliche Gmail-Konten. Absender mit mehr als 5.000 Nachrichten pro Tag benötigen SPF, DKIM und DMARC.
Verwenden Sie separate Absenderidentitäten für operative und Marketing-E-Mails. Yahoos Empfehlung rät dazu, Massen-Marketing vom transaktionalen Versand über IP oder DKIM-Signierdomain zu trennen. Beides trägt Reputationssignale, daher reicht eine andere Absenderadresse allein nicht aus, um die Infrastruktur zu trennen.
Steigern Sie das Versandvolumen schrittweise. Googles Empfehlung warnt vor plötzlichen Spitzen. Prüfen Sie Zustellverzögerungen und Bounces während einer Steigerung, damit Sie die Rate reduzieren können, wenn Empfangsserver mit dem Volumen nicht zurechtkommen.
Die Zustellbarkeits-Checkliste behandelt die weiterführende Authentifizierungs- und Absenderreputationsarbeit.
Wie sollten Sie Unterdrückungen und Präferenzen handhaben?
Prüfen Sie, warum ein Empfänger blockiert ist, bevor Sie entscheiden, ob ein weiterer Versand angemessen ist. Ein Marketing-Opt-out und eine nicht zustellbare Adresse erfordern unterschiedliche Maßnahmen.
Die Kategorierichtlinie von Bird erlaubt transaktionale E-Mails nach einem reinen Marketing-Opt-out. Hard Bounces, manuelle Unterdrückungen und ein Opt-out für alle Nachrichten blockieren beide Kategorien.
Eine transaktionale Kategorie setzt daher nicht jede Empfängereinschränkung außer Kraft. Wenn Bird recipient_suppressed meldet, prüfen Sie den Unterdrückungseintrag und die Präferenzen des Empfängers. Denselben Versand zu wiederholen repariert weder die Adresse noch ändert es diese Richtlinie.
Wie sollten Reset-Links und Codes ablaufen?
Erzwingen Sie den Ablauf in der Anwendung, die den Link oder Code validiert. Text in der E-Mail kann nicht verhindern, dass ein abgelaufenes Credential akzeptiert wird.
OWASP, die Community für Anwendungssicherheit, empfiehlt zufällig generierte Reset-Tokens oder Codes mit einer angemessenen Gültigkeitsdauer. Außerdem wird die einmalige Verwendung empfohlen. Invalidieren Sie das Credential nach erfolgreicher Nutzung, damit dieselbe Nachricht keinen weiteren Reset autorisieren kann.
Wählen Sie eine Gültigkeitsdauer für die Kontoaktion und zeigen Sie diese in der Nachricht an. Berücksichtigen Sie die Wartezeit in Ihrer Anwendung und bei der Zustellung. Eine E-Mail, die nach Ablauf ankommt, braucht einen Weg, einen neuen Reset anzufordern.
Prüfen Sie vor dem erneuten Versuch eines nicht gesendeten Reset-Jobs, ob das Credential noch gültig ist. Verlängern Sie die Gültigkeitsdauer eines Credentials nicht allein deshalb, weil ein Sendeversuch fehlgeschlagen ist. Andernfalls können Wiederholungsversuche das Credential über die gewählte Gültigkeitsdauer hinaus nutzbar halten.
Für Reset-URLs empfiehlt OWASP HTTPS und eine vertrauenswürdige Zieldomain. Außerdem wird empfohlen, Reset-Anfragen pro Konto zu begrenzen, um ein Überfluten des Posteingangs zu verhindern.
Wie vermeiden Wiederholungsversuche doppelte Sendungen?
Führen Sie einen dauerhaften Eintrag über das Geschäftsereignis und dessen Sendeoperation. Ein wiederholtes Bestellereignis sollte den bestehenden Quittungsjob finden, statt einen neuen zu erstellen.
Verwenden Sie denselben Idempotenzschlüssel, wenn Sie dieselbe API-Anfrage nach einer unklaren Antwort erneut versuchen. Der Idempotenzvertrag von Bird speichert eine abgeschlossene Antwort für drei Stunden. Nach diesem Zeitfenster kann eine weitere Anfrage mit demselben Schlüssel eine neue Nachricht erzeugen.
Diese Begrenzung macht Ihren eigenen Ereigniseintrag für ältere Wiederholungsversuche erforderlich. Speichern Sie die zurückgegebene Nachrichten-ID zum Ereignis, bevor Sie die Übermittlung als abgeschlossen betrachten.
Eine Zustellverzögerung unterscheidet sich von einer unklaren API-Antwort. Bird wiederholt verzögerte Zustellungen automatisch. Einen neuen Versand für jede Verzögerung zu erstellen kann zu doppelten Nachrichten führen, während die ursprüngliche noch in Bearbeitung ist.
Was sollten Sie überwachen und wofür Benachrichtigungen einrichten?
Verfolgen Sie jede erwartete Nachricht über die Übermittlung. Zeichnen Sie das Ergebnis jedes Empfängers auf. Messen Sie, ob der Benutzer die beabsichtigte Aktion abschließt.
Die Zustellereignisse von Bird unterscheiden Annahme, Zustellung, Verzögerung, Bounce und Ablehnung. Zustellung bedeutet, dass der empfangende Server die Nachricht akzeptiert hat. Sie bestätigt weder die Platzierung im Posteingang noch das Lesen.
Zeichnen Sie den Zeitpunkt des Geschäftsereignisses zusammen mit der Sendezeit und dem Empfängerergebnis auf. Vergleichen Sie bei Reset-Nachrichten die verstrichene Zeit mit der verbleibenden Gültigkeitsdauer des Credentials. Messen Sie abgeschlossene Resets in Ihrer Anwendung. Ein Open-Tracking-Ereignis beweist nicht, dass eine Person die Nachricht gelesen hat.
Richten Sie Benachrichtigungen rund um die Betriebsgrenzen des Workflows ein:
- Nicht gesendete Jobs nähern sich ihrem Ablauf.
- Fehler steigen über Ihren normalen Bereich.
- Die Webhook-Verarbeitung fällt zurück.
Benennen Sie eine verantwortliche Person, die auf jede Benachrichtigung reagieren kann.
| Fehler | Zu prüfende Hinweise | Verantwortliche und nächste Aktion |
|---|---|---|
| Kein Versand nach einem Bestellereignis | Anwendungsjob und Ereigniseintrag | Anwendungsteam: fehlenden Job wiederherstellen, ohne einen bestehenden Versand zu duplizieren |
| Unterdrückter Empfänger | Ablehnungsgrund, Unterdrückung und Präferenzen | Support- oder Versandteam: Blockierung untersuchen, bevor ein weiterer Versuch erfolgt |
| Steigende Zustellverzögerungen | Empfängerereignisse und Versandvolumen | Versandteam: Empfängerantworten prüfen und Verkehrsspitze reduzieren |
| Abgelaufener Reset bei Ankunft | Credential-Ablauf und Ereigniszeitstempel | Anwendungsteam: Verzögerung untersuchen und Pfad für neue Anfrage bereitstellen |
| Wiederholte Webhook-Zustellung | Webhook-Kennung und Verarbeitungseintrag | Anwendungsteam: bereits abgeschlossene Arbeit für dieses Ereignis überspringen |
Überprüfen Sie Webhook-Signaturen, bevor Sie Ereignisse akzeptieren. Der Webhook-Leitfaden von Bird verwendet webhook-id zur Deduplizierung, sodass eine wiederholte Benachrichtigung die Arbeit Ihrer Anwendung nicht wiederholt.
Was sollten Sie prüfen, bevor Sie über Bird senden?
Testen Sie den Workflow über Übermittlung, Empfängerergebnis und Anwendungswiederherstellung, bevor Sie ihn für produktive Kontonachrichten einsetzen.
- Verifizieren Sie die Absenderdomain. Prüfen Sie, ob der operative Versand die vorgesehene Identität und den vorgesehenen Pool verwendet.
- Veröffentlichen Sie das Template. Testen Sie die Quittungsdetails oder die Reset-Aktion mit repräsentativen Parametern.
- Setzen Sie
category: "transactional"für operative Inhalte. Wenden Sie die dokumentierte Unterdrückungs- und Präferenzrichtlinie an. - Bewahren Sie den Geschäftsereignis-Eintrag und den Idempotenzschlüssel auf. Speichern Sie die vom Sende-Endpunkt zurückgegebene Nachrichten-ID.
- Testen Sie die Fehlerbehandlung mit der Mail-Sandbox. Deren simulierte Ergebnisse durchlaufen die normalen Ereignis- und Webhook-Pfade, ohne einen echten Posteingang zu erreichen.
- Prüfen Sie die empfängerbezogene Zeitleiste im E-Mail-Log. Bestätigen Sie, dass Ihre Anwendung dieselben Ergebnisse verarbeitet und Benachrichtigungen an die Verantwortlichen weiterleitet.