Inventorier les expéditeurs tiers d'un domaine : la carte avant DMARC
Par Thomas · RSSI virtuel · 21 août 2026
Tout projet DMARC commence par une illusion : celle de savoir qui envoie des emails au nom du domaine. La réponse spontanée — « le serveur de messagerie », Microsoft 365 ou Google Workspace — est incomplète dans la quasi-totalité des organisations. Une entreprise ordinaire expédie en réalité depuis dix, quinze, parfois trente services distincts : une plateforme marketing, un outil de facturation, un CRM, un SIRH, une solution de supervision, un prestataire de signature électronique. Chacun de ces tiers écrit avec l'adresse de l'organisation, souvent depuis des années, et souvent sans que l'équipe informatique en ait jamais été informée.
Or DMARC ne pardonne pas l'oubli. À p=none, un tiers absent de la carte ne gêne personne ; à p=reject, il devient un flux cassé — des factures qui ne partent plus, des bulletins de paie bloqués, des alertes de supervision rejetées en silence. C'est la première cause d'échec des projets de durcissement, loin devant la difficulté technique : la politique a été appliquée avant que la carte ne soit complète. L'inventaire des expéditeurs tiers est pour cette raison le socle de la liste de l'année, point par point — la carte se dresse avant le voyage, jamais pendant.
Cet article déroule la méthode complète : pourquoi le tiers oublié condamne le projet, quelles familles de services chercher, quelles sources de vérité croiser, comment structurer la carte, et comment la garder vivante une fois p=reject atteint.
Le tiers oublié : la première cause d'échec
Le mécanisme mérite d'être posé clairement. DMARC ne juge pas la légitimité d'un message ; il juge son alignement. Un email passe si SPF ou DKIM valide un domaine aligné avec l'adresse visible de l'expéditeur. Un prestataire parfaitement légitime, sous contrat, payé chaque mois, mais dont personne n'a configuré l'authentification, échoue exactement comme un fraudeur : même verdict, même sort. Le standard n'a aucun moyen de distinguer l'outil de facturation que la comptabilité utilise depuis cinq ans d'une tentative d'usurpation.
L'asymétrie de la découverte aggrave tout. Tant que la politique reste en p=none, l'outil non aligné fonctionne : rien n'alerte personne. Le jour du passage en p=reject, il casse — et il casse en silence. L'équipe informatique ne voit rien : aucun serveur ne lui appartient dans ce flux, aucun journal ne remonte chez elle. Ce sont les métiers qui découvrent l'incident, des jours ou des semaines plus tard : relances clients restées sans effet, candidats sans réponse, alertes de supervision jamais reçues. Le classique du genre est l'outil de facturation branché par la direction financière sans ticket informatique : invisible jusqu'au durcissement, sinistré après. La séquence qui évite ce scénario est décrite dans atteindre p=reject sans casser ses emails ; elle suppose une carte complète — c'est l'objet du reste de cet article.
Les familles d'expéditeurs tiers : bien au-delà du marketing
Le réflexe courant s'arrête à la newsletter. En réalité, les tiers qui envoient au nom d'un domaine se répartissent en une dizaine de familles, et chacune a son angle mort :
- L'emailing marketing. Les plateformes comme Mailchimp ou Brevo sont les mieux identifiées — le marketing sait qu'il envoie. C'est la famille la plus visible, rarement la plus risquée.
- Le transactionnel applicatif. Confirmations de commande, réinitialisations de mot de passe, notifications produit, expédiées via SendGrid, Mailjet ou Amazon SES par les applications maison. Les développeurs le savent ; la sécurité, pas toujours.
- Le CRM et les outils commerciaux. Séquences de prospection, relances, devis envoyés « depuis » l'adresse du commercial par la plateforme, pas par la messagerie.
- Le support client. Chaque réponse à un ticket part du domaine, via l'outil de helpdesk — un volume quotidien considérable et pourtant rarement déclaré.
- La billetterie et l'événementiel. Confirmations d'inscription, rappels, billets : des pics saisonniers qui surgissent dans les rapports sans prévenir.
- Les RH et la paie. SIRH, coffre-fort numérique des bulletins, plateformes de recrutement : des flux peu volumineux mais critiques et chargés de données personnelles.
- La finance. Facturation, relances de paiement, notes de frais — la famille la plus souvent branchée sans ticket informatique.
- La supervision et la sécurité. Alertes d'infrastructure, rapports de sauvegarde : le flux que personne ne veut voir casser un jour d'incident.
- Les imprimeurs et routeurs de courrier hybride. Avis d'expédition et notifications envoyés par des prestataires postaux — la famille que personne ne cite jamais spontanément.
Chaque famille impose sa propre recette d'alignement, et c'est le détail qui coûte du temps, pas le principe : la configuration SPF et DKIM d'Amazon SES ne ressemble ni à celle de Mailgun, ni à celle de Postmark. Les plateformes commerciales ajoutent une difficulté de plus, celle du domaine d'envoi : HubSpot, Klaviyo et Salesforce signent chacune selon des règles distinctes, et une seule d'entre elles mal réglée suffit à faire échouer l'alignement du domaine entier. L'inventaire ouvre la liste des chantiers ; ils se referment fournisseur par fournisseur.
Une organisation à marques multiples multiplie chaque famille par le nombre de domaines ; la discipline correspondante relève de la gouvernance DMARC multi-marques.
Trois sources de vérité — une seule est exhaustive
Les rapports RUA d'abord. Publier p=none avec une adresse de collecte — v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr — transforme les grands récepteurs (Gmail, Microsoft, Yahoo) en observateurs : chaque IP qui a écrit au nom du domaine apparaît dans les rapports agrégés, volumes et résultats d'authentification compris. C'est la seule source exhaustive : elle voit le prestataire officiel, l'outil branché sans ticket, le script oublié sur un serveur — et l'usurpateur. Sa lecture demande un décodage, détaillé dans les rapports agrégés DMARC expliqués, et de la patience : quatre semaines de collecte au minimum pour voir passer les envois hebdomadaires et mensuels.
Les factures et contrats ensuite. Tout SaaS qui envoie du courrier est facturé à quelqu'un. Une extraction comptable des abonnements logiciels révèle des outils que personne n'a mentionnés — avec un nom de fournisseur, un contrat, un interlocuteur. La limite est connue : les outils gratuits et le shadow IT payé par carte personnelle échappent à la comptabilité.
Les entretiens métier enfin. Une demi-heure avec le marketing, les RH, la finance, le support et l'IT, une seule question : « quels outils envoient des emails ? ». La mémoire est faillible et les départs effacent le savoir, mais cette source apporte ce que les deux autres ignorent : le propriétaire de chaque flux, sa criticité, son calendrier.
Le croisement fait la valeur : les RUA donnent l'exhaustivité technique, la comptabilité donne la prise contractuelle, les entretiens donnent la dimension humaine. Un inventaire bâti sur une seule des trois sources est un inventaire troué.
Construire la carte : du nom d'outil au propriétaire interne
La carte prend la forme d'un tableau — un tableur partagé suffit largement — avec une ligne par couple outil-domaine et six colonnes : la source, le domaine technique d'envoi, l'état SPF, l'état DKIM, l'alignement constaté, le propriétaire interne.
| Source | Domaine technique | SPF | DKIM | Alignement | Propriétaire |
|---|---|---|---|---|---|
| Plateforme newsletter | em.exemple.fr |
include posé | CNAME délégués | aligné | Marketing |
| Facturation SaaS | bounce.exemple.fr |
include posé | absent | SPF seul | Finance |
| SIRH / paie | aucun (envoi direct) | absent | absent | non aligné | RH |
| Supervision | exemple.fr |
inclus | signé en propre | aligné | IT |
Le domaine technique est celui que le prestataire utilise réellement pour SPF (l'adresse de retour) et pour DKIM (le domaine de signature) — pas le nom commercial de l'outil. C'est lui qui décide de l'alignement. Pour chaque ligne, la documentation du prestataire indique la marche à suivre : un include: SPF (par exemple include:servers.mcsv.net pour Mailchimp), et surtout des enregistrements CNAME de délégation DKIM du type s1._domainkey.exemple.fr pointant vers l'infrastructure du fournisseur. DKIM mérite la priorité : la signature survit aux transferts, quand SPF casse au premier relais.
La colonne « propriétaire » n'est pas décorative : c'est elle qui rend la remédiation possible. Configurer l'authentification d'un outil suppose un accès à son paramétrage — donc une personne identifiée, côté métier, qui ouvre la console du prestataire pendant que l'équipe DNS pose les enregistrements. Une ligne sans propriétaire est une ligne qui ne sera jamais corrigée.
Les tiers qui ne savent pas s'aligner
La carte révèle presque toujours quelques lignes insolubles en l'état : des prestataires qui envoient avec l'adresse du domaine mais n'offrent ni SPF personnalisable ni DKIM délégué. Aucun enregistrement DNS ne peut sauver un outil qui ne signe pas.
Quatre issues, par ordre de préférence. Demander : la fonctionnalité existe parfois sur un palier supérieur ou sur simple demande au support — le contrat est une prise de négociation. Déplacer : faire envoyer l'outil depuis son propre domaine, celui du prestataire, dans l'adresse visible ; le flux sort du périmètre DMARC du domaine principal, au prix d'une adresse moins flatteuse. Isoler : cantonner l'outil à un sous-domaine dédié (notif.exemple.fr) portant sa propre politique, le temps de la transition — DMARCbis, la révision courante du standard, fournit d'ailleurs un mode test explicite, le tag t=y, qui remplace l'ancien mécanisme de pourcentage. Remplacer : un prestataire incapable d'authentifier son courrier en 2026 dit quelque chose de sa maturité technique ; le renouvellement du contrat est le bon moment pour en tirer les conséquences.
L'important est de trancher chaque ligne avant le durcissement : une ligne « non aligné » sans décision documentée est exactement le flux qui cassera au passage en application stricte.
Un inventaire vivant, pas une photo
Un inventaire daté du lancement du projet et jamais rouvert vaut à peine mieux que pas d'inventaire : le parc d'outils bouge en permanence. Trois mécanismes le gardent à jour.
Le premier est organisationnel : une question dans le processus d'achat. « Ce service enverra-t-il des emails au nom du domaine ? » — si oui, une ligne s'ajoute à la carte et l'authentification se configure avant la mise en production, pas après le premier rejet. Nouvel outil, nouvelle ligne : la règle tient en quatre mots.
Le deuxième est technique : la surveillance continue des rapports RUA. Une source inconnue qui apparaît dans le tableau de bord est soit un outil branché sans prévenir — la carte se complète —, soit une usurpation — l'incident se traite. Dans les deux cas, l'écart entre la carte et la réalité se voit en jours, pas en années.
Le troisième est événementiel : chaque changement majeur du système d'information rejoue l'inventaire. Le cas le plus brutal est la migration de fournisseur de messagerie, qui déplace d'un coup le premier expéditeur du domaine et réveille toutes les lignes dormantes de la carte. Fusions, acquisitions et refontes applicatives ont le même effet, à échéance moins prévisible.
En résumé
Un projet DMARC ne se gagne pas dans le DNS, il se gagne dans la carte. Les expéditeurs tiers — marketing, transactionnel, CRM, support, billetterie, RH, finance, supervision, courrier hybride — écrivent au nom du domaine, souvent à l'insu de l'équipe informatique, et chaque oubli devient un flux cassé au passage en p=reject. La méthode tient en quatre temps : croiser les trois sources de vérité (rapports RUA, seuls exhaustifs ; factures et contrats ; entretiens métier), consigner chaque flux dans un tableau reliant source, domaine technique, SPF/DKIM et propriétaire interne, trancher le sort des tiers incapables de s'aligner, puis maintenir la carte vivante — nouvel outil, nouvelle ligne.
Le premier relevé de terrain ne demande aucun projet : l'analyse DMARC gratuite montre en quelques secondes l'état d'authentification du domaine et ce que les récepteurs en voient déjà. Pour passer du relevé à la carte complète, l'ouverture d'un compte lance la collecte des rapports RUA — et l'inventaire se construit alors sur des faits observés, pas sur la mémoire des équipes.
Guides liés
- Quand la redirection d'email casse SPF (et ce que SRS répare)
Un email redirigé repart d'une IP absente du SPF d'origine : échec garanti. Ce que SRS répare, ce que DKIM sauve, et l'effet réel sur DMARC.
- DMARC échoue alors que SPF passe : comprendre l'alignement
Un rapport DMARC peut afficher spf=pass et dmarc=fail pour le même message. L'explication tient en un mot, l'alignement, et change la lecture des rapports.
- ARC : la chaîne de réception authentifiée (Authenticated Received Chain)
ARC (Authenticated Received Chain) rattrape le courrier légitime que les listes et les redirections font échouer à DMARC. Ce qu'il fait, et ses limites.
À propos de l'auteur
Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.