Résoudre les problèmes d'envoi d'e-mails en production : SMTP, DNS et réessais

À quoi ressemble « l'e-mail qui n'envoie pas » en production

Quand on dit qu'un e-mail « fonctionne en local mais pas en production », cela signifie souvent que le code de l'app est correct, mais que la configuration réelle diffère. La production tourne souvent derrière des réseaux plus stricts, utilise des variables d'environnement différentes et dépend du DNS et d'un compte fournisseur qui peut vous bloquer ou vous limiter.

Les symptômes les plus fréquents sont faciles à repérer une fois nommés :

• Les requêtes expirent (l'app attend, puis abandonne)
• Erreurs 401/403 (clé API invalide, mot de passe SMTP incorrect, ou compte bloqué)
• Messages affichés comme « en file » indéfiniment (le fournisseur les retient, ou votre worker est bloqué)
• Les e-mails arrivent mais vont en spam (livrabilité, pas envoi)

Beaucoup de solutions pour « résoudre les problèmes d'envoi d'e-mails en production » sont liées à la configuration, au DNS ou aux limites du fournisseur, pas au template d'e-mail. Une variable d'environnement manquante, un nouveau domaine expéditeur sans SPF/DKIM, ou une liste de suppression chez le fournisseur peut faire échouer un flux qui fonctionnait du jour au lendemain.

Avant de changer quoi que ce soit, rassemblez quelques détails pour tracer un e-mail de bout en bout :

• Horodatage exact (avec fuseau) du moment où vous avez déclenché l'e-mail
• Le texte d'erreur et tout code d'état dans vos logs
• Détails de la réponse du fournisseur (ID du message, ID de requête, ou code de réponse SMTP)
• Adresse du destinataire et type d'e-mail (réinitialisation de mot de passe, invitation, reçu)
• Si le problème affecte tous les utilisateurs ou seulement certains domaines (Gmail, Outlook, messagerie d'entreprise)

Si vous avez hérité d'une application générée par l'IA, c'est souvent là que se cachent de petites erreurs de configuration. Des équipes comme FixMyMess commencent souvent par cartographier un e-mail échoué jusqu'au point exact où ça casse : app, fournisseur ou boîte de réception.

Comment l'envoi d'e-mails fonctionne vraiment (modèle mental simple)

Considérez l'envoi d'e-mails comme une chaîne de transfert. Votre app crée un message (to, from, subject, body). Ensuite elle le remet à un expéditeur (soit SMTP, soit une API e-mail). Cet expéditeur remet ensuite le message au serveur mail du destinataire. Ce n'est qu'à la fin que le mail atteint la boîte de réception.

SMTP vs API e-mail change la "porte" que vous utilisez, pas la destination. Avec SMTP, votre app se connecte et dialogue avec le fournisseur comme le ferait un client mail. Avec une API e-mail, votre app fait une requête HTTPS et le fournisseur s'occupe de la partie SMTP pour vous. Dans les deux cas, vous avez toujours besoin : d'un domaine d'envoi vérifié, de l'autorisation d'envoyer, et d'un message que les fournisseurs de boîtes acceptent.

Les échecs surviennent généralement à l'un de ces niveaux :

• Couche app : destinataire erroné, bug de template, adresse "from" manquante, payload invalide
• Couche réseau : ports bloqués, problèmes TLS, timeouts
• Couche fournisseur : erreur d'auth, limite de débit, compte en pause, liste de suppression
• Couche destinataire : filtrage anti-spam, rebonds, ou mise en quarantaine silencieuse

Quelques termes, en langage simple : un bounce (rebond) signifie que la livraison a échoué (adresse invalide, boîte pleine, ou blocage). Une complaint est quand quelqu'un signale votre e-mail comme spam. La suppression signifie que votre fournisseur cesse d'envoyer à une adresse après rebonds ou plaintes. La réputation est votre historique en tant qu'expéditeur.

Une partie déroutante : votre fournisseur peut accepter le message (donc votre app enregistre « envoyé ») mais il n'apparaît jamais. Exemple : un e-mail de réinitialisation de mot de passe est accepté, puis bloqué silencieusement par le destinataire parce que le DNS de votre domaine manque SPF/DKIM/DMARC ou que votre réputation est faible. C'est pourquoi « résoudre les problèmes d'envoi d'e-mails en production » concerne souvent la délivrabilité, pas seulement l'envoi.

Si vous avez hérité d'un code généré par l'IA, FixMyMess trouve souvent rapidement la rupture dans cette chaîne : réessais manquants, envois en double, ou un rejet fournisseur que votre app n'a jamais remonté.

Triage rapide : 10 minutes pour restreindre le problème

Quand il faut corriger rapidement l'envoi d'e-mails en production, l'objectif est simple : déterminer si l'échec vient de votre côté (app/config/réseau) ou du fournisseur (compte/limites/suppression) avant de modifier le code.

Commencez par un test contrôlé : déclenchez un seul e-mail vers une boîte que vous contrôlez (pas un envoi massif). Conservez l'horodatage exact.

Faites ces vérifications dans l'ordre :

• Vérifiez que le fournisseur est opérationnel et que votre compte est autorisé à envoyer (page de statut, facturation, limites journalières/horaire, mode sandbox).
• Confirmez que l'adresse expéditrice et le domaine sont vérifiés si le fournisseur l'exige (les mismatches de From sont courants).
• Ouvrez vos logs de production pour la tentative d'envoi et copiez le texte d'erreur exact et tout code d'erreur.
• Confirmez que les variables d'environnement de production sont correctes (clé API/mot de passe SMTP, hôte, port, from, région).
• Récupérez l'ID du message fournisseur (ou l'ID de requête) depuis la réponse pour tracer l'événement chez eux.

Le texte d'erreur vous indique généralement la voie :

• Erreurs d'auth (401, 403, "Invalid login") signifient généralement clé ou identifiants SMTP erronés, ou permissions bloquées.
• Timeouts signifient souvent des blocages réseau en sortie, hôte/port incorrects, ou problèmes de négociation TLS.
• Erreurs API 400-level indiquent souvent un payload mal formé (ID de template invalide, adresse e-mail invalide).
• "Suppressed" ou "blocked" suggèrent des rebonds, plaintes, ou suppressions au niveau du compte.
• "Sender not verified" indique un problème de domaine ou d'adresse From.

Si vous avez hérité d'une app générée par l'IA, ces problèmes viennent souvent de variables d'environnement discordantes ou de clés de test codées en dur. FixMyMess commence typiquement par reproduire un envoi, récupérer l'ID du message, et le relier à la configuration défaillante pour éviter les suppositions.

Étape par étape : diagnostiquer de l'app à la boîte de réception

Commencez par rendre le problème répétable. Utilisez un destinataire connu (votre propre boîte) et envoyez un template précis (comme « réinitialisation de mot de passe »). Changez une seule chose à la fois pour savoir ce qui l'a réparé.

Ensuite, capturez ce que votre app a réellement envoyé. Pour une API e-mail, logguez le payload de la requête (masquez les secrets) et la réponse complète du fournisseur. Pour SMTP, capturez la conversation SMTP (les réponses du serveur comptent autant que vos commandes). L'objectif est un enregistrement unique sur lequel vous pouvez dire : « Cette tentative d'envoi a eu lieu à ce moment avec ces données. »

Puis suivez le message chez le fournisseur. Recherchez si la tentative a été :

• Acceptée/en file (le fournisseur va tenter la livraison)
• Différée (problème temporaire, il y aura réessai)
• Rebondie (rejet définitif)
• Bloquée (politique ou réputation)
• Droppée/supprimée (le fournisseur a refusé d'envoyer)

Vérifiez ensuite l'état dans votre app. Confirmez que vous avez enregistré l'ID du message fournisseur et un statut clair correspondant à l'événement côté fournisseur. Une panne fréquente : l'UI indique « e-mail envoyé » alors que le fournisseur affiche « dropped » (souvent dû à des listes de suppression ou à un manque de vérification).

Enfin, décidez si le domaine destinataire a rejeté ou filtré le message. Si le fournisseur dit « délivré » mais que l'e-mail manque, vérifiez le spam et la quarantaine, puis cherchez des signaux « rejeté par le destinataire » ou « contenu identifié comme spam ».

Si vous tentez de résoudre les problèmes d'envoi en production et que vos logs sont désordonnés ou manquants, FixMyMess peut auditer le chemin du code et les événements fournisseur pour que vous voyiez exactement où la chaîne casse.

Vérifications côté fournisseur d'e-mail (compte, limites et suppressions)

Avant de creuser le code, confirmez que le compte du fournisseur peut effectivement envoyer. Un étonnant nombre de cas « l'e-mail n'envoie pas en production » se règlent par un paramètre de compte, une limite ou un blocage silencieux.

Commencez par les identifiants. Si votre app utilise une clé API ou un mot de passe SMTP, assurez-vous qu'il correspond bien à l'environnement (prod vs staging), à la région et au sous-compte ou workspace correct. La rotation de clés casse souvent la production en premier parce que l'ancienne clé peut encore fonctionner en local.

Ensuite, vérifiez les règles sur l'adresse From. Beaucoup de fournisseurs n'acceptent d'envoyer que depuis des domaines vérifiés ou des boîtes spécifiques. Si un déploiement a changé le From en quelque chose comme [email protected], le fournisseur peut le rejeter ou l'accepter sans le délivrer.

Les limites de débit et quotas ressemblent à des échecs aléatoires. Vous pouvez voir des erreurs temporaires, des réponses de throttling ou des timeouts lors de pics (réinitialisations de mot de passe après une campagne marketing, rapports nocturnes, pics d'inscription). Vérifiez le tableau de bord fournisseur pour des alertes sur les plages horaires correspondant à vos horodatages.

L'une des issues les plus sournoises est la suppression (suppression automatique). Si un destinataire a rebondi ou vous a signalé comme spam une fois, certains fournisseurs mettent l'adresse en suppression et laissent tomber silencieusement les envois futurs. Votre app peut dire « envoyé » tandis que cette boîte ne reçoit plus rien.

Si votre application dépend d'événements, confirmez que les webhooks sont toujours connectés. Un webhook mal configuré peut faire croire à votre app que l'envoi a échoué (ou réussi) alors que le fournisseur dit le contraire.

Voici les vérifications fournisseur les plus rapides :

• Confirmez que la clé active/utilisateur SMTP est celle déployée en production.
• Cherchez des erreurs de vérification de l'adresse From ou du domaine.
• Vérifiez les caps journaliers et limites de burst autour de la fenêtre de panne.
• Cherchez l'adresse test dans les listes de suppression.
• Vérifiez la livraison et la signature des webhooks.

Si vous avez hérité d'une app générée par l'IA, ces réglages sont souvent codés en dur ou incohérents entre environnements. FixMyMess commence généralement par aligner la configuration du compte fournisseur avec la configuration utilisée par votre build de production, puis supprime le décalage.

Problèmes SMTP : ports, TLS, auth et blocages réseau

Si vous pouvez déclencher un e-mail dans l'app mais que rien n'arrive, SMTP est souvent le maillon faible. Le plus grand piège : les réseaux de production se comportent différemment que votre laptop.

Port et hôte d'abord. Beaucoup de fournisseurs mentionnent encore le port 25, mais il est souvent bloqué en hébergement réel pour empêcher le spam. Préférez le port recommandé par votre fournisseur pour l'envoi authentifié (souvent 587 avec STARTTLS, ou 465 avec TLS implicite).

TLS : STARTTLS vs TLS implicite

STARTTLS signifie que vous vous connectez en clair, puis vous passez en TLS. Le TLS implicite (souvent 465) démarre chiffré immédiatement. Les mélanger provoque des erreurs de handshake comme « wrong version number » ou « EOF ». Vérifiez aussi :

• Que le nom d'hôte SMTP correspond au certificat (utiliser une IP peut casser la validation)
• Que l'horloge du serveur est correcte (une date erronée peut faire échouer les vérifs de certificat)

Auth et blocages réseau

Les échecs d'auth sont généralement simples : mauvais nom d'utilisateur, mauvais mot de passe, ou utilisation d'un login humain au lieu d'un identifiant SMTP/API. Certains fournisseurs exigent un mot de passe d'application, un token, ou une liste d'IP autorisées.

Les blocages réseau sont fréquents sur les hébergements cloud et containers. Les règles de sortie, firewalls, NAT, ou passerelles d'egress d'entreprise peuvent laisser tomber silencieusement le trafic SMTP.

Pour tester sans deviner, exécutez un check de connectivité depuis le même environnement que votre app (même VM, container ou fonction) :

nc -vz smtp.yourprovider.com 587
openssl s_client -starttls smtp -connect smtp.yourprovider.com:587

Si le test de port échoue, c'est réseau. Si le test TLS connecte mais que l'auth échoue, c'est les identifiants ou la politique fournisseur. Cette séparation claire est le moyen le plus rapide de résoudre les problèmes d'envoi d'e-mails en production.

Si vous avez hérité d'une app générée par l'IA où les réglages SMTP sont dispersés dans le code et les vars d'env, FixMyMess peut auditer et réparer la configuration rapidement pour que l'envoi fonctionne fiablement après les déploiements.

Problèmes d'API e-mail : erreurs d'auth, bugs de payload et timeouts

Quand vous utilisez une API e-mail (au lieu de SMTP), « l'e-mail n'envoie pas » signifie souvent que votre app n'a jamais créé la requête d'envoi, ou que le fournisseur l'a rejetée avant qu'elle n'atteigne la file. Commencez par vérifier le code et la réponse du fournisseur pour la requête exacte.

Lire le code de statut comme un indice

La plupart des échecs tombent dans quelques catégories :

• 400 Bad Request : votre JSON est incorrect (champs requis manquants, ID de template invalide, encodage incorrect).
• 401 Unauthorized : la clé API manque, a expiré, ou vient du mauvais environnement.
• 403 Forbidden : la clé existe mais manque de permissions, ou le domaine/from n'est pas autorisé.
• 429 Too Many Requests : vous avez atteint les limites ; ralentissez et réessayez avec backoff.
• 202/200 mais pas d'e-mail : accepté par l'API, puis supprimé, rebondi, ou bloqué par une politique.

Les bugs de payload sont fréquents après un déploiement : champ renommé, liste "to" vide, HTML avec caractères invalides, ou variable de template qui ne correspond plus. Les pièces jointes peuvent aussi casser l'envoi. Nombre de fournisseurs imposent des limites de taille, et les fonctions serverless peuvent timeout lors du téléchargement de gros fichiers.

Si votre fournisseur utilise des requêtes signées, le skew d'horloge peut provoquer des échecs d'auth aléatoires. Assurez-vous que l'heure du serveur est correcte.

Pour corriger sans provoquer de doublons, utilisez des idempotency keys. Ainsi, si vous retentez après un timeout, le fournisseur considère que c'est le même envoi et ne fait pas deux copies.

Si vous avez hérité d'un code généré par l'IA qui fait ces erreurs, FixMyMess peut auditer la chaîne d'envoi et durcir les réessais pour qu'ils se comportent de façon prévisible sous charge.

Configuration du domaine : SPF, DKIM et DMARC sans confusion

Beaucoup de rapports « l'e-mail n'envoie pas » signifient en réalité « l'e-mail part mais n'atteint pas la boîte ». Pour résoudre les problèmes d'envoi en production, commencez par prouver que votre domaine est autorisé à envoyer.

SPF : qui est autorisé à envoyer

SPF est un enregistrement DNS TXT qui liste les serveurs autorisés à émettre pour votre domaine. Il devrait y avoir exactement un enregistrement SPF par domaine.

v=spf1 include:YOUR_PROVIDER.com -all

Les problèmes SPF courants sont simples : plusieurs enregistrements SPF (conflits), enregistrement sur le mauvais hostname (mis sur un sous-domaine alors que vous envoyez depuis le domaine racine, ou inversement), ou un include obsolète après changement de fournisseur.

DKIM et DMARC : prouver que c'est bien vous

DKIM ajoute une signature pour que les boîtes puissent vérifier que l'e-mail n'a pas été modifié et qu'il correspond vraiment à votre domaine. Si DKIM est configuré mais « mal aligné » (par exemple, votre From est monsite.com mais la signature DKIM est d'un autre domaine), la délivrance peut chuter.

DMARC lie SPF et DKIM. Commencez par le mode monitoring pour ne pas bloquer du courrier légitime, puis durcissez :

• Débutez avec p=none pour collecter des rapports et repérer les surprises
• Passez à p=quarantine une fois que les sources légitimes sont confirmées
• Terminez avec p=reject quand vous êtes sûr que rien d'autre ne doit envoyer

Les erreurs DNS sont courantes : copier l'enregistrement sur le mauvais sous-domaine, oublier un point dans un hostname, ou attendre l'expiration du TTL. Pour confirmer que les changements sont actifs, interrogez le DNS depuis un autre réseau et vérifiez les headers d'un vrai message pour "Authentication-Results" montrant SPF, DKIM et DMARC PASS.

Si vous avez hérité d'une app générée par l'IA avec du code e-mail désordonné et des domaines d'envoi flous, FixMyMess peut auditer la configuration et indiquer précisément ce qui échoue avant que vous ne touchiez à la production.

Déclencheurs de spam et notions de base sur la délivrabilité

Parfois « l'e-mail n'envoie pas » signifie « l'e-mail est livré mais personne ne le voit ». Votre fournisseur peut indiquer un succès, mais le message atterrit en Spam ou dans Promotions parce que les fournisseurs de boîtes font leur propre filtrage.

Les déclencheurs de spam courants sont étonnamment petits : objets criards ou trompeurs ("URGENT", "RE: invoice"), raccourcisseurs de liens, trop de liens, et HTML cassé (version texte manquante, images énormes, ou formatage erratique). Une seule ligne suspecte peut annuler le reste.

La réputation compte autant que le contenu. Les nouveaux domaines et nouvelles identités d'expéditeur partent avec peu de confiance. Si vous passez de 0 à des milliers d'e-mails du jour au lendemain, les filtres se durcissent. Chauffez progressivement et maintenez un faible taux de plaintes.

Les adresses "no-reply" se retournent souvent contre vous. Les gens répondent quand quelque chose semble suspect. Si cette réponse rebondit ou disparaît, vous recevez plus de plaintes. Utilisez un expéditeur réel et un Reply-To clair, et surveillez cette boîte.

Séparez les e-mails transactionnels des e-mails marketing : domaines ou sous-domaines d'envoi différents, idéalement des flux fournisseurs distincts. Ainsi une campagne marketing ne pénalise pas les réinitialisations de mot de passe.

Si les messages sont livrés mais vont en spam, essayez rapidement :

• Envoyer une version simple et texte (moins de HTML, moins de liens) et comparez
• Supprimer les raccourcisseurs de liens et les URLs trop trackées
• Faire en sorte que l'objet corresponde au contenu et à l'intention
• Demander à quelques destinataires de marquer « Pas comme spam » et de répondre une fois
• Vérifier les pics de volume après un déploiement ou une campagne

Envoi fiable : réessais, rebonds et éviter les doublons

Les e-mails échouent en production pour des raisons qui n'ont rien à voir avec le DNS ou les templates. La différence entre "instable" et "fiable" tient souvent à la façon dont vous retentez, ce que vous enregistrez et quand vous vous arrêtez.

Une politique de réessai simple

Réessayez seulement quand le fournisseur ou le réseau a un problème temporaire. Si l'adresse est invalide ou le domaine rejette le message, réessayer ne fait que créer du bruit et peut nuire à votre réputation.

Une approche pratique qui fonctionne pour la plupart des apps :

• Réessayez sur timeouts, 429 et erreurs SMTP temporaires.
• Ne réessayez pas sur "destinataire invalide", "boîte inexistante" et erreurs 5xx définitives.
• Utilisez un backoff exponentiel (par exemple : 1 min, 5 min, 20 min, 1 h) avec un peu d'aléa.
• Limitez le nombre de tentatives (3–6 au total) et arrêtez si l'utilisateur annule l'action (ex. nouvelle demande de reset).
• Séparez le "send now" du "send later" pour que la requête web ne reste pas bloquée.

Le backoff est important : marteler des réessais toutes les secondes peut déclencher des limites, sembler suspect et empirer un incident mineur.

Pour éviter les doublons, enregistrez chaque tentative d'envoi avec une clé de message stable. Par exemple : password_reset:\u003cuser_id\u003e:\u003ctoken_id\u003e. Si la même clé réapparaît, traitez-la comme idempotente et n'envoyez pas une seconde fois.

Rebonds, plaintes et ce qu'il faut surveiller

Si vous recevez un rebond ou une plainte, arrêtez d'envoyer à cette adresse et informez l'utilisateur ("Nous n'avons pas pu livrer cet e-mail. Veuillez le mettre à jour."). Conservez des métriques de base pour que les problèmes apparaissent vite :

• Taux de succès de livraison, taux de rebond, taux de plainte
• Nombre de réessais et temps passé en "pending"
• Réponses du fournisseur (codes d'état, messages d'erreur)

Si votre code a été généré rapidement et que la logique de la queue est désordonnée, FixMyMess peut auditer la pipeline d'envoi et rendre les réessais, l'idempotence et les logs fiables sans refondre toute votre application.

Erreurs courantes qui maintiennent l'e-mail cassé

Beaucoup d'équipes essaient de résoudre les problèmes d'envoi en production en changeant un paramètre à la fois. Le problème est souvent causé par quelques habitudes évitables qui masquent la vraie cause.

L'une des plus grandes erreurs est la mauvaise gestion des secrets. Clés API codées en dur, mots de passe SMTP commités dans un repo, ou tokens affichés dans les logs peuvent être rotés ou bloqués sans que vous le remarquiez. Pire encore, les secrets peuvent fuir côté client, permettant à n'importe qui d'envoyer du spam depuis votre compte.

Un autre piège courant est la confusion sur le domaine expéditeur. Si vous envoyez depuis un domaine que vous ne contrôlez pas, ou si vous mélangez plusieurs domains From entre environnements (staging et prod), l'alignement SPF/DKIM peut échouer et les messages finir en spam ou être rejetés.

Les dashboards fournisseurs peuvent aussi induire en erreur. "Accepted" signifie généralement que le fournisseur a pris le message, pas qu'il est arrivé en boîte. La boîte peut encore le supprimer pour des raisons de spam, DMARC ou liste de suppression.

Voici des erreurs qui prolongent silencieusement les problèmes :

• Pas d'alertes pour des pics de rebonds, webhooks échoués ou chute soudaine du volume d'envoi.
• Traiter les réessais comme un "renvoi" sans clé d'idempotence, entraînant des doublons.
• Réessayer chaque erreur de la même façon, y compris les échecs permanents comme adresse invalide.
• Ignorer les listes de suppression et se demander pourquoi certains utilisateurs ne reçoivent jamais de mails.
• Utiliser des sujets génériques ou des adresses "no-reply" qui déclenchent plus souvent les filtres.

Exemple : après un déploiement, les e-mails de réinitialisation « partent » mais n'arrivent pas. Le code a changé le From pour un nouveau sous-domaine, mais les enregistrements DNS n'ont jamais été ajoutés. Le fournisseur accepte le message, puis les récepteurs le rejettent. Si vous avez hérité d'un code e-mail généré par l'IA avec des domaines expéditeurs mélangés ou des logs dangereux, FixMyMess peut auditer le flux de bout en bout et pointer l'endroit exact où ça casse.

Exemple : réinitialisations de mot de passe qui échouent après un déploiement

Vous déployez une nouvelle build un vendredi. Quelques minutes plus tard, le support signale : « Je ne reçois pas l'e-mail de réinitialisation. » En production, cela ressemble souvent à « l'e-mail n'envoie pas », mais la cause réelle est généralement l'une des trois suivantes : DNS, auth fournisseur, ou un changement de code.

D'abord, vérifiez les logs de l'app pour la tentative d'envoi. Une régression peut se manifester par une nouvelle erreur comme Missing API key, 535 Authentication failed, ou ECONNREFUSED. Si les logs disent "sent" mais que les utilisateurs ne voient rien, passez au fournisseur.

Ouvrez le feed d'activité du fournisseur. Indices typiques :

• Beaucoup d'événements 401/403 : votre déploiement a changé ou effacé une variable d'environnement (clé API, user/pass SMTP).
• Beaucoup d'événements suppressed/blocked : vous avez touché une liste de rebond ou une limite d'envoi.
• Accepté par le fournisseur mais pas de livraison : problème de domaine ou spam plus probable.

Ensuite, écartez rapidement le DNS. Si vous avez fait tourner les domaines, changé le From, ou migré de fournisseur, un mismatch SPF/DKIM/DMARC peut transformer du vrai courrier en spam ou provoquer un rejet. Vous pouvez aussi voir des avertissements fournisseur comme "DKIM not aligned" ou "SPF softfail".

Les corrections typiques :

• Corriger les vars d'environnement en production (et redémarrer l'app pour qu'elle les prenne en compte).
• Vérifier SPF/DKIM/DMARC pour le domaine exact utilisé dans le From.
• Ajouter des réessais sûrs pour les timeouts (backoff court), et utiliser une clé d'idempotence pour éviter les doublons.

Enfin, ajoutez un simple monitor : toutes les 5 minutes, déclenchez un test de reset vers une boîte que vous contrôlez et alertez si aucun événement "delivered" côté fournisseur n'apparaît dans les 2 minutes. Si vous avez besoin d'aide pour réparer rapidement les envois en production, FixMyMess peut auditer le code, la config et le DNS ensemble pour que vous ne deviniez plus.

Checklist rapide avant de redéployer

Avant de redéployer, faites un test propre depuis la production et suivez la trace de bout en bout. L'objectif est de prouver si le message a quitté votre app, a atteint le fournisseur et a eu une chance d'atterrir en boîte.

Vérifications avant déploiement (10 minutes)

Parcourez ces points dans l'ordre. Chacun peut expliquer la plupart des rapports « l'e-mail n'envoie pas ».

• Envoyez un test unique à une boîte que vous contrôlez et récupérez l'ID du message fournisseur (ou l'ID de queue SMTP). Confirmez aussi que le fournisseur n'a pas d'incident et que votre compte n'est pas en pause, limité ou en train de supprimer ce destinataire.
• Confirmez que le domaine From est correctement configuré : SPF et DKIM existent, et DMARC est présent. Assurez-vous que le domaine From correspond à ce que votre fournisseur signe (l'alignement compte).
• Vérifiez les secrets de production : la bonne clé API ou le bon user/pass SMTP est chargé en production (pas en staging), et il a la permission d'envoyer depuis votre domaine choisi.
• Relisez le contenu de l'e-mail : évitez les objets spammy, vérifiez que les liens sont valides, et assurez-vous que les templates n'ont pas de variables manquantes (un HTML cassé nuit à la délivrabilité).
• Vérifiez la fiabilité : les réessais sont limités, chaque tentative est logguée, et votre appel d'envoi est idempotent pour qu'un timeout n'engendre pas de doublons.

Si vous ne parvenez toujours pas à résoudre les problèmes d'envoi en production après cela, il vous faudra probablement un diagnostic plus profond au niveau app (workers de queue, règles d'egress réseau, ou événements webhook fournisseur). FixMyMess peut auditer la chaîne et la durcir pour que les envois restent prévisibles après chaque déploiement.

Étapes suivantes si le problème revient régulièrement

Si vous devez sans cesse « réparer l'e-mail », traitez cela comme un problème de fiabilité, pas comme un bug ponctuel. Commencez par décider ce que vous vérifierez chaque semaine, même quand tout semble ok. La plupart des échecs d'e-mail se voient tôt comme une augmentation progressive des rebonds ou des plaintes.

Un monitor hebdomadaire simple peut suivre :

• Envois échoués (erreurs API ou rejets SMTP)
• Taux de rebond (dur vs soft)
• Plaintes pour spam
• Croissance des listes de suppression
• Latence moyenne d'envoi et nombre de timeouts

Ensuite, consignez votre configuration « connue bonne » en un seul endroit. Incluez le domaine expéditeur, le format de l'adresse From, le nom du fournisseur, la région d'envoi et les enregistrements DNS exacts attendus (SPF, DKIM, DMARC). Lors d'un déploiement ou d'un changement d'environnement, comparez rapidement pour voir ce qui a bougé au lieu de deviner.

Puis choisissez une petite amélioration qui réduit les incidents récurrents. Bonnes options : meilleurs logs d'erreur (stocker les codes de réponse du fournisseur), logique de réessai plus sûre (réessayer seulement sur erreurs temporaires avec backoff), ou gestion des webhooks qui enregistre rebonds et suppressions pour ne pas réessayer des adresses mortes.

Si vous tentez de réparer des envois en production dans une app générée par un outil d'IA, les problèmes récurrents viennent souvent de la dérive de configuration, de secrets exposés, ou d'auth flows cassés autour des réinitialisations et invitations. FixMyMess peut réaliser un audit gratuit du code pour trouver ces causes racines et réparer le code et le déploiement afin que l'envoi devienne fiable.