Expéditeurs inconnus dans les rapports DMARC : comment les identifier

Vos premiers rapports DMARC contiennent presque toujours une surprise : une adresse IP que vous ne reconnaissez pas, qui envoie des milliers de messages avec votre domaine dans la ligne From. Parfois, c'est un outil que votre équipe commerciale a adopté au printemps dernier. Parfois, c'est un service de transfert. Plus rarement, c'est quelqu'un qui usurpe votre identité. Ce guide vous donne une méthode reproductible pour identifier chaque source inconnue, la classer dans une catégorie et décider quoi faire, sans deviner et sans casser le courrier légitime.

La réponse en bref#

Pour identifier un expéditeur inconnu dans un rapport DMARC, prenez son IP source et passez quatre vérifications dans l'ordre : le nom DNS inverse (PTR) de l'IP, la présence ou non de l'IP dans un include SPF que vous ou un fournisseur publiez, le domaine de la signature DKIM (d=) lu dans le rapport brut, et le propriétaire du bloc d'IP via une recherche auprès du registre. Classez ensuite la source : service oublié, votre propre serveur ou script, transfert, fournisseur de messagerie de vos collaborateurs, ou usurpateur. Authentifiez les sources légitimes, ignorez la plupart des transferts et laissez p=reject s'occuper de l'usurpateur. Ne bloquez et ne « réparez » jamais une source avant de savoir à quel groupe elle appartient. L'outil gratuit de recherche DNS inverse couvre la première étape, et l'analyseur gratuit de rapports DMARC vous permet d'inspecter les champs bruts d'un rapport isolé.

Partez de ce que le rapport vous dit déjà#

Avant de chercher quoi que ce soit, rassemblez tout ce que la ligne vous donne. Pour chaque IP inconnue, notez :

• L'adresse IP et le nombre de messages envoyés.
• Les résultats SPF et DKIM, et si chacun était aligné avec votre domaine From.
• La disposition, c'est-à-dire ce que le destinataire a fait : none, quarantine ou reject.
• Les domaines utilisés dans les contrôles SPF et DKIM bruts, si vous pouvez voir le XML brut.

Ce dernier point est plus utile qu'il n'y paraît. Une ligne où DKIM a réussi avec d=example.com signifie que l'expéditeur signe avec une clé publiée sous votre domaine : vous, ou un fournisseur que vous avez configuré, l'avez mise en place. Une ligne où DKIM a réussi avec d=vendor.example.net et où SPF a réussi pour le domaine de rebond du fournisseur signifie que le fournisseur envoie du courrier authentifié pour lui-même, avec votre domaine seulement dans la ligne From. C'est le cas classique de l'expéditeur tiers non aligné. Une ligne où SPF et DKIM ont tous deux échoué ou sont absents pointe beaucoup plus nettement vers une usurpation ou un relais non configuré.

Si votre outil de surveillance affiche déjà un nom lisible pour la source, prenez-le comme un indice, pas comme une preuve. Ces noms sont déduits de motifs de DNS inverse, et vous devez quand même confirmer avec les étapes ci-dessous.

Étape 1 : consultez le nom DNS inverse#

La plupart des expéditeurs légitimes publient un enregistrement PTR pour leurs IP d'envoi. Lancez une recherche inverse :

dig -x 203.0.113.42 +short
mail-42.sendingplatform.example.net.

Le nom d'hôte désigne souvent directement le service. Deux précautions :

• Confirmez-le dans le sens direct. Cherchez l'enregistrement A de ce nom d'hôte et vérifiez qu'il renvoie la même IP. Un enregistrement PTR est contrôlé par le propriétaire de l'IP : n'importe qui peut donc revendiquer n'importe quel nom. Seul un nom qui se résout vers la même IP mérite votre confiance.
• Un PTR absent ou générique est lui-même une information. Des noms d'hôte comme static-203-0-113-42.hosting.example désignent généralement un serveur loué ou une ligne résidentielle, pas une plateforme d'envoi. Cela correspond mieux à un usurpateur ou à un script auto-hébergé qu'à un fournisseur sérieux.

Vous pouvez faire cette recherche en un clic avec l'outil de recherche DNS inverse si vous n'avez pas de terminal sous la main.

Étape 2 : vérifiez si l'IP fait partie de votre périmètre SPF#

Regardez votre propre enregistrement SPF et voyez si cette IP est couverte, directement ou via un include :

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendingplatform.example.net ~all"

Si le nom du fournisseur trouvé à l'étape 1 figure déjà dans un include:, quelqu'un l'a autorisé à un moment donné. La source est la vôtre, et la question ouverte est de savoir pourquoi l'alignement échoue. C'est généralement parce que le SPF du fournisseur réussit pour son propre domaine de rebond, qui ne s'aligne pas avec votre domaine From, et qu'aucune signature DKIM pour votre domaine n'a jamais été configurée. La correction se fait côté DKIM, comme expliqué dans les échecs d'alignement DMARC.

Si l'IP n'est pas couverte et que le PTR pointe vers un fournisseur dont vous n'avez jamais entendu parler, vous avez soit un service oublié, soit un inconnu. Continuez. Vous pouvez aussi passer le domaine dans le vérificateur SPF, DKIM et DMARC pour voir ce que contient votre enregistrement SPF aujourd'hui.

