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

Pour envoyer des courriels de votre application de façon fiable, utilisez un fournisseur d'envoi de courriels plutôt que votre propre boîte aux lettres, envoyez depuis une adresse de votre propre domaine, et ajoutez les enregistrements DNS que le fournisseur vous donne afin que SPF, DKIM et DMARC soient tous validés. Gardez les courriels transactionnels (réinitialisations de mot de passe, reçus, confirmations) séparés des courriels marketing, n'envoyez chacun qu'aux personnes qui s'y attendent, et gérez les rebonds et les désabonnements. Réglez d'abord l'authentification : c'est la cause la plus fréquente des courriels d'application qui aboutissent dans les pourriels.

Courriel transactionnel ou marketing

Ces deux types de courriels se ressemblent dans le code, mais les fournisseurs de boîtes de réception et la loi les traitent très différemment.

Gardez-les séparés. Si une campagne marketing reçoit des plaintes pour pourriel, vous ne voulez pas que les réinitialisations de mot de passe du même flux en pâtissent. Une approche courante consiste à utiliser des sous-domaines distincts, par exemple mail.exemple.com pour les courriels de compte et news.exemple.com pour les infolettres, et certains fournisseurs séparent eux-mêmes les deux. Postmark, par exemple, décrit ses « flux de messages » transactionnels et de diffusion comme fonctionnant sur une infrastructure d'envoi distincte, en date de septembre 2026.

Choisir un fournisseur

Votre application ne devrait pas envoyer elle-même des courriels depuis son propre serveur. Les fournisseurs 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, on compte Postmark, Resend, SendGrid, Amazon SES et Mailgun. Chacun offre une API HTTP et un accès SMTP. Les prix et les forfaits changent, alors comparez-les sur leurs propres sites.

Éléments à comparer :

• Spécialisation. Certains fournisseurs se concentrent sur le transactionnel; d'autres combinent transactionnel et marketing.
• Expérience développeur. Une API claire, des bibliothèques officielles pour votre langage, et des journaux utiles qui indiquent si chaque message a été livré, rebondi ou marqué comme pourriel.
• Webhooks pour les rebonds, les plaintes et les livraisons, afin que votre application puisse réagir.
• Gabarits : stockés chez le fournisseur ou dans votre propre code. Les garder dans le code les rend versionnés et testables.
• Région et traitement des données, si vous avez des exigences sur l'endroit où les données sont traitées.
• Coût à votre volume, y compris ce qui se passe lorsque vous dépassez un palier gratuit.

Pour les infolettres destinées à une liste, un outil d'infolettre ou de marketing par courriel dédié convient souvent mieux que de créer des 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 courriel envoyé depuis une boîte gratuite par un service tiers échoue aux contrôles d'authentification et risque d'être filtré.

Envisagez un sous-domaine réservé à l'envoi. Resend, par exemple, recommande d'envoyer à partir de sous-domaines comme mises-a-jour.exemple.com pour isoler la réputation d'envoi (en date de septembre 2026). Cela garde aussi les enregistrements DNS du courriel séparés de ceux de votre site principal.

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

SPF

SPF (Sender Policy Framework) est un enregistrement TXT qui énumère les serveurs autorisés à envoyer des courriels pour votre domaine. Les destinataires vérifient si le serveur expéditeur figure sur la liste.

• Un domaine ne devrait avoir qu'un seul enregistrement SPF. Si vous ajoutez un fournisseur, fusionnez-le dans l'enregistrement existant plutôt que d'en ajouter un deuxième.
• SPF permet 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.
• Plusieurs fournisseurs configurent SPF sur un sous-domaine de chemin de retour qu'ils vous demandent de créer, de sorte que vous n'avez peut-être pas à toucher à votre enregistrement SPF principal.

DKIM

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

L'étape « vérifier le domaine » de votre fournisseur porte surtout sur DKIM. Ne la sautez pas.

DMARC

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

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

Une démarche raisonnable consiste à commencer avec p=none et une adresse de rapport, à confirmer 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 d'autres.

Ce que Gmail exige

En date de septembre 2026, les lignes directrices de Google pour les expéditeurs stipulent :

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

Votre fournisseur gère les parties 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 la façon la plus simple d'être en sécurité.

