7 expéditeurs tiers qui enfreignent fréquemment les règles DMARC (et comment authentifier chacun d'entre eux)

La plupart des entreprises envoient des e-mails à partir d’un nombre de systèmes bien plus important que leur simple serveur de messagerie. Les plateformes marketing, les CRM, les services d’assistance, les outils de facturation et une liste toujours plus longue d’assistants IA envoient tous des messages dont l’adresse d’expéditeur comporte votre domaine. Chacun de ces systèmes constitue un expéditeur tiers et représente un point où les protocoles SPF, DKIM et DMARC peuvent échouer sans que personne ne s’en aperçoive.

Les échecs ont désormais davantage d'importance. Gmail, Yahoo et Outlook.com exigent que les expéditeurs envoyant plus de 5 000 messages par jour s'authentifient via SPF, DKIM et DMARC, et que ces éléments correspondent au domaine « De » ; dans le cas contraire, ils peuvent rejeter purement et simplement les envois en masse non conformes. En dessous de ce volume, un message qui échoue au contrôle DMARC a plus de chances d'atterrir dans le dossier spam, et il n'arrivera tout simplement pas à destination si vous adoptez une politique de rejet.

Ce guide présente sept catégories d'expéditeurs tiers, explique comment chacun d'entre eux enfreint généralement les règles DMARC et détaille les étapes à suivre pour les authentifier. Il se termine par des exemples d'enregistrements DNS, une méthode de vérification et un plan de mise en œuvre.

Pourquoi les expéditeurs tiers contournent le protocole DMARC

Le DMARC est considéré comme valide dès lors qu'au moins l'un des protocoles suivants : SPF ou DKIM est valide et qu'il correspond au domaine figurant dans l'adresse « De » visible. C'est justement cette correspondance que beaucoup de gens négligent.

• SPF alignement compare le domaine figurant dans le champ « return-path » (également appelé « expéditeur de l’enveloppe » ou « adresse de rebond ») avec le domaine « De ». Les fournisseurs utilisent généralement leur propre domaine de rebond ; ainsi, SPF est valide pour eux, mais ne correspond pas au vôtre.
• Alignement DKIM compare le domaine signataire figurant dans la signature DKIM (la valeur « d= ») avec le domaine « De ». Par défaut, les fournisseurs signent généralement avec leur propre domaine ; la validation DKIM est donc réussie, mais l'alignement échoue.
• Erreurs de configuration perturbent le reste. Les erreurs courantes sont notamment plus de 10 requêtes DNS dans SPF, plusieurs enregistrements SPF sur un domaine, des enregistrements DKIM manquants et des enregistrements laissés par des fournisseurs que vous n'utilisez plus.

Avec l'alignement « assoupli » (réglage par défaut), un sous-domaine s'aligne sur le domaine organisationnel parent. L'alignement « strict » exige une correspondance exacte. Étant donné que les signatures DKIM sont généralement conservées lors du transfert, contrairement à l'SPF , la plupart des équipes visent un alignement DKIM pour chaque expéditeur tiers.

Les Sept Expéditeurs en bref

1. Prise de notes et assistance aux réunions grâce à l'IA

Les assistants de réunion envoient des résumés, des points d'action, des projets de suivi et partagent des liens, souvent avec des participants extérieurs à votre entreprise. Que votre équipe utilise Fathom ou qu'elle envisage des alternatives à Fathom, demandez au fournisseur comment ses e-mails sont authentifiés avant de connecter une boîte mail ou d’activer l’envoi depuis votre domaine.

Bon nombre de ces outils envoient des e-mails depuis leur propre domaine et affichent votre nom comme nom d’affichage. Cela n’affecte pas vos résultats DMARC, car le domaine figurant dans l’adresse « De » est celui du fournisseur. Les problèmes commencent avec les fonctionnalités qui placent votre domaine dans l’adresse « De » tout en envoyant les e-mails depuis les serveurs du fournisseur, comme les e-mails de suivi qui semblent provenir de vous. Ces messages comportent le chemin de retour et la signature DKIM du fournisseur ; ainsi, les tests « SPF » et DKIM peuvent être validés, même si l’alignement avec votre domaine échoue. Un troisième cas de figure concerne les outils qui envoient les e-mails via votre propre boîte de réception Google ou Microsoft. Ces e-mails sont signés et remis par votre fournisseur de messagerie ; ils sont donc alignés tant que la signature DKIM est activée pour votre domaine sur cette plateforme.

Questions à poser au vendeur :

• Quel nom de domaine apparaît dans le champ « De » des résumés, des invitations et des rappels ?
• Y a-t-il une fonctionnalité qui permet d'envoyer des e-mails depuis les serveurs du fournisseur en utilisant mon domaine dans le champ « De » ?
• Si tel est le cas, puis-je m'authentifier à l'aide d'un DKIM personnalisé et d'un chemin de retour personnalisé sur un sous-domaine ?
• Est-il possible de limiter ou de désactiver l'envoi d'e-mails aux participants externes ?
• Si l'outil envoie des messages via ma boîte mail, quelles autorisations demande-t-il ?

Comment l'authentifier :

• Si le domaine « De » appartient au fournisseur, vous n'avez rien à configurer pour votre DMARC. Concentrez-vous plutôt sur les destinataires des e-mails.
• Si le fournisseur envoie des e-mails depuis votre domaine, ajoutez les enregistrements DKIM et « return-path » indiqués dans sa documentation, de préférence sur un sous-domaine dédié.
• Si l'outil envoie des e-mails via votre boîte de réception, assurez-vous que la signature DKIM est activée pour votre domaine personnalisé dans Google Workspace ou Microsoft 365.
• Envoyez un véritable résumé vers une boîte mail externe et consultez les en-têtes d'authentification avant le déploiement.

2. Plateformes de marketing et de messagerie électronique

Les plateformes marketing génèrent le plus grand volume d’e-mails provenant de tiers, ce qui en fait la source la plus courante de problèmes liés au DMARC. Par défaut, beaucoup d’entre elles signent leurs e-mails avec la clé DKIM du fournisseur et utilisent le domaine de rebond de ce dernier comme chemin de retour. L’ SPF e et le DKIM sont alors validés pour le domaine du fournisseur, mais aucun des deux ne correspond au domaine figurant dans votre adresse « De », ce qui entraîne un échec du DMARC.

Le volume fait monter les enjeux. Gmail, Yahoo et Outlook.com exigent des expéditeurs envoyant plus de 5 000 messages par jour qu’ils s’authentifient via SPF, DKIM et DMARC, et que leur domaine d’expédition corresponde à celui indiqué dans le champ « De ». Les e-mails marketing doivent également proposer une option de désabonnement en un clic et présenter un faible taux de plaintes pour spam. Les e-mails en masse non conformes peuvent être purement et simplement rejetés.

Comment l'authentifier :

• Envoyez vos e-mails depuis un sous-domaine dédié, tel que news.example.com, afin que la réputation marketing et les enregistrements DNS restent distincts de la messagerie d'entreprise.
• Effectuez l'authentification de domaine sur la plateforme. Cela implique généralement d'ajouter des enregistrements DKIM, souvent des enregistrements CNAME, afin que les messages soient signés avec votre domaine, ainsi qu'un domaine de chemin de retour personnalisé si cette option est proposée.
• Publiez l'SPF e là où il faut. Si le chemin de retour est un sous-domaine personnalisé, l'enregistrement « SPF » se trouve sur ce sous-domaine, ce qui permet de garder votre enregistrement racine court.
• Définissez une politique DMARC pour le sous-domaine, soit en ajoutant « sp= » à l'enregistrement parent, soit en créant un enregistrement distinct, puis consultez les rapports agrégés.
• Ajoutez des en-têtes permettant de se désabonner en un clic et surveillez les taux de réclamations.

3. Plateformes de gestion de la relation client (CRM) et d'engagement commercial

Les outils de vente envoient généralement les e-mails de deux manières différentes. Les e-mails individuels envoyés via une boîte mail Google ou Microsoft connectée sont authentifiés par votre fournisseur de messagerie. Les campagnes d'envoi en masse et les options « d'envoi via la plateforme » utilisent les serveurs propres à la plateforme, et celles-ci nécessitent une configuration. Une erreur courante consiste à utiliser une plateforme qui envoie des e-mails depuis les adresses personnelles des utilisateurs sur votre domaine sans aucune configuration DKIM ni chemin de retour.

Ces outils accumulent également les inclusions de type « SPF ». Chaque inclusion entraîne des requêtes DNS, et SPF n'en autorise que 10 par évaluation (RFC 7208). Si cette limite est dépassée, les destinataires considèrent SPF comme une erreur permanente, ce qui entraîne l'échec de la vérification.

Comment l'authentifier :

• Utilisez l'envoi lié à la boîte aux lettres pour vos communications personnalisées.
• Pour les messages envoyés via une plateforme, authentifiez un sous-domaine dédié à l'aide d'un DKIM et d'un chemin de retour personnalisés, et conservez les communications de prospection sur un domaine ou un sous-domaine distinct de celui de la messagerie d'entreprise.
• Vérifiez quels utilisateurs et quelles plateformes sont autorisés à envoyer des e-mails au nom de votre domaine.
• Comptez régulièrement le nombre de requêtes « SPF ». Regroupez ou supprimez les inclusions correspondant aux outils que vous n'utilisez plus, et faites attention à l'aplatissement, car les listes d'IP aplaties deviennent obsolètes lorsque les fournisseurs changent d'adresse.

4. Outils d'assistance et de service client

Les équipes d'assistance souhaitent généralement que les réponses proviennent de l'adresse [email protected]. Cela signifie que les serveurs du service d'assistance envoient des e-mails avec votre domaine dans le champ « De », ce qui nécessite une conformité SPF ou DKIM pour passer le contrôle DMARC. De nombreuses configurations négligent cette étape, car les tickets semblent fonctionner lors des tests : les vérifications effectuées par le fournisseur lui-même sont réussies et la livraison vers une boîte de réception peu stricte aboutit.

Le traitement des messages entrants soulève une deuxième série de problèmes. Le transfert automatique d’une boîte mail d’assistance vers le service d’assistance est simple, mais ce transfert perturbe souvent l’ SPF , car l’adresse IP de l’expéditeur du transfert n’est pas autorisée par l’expéditeur d’origine. Les signatures DKIM peuvent résister au transfert, ce qui explique en partie pourquoi l’alignement DKIM est plus fiable que l’alignement « SPF ».

Comment l'authentifier :

• Ajoutez les enregistrements DKIM du fournisseur afin que les réponses soient signées avec votre domaine, et ajoutez les enregistrements « SPF » ou « return-path » du fournisseur si nécessaire.
• Privilégiez le routage MX ou la méthode de transfert prise en charge par le fournisseur plutôt que les règles de transfert automatique des boîtes aux lettres.
• Testez l'envoi d'une réponse à un ticket vers une boîte mail externe et examinez les en-têtes, puis répétez l'opération pour les messages automatisés, tels que les enquêtes de satisfaction, qui proviennent parfois d'un autre système.
• Supprimez les entrées correspondant aux outils d'assistance que vous n'utilisez plus.

5. Outils de calendrier et de planification

Les outils de planification envoient des invitations, des confirmations et des rappels, généralement au nom d'un organisateur. La plupart effectuent ces envois depuis le domaine du fournisseur, en indiquant votre adresse dans le champ « Répondre à », ce qui n'a aucune incidence sur votre DMARC. Les problèmes proviennent des options personnalisées qui envoient des messages depuis votre domaine sans authentification, ainsi que des e-mails liés au calendrier qui sont envoyés sans signature.

On passe facilement à côté du cas où la signature fait défaut. Si la signature DKIM n'est pas activée pour votre domaine personnalisé dans Microsoft 365, les e-mails sortants sont signés avec le domaine par défaut du locataire, qui ne correspond pas à votre domaine « De ». De même, Google Workspace nécessite que la signature DKIM soit activée pour votre domaine.

Comment l'authentifier :

• Vérifiez quel domaine l'outil utilise dans l'adresse d'expéditeur pour chaque type de message.
• Activez la signature DKIM pour votre domaine personnalisé auprès de votre fournisseur de messagerie, afin que les invitations de calendrier et les messages envoyés depuis votre boîte mail soient cohérents.
• Si vous utilisez une option d'envoi personnalisée, authentifiez-la à l'aide des enregistrements DKIM et « return-path » du fournisseur.
• Vérifiez les e-mails de rappel et d'annulation séparément des invitations.

6. Plateformes de facturation et de paiement

Les factures, les reçus et les rappels de paiement comptent parmi les types d’e-mails les plus souvent utilisés à des fins malveillantes. Les pirates les imitent car les destinataires réagissent rapidement dès qu’il est question d’argent, et une facture falsifiée peut détourner un paiement. Ces plateformes envoient souvent des e-mails depuis leur propre domaine en utilisant le nom de votre entreprise, et elles proposent une option permettant d’envoyer des e-mails depuis [email protected]. Cette option ne fonctionne avec DMARC que lorsque les enregistrements DNS sont correctement configurés.

Les entreprises utilisent souvent plusieurs outils liés à la facturation en parallèle, tels qu'un logiciel de comptabilité, un prestataire de services de paiement et un gestionnaire d'abonnements. Chacun d'entre eux constitue un expéditeur distinct disposant de ses propres données.

Comment l'authentifier :

• Utilisez la fonctionnalité de domaine de messagerie personnalisé de chaque plateforme et publiez les enregistrements DKIM, « SPF » et « return-path » qu'elle fournit.
• Dressez la liste de tous les systèmes qui envoient des courriers de facturation, puis vérifiez que chacun d'entre eux procède à une authentification et à une mise en correspondance.
• Mettez en place une politique de contrôle dès que les rapports indiquent que vos sources légitimes ne sont plus validées. C'est ce qui empêche les pirates d'envoyer des factures qui ressemblent aux vôtres.
• Indiquez à vos clients d'où proviennent vos factures.

7. Systèmes de gestion des ressources humaines, de recrutement et de paie

Les systèmes de gestion des candidatures envoient des e-mails aux candidats depuis des adresses du type careers@ ou jobs@, les plateformes d’intégration envoient des messages de bienvenue et les outils de gestion de la paie envoient des notifications aux salariés. Ces outils sont souvent choisis et configurés par les RH sans l’intervention du service informatique, si bien que personne ne vérifie la configuration DNS. Résultat : les offres d’emploi finissent dans les dossiers de spam et les candidats ne reçoivent pas leurs invitations à des entretiens.

L'usurpation d'identité est également courante ici. Les e-mails frauduleux proposant de faux offres d'emploi et reprenant l'identité visuelle d'une véritable entreprise constituent une tactique bien connue, et la mise en place d'une politique DMARC rend plus difficile leur envoi depuis votre domaine réel.

Comment l'authentifier :

• Intégrez l'évaluation du DNS au processus d'achat d'un logiciel RH.
• Authentifier un sous-domaine dédié aux e-mails de recrutement, à l'aide des enregistrements DKIM et « return-path » fournis par le fournisseur.
• Publiez une liste succincte des adresses officielles relatives au recrutement et à la paie afin que les candidats et les salariés puissent les identifier.
• Vérifiez que les invitations aux entretiens et les e-mails d'offre d'emploi parviennent bien dans les boîtes de réception, y compris celles des fournisseurs de messagerie en ligne gratuits.

Exemples d'enregistrements DNS

Les noms et valeurs exacts proviennent de la page de configuration de chaque fournisseur. Les exemples ci-dessous donnent une idée de ce à quoi s'attendre. Les noms de domaine sont des espaces réservés.

SPF sur le sous-domaine d'envoi (un enregistrement par domaine)
mail.example.com. TXT « v=spf1 include:_spf.vendor.example ~all »

Enregistrements de signature DKIM, généralement fournis sous forme de CNAME:
selector1._domainkey.mail.example.com. CNAME selector1.dkim.vendor.example.
selector2._domainkey.mail.example.com. CNAME selector2.dkim.vendor.example.

Domaine personnalisé pour le chemin de retour (messages rejetés):
bounce.mail.example.com. CNAME return.vendor.example.

Enregistrement DMARC, en mode surveillance
_dmarc.example.com. TXT « v=DMARC1; p=none; rua=mailto:[email protected] » 

Comment vérifier l'identité d'un expéditeur avant la mise en ligne

Envoyez un véritable message depuis le système vers une boîte mail externe, ouvrez le message d'origine et consultez les résultats de l'authentification. Vous devez vous assurer que les vérifications SPF ou DKIM sont validées et que le domaine associé à cette validation correspond au domaine « De ».

Conforme : DMARC validé
spf=pass smtp.mailfrom=bounce.mail.example.com
dkim=pass header.d=mail.example.com
dmarc=pass header.from=mail.example.com

Validé mais non aligné : échec DMARC
spf=pass smtp.mailfrom=bounces.vendor.example
dkim=pass header.d=vendor.example
dmarc=fail header.from=example.com 

Dans le deuxième exemple, les deux vérifications sont réussies, mais pour le domaine du fournisseur. Aucun des deux ne correspond à example.com, ce qui entraîne l'échec de la validation DMARC. C'est là la marque distinctive d'un expéditeur tiers non authentifié.

Un plan de déploiement

1. Faites l'inventaire de vos expéditeurs. Renseignez-vous auprès du service financier sur les abonnements SaaS, passez en revue la liste de vos applications à authentification unique, consultez les pièces jointes de vos e-mails SPF et vérifiez les journaux de messagerie.
2. Publiez un enregistrement DMARC avec p=none et une adresse de rapport. Les rapports agrégés répertorient tous les systèmes envoyant des e-mails au nom de votre domaine, y compris ceux dont personne ne se souvenait.
3. Authentifier chaque expéditeur légitime. Utilisez un DKIM et un chemin de retour personnalisés, et privilégiez les sous-domaines pour les systèmes à fort volume ou à haut risque.
4. Passez à la phase de mise en application. Dès que les rapports indiquent que des e-mails légitimes passent, passez à la phase « quarantine », puis «Reject», en surveillant les rapports à chaque étape.
5. Faites-en une habitude. Ajoutez une vérification d'authentification par e-mail lors de l'intégration d'un fournisseur, et supprimez les enregistrements DNS lorsque vous mettez un outil hors service.

FAQ

Quelle est la différence entre une validation « SPF » ou « DKIM » et une validation DMARC ?

SPF et le DKIM peut valider n'importe quel domaine, y compris celui du fournisseur. Le DMARC impose en outre que le domaine validé corresponde au domaine figurant dans votre adresse « De ».

Dois-je ajouter chaque fournisseur à mon enregistrement « SPF » ?

Pas toujours. Si un fournisseur utilise un chemin de retour personnalisé sur votre sous-domaine et signe avec un DKIM aligné, le DMARC peut être validé sans toucher à votre enregistrement « SPF » racine. Le fait d’utiliser moins d’inclusions vous aide également à rester en dessous de la limite de 10 requêtes.

Dois-je utiliser des sous-domaines pour les expéditeurs tiers ?

Souvent, oui. Un sous-domaine permet de séparer la réputation et les enregistrements DNS, ce qui facilite le suivi et le contrôle de chaque source. N’oubliez pas que les sous-domaines héritent de votre politique DMARC, sauf si vous définissez « sp= » ou publiez un enregistrement distinct.

Combien de temps faut-il pour atteindre p = rejet ?

Cela dépend du nombre d'expéditeurs que vous avez et de la rapidité avec laquelle vous pouvez les corriger. De nombreuses organisations mettent entre plusieurs semaines et quelques mois à le faire, en s'appuyant sur des rapports globaux.

Que faire si un fournisseur ne parvient pas à se connecter à mon domaine ?

Dans ce cas, le protocole DMARC devrait passer par l'alignement « SPF » avec un chemin de retour personnalisé. Si aucune de ces deux options n'est possible, le fournisseur devrait envoyer les e-mails depuis son propre domaine, et non depuis le vôtre.

Le protocole DMARC s'applique-t-il aux e-mails envoyés via Google Workspace ou Microsoft 365 ?

Oui. Assurez-vous que la signature DKIM est bien activée pour votre domaine personnalisé dans cette section, sinon vos e-mails risquent d'être signés avec un domaine par défaut qui ne correspond pas.