Comment envoyer des e-mails depuis votre application (et arriver dans la boîte de réception)

Pour envoyer des e-mails de façon fiable depuis votre application, utilisez un prestataire d'envoi plutôt que votre propre boîte mail, envoyez depuis une adresse de votre domaine, et ajoutez les enregistrements DNS fournis par le prestataire pour que SPF, DKIM et DMARC soient tous validés. Gardez les e-mails transactionnels — réinitialisations de mot de passe, reçus, confirmations — séparés des e-mails marketing, n'envoyez chacun qu'aux personnes qui s'y attendent, et gérez les rebonds et les désabonnements. Commencez par bien configurer l'authentification : c'est la cause la plus fréquente des e-mails d'application qui finissent dans les spams.

E-mail transactionnel ou marketing

Ces deux types d'e-mails se ressemblent dans le code, mais les fournisseurs de messagerie et la loi les traitent très différemment.

Séparez-les. Si une campagne marketing reçoit des plaintes pour spam, vous ne voulez pas que les réinitialisations de mot de passe envoyées depuis le même flux en pâtissent. Une approche courante consiste à utiliser des sous-domaines distincts — par exemple mail.exemple.com pour les e-mails de compte et news.exemple.com pour les newsletters — et certains prestataires séparent les deux en interne. Postmark, par exemple, décrit ses « flux de messages » transactionnels et de diffusion comme fonctionnant sur des infrastructures d'envoi distinctes, à la date de septembre 2026.

Choisir un prestataire

Votre application ne devrait pas envoyer elle-même les e-mails depuis son propre serveur. Les prestataires d'envoi gèrent l'infrastructure, la réputation des adresses IP, les nouvelles tentatives et le traitement des rebonds. Parmi les options bien connues figurent Postmark, Resend, SendGrid, Amazon SES et Mailgun ; chacune propose une API HTTP et un accès SMTP. Les tarifs et les formules évoluent, comparez-les donc sur leurs sites.

Ce qu'il faut comparer :

• Spécialisation. Certains prestataires se concentrent sur l'e-mail transactionnel, d'autres combinent transactionnel et marketing.
• Expérience développeur. Une API claire, des bibliothèques officielles pour votre langage, des journaux utiles indiquant si chaque message a été délivré, rebondi ou signalé comme spam.
• Webhooks pour les rebonds, les plaintes et les livraisons, afin que votre application puisse réagir.
• Modèles — stockés chez le prestataire ou dans votre propre code. Les garder dans le code permet de les versionner et de les tester.
• Région et traitement des données, si vous avez des exigences sur le lieu de traitement des données.
• Coût à votre volume, y compris ce qui se passe lorsque vous dépassez une offre gratuite.

Pour les newsletters envoyées à une liste, un outil dédié de newsletter ou d'e-mailing est souvent mieux adapté que la création de fonctions de campagne dans votre application.

Configurer votre domaine d'envoi

Envoyez depuis votre propre domaine — bonjour@exemple.com, et non une adresse Gmail ou Outlook. Un message envoyé depuis une adresse de messagerie gratuite via un service tiers échoue aux contrôles d'authentification et risque d'être filtré.

Pensez à un sous-domaine réservé à l'envoi. Resend, par exemple, recommande d'envoyer depuis des sous-domaines comme mises-a-jour.exemple.com pour isoler la réputation d'envoi (à la date de septembre 2026). Cela permet aussi de garder les enregistrements DNS des e-mails séparés de ceux de votre site principal.

Le prestataire vous fournit ensuite des enregistrements DNS à ajouter là où le DNS de votre domaine est géré. Si le DNS est nouveau pour vous, comment fonctionnent les domaines et le DNS explique d'abord les enregistrements.

SPF

SPF (Sender Policy Framework) est un enregistrement TXT qui liste les serveurs autorisés à envoyer des e-mails pour votre domaine. Le destinataire vérifie si le serveur expéditeur figure dans cette liste.

