Rapports DMARC pour les domaines de prospection : lire les rapports RUA en toute sécurité

Ce que résout le reporting DMARC pour les domaines de prospection

DMARC est une règle que votre domaine publie pour indiquer aux boîtes deux choses : qui est autorisé à envoyer du courrier au nom de votre domaine, et que faire quand un message semble faux. Il s’appuie sur SPF et DKIM, mais ajoute une idée supplémentaire importante pour la prospection : l’alignement.

L’alignement signifie que l’adresse From visible doit correspondre au domaine qui a passé SPF ou DKIM.

Les domaines de prospection sont des cibles intéressantes parce qu’ils envoient beaucoup de mails et paraissent souvent récents aux filtres. Cela les rend utiles pour les escrocs qui veulent usurper votre marque, envoyer de fausses factures ou lancer du phishing. Si quelqu’un usurpe votre domaine de prospection, votre délivrabilité et votre réputation peuvent en souffrir même si vous n’avez rien fait de mal.

Le reporting DMARC vous aide à voir cela tôt. Quand vous ajoutez un enregistrement DMARC avec une adresse rua, les principaux destinataires vous envoient des rapports agrégés. Ces rapports n’incluent pas le contenu des messages. Ce sont des synthèses montrant d’où viennent les mails qui prétendent provenir de votre domaine, et s’ils ont passé SPF/DKIM et l’alignement.

Les rapports RUA indiquent en général :

• Quelles sources envoient en utilisant votre domaine (votre ESP, votre CRM, serveurs inconnus)
• Taux de passage ou d’échec pour SPF, DKIM et l’alignement DMARC
• Schémas de volume (par ex. un pic soudain depuis un pays ou un fournisseur que vous n’utilisez pas)
• Alerte précoce que votre domaine est usurpé

Ils ne montrent pas le corps du mail, l’objet ou la personne ciblée. Pensez aux RUA comme des caméras de circulation, pas comme des enregistrements complets.

Une peur courante est de casser l’envoi quand on durcit la politique. Cela ressemble souvent à des campagnes légitimes qui atterrissent en spam ou sont rejetées parce que SPF ou DKIM passent mais ne sont pas alignés avec le domaine From, ou parce que des messages sont transférés et que SPF échoue en chemin. Exemple réel : votre outil de séquences envoie correctement, mais les réponses ou le tracking passent par un autre domaine et l’alignement échoue silencieusement.

Si vous utilisez une plateforme comme LeadTrain qui configure SPF/DKIM/DMARC en coulisses, les rapports RUA restent importants. Ils prouvent que tout est aligné avant de sortir de la phase de surveillance.

Le minimum à connaître : SPF, DKIM, alignement

Pour comprendre les rapports DMARC, il suffit de trois idées : SPF, DKIM et l’alignement. Elles répondent : cet expéditeur est-il autorisé, le message a-t-il été altéré, et les identités correspondent-elles ?

SPF est une liste d’autorisation. Il indique quels serveurs peuvent envoyer au nom d’un domaine.

DKIM est un contrôle d’intégrité. Le serveur d’envoi ajoute une signature cryptographique que le destinataire peut vérifier. Si le message est modifié en transit, DKIM peut échouer.

DMARC est la règle et le tableau de score. Il dit aux destinataires quoi faire si les vérifications échouent (monitorer, mettre en quarantaine, rejeter) et où envoyer les rapports.

Ce que signifie l’alignement (et pourquoi ça compte)

L’alignement signifie que le domaine visible dans le From correspond au domaine qui a passé SPF ou DKIM. C’est ce qui empêche les usurpations simples. Si votre From indique outreach.example mais que SPF passe pour un autre domaine, DMARC peut échouer parce que les identités ne correspondent pas.

Une façon simple de s’en souvenir :

• SPF vérifie l’expéditeur d’enveloppe et ses serveurs autorisés.
• DKIM vérifie le domaine de signature qui a signé le message.
• DMARC vérifie si le domaine SPF ou DKIM qui a réussi s’aligne avec le domaine visible dans le From.

Comment on peut réussir une vérification et quand même échouer DMARC

Vous pouvez réussir SPF mais échouer DMARC si SPF passe pour un domaine de retour (return-path) possédé par votre fournisseur, pas pour votre domaine From. Cela arrive souvent avec le forwarding et certains systèmes de tracking.