Étape 3 : lisez le domaine de signature DKIM#

Quand le rapport brut indique un résultat DKIM, il nomme le domaine de signature et le sélecteur. Trois cas sont fréquents :

• d= est votre domaine. Un système interne ou un fournisseur que vous avez configuré signe avec votre clé. Retrouvez le sélecteur dans votre DNS pour savoir de quelle clé il s'agit. Si vous ne reconnaissez pas le sélecteur, consultez comment trouver un sélecteur DKIM.
• d= est le domaine du fournisseur. Authentifié pour le fournisseur, pas pour vous. Réparable dès que vous avez identifié le fournisseur.
• Aucun résultat DKIM. L'expéditeur ne signe pas. Les petits scripts, les imprimantes, les vieux plugins de CMS et les usurpateurs ont tous cette allure.

Si vous n'avez qu'un en-tête d'un message reçu et non un rapport, l'analyseur d'en-têtes d'e-mail montre le verdict DKIM et la présence éventuelle d'une signature, et vous lisez vous-même le domaine d= sur la ligne DKIM-Signature.

Étape 4 : trouvez le propriétaire du bloc d'IP#

Si le PTR est absent ou peu utile, interrogez le registre Internet régional pour cette adresse (recherche WHOIS ou RDAP). Le résultat nomme l'organisation qui détient le bloc, souvent un hébergeur ou un fournisseur de cloud. Cela vous dit d'où vient le trafic, pas qui en est responsable : servez-vous-en pour restreindre la recherche, pas pour accuser quiconque. Un bloc appartenant à une plateforme d'e-mailing connue renforce l'hypothèse du « fournisseur oublié ». Un bloc appartenant à un hébergeur low-cost sans DNS inverse va dans l'autre sens.

Classez la source, puis agissez#

Après ces quatre vérifications, la plupart des sources tombent dans l'un des cinq groupes.

Le piège à éviter est de traiter tout ce qui est inconnu comme un usurpateur. Durcir votre politique alors qu'un outil de facturation oublié échoue encore à l'alignement, c'est ainsi qu'une entreprise finit par rejeter ses propres factures. Triez d'abord. L'ordre sûr du durcissement est expliqué dans le passage de p=none à p=reject.

Rendez l'identification moins coûteuse la prochaine fois#

Le premier passage est lent. Ensuite, il ne devrait plus l'être. Quelques habitudes aident :

• Tenez un inventaire. Une ligne par source légitime, avec le responsable, le type de courrier et la façon dont elle s'authentifie. La surveillance DMARC présente un tableur simple.
• Exigez une demande avant le lancement d'un nouvel outil. Une courte étape de validation (« cet outil envoie-t-il avec notre domaine ? ») évite la plupart des sources inconnues.
• Revérifiez les anciens comptes. Les essais gratuits et les outils d'agence laissés actifs sont une source fréquente d'expéditeurs surprises.
• Consignez les décisions. Quand vous décidez qu'une source relève du bruit de transfert, écrivez-le pour que le prochain relecteur ne refasse pas l'enquête.

Le module Rapports DMARC vous aide pour la partie nommage. Il résout le DNS inverse de chaque IP source et reconnaît environ 25 expéditeurs courants, comme Google, Microsoft 365, Amazon SES, SendGrid et Mailchimp. Tout ce qu'il ne reconnaît pas apparaît sous le nom d'hôte brut ou sous « Unknown sender ». Il ne permet pas d'étiqueter, de nommer ou de mettre une source en liste d'autorisation : votre tableur d'inventaire reste donc la référence. Il n'affiche pas non plus le domaine ni le sélecteur de signature DKIM d'une source, de sorte que l'étape 3 demande un rapport brut ou l'en-tête d'un message reçu ; si vous voulez les fichiers bruts, gardez une adresse de boîte aux lettres en plus dans votre liste rua=.

Et si la source est un usurpateur ?#

Si les éléments montrent que la source n'a rien à voir avec vous, il y a peu à réparer. Votre rôle est de faire en sorte que l'échec ait des conséquences. Avec une politique reject et un courrier légitime authentifié, les destinataires qui respectent DMARC rejetteront ou mettront en spam les messages usurpés. Vous ne pouvez pas empêcher un usurpateur d'envoyer. Vous pouvez seulement faire échouer son courrier là où les destinataires appliquent votre politique.

Quelques mesures supplémentaires sont raisonnables :

• Notez le volume et les dates pour pouvoir comparer avec les semaines suivantes.
• Vérifiez l'IP d'envoi dans les listes de blocage publiques avec le vérificateur de listes noires.
• Si la campagne est importante et vise vos clients, indiquez à votre équipe support à quoi ressemblent les messages.

Les rapports des petits destinataires qui n'envoient pas de données agrégées ne vous montreront jamais l'ampleur complète : ne prenez donc pas une semaine calme pour la fin d'une campagne d'abus.

Identifier qui envoie avec votre domaine n'est que la moitié de l'hygiène e-mail ; l'autre moitié, c'est la liste à laquelle vous écrivez. L'offre gratuite de la page des tarifs vous donne 100 crédits pour lancer la vérification complète sur une liste, et le vérificateur d'e-mails gratuit couvre les adresses isolées. Une authentification propre a quand même besoin d'une liste saine pour atteindre la boîte de réception.