Une réinitialisation de mot de passe doit arriver tant que son lien fonctionne encore. Un reçu doit décrire la bonne commande sans réapparaître après un réessai.
Ces exigences commencent dans votre application et se poursuivent après que le service d'e-mail a accepté le message.
Que doit contenir un message transactionnel ?
Fournissez au destinataire l'information ou l'action nécessaire pour l'événement qui a déclenché l'e-mail. Un reçu confirme une commande. Un message de réinitialisation offre un moyen de retrouver l'accès.
Utilisez un nom d'expéditeur reconnaissable. Rédigez un objet qui identifie l'événement. Dirigez les réponses vers une adresse surveillée par votre équipe lorsque le workflow nécessite un support.
Pour un reçu à titre d'exemple, utilisez un objet tel que Receipt for order 8472. Incluez la référence de commande, les articles achetés et un contact de support. Pour un message de réinitialisation, placez l'action de réinitialisation en premier et indiquez quand elle expire.
Testez le contenu en HTML et en texte brut. Vérifiez que l'action principale reste compréhensible sur un écran étroit et avec les images désactivées.
Séparez les promotions des messages de compte indispensables. E-mail transactionnel et e-mail marketing explique comment la finalité du message influence les contrôles du destinataire et la politique d'envoi.
Comment authentifier et séparer les expéditeurs ?
Authentifiez le domaine d'envoi avant le trafic de production. Les exigences d'expéditeur de Gmail imposent SPF ou DKIM pour tout expéditeur vers les comptes Gmail personnels. Les expéditeurs dépassant 5 000 messages par jour doivent aussi avoir SPF, DKIM et DMARC.
Utilisez des identités d'envoi distinctes pour le courrier opérationnel et le courrier marketing. Les recommandations de Yahoo conseillent de séparer le marketing de masse du trafic transactionnel par IP ou par domaine de signature DKIM. Les deux portent des signaux de réputation : une simple adresse From différente ne sépare pas l'infrastructure.
Augmentez le volume d'envoi progressivement. Les recommandations de Google mettent en garde contre les pics soudains. Surveillez les reports et les rebonds pendant la montée en charge afin de pouvoir réduire le débit lorsque les serveurs destinataires peinent à absorber le trafic.
La liste de contrôle de délivrabilité couvre l'ensemble du travail d'authentification et de réputation d'expéditeur.
Comment gérer les suppressions et les préférences ?
Vérifiez pourquoi un destinataire est bloqué avant de décider si un nouvel envoi est approprié. Un désabonnement marketing et une adresse non distribuable appellent des actions différentes.
La politique de catégorie de Bird autorise le courrier transactionnel après un désabonnement limité au marketing. Les rebonds définitifs, les suppressions manuelles et un désabonnement couvrant tous les messages bloquent les deux catégories.
Une catégorie transactionnelle ne supplante donc pas toutes les restrictions liées au destinataire. Lorsque Bird signale recipient_suppressed, inspectez l'enregistrement de suppression et les préférences du destinataire. Répéter le même envoi ne répare pas l'adresse et ne modifie pas cette politique.
Comment les liens et codes de réinitialisation doivent-ils expirer ?
Appliquez l'expiration dans l'application qui valide le lien ou le code. Le texte de l'e-mail ne peut pas empêcher l'acceptation d'un identifiant expiré.
OWASP, la communauté de sécurité applicative, recommande des jetons ou codes de réinitialisation générés aléatoirement avec une durée d'expiration adaptée. Elle recommande aussi un usage unique. Invalidez l'identifiant après une utilisation réussie afin que le même message ne puisse pas autoriser une autre réinitialisation.
Choisissez une durée de vie pour l'action sur le compte et affichez cette durée dans le message. Tenez compte du temps d'attente dans votre application et du délai de livraison. Un e-mail reçu après expiration doit offrir un moyen de demander une nouvelle réinitialisation.
Avant de réessayer un job de réinitialisation non envoyé, vérifiez si son identifiant est encore valide. N'étendez pas l'expiration d'un identifiant simplement parce qu'une tentative d'envoi a échoué. Sinon les réessais peuvent maintenir l'identifiant utilisable au-delà de la durée de vie que vous avez choisie.
Pour les URL de réinitialisation, OWASP recommande HTTPS et un domaine de destination de confiance. Elle recommande aussi de limiter les demandes de réinitialisation par compte pour éviter l'engorgement de la boîte de réception.
Comment les réessais évitent-ils les envois en double ?
Conservez un enregistrement durable de l'événement métier et de son opération d'envoi. Un événement de commande répété doit retrouver le job de reçu existant au lieu d'en créer un autre.
Utilisez la même clé d'idempotence lorsque vous réessayez la même requête API après une réponse incertaine. Le contrat d'idempotence de Bird conserve une réponse complétée pendant trois heures. Passé cette fenêtre, une autre requête avec la même clé peut créer un nouveau message.
Cette limite rend votre propre enregistrement d'événement nécessaire pour les réessais plus anciens. Enregistrez l'identifiant de message retourné en regard de l'événement avant de considérer la soumission comme terminée.
Un report de livraison est différent d'une réponse API incertaine. Bird réessaie automatiquement les livraisons reportées. Créer un nouvel envoi pour chaque report peut ajouter des messages en double pendant que l'original est encore en cours.
Que devez-vous surveiller et sur quoi alerter ?
Suivez chaque message attendu tout au long de la soumission. Enregistrez le résultat pour chaque destinataire. Mesurez si l'utilisateur accomplit l'action prévue.
Les événements de livraison de Bird distinguent acceptation, livraison, report, rebond et rejet. Livraison signifie que le serveur destinataire a accepté le message. Cela ne garantit ni le placement en boîte de réception ni la lecture.
Enregistrez l'horodatage de l'événement métier aux côtés de l'heure d'envoi et du résultat par destinataire. Pour les messages de réinitialisation, comparez le temps écoulé avec la durée de vie restante de l'identifiant. Mesurez les réinitialisations abouties dans votre application. Un événement de suivi d'ouverture ne prouve pas qu'une personne a lu le message.
Définissez des alertes autour des limites de fonctionnement du workflow :
- Les jobs non envoyés approchent de leur expiration.
- Les échecs dépassent votre plage habituelle.
- Le traitement des webhooks prend du retard.
Désignez un responsable capable d'agir sur chaque alerte.
| Défaillance | Éléments à inspecter | Responsable et action suivante |
|---|---|---|
| Aucun envoi après un événement de commande | Job applicatif et enregistrement d'événement | Équipe applicative : récupérer le job manquant sans dupliquer un envoi existant |
| Destinataire supprimé | Raison du rejet, suppression et préférences | Équipe support ou envoi : investiguer le blocage avant une nouvelle tentative |
| Reports de livraison en hausse | Événements destinataire et volume d'envoi | Équipe d'envoi : inspecter les réponses des serveurs destinataires et réduire un pic de trafic |
| Réinitialisation expirée à la réception | Expiration de l'identifiant et horodatages | Équipe applicative : investiguer le délai et fournir un chemin de nouvelle demande |
| Livraison de webhook répétée | Identifiant de webhook et enregistrement de traitement | Équipe applicative : ignorer le travail déjà effectué pour cet événement |
Vérifiez les signatures des webhooks avant d'accepter les événements. Le guide des webhooks de Bird utilise webhook-id pour la déduplication, de sorte qu'une notification réessayée ne répète pas le travail de votre application.
Que devez-vous vérifier avant d'envoyer via Bird ?
Testez le workflow de bout en bout (soumission, résultat par destinataire et reprise applicative) avant de l'utiliser pour des messages de compte en production.
- Vérifiez le domaine d'envoi. Confirmez que le trafic opérationnel utilise l'identité et le pool prévus.
- Publiez le template. Testez les détails du reçu ou l'action de réinitialisation avec des paramètres représentatifs.
- Définissez
category: "transactional"pour le contenu opérationnel. Appliquez la politique de suppression et de préférences documentée. - Conservez l'enregistrement d'événement métier et la clé d'idempotence. Gardez l'identifiant de message retourné par le point de terminaison d'envoi.
- Testez la gestion des échecs avec le bac à sable e-mail. Ses résultats simulés passent par les chemins normaux d'événements et de webhooks sans atteindre une vraie boîte de réception.
- Inspectez la chronologie par destinataire dans le journal e-mail. Confirmez que votre application traite les mêmes résultats et achemine les alertes vers leurs responsables.