Vous pouvez réussir DKIM mais échouer DMARC si la signature DKIM utilise un domaine différent, ou si un système modifie le message et casse la signature.

Les outils de cold email envoient soit via leur propre infrastructure, soit en se connectant à la vôtre. Dans les deux cas, vous voulez qu’ils signent en DKIM pour votre domaine de prospection et envoient de façon à maintenir l’alignement SPF ou DKIM. Des plateformes comme LeadTrain réduisent les surprises où l’envoi semble OK mais DMARC échoue en centralisant la configuration d’authentification.

Qu’est-ce qu’un rapport RUA DMARC et quoi surveiller

Un rapport RUA DMARC est un résumé agrégé que les fournisseurs envoient au sujet des mails prétendant venir de votre domaine. Il n’affiche pas le contenu complet. Il montre plutôt ce qu’ils ont vu à grande échelle : qui a envoyé du courrier en utilisant votre domaine, comment l’authentification s’est comportée et quelle proportion a passé ou échoué.

Vous verrez parfois RUF mentionné. RUF est un rapport médico-légal plus proche d’un échantillon individuel. Beaucoup de fournisseurs n’envoient plus de RUF pour des raisons de confidentialité. Pour la plupart des domaines de prospection, RUA suffit : il permet de repérer l’usurpation, les outils mal configurés et de décider quand passer de la surveillance à l’application.

La plupart des RUA arrivent en XML et peuvent sembler confus parce qu’un fichier peut contenir plusieurs sources d’envoi, plusieurs IP et plusieurs résultats. Si plus d’un outil envoie pour votre domaine (CRM, calendrier, helpdesk, plateforme d’outreach), le rapport les mélange. Même pour un domaine dédié à la prospection, vous verrez souvent plusieurs IP car les fournisseurs font tourner leur infrastructure.

Un rapport typique inclut :

• L’IP source, le fournisseur destinataire et la fenêtre temporelle
• Le volume de messages (combien de messages vus depuis cette IP)
• Le résultat SPF et quel domaine a passé SPF
• Le résultat DKIM et quel domaine a signé DKIM
• Le résultat DMARC (pass ou fail) basé sur l’alignement

Commencez par deux signaux : le volume et l’alignement. Pour un domaine dédié à la prospection, c’est bon signe quand la majorité du volume provient d’un système d’envoi attendu, et que DMARC passe parce que SPF ou DKIM s’aligne (idéalement DKIM).

Exemple : vous configurez un domaine uniquement pour la prospection et envoyez via une seule plateforme. Dans les RUA, vous devriez reconnaître les IP principales d’envoi, voir un DKIM passe cohérent avec votre domaine, et très peu (ou aucun) IP inattendue. Si vous utilisez une plateforme comme LeadTrain où l’infrastructure d’envoi est isolée par client, les sources restent souvent stables, ce qui rend les anomalies plus faciles à repérer.

Comment lire les rapports RUA pas à pas (sans vous perdre)

Un rapport RUA est essentiellement un reçu quotidien des fournisseurs de boîtes. Il montre qui a envoyé du courrier prétendant venir de votre domaine, depuis quelles IP, et si SPF, DKIM et DMARC ont passé.

1) Commencez par le volume

Regardez d’abord les comptes les plus élevés. Une source peut représenter 90 % de votre trafic. Corriger un problème à fort volume a souvent le plus d’impact sur la délivrabilité.

Dans les setups de prospection, les principales sources sont souvent votre outil de cold email, un fournisseur de boîte, et parfois un outil de support ou un CRM.

2) Vérifiez SPF et DKIM, puis le résultat DMARC

Pour chaque source à fort volume, vérifiez :

• SPF passe ou échoue (et quel domaine a authentifié)
• DKIM passe ou échoue (et quel domaine a signé)
• DMARC passe ou échoue (la décision finale)

Raccourci : si DMARC échoue alors que SPF ou DKIM passe, vous avez souvent un problème d’alignement, pas une panne d’envoi.

3) Confirmez l’alignement avec votre domaine From

DMARC se soucie du champ From que votre destinataire voit. Confirmez que l’identifiant authentifié (domaine SPF ou domaine de signature DKIM) correspond ou s’aligne avec ce domaine From. Le misalignment est fréquent lorsque l’outil envoie en utilisant son propre domaine ou un sous-domaine inattendu.

