E-mails depuis votre propre domaine

Votre bot peut écrire à vos clients par e-mail depuis une adresse de votre domaine, par exemple noreply@example.com. Le message, lui, part de notre serveur. C'est pourquoi il faut, une fois pour toutes et avant le premier envoi, ajouter trois enregistrements au DNS de votre domaine. Ci-dessous : pourquoi c'est nécessaire, quoi ajouter exactement et ce qui se passe ensuite.

Pourquoi sans enregistrements DNS les e-mails n'arrivent pas

Placez-vous du côté du destinataire — Gmail, Outlook ou le serveur de messagerie de votre client. Il reçoit un message qui prétend venir de votre domaine, mais qui arrive d'un serveur n'appartenant pas à votre domaine. C'est exactement l'apparence d'une falsification : c'est ainsi que fonctionne le phishing.

La seule façon pour le destinataire de faire la différence est d'interroger le domaine lui-même : « cet expéditeur agit-il vraiment en votre nom ? ». La réponse, vous la publiez dans le DNS de votre domaine, car le DNS est le seul endroit dont vous seul disposez — et donc le seul auquel le destinataire accorde foi.

Tant que cette réponse manque, un serveur de messagerie consciencieux doit considérer le message comme suspect. Au mieux il finit dans les indésirables, au pire il est rejeté et le destinataire n'en saura jamais rien.

Les trois enregistrements ci-dessous ne sont donc ni une formalité ni une case à cocher. Ils sont votre autorisation.

Les trois enregistrements et le rôle de chacun

DKIM — la signature qui prouve l'authenticité

DKIM est une signature cryptographique apposée sur chaque message sortant. La plateforme génère pour votre domaine une paire de clés : la privée reste chez nous et signe les envois, la publique, vous la publiez dans le DNS. Le destinataire prend la clé publique dans votre DNS et vérifie la signature. Si elle correspond, le message a bien été envoyé par le détenteur de la clé privée et son contenu n'a pas été modifié en route.

Sans DKIM : il n'y a rien pour vérifier la signature. Le message paraît non signé, sans crédit, et aucun autre réglage ne compense. DKIM est le plus important des trois.

SPF — quels serveurs peuvent envoyer en votre nom

SPF répond à une autre question : depuis quels serveurs des e-mails de ce domaine sont admissibles. C'est une liste de sources : les serveurs de votre hébergeur, les services d'envoi que vous utilisez déjà et, pour que le bot puisse écrire, nos serveurs d'envoi.

Sans SPF : le message arrive d'un serveur que votre domaine ne connaît pas. Pour un filtre, c'est un signe classique de falsification, qui s'ajoute à tous les autres soupçons.

DMARC — que doit faire le destinataire si les contrôles échouent

DKIM et SPF répondent à « le message est-il authentique ». DMARC répond à la suite : que faire si non. C'est votre instruction au destinataire — ne rien faire et se contenter d'un rapport, mettre en indésirables, ou rejeter. DMARC est aussi l'adresse à laquelle les destinataires envoient des rapports agrégés sur le courrier émis en votre nom, y compris les tentatives de falsification.

Commencez par la politique la plus douce, « rapports seulement ». Durcissez-la plus tard, une fois assuré que tous vos expéditeurs légitimes (comptabilité, CRM, newsletters, ce bot) passent les contrôles. Une politique stricte activée trop tôt se met à dévorer votre propre courrier.

Sans DMARC : chaque destinataire décide pour lui-même, et vous n'apprenez jamais ce qu'il advient du courrier envoyé en votre nom.

Quels enregistrements ajouter

Déclarez d'abord le domaine dans l'espace client : rubrique Email → « Sending domains » → bouton « Add domain ». La boîte de dialogue comporte trois champs : le domaine lui-même (par exemple shop.example.com), la partie locale de l'adresse (ce qui précède le @, en général noreply) et le nom d'expéditeur que le destinataire voit à la place d'une adresse. Une fois enregistré, vos enregistrements DNS s'affichent à l'écran.

