guide · bounce d’e-mail
Comment une équipe produit peut-elle diagnostiquer et gérer les bounces d’e-mails en toute sécurité ?
Traitez un bounce d’e-mail comme une preuve de livraison liée à un destinataire et à une tentative, et non comme un simple indicateur d’échec générique. Conservez l’identifiant du message d’origine, l’expéditeur d’enveloppe, le destinataire, le code de statut SMTP ou étendu, le diagnostic, le serveur émetteur du rapport et l’heure de l’événement. Distinguez un rejet SMTP immédiat d’une notification d’état de livraison ultérieure. Ne réessayez que les résultats temporaires 4.x, avec un backoff borné et des limites d’ancienneté dans la file d’attente ; arrêtez les nouvelles tentatives pour le destinataire concerné et placez-le en liste de suppression après un échec définitif 5.x confirmé. Authentifiez les événements du fournisseur, dédupliquez-les, évitez de générer du backscatter, et traitez comme des états distincts l’acceptation par le fournisseur, l’acceptation par le serveur de destination, une non-livraison ultérieure et le placement en boîte de réception.
Identifiez où l’échec a été observé
Un produit peut apprendre une non-livraison pendant la transaction SMTP en direct, via une notification d’état de livraison ultérieure, ou via un événement authentifié du fournisseur. Ces observations n’apportent pas les mêmes preuves. Un refus immédiat au RCPT TO s’applique à ce destinataire avant que les données du message soient acceptées. Un rejet à l’étape DATA peut s’appliquer à toute la transaction soumise. Une DSN ultérieure indique qu’un système a accepté la prise en charge puis n’a pas pu livrer ou relayer le message. Consignez l’étape, le serveur, le périmètre de destinataires, la tentative, l’horodatage, la réponse SMTP, le code de statut étendu, le diagnostic et les identifiants de corrélation d’origine. Ne ramenez pas tous les cas à « bounce ». Conservez le payload brut du fournisseur ou la DSN au format standard seulement aussi longtemps que l’exigent les besoins opérationnels et vos règles internes, avec un accès restreint. Une capture d’écran du support ou une paraphrase humaine ne suffit pas comme preuve pour les nouvelles tentatives automatiques, la suppression ou le statut affiché au client.
Distinguez les résultats temporaires et définitifs
SMTP utilise les réponses 4yz pour un échec négatif transitoire et les réponses 5yz pour un échec négatif permanent. Les codes de statut étendus ajoutent une classe commençant par 4 pour un échec transitoire persistant ou par 5 pour un échec permanent, suivie de valeurs de sujet et de détail. Conservez à la fois les codes de base et les codes étendus, car le texte seul est propre à chaque fournisseur et peut changer. Un résultat temporaire peut justifier une nouvelle tentative du même message logique après un délai ; il ne justifie ni des boucles immédiates ni un séjour illimité dans la file d’attente. Un échec permanent sur un destinataire doit arrêter la relance automatique pour ce destinataire et cette tentative jusqu’à ce que l’adresse ou la politique change par un processus autorisé. Ne déduisez pas « hard » ou « soft » uniquement à partir des libellés informels des fournisseurs. Construisez votre politique à partir du statut exact, de l’étape, du diagnostic, de la catégorie de message, du destinataire et de la documentation actuelle du fournisseur. Les réponses inconnues ou malformées doivent échouer de manière sûre, vers une revue ou une dead-letter queue, plutôt que de déclencher un renvoi par défaut.
Analysez les notifications d’état de livraison de manière défensive
La RFC 3464 définit un format de notification d’état de livraison lisible par machine, transporté dans un multipart/report avec des champs message/delivery-status. Parmi les champs utiles figurent Reporting-MTA, Final-Recipient, Action, Status, Remote-MTA, Diagnostic-Code et les heures d’arrivée ou de dernière tentative. Traitez chaque champ comme une entrée non fiable, même lorsque la structure MIME est correctement analysée. Bornez la taille du message, le nombre d’en-têtes, le nombre de parties, l’imbrication, le décodage des caractères et la longueur des diagnostics stockés. N’exécutez jamais de pièces jointes, ne suivez pas automatiquement les liens des diagnostics et n’acceptez pas une adresse de destinataire comme identité de tenant. Rattachez la DSN à une tentative appartenant à l’application à l’aide d’un identifiant de message fournisseur stable, des métadonnées d’enveloppe d’origine ou d’un en-tête de corrélation respectueux de la vie privée. Une DSN peut contenir des parties du message d’origine et des données de destinataires : restreignez donc les logs et la conservation. Si la corrélation est ambiguë, conservez les preuves sans placer en liste de suppression une adresse sans rapport ni révéler l’historique des messages d’un autre tenant.
Modélisez les transitions d’état par destinataire
Un même message peut viser plusieurs destinataires et obtenir des résultats différents. Stockez le statut par destinataire et par tentative, et pas seulement sur la ligne du message. Un fournisseur peut accepter certaines commandes RCPT et en refuser d’autres, ou signaler plus tard une livraison pour un destinataire et un échec pour un autre. Définissez des transitions monotones pour qu’un événement accepté ou reporté arrivé en retard ne puisse pas écraser un échec permanent, une plainte ou une désinscription confirmés ultérieurement. Conservez le journal des événements et dérivez l’état affiché courant à l’aide de règles de priorité explicites. Distinguez soumis, accepté par le fournisseur, accepté par le serveur du destinataire, temporairement reporté, définitivement en échec, supprimé, plainte, désinscrit et inconnu. L’acceptation par le serveur de destination ne révèle toujours ni le dossier final de la boîte aux lettres ni la lecture par un humain. Faites en sorte que les nouvelles tentatives créent des tentatives liées sous la même clé d’événement logique, afin que le risque de doublon et les preuves restent visibles. Ne présentez pas une nouvelle tentative planifiée comme une nouvelle action du client.
Réessayez les échecs transitoires dans des limites strictes
Pour les résultats transitoires éligibles, planifiez un backoff exponentiel avec jitter, un nombre fini de tentatives et une ancienneté maximale dans la file d’attente. Suivez le comportement de nouvelle tentative documenté par le fournisseur et n’ajoutez pas une boucle applicative agressive par-dessus un relais qui réessaie déjà. Gardez la même identité de message logique et le même contrôle de suppression pour chaque tentative. Arrêtez les nouvelles tentatives lorsque le destinataire est placé en liste de suppression, que le consentement change, que l’événement expire, que l’identité d’envoi est révoquée ou qu’une réponse permanente arrive ensuite. Limitez le débit par tenant, domaine de destination, expéditeur et classe d’échec, pour qu’une panne chez un destinataire ne puisse pas monopoliser la file d’attente. Respectez Retry-After ou les recommandations de report documentées lorsqu’elles existent, mais ne considérez jamais un contenu de message arbitraire comme des instructions de nouvelle tentative. Déclenchez des alertes sur l’ancienneté croissante de la file, les codes temporaires répétés, les domaines inhabituels et les tentatives proches de l’expiration. Un code transitoire peut masquer un problème persistant de politique ou de réputation ; des nouvelles tentatives bornées font gagner du temps pour la reprise, elles n’autorisent pas à ignorer la cause.
Placez en liste de suppression les échecs permanents confirmés
Un échec permanent confirmé sur une adresse ou une boîte aux lettres doit mettre à jour un enregistrement de suppression appartenant au produit avant la soumission de toute tâche ultérieure. Stockez le tenant, la clé de destinataire normalisée, la portée, l’événement source, la catégorie de statut et de diagnostic, la date d’effet et une référence à la preuve, sans exposer largement l’adresse. Appliquez la suppression au moment de l’envoi, et pas seulement lors de l’import des listes. Distinguez adresse invalide, domaine inexistant, rejet pour politique, rejet du contenu du message, échec d’authentification, quota et réputation de l’expéditeur, car les remèdes sûrs diffèrent. Un destinataire invalide justifie une suppression limitée à ce destinataire ; un rejet lié à l’authentification de l’expéditeur doit suspendre la configuration de l’expéditeur plutôt que de placer tous les destinataires en liste de suppression. Protégez le retrait manuel par une autorisation forte, un motif et un historique d’audit. Une reconfirmation ou une correction doit créer une nouvelle décision vérifiée, et non effacer l’ancienne preuve. Les listes de suppression des fournisseurs sont utiles, mais ne remplacent pas un registre applicatif du consentement et de la sécurité, en particulier lors d’une migration de fournisseur.
Évitez les boucles de bounces et le backscatter
SMTP utilise un chemin de retour nul pour les notifications d’état de livraison, afin qu’un échec lors de la livraison de la notification ne génère pas un nouveau bounce. Préservez ce comportement dans les relais et n’envoyez pas de réponses automatiques aux DSN, aux réponses automatiques ou aux messages présentant des signaux de génération automatique. La RFC 3834 fournit des recommandations sur les réponses automatiques aux e-mails, notamment au sujet des boucles et de l’amplification. Ne générez jamais de bounce vers une adresse From visible non vérifiée après avoir accepté un message suspect, car des identités d’expéditeur falsifiées peuvent transformer le système en source de backscatter. Rejetez les destinataires invalides pendant la session SMTP lorsque c’est possible, au lieu d’accepter le message puis de notifier une adresse falsifiée. Bornez les réponses automatiques par expéditeur et par conversation, et utilisez des identités de réponse contrôlées. Un webhook produit ou un événement d’erreur interne est souvent plus sûr que la génération d’un nouvel e-mail sur Internet. Testez dans des fixtures isolées un From falsifié, un expéditeur d’enveloppe nul, des DSN répétées, des en-têtes auto-submitted, du trafic de listes de diffusion et des rapports malformés.
Authentifiez les événements du fournisseur avant de les appliquer
Si un fournisseur transmet les événements de bounce par webhooks, validez la signature ou le mécanisme d’authentification documenté sur la requête exacte avant d’analyser les champs métier. Imposez la fraîcheur de l’horodatage, la protection contre le rejeu, des limites de taille du corps et la corrélation avec le tenant. Persistez ou mettez en file d’attente l’événement authentifié avant de renvoyer un succès, puis dédupliquez sur un identifiant d’événement fournisseur stable ou une clé composite prudente qui ne peut pas fusionner des destinataires ou des tentatives. Stockez l’heure de survenue séparément de l’heure de traitement, car les événements peuvent être retardés et arriver dans le désordre. Rejetez les événements dont le domaine d’expéditeur, le compte, l’espace de travail, l’identifiant de message ou le périmètre de destinataires ne peut pas être rattaché au tenant attendu. Faites la rotation des secrets de webhook indépendamment des identifiants SMTP ou API. Surveillez les échecs de signature, les taux de doublons, la latence, les dead letters et les types d’événements inconnus. Un webhook authentifié prouve l’origine au regard du secret configuré ; il ne prouve pas que l’événement a été rattaché à la bonne tâche interne tant que la corrélation n’a pas réussi.
Diagnostiquez par famille de statut, pas en devinant le libellé
Commencez par le sujet du statut étendu : statut de l’adresse, statut de la boîte aux lettres, statut du système de messagerie, statut du réseau ou du routage, statut du protocole de livraison, statut du contenu ou du média du message, ou statut de sécurité et de politique. Utilisez ensuite le code de détail et le diagnostic complet avec la documentation actuelle du destinataire ou du fournisseur. Vérifiez la syntaxe du destinataire et le DNS du domaine pour les échecs d’adresse ; l’existence de la boîte aux lettres et les preuves de quota pour les échecs de boîte aux lettres ; les preuves MX, de routage, TLS et réseau pour les échecs de transport ; la taille, le MIME, l’encodage et le contenu pour les échecs liés au message ; et SPF, DKIM, DMARC, les identifiants, la politique d’expéditeur ou la réputation pour les échecs de sécurité. Ne changez qu’une variable à chaque nouveau test contrôlé. Ne changez pas d’IP, de domaine ou de fournisseur pour contourner une décision de politique permanente. Conservez la réponse d’origine et annulez toute modification de configuration qui élargit les droits de l’expéditeur ou affaiblit l’authentification sans corriger la cause observée.
Mesurez la santé des bounces sans divulguer les données des destinataires
Suivez l’acceptation à la première tentative, les reports temporaires, les échecs permanents, les reprises après nouvelle tentative, les résultats inconnus, les plaintes, les suppressions et l’ancienneté de la file par cohortes respectueuses de la vie privée. Les dimensions utiles comprennent le domaine d’expéditeur, le domaine de destination à un niveau d’agrégation approuvé, la catégorie de message, la révision du modèle, le fournisseur, la famille de statut et la période. Évitez les adresses complètes, le contenu des messages, les blobs de diagnostic ou les en-têtes bruts dans les analyses courantes. Séparez le taux de destinataires invalides des échecs de politique, d’authentification, de contenu, de réputation et d’infrastructure transitoire ; un taux de bounces unique masque des causes sur lesquelles on peut agir. Utilisez des dénominateurs fondés sur les tentatives par destinataire et rattachez les événements tardifs à leur cohorte d’origine. Définissez les alertes à partir de références historiques et du risque métier, et non d’un pourcentage universel. Auditez l’application des suppressions et les dérogations manuelles. Ne conservez que les preuves nécessaires aux opérations, à la sécurité, aux obligations légales et aux litiges, puis supprimez-les ou agrégez-les. Un faible taux de bounces ne prouve ni le consentement, ni l’engagement, ni le placement en boîte de réception.
Comment SendHQ s’intègre
SendHQ documente le suivi des livraisons et des bounces ainsi que les suppressions. Consultez la documentation actuelle pour connaître le comportement pris en charge.
Questions fréquentes
Qu’est-ce qu’un bounce d’e-mail ?
C’est la preuve, signalée pendant la session SMTP, par une DSN ou par un événement du fournisseur, qu’un destinataire SMTP ou une tentative de livraison ultérieure a échoué ou a été reporté.
Quelle est la différence entre un bounce 4xx et un bounce 5xx ?
Une réponse 4xx est transitoire et peut justifier une nouvelle tentative bornée. Une réponse 5xx est définitive pour cette tentative et exige normalement une correction ou une suppression.
Faut-il placer en liste de suppression chaque adresse en bounce ?
Non. Placez en liste de suppression les échecs permanents confirmés sur un destinataire. Les échecs liés à l’authentification de l’expéditeur, au contenu, à la réputation, au quota ou à une infrastructure temporairement défaillante exigent des remèdes de portée différente. Appliquez le remède adapté à la cause observée et au périmètre de destinataires concerné.
Un message peut-il être partiellement en bounce ?
Oui. SMTP peut accepter certains destinataires et en refuser d’autres, et des DSN ultérieures peuvent signaler des résultats différents par destinataire. Stockez l’état au niveau du destinataire.
Comment réessayer les bounces transitoires ?
Utilisez la même tâche logique durable avec un backoff exponentiel, du jitter, des plafonds sur le nombre de tentatives et l’ancienneté dans la file, et un nouveau contrôle de suppression avant chaque tentative.
Une réponse SMTP 250 empêche-t-elle un bounce ultérieur ?
Non. Un serveur peut accepter la prise en charge puis générer plus tard une preuve de non-livraison. L’acceptation par la destination n’établit pas non plus le placement en boîte de réception ni l’engagement d’un humain.
Pourquoi les messages de bounce doivent-ils utiliser un chemin de retour nul ?
Un chemin de retour nul empêche un échec de livraison d’une DSN de générer une autre DSN, ce qui évite les boucles de bounces et l’amplification.
SendHQ gère-t-il les bounces ?
Oui. SendHQ documente le suivi des livraisons et des bounces ainsi que les suppressions.