4) Signalez les sources inconnues et catégorisez-les

Scannez les IP, vendeurs ou régions que vous ne reconnaissez pas. C’est là que le reporting est le plus utile : il met en lumière l’usurpation et les outils oubliés.

Gardez-le simple :

• Légitime (expéditeur attendu et passe)
• À investiguer (outil connu mais échoue ou est mal aligné)
• Suspect (inconnu ou manifestement en échec)

Après quelques revues, le rapport devient prévisible. Vous ne lisez plus des données brutes : vous vérifiez une courte liste d’expéditeurs que vous utilisez réellement.

Comment repérer l’usurpation et les envois de type lookalike dans les rapports

Les rapports DMARC sont un tableau de score : quels serveurs ont envoyé en prétendant être votre domaine, et si SPF/DKIM étaient alignés. Votre objectif est de séparer les expéditeurs attendus de ceux qui se font passer pour vous.

Commencez par lister les sources légitimes que vous vous attendez à voir : votre expéditeur cold email, votre fournisseur de boîte et tout outil support/CRM qui envoie en votre nom (tickets, notifications, réinitialisations de mot de passe). Si vous utilisez LeadTrain plus un fournisseur de boîte, ces sources devraient revenir régulièrement, avec un volume stable et des résultats majoritairement pass.

Signes rouges qui signifient souvent une usurpation (ou un lookalike)

• Fort taux d’échec DMARC (surtout quand SPF et DKIM échouent)
• Réseaux d’hébergement ou régions que vous n’utilisez jamais, parfois répartis sur de nombreuses IP
• Pics soudains de volume pour une source inconnue
• Beaucoup d’adresses From différentes sous votre domaine sur une courte période
• Échecs persistants alors que vous n’avez rien changé dans le DNS

L’usurpation vs la mauvaise configuration se différencient surtout par la cohérence. La mauvaise configuration vient généralement d’un service connu et échoue de façon répétable (ex. DKIM passe mais n’est pas aligné). L’usurpation paraît souvent désordonnée : IP inconnues, les deux contrôles échouent, et aucun schéma correspondant à un outil réel.

Quand traiter un expéditeur comme suspect même à faible volume

Les attaquants testent souvent discrètement. Considérez une IP comme suspecte si elle est inconnue et présente l’un de ces signes :

• SPF et DKIM échouent tous les deux
• Le header-from est votre domaine mais les domaines authentifiés sont sans rapport
• Elle apparaît une ou deux fois depuis un réseau aléatoire avec 100 % d’échecs

Exemple : si une nouvelle IP envoie trois messages qui échouent SPF et DKIM tout en prétendant être votre domaine de prospection, c’est rarement une petite erreur de configuration. C’est souvent une sonde ou une petite tentative d’usurpation.

Les raisons les plus courantes pour lesquelles DMARC échoue sur des mails légitimes

La plupart des échecs DMARC dans les RUA ne sont pas des attaques. Ce sont des sources légitimes qui manquent un détail.

Désalignement : le From ne correspond pas à ce qui est authentifié

C’est la cause la plus courante. Votre email peut passer SPF ou DKIM et pourtant échouer DMARC si le domaine authentifié ne s’aligne pas avec le domaine visible dans le From.

Exemple : vous envoyez en tant que [email protected], mais l’outil signe DKIM pour vendor-mail.example ou utilise un return-path SPF sur un domaine différent. La correction consiste généralement à choisir le bon domaine d’envoi chez le fournisseur et à s’assurer que DKIM est configuré pour le même domaine affiché en From.

Problèmes DKIM : sélecteur manquant, clé erronée ou configuration incomplète

Les échecs DKIM proviennent souvent d’erreurs de configuration : sélecteur incorrect, enregistrement DNS manquant, ou une boîte/fournisseur jamais finalisé. Si vous voyez une source reconnue échouer DKIM de façon récurrente alors que SPF est mixte, cela pointe vers un souci DNS DKIM.

Problèmes SPF : expéditeurs manquants et trop de recherches

SPF peut échouer parce qu’un expéditeur manque, ou parce que la limite de recherches DNS (10) est dépassée. Trop de recherches signifie généralement que l’enregistrement SPF a trop d’include et de redirections, si bien que les récepteurs arrêtent l’évaluation et traitent cela comme un échec.

Les transferts et mailing lists déclenchent des faux positifs

