Votre infolettre peut envoyer vos factures aux indésirables

Si vous ne retenez qu'une phrase, retenez celle-ci : chaque outil qui envoie au nom de votrenom.com puise dans la même réputation, et n'importe lequel d'entre eux peut la gaspiller pour tous les autres.

Faites le compte. Microsoft 365 pour vos employés. Un CRM pour les suivis. Un outil d'infolettre. Un système de soutien qui répond aux clients. Le logiciel comptable qui envoie les factures. Dans la plupart des PME et des organismes, chacun d'eux envoie comme @votrenom.com.

Ça fonctionne, parfois pendant des années. C'est justement le piège.

Petit avertissement : la suite est technique. On n'essaie pas de vous donner mal à la tête. Si ça vous en donne quand même, passez directement à la version sans mal de tête, à la fin. Elle est là exprès, et personne ne vous note.

Un seul nom, une seule réputation

Gmail, Outlook et Yahoo ne jugent pas seulement le serveur d'où vient un message. Ils jugent aussi le domaine qui l'a signé. Google le dit clairement : la réputation affichée dans ses Postmaster Tools est celle du « domaine exact utilisé pour l'authentification DKIM et SPF » (Google, notre traduction). Yahoo : « Chaque adresse IP et chaque domaine DKIM a une réputation, qui peut influencer la livraison de vos courriels » (Yahoo, notre traduction).

Vos outils envoient à partir de serveurs différents : ceux de Microsoft, ceux du fournisseur du CRM, ceux de la plateforme d'infolettre. Chacun de ces serveurs a sa propre réputation. Mais s'ils signent tous comme votrenom.com, ils partagent une seule réputation de domaine. L'infolettre part vers une vieille liste, les plaintes s'accumulent, et la prochaine facture de la comptabilité et la prochaine réponse de votre équipe de soutien partent sous le même nom abîmé.

Deux façons dont un outil entraîne les autres

Il envoie mal. Une vieille liste, une campagne que personne n'a demandée, une vague de rebonds. Les plaintes et les rebonds comptent contre le domaine qui a authentifié le courriel. C'est le vôtre.