Les trois sont des enregistrements TXT dans le DNS de votre domaine. On les ajoute là où vous gérez le domaine : le panneau de votre registrar ou votre fournisseur DNS.

Les valeurs ci-dessous prennent example.com en exemple — remplacez-le par le vôtre. Les valeurs exactes pour votre domaine figurent sur la fiche du domaine dans l'espace client : copiez-les de là, surtout DKIM, dont la valeur contient votre propre clé publique, différente pour chaque domaine et impossible à tirer de la documentation.

À l'écran, chaque enregistrement est scindé en deux champs distincts — « Host » et « Value » —, chacun avec son bouton « Copy ». Copiez-les un par un dans les champs correspondants chez votre fournisseur DNS : les deux parties ne se collent pas d'un seul bloc.

Deux pièges fréquents :

• Beaucoup de panneaux ajoutent eux-mêmes le domaine au nom. Si le champ affiche déjà « .example.com », saisissez seulement mybot._domainkey et non le nom complet, sinon vous obtiendrez mybot._domainkey.example.com.example.com.
• La valeur DKIM est longue et ne doit contenir ni retour à la ligne ni espace à l'intérieur de la clé. Copiez-la avec le bouton, pas à la souris.

Si le domaine possède déjà un enregistrement SPF

Un domaine ne peut avoir qu'un seul enregistrement SPF. Si vous envoyez déjà du courrier via votre hébergement, un CRM ou un autre service d'e-mailing, il existe. N'en ajoutez pas un second : complétez l'existant avec un include supplémentaire, avant le ~all final :

v=spf1 include:spf.votrefournisseur.fr include:esp.getmybot.dev ~all

Deux enregistrements SPF sur un domaine, c'est la même erreur qu'aucun : le contrôle échoue, car le destinataire ne peut pas savoir auquel des deux se fier.

Attention : être « couvert » par l'enregistrement d'un tiers ne suffit pas. Même si votre prestataire actuel nous inclut dans son propre SPF, notre include doit figurer directement dans votre enregistrement — voir la section sur la vérification du domaine, plus bas, pour la raison.

Pourquoi un include dans SPF et pas une adresse IP

L'erreur la plus courante consiste à coller une adresse IP aperçue dans un en-tête de message ou sur un forum. Ne le faites pas.

include:esp.getmybot.dev est un renvoi vers notre propre liste, tenue à jour, de serveurs d'envoi. Aujourd'hui, ce nom pointe vers un unique relais. Demain ils pourront être plus nombreux, déménager ou être remplacés. Le jour venu, nous mettrons la liste à jour de notre côté — et votre enregistrement continuera de fonctionner sans que vous ayez à y toucher. C'est tout l'intérêt : l'adresse change à un seul endroit et non dans le DNS de chaque client.

Une IP écrite à la main cesse simplement d'être vraie à ce moment-là. Les messages commencent à échouer au contrôle SPF sans le moindre avertissement : ni erreur dans l'espace client, ni notification. Vous l'apprendrez de clients qui « n'ont jamais rien reçu ».

Écrivez exactement include:esp.getmybot.dev et n'y ajoutez rien.

Vérification du domaine

Vérifier le domaine, c'est la plateforme qui consulte elle-même le DNS de votre domaine et confirme que les trois enregistrements sont en règle. Si les trois passent, le domaine devient vérifié et l'envoi est autorisé. Tant qu'un seul échoue, il reste en attente.

Le contrôle va plus loin que « l'enregistrement existe » :

Pourquoi DMARC est contrôlé plus souplement : il dit aux destinataires quoi faire des résultats DKIM et SPF, mais il ne nous donne pas le droit d'envoyer en votre nom. Ce droit vient uniquement des deux premiers enregistrements, tous deux vérifiés intégralement sur leur contenu.

Un include tiers ne compte pas

include:esp.getmybot.dev doit figurer dans votre propre enregistrement SPF. Si votre SPF inclut un prestataire tiers dont l'enregistrement nous inclut à son tour, la vérification ne l'acceptera pas : la plateforme ne déroule pas les chaînes d'includes d'autrui. La raison est simple — cela garde sans ambiguïté la réponse à la question « ce domaine précis nous a-t-il autorisés ».