Intégrer l'envoi à votre application

Une fois le domaine vérifié :

1. Stockez la clé d'API comme secret côté serveur, jamais dans le code de l'interface. Voir ce que sont les variables d'environnement et les secrets.
2. Envoyez depuis le serveur, après que l'action déclencheuse a réussi.
3. Ne faites pas attendre l'utilisateur pour le courriel. Pour toute application dépassant le plus simple, mettez l'envoi en file d'attente et réessayez en cas d'échec temporaire, afin qu'une réponse lente du fournisseur ne ralentisse pas l'inscription.
4. Consignez le résultat : l'identifiant du message chez le fournisseur et son statut, sans journaliser la clé ni le contenu complet des messages contenant des données personnelles.
5. Gérez les webhooks pour les rebonds et les plaintes : cessez d'écrire aux adresses qui rebondissent définitivement ou qui vous signalent comme pourriel.

Une consigne qui couvre les bases :

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

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

Habitudes de délivrabilité

L'authentification vous rend crédible. Le comportement vous garde 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.
• Rendez le désabonnement facile pour tout ce qui n'est pas strictement transactionnel, et respectez-le immédiatement.
• Préparez graduellement les nouveaux domaines. Un domaine tout neuf qui envoie des milliers de messages dès le premier jour paraît suspect. Commencez avec vos courriels transactionnels et augmentez le volume graduellement.
• Gardez vos listes propres. Retirez 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. Inscrivez votre domaine dans Google Postmaster Tools et lisez de temps à autre les rapports DMARC.
• Utilisez une vraie adresse de réponse que quelqu'un lit. Les réponses sont un bon signal et une rétroaction utile.

Tester sans envoyer de pourriels à qui que ce soit

• Utilisez le mode test ou le bac à sable de votre fournisseur lorsqu'il en offre un, ou envoyez à des adresses qui vous appartiennent.
• En développement, envoyez vers une boîte de test qui capte tous les courriels au lieu de vrais utilisateurs; une base de données d'exemple remplie d'adresses d'apparence réelle est un moyen facile d'écrire par erreur à des inconnus.
• Vérifiez chaque gabarit dans quelques clients : Gmail sur le web, une application de courriel sur téléphone, Outlook, et en mode sombre.
• Regardez les en-têtes d'un courriel de test : ils indiquent si SPF, DKIM et DMARC ont été validés.

Notions juridiques de base

Les règles varient selon le pays. Dans l'ensemble, le courriel marketing exige le consentement dans de nombreux endroits, doit identifier l'expéditeur et offrir un désabonnement fonctionnel; le courriel transactionnel est traité différemment, mais ne doit pas servir à glisser du marketing. Si vous recueillez des adresses depuis une page de liste d'attente, dites ce que vous enverrez et conserverez, et quand et comment chaque personne s'est inscrite. En cas de doute, vérifiez les règles applicables là où se trouvent vos utilisateurs.

Liste de contrôle pour les courriels

• Fournisseur d'envoi choisi; clé d'API stockée comme secret serveur
• Envoi depuis votre propre domaine ou sous-domaine, et non une boîte gratuite
• Enregistrements SPF, DKIM et DMARC ajoutés et validés
• Courriels transactionnels et marketing séparés
• Envois mis en file d'attente et réessayés; résultats consignés
• Webhooks de rebonds et de plaintes gérés
• Désabonnement dans les courriels non transactionnels, respecté immédiatement
• Gabarits testés dans plusieurs clients; les courriels de test n'atteignent jamais de vrais utilisateurs

Envoyer des courriels depuis une application Mythex

Mythex n'inclut pas de service d'envoi de courriels intégré pour les applications que vous créez; vous apportez donc votre propre fournisseur, comme Resend, SendGrid ou Postmark. Stockez sa clé d'API comme secret du projet : l'agent peut la demander au moyen d'une fiche de secrets dans le clavardage. Demandez ensuite les courriels dont vous avez besoin, en termes simples. La documentation contient une consigne de départ dans envoyer un courriel depuis votre application. Si vous avez acheté votre domaine par Mythex avec le forfait Pro, vous pouvez ajouter les enregistrements TXT et CNAME du fournisseur dans les paramètres DNS du domaine; voir domaines personnalisés.

Questions