1. Établir une référence avec un cas minimal
Créez une nouvelle boîte de réception de test, copiez l’adresse, puis déclenchez immédiatement un e-mail au contenu simple et à l’objet unique. Vous pouvez inclure l’identifiant du test dans l’objet, mais jamais de clé de production ni de données client réelles.
Notez l’heure du clic sur le bouton métier, de la mise en file et de l’acceptation par le prestataire. Si l’e-mail simple arrive mais pas le modèle complexe, le problème vient probablement du rendu, des pièces jointes ou des règles de contenu, plutôt que du réseau.
2. Vérifier que l’application génère bien l’e-mail
Vérifiez que l’événement métier remplit les conditions d’envoi : état du compte, activation de l’environnement, règles de déduplication et préférences de notification. Les journaux doivent afficher l’adresse finale du destinataire, et pas seulement un message générique indiquant que la tâche a été créée.
Vérifiez que l’adresse correspond exactement, surtout si l’application conserve en cache une ancienne adresse après le remplacement de la boîte de test. Si aucun message n’est enregistré, corrigez d’abord le déclenchement et les paramètres du modèle, sans passer à l’étude du DNS.
Preuves attendues
- Identifiant de l’événement métier et version du modèle
- Adresse du destinataire normalisée
- Création réussie du message ou erreur explicite
3. Contrôler la file, les tentatives et la chronologie
Les e-mails asynchrones restent souvent bloqués par la connexion à la file, le processus de traitement, l’heure planifiée ou le délai entre les tentatives. Comparez l’heure de mise en file, de la première exécution, de chaque nouvelle tentative et de l’état final pour vérifier que la tâche n’est pas simplement en attente.
Si un même événement génère plusieurs e-mails, vérifiez que la clé d’idempotence reste stable et que le consommateur n’expire pas avant la réponse de succès. Ne masquez pas une erreur déterministe du modèle par des tentatives infinies : vous risqueriez de créer des doublons chez le destinataire.
4. Lire les événements du prestataire d’envoi
Une réponse HTTP 2xx signifie généralement que le prestataire a reçu la requête, pas que le serveur destinataire l’a finalement acceptée. Recherchez ensuite les événements queued, sent, delivered, deferred, bounced ou rejected, et conservez l’identifiant du message fourni par le prestataire.
Les réponses SMTP de type 4xx indiquent généralement un retard temporaire : appliquez le délai recommandé avant une nouvelle tentative. Les réponses 5xx correspondent le plus souvent à un refus définitif : corrigez d’abord l’adresse, l’identité ou la règle concernée. Si aucun message correspondant n’existe chez le prestataire, la rupture se situe encore entre l’application et celui-ci.
5. Vérifier l’identité du domaine expéditeur
Vérifiez que SPF couvre la source d’envoi réelle, que le domaine de signature DKIM correspond au domaine From configuré, et que l’alignement ainsi que la politique DMARC sont cohérents avec l’environnement de test. Après une modification DNS, tenez aussi compte du TTL et du cache des différents résolveurs.
Ne vous contentez pas d’un indicateur vert dans la console : consultez les événements détaillés ou les résultats d’authentification dans les en-têtes bruts. Un domaine de test partagé dont la plateforme d’envoi change souvent peut conserver d’anciennes entrées ou dépasser la limite de recherches SPF.
6. Isoler les problèmes de modèle et de contenu
Envoyez d’abord une version texte de référence, puis ajoutez progressivement le HTML, les images, les liens et les pièces jointes. Si l’échec survient après l’ajout d’un élément, vérifiez la réputation des URL, le type de pièce jointe, l’encodage, la taille du message et les variables de modèle non remplacées.
N’imitez pas un discours d’hameçonnage dans l’objet ou le corps, et n’utilisez jamais de véritables identifiants. Pour tester un code de vérification, utilisez un code fixe clairement marqué comme test afin que personne ne le confonde avec une notification de production.
7. Écarter un problème d’état du destinataire
Vérifiez que le compte à rebours de la boîte de réception de test n’est pas arrivé à zéro et que l’adresse affichée dans la barre d’outils correspond à la cible d’envoi. Actualisez manuellement la page ; après un changement d’adresse, les messages de l’ancienne boîte ne sont pas transférés vers la nouvelle.
Une fois le véritable e-mail arrivé, la ligne de démonstration doit disparaître au profit des données réelles. Ouvrez les détails et contrôlez l’objet, l’expéditeur, l’heure d’arrivée, le corps HTML et la version texte de secours. Ne jugez pas le modèle uniquement à partir de l’aperçu de la liste.
8. Analyser les retards, le désordre et les doublons
Comparez le déclenchement métier, la mise en file, l’acceptation par le prestataire et la réception dans un même fuseau horaire. Vous ne pouvez attribuer le retard à une étape que si celle-ci est nettement plus longue ; des horodatages non harmonisés entre fuseaux faussent l’analyse.
Pour un nouvel essai, utilisez un identifiant d’événement unique tout en conservant les anciens identifiants de message. Si le message envoyé plus tard arrive en premier, vérifiez la priorité de la file, les consommateurs parallèles et les nouvelles tentatives du prestataire, plutôt que d’accuser immédiatement le tri de la boîte.
9. Réduire le périmètre avec une matrice des symptômes
10. Savoir quand transmettre le dossier et quoi fournir
Si les étapes précédentes ne permettent pas d’identifier le problème, rassemblez dans un dossier minimal la chronologie, l’adresse cible, l’identifiant de l’événement métier, l’identifiant du message chez le prestataire, l’état final et les éléments déjà écartés. Supprimez les parties sensibles du corps et ne conservez que les informations nécessaires à la reproduction.
Lorsque vous contactez le support MSGTMP, indiquez l’heure de création et d’expiration de la boîte, précisez si l’adresse a été changée, et communiquez la réponse finale enregistrée par le prestataire d’envoi. N’envoyez ni mot de passe, ni code de connexion, ni clé privée complète ; l’adresse du support est support@msgtmp.com.
Critères de fin du diagnostic
Il ne s’agit pas d’un message arrivé par hasard après un renvoi : vous devez pouvoir identifier le point de rupture, en expliquer la cause et démontrer la stabilité de la correction avec le même cas minimal.