Concrètement : même si vous êtes convaincu d'être « couvert via votre prestataire », ajoutez notre include directement à votre propre enregistrement. C'est exactement ce que dit l'écran lui-même dans son explication du SPF : si le domaine possède déjà un enregistrement SPF, ajoutez-y la valeur include:... au lieu de remplacer l'enregistrement en entier, car le domaine envoie peut-être aussi du courrier par d'autres voies. Cette note est affichée en permanence, elle n'apparaît pas seulement après un échec.

Le DNS ne se met pas à jour instantanément. Après enregistrement chez le registrar, il faut que les données se propagent sur les serveurs de noms : généralement quelques minutes, parfois des heures, rarement jusqu'à une journée. Cela dépend de votre fournisseur et du TTL. C'est normal et hors de notre contrôle.

Attendre passivement n'est cependant pas nécessaire. La plateforme revérifie les domaines en attente toutes les heures, mais la fiche du domaine propose le bouton « Verify now » : le même contrôle, lancé immédiatement, avec le résultat aussitôt à l'écran. Utilisez-le juste après avoir enregistré les valeurs : en cas de faute de frappe, vous le saurez en une seconde et non en une heure. Vous pouvez le relancer autant de fois que vous voulez.

Le statut du domaine figure sur la fiche : « Pending verification », « Verified » ou « Not verified ». Tant qu'il n'est pas vérifié, la fiche porte aussi l'avertissement « Sending from this domain is disabled until it is verified. »

Le résultat n'est pas un simple « échec ». Chacun des trois enregistrements a son propre statut à l'écran — « Passing », « Not passing » ou « Not checked yet » — et sa propre ligne expliquant ce qui ne va pas.

Pour SPF, l'écran distingue deux situations, et c'est la distinction la plus importante de tout le parcours :

• Le domaine n'a aucun enregistrement SPF. Publiez-en un, avec la valeur du tableau ci-dessus.
• Un enregistrement SPF existe mais ne contient pas notre include. Ajoutez l'include à l'enregistrement existant : n'en créez pas un second et ne le remplacez pas entièrement. Le même message traite explicitement le cas de la chaîne : si l'include ne nous atteint qu'à travers l'enregistrement SPF d'un autre prestataire, cela ne compte pas — les chaînes ne sont pas déroulées.

Le second cas est le moment le plus déroutant de tout le parcours : l'enregistrement est déjà là, vous venez de le relire vous-même, et la vérification refuse quand même. Le message d'erreur dit désormais exactement la même chose que la note affichée en permanence à côté de l'enregistrement : ajoutez notre include à ce qui existe déjà.

Si la vérification échoue :

1. Lisez lequel des trois enregistrements porte « Not passing » et ce que dit son explication, puis agissez en conséquence.
2. Assurez-vous que les enregistrements sont bien publiés — beaucoup de panneaux exigent un « appliquer les modifications » séparé.
3. Vérifiez le nom de l'enregistrement, au cas où le domaine serait doublé (voir plus haut).
4. Vérifiez qu'il n'y a qu'un seul enregistrement SPF et que notre include se trouve dans cet enregistrement même.
5. Patientez et relancez : la modification n'est peut-être pas encore propagée.

Tant que le domaine n'est pas vérifié, l'envoi refuse de fonctionner

Tant qu'un domaine n'est pas vérifié, les messages ne partent pas. Non pas « partent et tombent en indésirables » : ils ne partent pas du tout, la tentative échoue avec une erreur de domaine non vérifié, visible dans le journal.

C'est délibéré, et ce n'est pas un dysfonctionnement. Le courrier d'un domaine qui ne s'est pas porté garant pour lui-même se transforme en plaintes pour spam, et les plaintes abîment la réputation d'une infrastructure d'envoi partagée par tous les clients de la plateforme. Ne pas envoyer un message coûte moins cher que l'envoyer et passer ensuite six mois à sortir des listes noires. D'où une interdiction plutôt qu'un avertissement.