• Un domaine ne doit avoir qu'un seul enregistrement SPF. Si vous ajoutez un prestataire, fusionnez-le dans l'enregistrement existant plutôt que d'en ajouter un second.
• SPF autorise au maximum 10 recherches DNS lors de son évaluation ; de longues chaînes d'entrées include: peuvent dépasser cette limite et provoquer des échecs.
• De nombreux prestataires configurent SPF sur un sous-domaine de chemin de retour qu'ils vous demandent de créer ; il se peut donc que vous ne touchiez pas à votre enregistrement SPF principal.

DKIM

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque message. Le prestataire signe avec une clé privée ; vous publiez la clé publique correspondante sous forme d'enregistrement DNS (TXT ou CNAME, selon le prestataire). Le destinataire vérifie la signature pour confirmer que le message provient d'un expéditeur autorisé et n'a pas été modifié en chemin.

L'étape « vérifier le domaine » de votre prestataire concerne surtout DKIM. Ne l'ignorez pas.

DMARC

DMARC relie les deux autres. C'est un enregistrement TXT placé sur _dmarc.votredomaine.com qui indique aux destinataires :

• Alignement : le domaine de l'adresse d'expédition visible doit correspondre au domaine validé par SPF ou DKIM.
• Politique : quoi faire des messages qui échouent — p=none (simple rapport), p=quarantine (traiter comme suspect, souvent en spam) ou p=reject (rejeter).
• Rapports : l'adresse où envoyer les rapports agrégés (rua=), pour voir qui envoie des e-mails en votre nom.

Une démarche raisonnable consiste à commencer avec p=none et une adresse de rapport, à vérifier que vos messages légitimes passent, puis à passer à quarantine, et finalement à reject. Une politique stricte rend aussi beaucoup plus difficile l'usurpation de votre domaine par des tiers.

Ce qu'exige Gmail

Depuis septembre 2026, les consignes d'expédition de Google indiquent :

• Tous les expéditeurs vers les comptes Gmail personnels doivent disposer de SPF ou DKIM, d'une résolution directe et inverse valide pour les serveurs d'envoi, de TLS, et d'un taux de spam inférieur à 0,3 % dans Postmaster Tools.
• Les expéditeurs en masse (plus de 5 000 messages par jour vers Gmail) doivent avoir SPF et DKIM, un enregistrement DMARC (une politique p=none est autorisée), un alignement du domaine d'expédition, ainsi qu'un désabonnement en un clic et un lien de désabonnement visible sur les messages marketing et d'abonnement.

Votre prestataire gère les aspects côté serveur. Les enregistrements DNS et la gestion des désabonnements vous reviennent. Même si vous êtes loin des 5 000 par jour, respecter les règles d'envoi en masse est le moyen le plus simple d'être en sécurité.

Intégrer l'envoi dans votre application

Une fois le domaine vérifié :

1. Stockez la clé d'API comme secret côté serveur — jamais dans le code front-end. Voir ce que sont les variables d'environnement et les secrets.
2. Envoyez depuis le serveur, après que l'action déclenchant l'e-mail a réussi.
3. Ne faites pas attendre l'utilisateur pour l'e-mail. Pour toute application qui dépasse le plus simple, mettez l'envoi en file d'attente et relancez-le en cas d'échec temporaire, afin qu'une réponse lente du prestataire ne ralentisse pas l'inscription.
4. Journalisez le résultat — l'identifiant du message chez le prestataire et son statut — sans journaliser la clé ni le contenu complet des messages contenant des données personnelles.
5. Gérez les webhooks de rebonds et de plaintes : arrêtez d'écrire aux adresses en rebond définitif ou qui vous signalent comme spam.

Une consigne qui couvre les bases :

Envoie un e-mail transactionnel avec [PRESTATAIRE] en utilisant le secret serveur [NOM_VARIABLE], depuis « Acme bonjour@mail.acme.com ». Envoie un e-mail de bienvenue après l'inscription et une confirmation de réservation dès qu'une réservation est enregistrée. Garde les modèles dans le code, avec une version texte brut à côté du HTML. Mets les envois en file d'attente et relance les échecs temporaires jusqu'à trois fois. Journalise les échecs avec l'erreur du prestataire, mais jamais la clé d'API. Ajoute un point de terminaison webhook qui marque les adresses comme non délivrables en cas de rebond définitif ou de plainte, et ignore ces adresses à l'avenir.