Il est mal configuré. Celle-ci est plus discrète. DMARC réussit si SPF ou DKIM correspond à votre domaine, et par défaut, bien des plateformes d'envoi mettent l'adresse technique de retour (l'adresse de rebond) sur leur propre domaine. SPF ne correspond donc pas pour elles. Il reste DKIM. Un outil qui n'a jamais activé DKIM pour votre domaine échoue à DMARC pour chaque message qu'il envoie. Tant qu'il tourne, vous ne pouvez pas passer votre politique DMARC à quarantine ou reject sans le bloquer. Tout le domaine reste à p=none, ouvert à quiconque veut envoyer en votre nom, parce qu'un seul outil n'a jamais été terminé.

Et un mécanisme frappe tous les outils à la fois, Microsoft 365 compris.

SPF a une limite stricte de 10 requêtes DNS. Chaque include: que vous ajoutez pour un outil en coûte au moins une, souvent plusieurs, parce que les fournisseurs imbriquent leurs propres include:. Au-delà de 10, SPF retourne une erreur permanente, et tout message dont la vérification a besoin de ces requêtes de trop échoue à SPF. Microsoft 365 est habituellement la première entrée de l'enregistrement : il peut donc encore réussir pendant que les outils inscrits après lui échouent. La limite est fixe, 10 (RFC 7208). Ce qui bouge, c'est votre total : un fournisseur ajoute un autre include: imbriqué de son côté, et un bon matin vous dépassez sans avoir rien touché. La documentation de Microsoft signale un second piège : si le domaine d'un include: d'un fournisseur cesse de répondre, ou perd son enregistrement SPF, votre SPF échoue de la même façon. Une erreur dans le DNS de quelqu'un d'autre brise le vôtre. (DKIM peut encore faire passer vos courriels à DMARC quand SPF est brisé, une raison de plus pour qu'il soit en place. Mais les outils au-delà de la limite restent en panne jusqu'à ce que quelqu'un s'en aperçoive.)

« Ça fonctionne depuis un an. » Ça ne prouve rien.

Tout le monde le dit, et c'est souvent vrai. Ce n'est pas la question.

Chaque plateforme que vous utilisez aura un jour une mauvaise journée, et vous ne choisirez pas laquelle :

• Un fournisseur ajoute des serveurs et son include: SPF dépasse votre budget de requêtes. Vous n'avez rien changé.
• Un fournisseur change ses clés DKIM et l'enregistrement que vous avez publié il y a deux ans ne correspond plus.
• Quelqu'un vole par hameçonnage le mot de passe d'un compte marketing ou CRM et envoie par cette plateforme. Le courriel est signé avec votre domaine et réussit toutes les vérifications. C'est exactement pour ça que les attaquants aiment les comptes piratés sur de vraies plateformes.
• Le fournisseur lui-même est piraté, ou subit une panne de son propre DNS.
• Quelqu'un aux TI fait le ménage du DNS et supprime un enregistrement qui « avait l'air vieux ».
• Vous abandonnez un outil et laissez ses enregistrements en place.

La plupart de ces situations ne sont pas la faute de votre équipe, et aucune ne s'annonce. Quand tous les outils partagent un domaine, peu importe lequel flanche, il flanche sur le nom qu'utilisent vos employés et vos factures.

Donnez à chaque outil son propre sous-domaine

La solution est vieille, ennuyante et recommandée par les fournisseurs de messagerie eux-mêmes. Microsoft, dans sa documentation sur SPF :

Pour les services de courriel qui ne sont pas sous votre contrôle direct (par exemple, les services d'envoi en masse), nous recommandons d'utiliser un sous-domaine (par exemple, marketing.contoso.com) plutôt que votre domaine de messagerie principal (par exemple, contoso.com). Vous ne voulez pas que des problèmes avec les courriels envoyés par ces services nuisent à la réputation des courriels envoyés par les employés de votre domaine principal. — Microsoft Learn (notre traduction)

Yahoo parle plutôt de serveurs d'envoi, mais le principe est le même. Il écrit que « chaque adresse IP et chaque domaine DKIM a une réputation » et qu'« en séparant vos courriels selon leur fonction, vous les aidez à obtenir la meilleure livraison possible » (Yahoo, notre traduction). Un sous-domaine à vous donne à chaque fonction son propre domaine DKIM.

Remarquez le critère de Microsoft : les services qui ne sont pas sous votre contrôle direct. C'est tout l'argument qui précède. Vous ne contrôlez ni les serveurs d'un fournisseur, ni ses clés, ni son DNS, ni les mots de passe de ses clients.

Concrètement, ça ressemble à ceci :

Chaque sous-domaine a son propre enregistrement SPF (avec son propre budget de 10 requêtes), sa propre clé DKIM et son propre enregistrement DMARC. Une précision sur SPF : il vérifie l'adresse de retour, pas le From:. Le budget SPF du sous-domaine n'aide que si l'adresse de retour de l'outil est sur ce sous-domaine. Si elle reste sur le domaine du fournisseur, le gain est plus simple : retirez l'include: de ce fournisseur de votre enregistrement principal. Google affiche chacun comme une réputation de domaine distincte dans Postmaster Tools.

Deux conditions, sinon ça ne sert à rien. L'adresse que les gens voient dans le champ From: (l'expéditeur affiché) doit être sur le sous-domaine, et la signature DKIM doit être celle du sous-domaine. Un outil qui envoie encore From: [email protected] utilise toujours votre domaine principal, peu importe son adresse technique de retour. Bien des plateformes mettent déjà cette adresse de retour (l'expéditeur de l'enveloppe) sur un sous-domaine comme bounce.votrenom.com. C'est de la plomberie, pas de la séparation : DMARC juge la ligne From:, votre lecteur voit la ligne From:, et le clic « signaler comme pourriel » tombe sur la ligne From:. Vérifiez un message réellement reçu, pas la page de configuration du fournisseur.

Par outil ou par public?

C'est là que les avis divergent. Notre réponse : par outil d'abord.

Ce qui brise, c'est presque toujours un outil : ses clés, son include: SPF, ses serveurs, ses comptes. Un sous-domaine par outil, c'est une panne qui reste à un seul endroit. Quand un sous-domaine a un problème, son nom vous dit quel fournisseur appeler.

Le public, ou plus précisément le type de courriel, est la deuxième séparation. Vous n'en avez besoin que si un même outil envoie deux types de courriels très différents. L'exemple de Microsoft est exactement celui-là : m.contoso.com pour le marketing, t.contoso.com pour le transactionnel (Microsoft Learn). Si la même plateforme envoie votre infolettre et vos réinitialisations de mot de passe, séparez-les. Les infolettres attirent les plaintes. Les réinitialisations de mot de passe, non, et vous ne voulez pas qu'une promotion soit la raison pour laquelle une réinitialisation aboutit aux indésirables.

Deux conseils pratiques :

• Nommez les sous-domaines selon leur usage, pas selon le fournisseur. infolettre. survit au jour où vous changez de plateforme. Le nom d'un fournisseur dans votre DNS indique aussi à un attaquant quelle plateforme viser.
• N'en créez pas vingt. Chaque sous-domaine, c'est une clé DKIM à renouveler, un enregistrement DMARC à surveiller et quelqu'un qui doit en être responsable. Un par outil d'envoi, c'est amplement suffisant.

Ce qu'un sous-domaine ne fera pas

C'est la partie que la plupart des articles sautent. Un sous-domaine limite les dégâts. Il ne les efface pas.

• Ce n'est pas un mur. Dans Postmaster Tools, Google affiche le statut de conformité pour le domaine principal seulement, et précise qu'il est calculé aussi à partir des données des sous-domaines (Google). Un sous-domaine qui se comporte mal peut faire paraître tout le domaine non conforme.
• Les volumes s'additionnent. Google compte tous les messages d'un même domaine principal pour son seuil d'expéditeur en masse de 5 000 par jour. Son propre exemple : 2 500 de solarmora.com plus 2 500 de promotions.solarmora.com font un expéditeur en masse. Google précise aussi que ce statut n'expire jamais (Google).
• Ce n'est pas un nouveau départ. Les serveurs de réception voient bien que infolettre.votrenom.com appartient à votrenom.com. Aucun fournisseur ne publie exactement comment la réputation circule entre les deux, mais on observe largement qu'un domaine principal mal réputé entraîne ses sous-domaines avec lui. Créer courriel2.votrenom.com pour échapper à une mauvaise réputation ne fonctionne pas.
• Ça ne règle pas les serveurs partagés. Si un outil envoie à partir de serveurs partagés avec les autres clients du fournisseur, leur comportement vous touche quand même. C'est la réputation du serveur, et un sous-domaine n'y change rien.
• À lui seul, il n'empêche pas un outil compromis d'usurper votre domaine principal. Par défaut, DMARC accepte la signature de n'importe quel sous-domaine comme valable pour le domaine principal (c'est ce qu'on appelle l'alignement souple). La plateforme détient la clé privée qui signe pour infolettre.votrenom.com. Si ses systèmes sont piratés, l'attaquant peut signer avec cette clé un message From: [email protected], et il réussit DMARC pour votre domaine principal. Vous pouvez fermer cette porte en exigeant une correspondance exacte dans l'enregistrement DMARC du domaine principal : adkim=s (et aspf=s pour SPF).