Si vous voyez cette erreur, vérifiez les enregistrements DNS et lancez le contrôle avant d'écrire au support. Dans l'immense majorité des cas, il s'agit d'une faute de frappe dans le nom d'un enregistrement.

Désabonnements, plaintes et rejets

Trois règles qui surprennent quand on ne les connaît pas à l'avance.

Chaque message commercial comporte un désabonnement en un clic. La plateforme ajoute d'elle-même un lien de désabonnement en pied de message ainsi que les en-têtes techniques à partir desquels le logiciel de messagerie dessine un bouton « Se désabonner » à côté de l'adresse de l'expéditeur. Impossible de l'enlever, ni par un réglage ni par la mise en page. Le désabonnement prend effet immédiatement, sans ouvrir le message et sans étape de confirmation. Gmail et les autres grands acteurs l'exigent des expéditeurs de masse : un message qui en est dépourvu part en indésirables à coup sûr.

Un désabonnement est définitif et ne s'annule pas depuis l'interface. Une adresse désabonnée ne reçoit plus rien de ce bot. Pas de bouton « restaurer », pas de contournement par un réimport de liste : un désabonnement n'est jamais annulé au-dessus de la tête de la personne. Elle ne peut revenir que d'elle-même, en laissant à nouveau son adresse dans votre formulaire d'inscription.

Il existe un cas encore plus strict : si quelqu'un a appuyé sur « Ceci est un spam » dans son logiciel, l'adresse est fermée pour de bon. Même une nouvelle inscription via votre formulaire ne la rouvre pas — car nous savons déjà comment s'est terminée la tentative précédente, et écrire à de telles adresses est ce qui détruit le plus vite la réputation d'un domaine. Les adresses fermées manuellement sur demande juridique se comportent de la même manière.

Un rejet définitif supprime l'adresse pour toujours. Si le serveur du destinataire répond que cette boîte n'existe pas, l'adresse est marquée comme non délivrable et exclue des envois suivants. Ce n'est pas un état temporaire : continuer à frapper à une boîte inexistante est le chemin le plus court vers les filtres antispam, en y entraînant toutes les autres adresses.

Les rejets temporaires (boîte pleine, serveur momentanément indisponible) ne ferment pas l'adresse : l'envoi se poursuit.

Pourquoi le taux d'ouverture est sous-estimé

Les statistiques e-mail comportent un chiffre d'ouvertures, et il est toujours inférieur à la réalité. Ce n'est pas une erreur de comptage, c'est la manière même dont les ouvertures se mesurent.

Une ouverture est enregistrée lorsque le logiciel de messagerie charge depuis un serveur une minuscule image de suivi au moment d'afficher le message. Les logiciels modernes ne chargent pas les images distantes par défaut ; et ceux qui le font (Apple Mail et autres fonctions de confidentialité) les chargent à l'avance pour tout le monde, y compris pour ceux qui n'ont jamais ouvert le message. Dans le premier cas l'ouverture est perdue, dans le second elle est attribuée à quelqu'un qui n'était pas là. Il n'existe aucun moyen de compter les ouvertures plus précisément — ni pour nous, ni pour personne.

C'est pourquoi l'interface affiche une réserve à côté du chiffre : c'est une borne inférieure, pas un nombre exact. Servez-vous-en pour comparer des messages entre eux, où la même distorsion s'applique à tous, mais pas comme réponse à « combien de personnes ont lu ce message ».

Si vous avez besoin d'une mesure d'engagement fiable, regardez « Link clicks ». Un clic sur un lien est une action réelle d'une personne réelle ; personne ne l'accomplit à sa place par anticipation. « Delivered », « Unsubscribes », « Complaints » et « Bounces » sont eux aussi comptés exactement : ils sont rapportés par des serveurs de messagerie, non par une image dans un message. Tout cela se trouve dans le bloc « Sending stats » du même écran Email.

Et ensuite

• Canaux — multicanalité et possibilités des canaux.
• Diffusions — envoi en masse.
• Analytique — où consulter les chiffres.