Les e-mails de compte — liens de vérification, liens magiques et réinitialisations de mot de passe — font partie de la connexion. Comment ajouter une connexion à votre application explique comment ces parcours s'articulent ; rendez ces liens à usage unique et de courte durée.

Les bonnes pratiques de délivrabilité

L'authentification vous fait prendre en considération. Le comportement vous maintient dans la boîte de réception.

• N'envoyez que ce que les gens attendent. Inscriptions confirmées, consentement explicite pour le marketing, aucune liste achetée.
• Facilitez le désabonnement pour tout ce qui n'est pas strictement transactionnel, et respectez-le immédiatement.
• Faites chauffer les nouveaux domaines. Un domaine tout neuf qui envoie des milliers de messages dès le premier jour paraît suspect. Commencez avec vos e-mails transactionnels et augmentez le volume progressivement.
• Gardez des listes propres. Supprimez immédiatement les rebonds définitifs et envisagez de retirer les personnes qui n'ont rien ouvert depuis longtemps.
• Écrivez comme une personne. Un objet clair, un nom d'expéditeur reconnaissable, une partie en texte brut, peu d'images, et des liens vers votre propre domaine. Évitez les raccourcisseurs de liens.
• Surveillez. Enregistrez votre domaine dans Google Postmaster Tools et consultez de temps en temps les rapports DMARC.
• Utilisez une vraie adresse de réponse que quelqu'un lit. Les réponses sont un bon signal et un retour utile.

Tester sans spammer qui que ce soit

• Utilisez le mode test ou le bac à sable de votre prestataire lorsqu'il en propose un, ou envoyez à des adresses qui vous appartiennent.
• En développement, envoyez vers une boîte de test qui capte tous les messages plutôt que vers de vrais utilisateurs ; une base de données de test remplie d'adresses d'apparence réelle est un moyen facile d'écrire par erreur à des inconnus.
• Vérifiez chaque modèle dans quelques clients — Gmail sur le web, une application de messagerie mobile, Outlook — et en mode sombre.
• Consultez les en-têtes d'un e-mail de test : ils indiquent si SPF, DKIM et DMARC ont été validés.

Les bases juridiques

Les règles varient selon les pays. En règle générale, l'e-mail marketing nécessite un consentement dans de nombreux endroits, doit identifier l'expéditeur et proposer un désabonnement fonctionnel ; l'e-mail transactionnel est traité différemment, mais ne doit pas servir à glisser du marketing. Si vous collectez des adresses depuis une page de liste d'attente, indiquez ce que vous enverrez et conserverez, et quand et comment chaque personne s'est inscrite. En cas de doute, renseignez-vous sur les règles applicables là où se trouvent vos utilisateurs.

Liste de contrôle des e-mails

• Prestataire d'envoi choisi ; clé d'API stockée comme secret serveur
• Envoi depuis votre propre domaine ou sous-domaine, pas une messagerie gratuite
• Enregistrements SPF, DKIM et DMARC ajoutés et validés
• E-mails transactionnels et marketing séparés
• Envois mis en file d'attente et relancés ; résultats journalisés
• Webhooks de rebonds et de plaintes gérés
• Désabonnement sur les e-mails non transactionnels, respecté immédiatement
• Modèles testés dans plusieurs clients ; les e-mails de test n'atteignent jamais de vrais utilisateurs

Envoyer des e-mails depuis une application Mythex

Mythex n'inclut pas de service d'envoi d'e-mails intégré pour les applications que vous créez ; vous apportez donc un prestataire comme Resend, SendGrid ou Postmark. Stockez sa clé d'API comme secret de projet — l'agent peut la demander au moyen d'une carte de secrets dans le chat — et demandez les e-mails dont vous avez besoin en langage courant. La documentation propose une consigne de départ dans envoyer un e-mail depuis votre application. Si vous avez acheté votre domaine via Mythex avec l'offre Pro, vous pouvez ajouter les enregistrements TXT et CNAME du prestataire dans les paramètres DNS du domaine ; voir domaines personnalisés.

Questions