⚠️ N'activez pas le mode strict parce que vous venez d'en lire la description. adkim=s et aspf=s sont les réglages les plus dangereux de cet article. Bien des outils qui semblent corrects aujourd'hui réussissent DMARC seulement parce que le mode souple leur pardonne : une infolettre ou un CRM qui signe avec un sous-domaine comme em.votrenom.com, ou un outil dont l'adresse de retour est sur bounce.votrenom.com et qui n'a aucune signature DKIM pour votre domaine. Les deux affichent From: @votrenom.com et les deux réussissent aujourd'hui. Passez au mode strict avec l'un d'eux encore en place, et ses courriels échouent à DMARC le jour même, sans que rien dans votre propre boîte ne vous avertisse. Vos factures, votre infolettre ou vos réinitialisations de mot de passe cessent simplement d'arriver.

Le mode strict est la dernière étape, pas la première. Lisez vos rapports DMARC pendant au moins deux à quatre semaines, confirmez que chaque source qui envoie encore avec votre domaine principal dans le From: réussit avec une signature DKIM pour exactement ce domaine, et seulement ensuite, changez le réglage. Si vous ne savez pas comment lire ces rapports, c'est l'étape pour laquelle il vaut la peine de demander de l'aide.

Dans cet ordre, sur quelques semaines, pas en un après-midi