Le forwarding et les listes de diffusion cassent souvent SPF parce que le forwarder devient la nouvelle IP d’envoi. DKIM peut survivre au forwarding, mais certaines listes réécrivent les messages et cassent DKIM aussi.

Trop d’outils et pas de propriétaire clair

Si plusieurs outils envoient depuis un même domaine, les rapports deviennent vite brouillés. Gardez un inventaire simple et assignez un responsable pour chaque expéditeur. Si vos SDR utilisent LeadTrain pour la prospection mais que le marketing envoie depuis le même domaine via un autre outil, vous verrez plusieurs domaines DKIM. Ce n’est pas toujours incorrect, mais cela doit s’aligner avec le domaine visible en From.

Passer de la surveillance à l’application en toute sécurité

L’objectif est simple : bloquer l’usurpation sans bloquer les envois réels.

Commencez par p=none et considérez-le comme une période de référence, pas comme l’étape finale. Laissez-lui le temps de capturer les schémas normaux (jours ouvrés vs week-ends, nouvelles séquences, mails de fournisseurs). Si le volume de prospection augmente rapidement, prolongez la période jusqu’à stabilisation.

Avant de durcir la politique, corrigez les sources légitimes. Pour le cold email, cela signifie généralement vous assurer que votre outil signe en DKIM pour le même domaine utilisé en From, et que SPF ne casse pas parce que le mail circule via un autre service. Si SPF ou DKIM passe et s’aligne, DMARC peut passer.

Un déploiement sécurisé ressemble souvent à ceci :

• Gardez p=none jusqu’à ce que les seuls échecs soient clairement des sources indésirables
• Mettez p=quarantine avec un petit pct (par ex. 10–25)
• Augmentez le pct étape par étape en surveillant rebonds, réponses et plaintes
• Passez à p=reject uniquement lorsque vous êtes sûr que les échecs restants sont de l’usurpation

La quarantaine est une étape utile pour les domaines de prospection car elle met la pression sur les usurpateurs tout en vous laissant du temps pour attraper les surprises.

Ayez toujours un plan de retour en arrière. Le premier signe de problème est souvent discret : moins de réponses, pas un message d’erreur bruyant. Si le volume chute après un changement de politique, revenez en arrière dans cet ordre :

• Réduire pct au niveau précédent
• Passer temporairement de p=quarantine à p=none
• Re-vérifier le sélecteur DKIM et l’alignement pour votre expéditeur de prospection
• Vérifier que SPF inclut le vrai service d’envoi (et qu’il ne casse pas à cause d’un trop grand nombre de recherches)

Même si une plateforme comme LeadTrain configure SPF/DKIM/DMARC et chauffe les boîtes, l’application gagne à être montée progressivement. Utilisez les rapports pour confirmer que seules les mauvaises sources sont impactées.

Erreurs qui causent des problèmes de délivrabilité lors de l’application

C’est lors de l’application que de bonnes intentions peuvent bloquer des envois légitimes. Le reporting est le plus utile ici car il vous indique quels expéditeurs seraient affectés avant le changement de politique.

Activer p=reject trop tôt est l’erreur la plus courante. Si même un expéditeur légitime échoue l’alignement, vous pouvez bloquer des réinitialisations de mot de passe, factures, invitations calendaires ou séquences de prospection du jour au lendemain.

Une autre erreur fréquente est de penser que SPF suffit. SPF peut passer tandis que DMARC échoue, notamment avec le forwarding ou des From mal alignés. Pour la prospection, DKIM aligné est généralement la base la plus stable.

Les sous-domaines peuvent aussi vous piéger. Vous pourriez appliquer une politique sur le domaine racine alors que la prospection part d’un sous-domaine, ou un fournisseur utilise un sous-domaine que vous n’aviez pas remarqué. Définissez clairement la portée de la politique.

Les petites sources comptent aussi. Quelques messages échouant par jour depuis un outil de helpdesk ou un plugin de formulaire peuvent devenir des milliers plus tard. Corrigez-les tant qu’ils sont encore petits.

Si possible, n’appliquez pas DMARC d’entrée sur votre domaine marque principal. Séparez les domaines de prospection du domaine principal pour qu’une erreur n’impacte pas les mails critiques.

Checklist rapide RUA avant de changer la politique

Avant de sortir de la surveillance, utilisez les RUA pour confirmer que les envois réels sont propres et prévisibles. Passez en revue les 7 à 14 derniers jours et comparez à la période précédente pour détecter des tendances, pas des bruits isolés.

• Confirmer que chaque système légitime signe en DKIM d’une manière alignée avec votre domaine From
• Pour chaque source légitime, vérifier au moins une voie alignée : SPF aligné ou DKIM aligné
• Scanner les IP ou services inconnus ayant un volume significatif
• Chercher des pics d’échecs semaine après semaine
• Utiliser un ramp safety avec pct avant de changer p

Règle pratique : si les sources légitimes passent avec alignement et que les échecs sont majoritairement petits et aléatoires, vous pouvez tester p=quarantine avec un pct bas. Si un expéditeur légitime échoue de façon répétée, corrigez-le d’abord.

Si vous utilisez une solution tout-en-un comme LeadTrain pour acheter des domaines, configurer l’authentification, chauffer les boîtes et exécuter des séquences, la liste d’expéditeurs légitimes est souvent plus courte, ce qui accélère la revue.

Exemple : un domaine de prospection qui monte en charge sans casser les envois

Une équipe lance un nouveau domaine de prospection pour le cold email. Elle a deux boîtes (alex@ et sam@) et envoie via un fournisseur unique (par exemple, AWS SES via une plateforme comme LeadTrain). Ils commencent avec DMARC réglé sur p=none pour que rien ne soit bloqué pendant l’observation.

La première semaine, les rapports montrent en général quelques catégories claires :

• IP d’envoi réelles passant SPF et DKIM
• Du mail transféré (souvent SPF échoue, DKIM passe)
• Bruit de fond aléatoire : sources essayant d’envoyer comme le domaine

Le jour 3, l’équipe remarque un petit pic : 15 messages depuis une plage IP inconnue prétendant venir de leur domaine. SPF échoue, DKIM est absent et l’alignement échoue. Ils vérifient que ce n’est pas leur outil en croisant les horodatages avec leurs envois et constatent que le trafic légitime vient uniquement des sources attendues.

Ils trouvent aussi un problème légitime : DKIM passe mais l’alignement échoue parce que la valeur d= est un sous-domaine qui ne correspond pas au From utilisé pour la prospection. Ils corrigent en signant avec le même domaine affiché en From (ou en changeant le From pour correspondre au domaine de signature), puis attendent 48 heures pour les nouveaux rapports.

Quand les rapports montrent des passages stables, ils durcissent progressivement en jouant sur pct. Ils passent à p=quarantine avec pct=25 quelques jours, puis 50, puis 100. Ce n’est qu’après une période propre qu’ils envisagent p=reject.

Le succès est ennuyeux : le mail légitime passe via DKIM aligné ou SPF aligné, les sources d’usurpation continuent d’échouer et se retrouvent en quarantaine ou rejetées, et le volume d’IP inconnues tend vers zéro.

Étapes suivantes : instaurer une routine, puis simplifier la configuration des domaines

La façon la plus rapide d’extraire de la valeur du reporting DMARC est d’en faire une routine. Choisissez un domaine de prospection à standardiser en premier et listez tous les outils autorisés à envoyer pour lui (plateforme de cold email, fournisseur de boîte, CRM, helpdesk, outil calendrier). Cela garde les rapports lisibles et empêche des sources mystères d’apparaître.

Mettez en place un rythme de revue que vous pourrez tenir. Hebdomadaire est un bon départ. Lors de la revue, vous vérifiez surtout l’apparition de nouveaux expéditeurs inconnus, des pics de volume et tout expéditeur légitime échouant l’alignement.

Tenez une liste d’expéditeurs approuvés, mais sans la sur-complexifier. Pour la plupart des équipes, trois champs suffisent : nom de l’outil, ce qu’il envoie, et si vous attendez un SPF aligné ou un DKIM aligné.

Si vous voulez moins d’éléments mouvants, réduisez le nombre de systèmes pouvant envoyer au nom du domaine. Une configuration unifiée comme LeadTrain aide en achetant et configurant les domaines, en gérant SPF/DKIM/DMARC, en chauffant les boîtes et en exécutant les séquences au même endroit, de sorte que vos rapports reflètent un plus petit ensemble de sources légitimes.

L’objectif reste le même : moins d’expéditeurs, moins de surprises et une politique que vous pouvez durcir sans casser les envois réels.