Chaque étape ci-dessous change la façon dont de vrais courriels sont livrés. Faites-en une, surveillez vos rapports DMARC une semaine ou deux, puis passez à la suivante.

1. Dressez la liste de chaque outil qui envoie au nom de votre domaine. Personne n'a cette liste. C'est normal, et c'est le premier vrai problème.
2. Comptez vos requêtes SPF. Si vous approchez de 10, un seul changement chez un fournisseur peut briser les courriels de tout le monde.
3. Déplacez les outils que vous ne contrôlez pas vers des sous-domaines, un chacun, avec leurs propres SPF, DKIM et DMARC. Commencez par celui qui envoie le plus, habituellement l'infolettre.
4. Envoyez un vrai message de chaque outil à un outil de vérification. Confirmez que le From: et la signature DKIM sont tous les deux sur le sous-domaine.
5. Faites le ménage du domaine principal. Retirez les anciens include: et les anciennes clés DKIM, y compris ceux des outils abandonnés.
6. Ensuite, appliquez DMARC sur le domaine principal.
7. Seulement à la toute fin, et seulement si les rapports sont propres, envisagez le mode strict (adkim=s). Lisez d'abord l'avertissement ci-dessus. Si quoi que ce soit dans vos rapports réussit encore grâce à une signature de sous-domaine ou à une adresse de retour sur un sous-domaine, laissez le mode strict désactivé.

La version sans mal de tête

Si vous avez sauté directement ici, bienvenue. Mettez la bouilloire en marche. Voici tout ce qui compte, en trois lignes :

1. Chaque outil qui envoie au nom de votre domaine partage la même réputation. Un seul outil mal utilisé ou mal configuré peut nuire à tous vos courriels, y compris ceux de vos employés.
2. Donnez à chaque outil externe son propre sous-domaine, comme infolettre.votrenom.com, autant pour l'adresse que les gens voient que pour la signature DKIM. Ça ne vous rendra pas invulnérable, mais une erreur reste dans un coin au lieu de se répandre partout.
3. Allez-y lentement. Changez une chose à la fois, surveillez vos rapports DMARC, et ne touchez pas au mode strict (adkim=s) à moins de savoir exactement ce qui envoie en votre nom.

Le reste de l'article, c'est le pourquoi. Vous pourrez y revenir un jour où il y aura plus de café.

Faites-le suivre

Quelqu'un dans votre organisation s'apprête à brancher un nouvel outil « pour envoyer au nom de notre domaine, ça prend cinq minutes ». Envoyez-lui ceci d'abord.

Vérifiez votre domaine gratuitement. Si vous ne savez pas quels outils envoient en votre nom, la Carte des sources d'envoi teste chacun d'eux et vous guide dans la correction de ceux qui échouent : 99 $ CA, paiement unique, jusqu'à 10 sources.