Aller au contenu
DMARC
← Blog

DMARC auto-hébergé (open source) ou service géré : comment trancher

Par Thomas · RSSI virtuel · 19 août 2026

L'enregistrement DMARC est publié, les rapports arrivent, et une question d'architecture se pose : qui exploite la chaîne de collecte et d'analyse ? Deux options s'affrontent. La première consiste à auto-héberger toute la pile — boîte de réception pour les rapports, parseur XML, base de données, tableaux de bord, alerting — à partir de briques open source. La seconde, à acheter un service géré qui prend tout en charge. Ce guide compare les deux honnêtement, comme un arbitrage d'ingénierie et pas comme un argumentaire de vente. Chaque camp a des partisans sincères, et le bon choix dépend de facteurs très concrets : la capacité d'ingénierie interne, les exigences de souveraineté des données, le nombre de domaines et la vitesse à laquelle les résultats sont attendus.

Sans le moindre rapport en main, la décision se prend trop tôt : mieux vaut d'abord comprendre ce que recouvre réellement le standard et publier une politique p=none avec une adresse rua. Ce qui suit suppose que les rapports arrivent déjà quelque part, et que la seule question est : « faut-il construire la machine à les lire, ou la louer ? »

Ce que « auto-héberger DMARC » veut vraiment dire

Le mot « auto-hébergé » sonne simple. La réalité l'est moins, parce que le reporting DMARC n'est pas un produit unique mais une chaîne de plusieurs maillons, et auto-héberger signifie tenir chacun d'eux en interne. Reste à voir ce que ça implique concrètement.

D'abord, il faut une boîte de réception qui reçoit les rapports agrégés rua. L'adresse mailto: publiée dans l'enregistrement DMARC doit pointer vers une boîte réelle, capable d'encaisser un volume parfois important de messages quotidiens venant de dizaines de fournisseurs. Cette boîte doit être fiable, surveillée, et son contenu régulièrement dépilé — un rapport non traité est un rapport perdu.

Ensuite, il faut parser le XML. Les rapports agrégés arrivent en pièce jointe, presque toujours compressés en gzip (parfois en zip), et leur structure XML est standardisée mais truffée de cas limites : encodages exotiques, champs optionnels absents, valeurs vides, variations d'un fournisseur à l'autre, fichiers volumineux, pièces jointes malformées. Écrire un parseur qui encaisse proprement toute cette diversité — sans planter sur le premier rapport bizarre, sans avaler silencieusement des lignes — représente un vrai travail. Le format lui-même est décrit dans comprendre les rapports agrégés DMARC ; c'est précisément ce XML qu'une pile auto-hébergée s'engage à digérer.

Puis il faut stocker et dédupliquer. Les rapports se chevauchent — le même fournisseur peut couvrir des plages de temps qui se recoupent, et les enregistrements en double s'accumulent tant que rien ne les identifie. Il faut un schéma de base de données, une clé de déduplication solide, et une politique d'agrégation pour transformer des milliers de lignes brutes en une vue lisible « qui envoie au nom du domaine, aligné ou non ».

Ensuite viennent les tableaux de bord et l'alerting. Des lignes en base ne servent à rien tant qu'un humain ne peut pas y lire une tendance. Il faut construire des vues — évolution de l'alignement, top des sources, nouvelles IP apparues — et surtout un système d'alerte qui prévient quand quelque chose bouge (une source légitime qui se met à échouer, un pic de trafic non aligné). Cet alerting, personne ne le fournit : il se construit.

Enfin, il y a l'identification des sources, la rétention et la garde des clés DKIM. Une IP brute (198.51.100.7) ne dit rien ; reconnaître derrière elle le prestataire de facturation demande un travail d'enrichissement (reverse DNS, ASN, corrélation). La rétention des données — combien de temps garder des rapports qui contiennent des adresses IP, donc des données à caractère personnel — est une décision de conformité qui incombe entièrement à l'organisation. Et auto-héberger, c'est aussi détenir les clés privées DKIM : leur stockage, leur rotation et leur révocation deviennent une responsabilité interne, un sujet à traiter avec le sérieux décrit dans la rotation des clés DKIM.

Les avantages réels de l'auto-hébergement

Maintenant que le périmètre est clair, les bénéfices apparaissent nettement — et ils sont réels, pas théoriques.

  • Souveraineté totale des données. Rien ne sort de l'infrastructure de l'organisation. Les rapports, les IP, les métadonnées des flux mail restent en interne, sous contrôle juridique et technique direct. Pour une organisation soumise à des règles strictes de résidence des données, c'est parfois l'argument décisif — aucun tiers ne voit passer qui écrit à l'entreprise ni depuis où.
  • Aucun coût par domaine. Une fois la pile construite, ajouter un domaine ne coûte pas un abonnement de plus. Pour qui maîtrise déjà l'ingénierie, le coût marginal tend vers zéro.
  • Contrôle total. Le parseur, les seuils d'alerte, la granularité des tableaux de bord s'ajustent exactement à la réalité du terrain. Pas de fonctionnalité manquante qu'un éditeur refuse de prioriser.
  • Auditabilité. Toute la chaîne appartient à l'organisation, inspectable de bout en bout — précieux quand un auditeur demande de prouver où vivent les données et comment elles sont traitées.

Les inconvénients réels de l'auto-hébergement

Le revers est tout aussi concret, et c'est là que beaucoup d'équipes se trompent dans leur estimation.

  • Du temps d'ingénierie, pour construire ET pour maintenir. Le coût visible, c'est le développement initial. Le coût caché, bien plus lourd sur la durée, c'est la maintenance : un fournisseur change son format à la marge, un rapport malformé fait tomber le parseur, la boîte de réception sature, la base grossit. Ce n'est jamais « fini ».
  • Les cas limites du XML et de la boîte mail. On l'a dit : encodages, pièces jointes bizarres, volumétrie. Chaque cas non géré est un trou silencieux dans la visibilité.
  • L'alerting et l'identification des sources restent à la charge de l'équipe. Un service géré livre « cette IP est probablement tel prestataire » et « attention, cette source légitime vient d'échouer » clé en main. Auto-hébergée, cette intelligence se bâtit en interne.
  • La rétention et les données personnelles reposent sur l'organisation. Les IP sont des données à caractère personnel. Définir une durée de conservation, purger, documenter le traitement : c'est un dossier de conformité interne, pas celui d'un éditeur.
  • La garde des clés DKIM est un fardeau. Détenir les clés privées, c'est aussi porter le risque de leur fuite et l'obligation de les faire tourner proprement.

Le service géré : avantages et inconvénients

En face, le service géré inverse presque tous les curseurs.

Ses avantages : un temps de mise en valeur très court — le rua pointe vers le service et les tableaux de bord deviennent lisibles en quelques heures, pas en quelques sprints. Un support quand ça coince. Une gestion multi-domaines native, sans effort marginal par domaine. Et surtout, l'identification des sources et les conseils de remédiation livrés d'emblée : le service nomme qui envoie, dit si c'est aligné, et indique quoi faire ensuite — exactement le genre d'accompagnement que porte le copilote de remédiation de DMARC.com, pensé pour mener un domaine de p=none à p=reject sans casser ses flux.

Ses inconvénients : un coût récurrent (le sujet est creusé dans le coût d'un déploiement DMARC), et le fait que les données de rapport transitent chez un sous-traitant. Ce dernier point est le miroir exact de l'argument de souveraineté — et il se neutralise largement quand l'éditeur offre une vraie résidence des données et une souveraineté claire (hébergement dans la juridiction du client, engagements contractuels). Un service géré souverain enlève à l'auto-hébergement son avantage le plus fort, tout en gardant sa rapidité.

Les axes de décision

Le choix se ramène à quatre questions honnêtes.

  1. Capacité d'ingénierie interne. L'équipe est-elle capable de construire et surtout de maintenir une pile de parsing/stockage/alerting sur plusieurs années ? Pas « quelqu'un pourrait le coder un week-end », mais « quelqu'un le tiendra en vie dans deux ans ».
  2. Exigences de résidence et de conformité. Des règles strictes interdisent-elles aux métadonnées mail de sortir de la juridiction ? Si oui, l'alternative se réduit à deux termes : auto-hébergement, ou géré souverain.
  3. Nombre de domaines. Un domaine unique se pilote à la main ; cinquante domaines multiplient la valeur d'une gestion multi-domaines mutualisée.
  4. Vitesse de résultat attendue. Les résultats sont-ils attendus ce trimestre pour répondre à une exigence Gmail/Yahoo, NIS2 ou un partenaire — ou un projet interne étalé reste-t-il envisageable ?

Un exemple concret

Prenons deux organisations aux profils opposés.

La première est une scale-up très orientée ingénierie de sécurité — une cinquantaine d'ingénieurs, une culture « on héberge nos outils », des règles de résidence des données strictes imposées par ses clients grands comptes, et peu de domaines (deux marques, quelques sous-domaines). Pour elle, auto-héberger a du sens : l'équipe sait construire un parseur robuste et le maintenir, la souveraineté est une exigence contractuelle non négociable, et le faible nombre de domaines limite la charge. Le coût d'ingénierie est réel mais absorbable, et le contrôle total sert une posture sécurité déjà mûre. Décision : pile open source auto-hébergée, avec une garde des clés DKIM traitée aussi sérieusement que le reste de ses secrets.

La seconde est une PME menée par le marketing — une quinzaine de personnes, pas d'équipe d'ingénierie dédiée à l'infrastructure, mais beaucoup de domaines (la marque principale plus une douzaine de domaines de campagne et d'acquisition), et une échéance proche : les nouvelles exigences des boîtes grand public menacent sa délivrabilité maintenant. Ici, auto-héberger serait une erreur : personne ne maintiendra le parseur, chaque domaine ajouté alourdirait un projet déjà sans pilote, et le temps de mise en œuvre dépasserait l'échéance. Décision : service géré, idéalement souverain pour cocher la case résidence, avec identification des sources et conseils de remédiation qui font gagner des semaines. Pour évaluer le budget, elle regarde d'abord la tarification et compare au coût chargé d'un développement interne.

Même standard DMARC, deux architectures opposées — parce que la capacité d'ingénierie, le nombre de domaines et l'urgence, eux, diffèrent radicalement.

Les pièges de l'auto-hébergement qu'on sous-estime

Quelques réalités que les équipes découvrent trop tard :

  • « C'est juste un parseur XML. » Non. C'est un parseur XML plus une boîte mail fiable, plus un schéma de déduplication, plus de l'alerting, plus de l'enrichissement de sources, plus une politique de rétention. Le parseur est la partie facile.
  • Le coût de maintenance dépasse le coût de construction. Le développement initial est un pic ; la maintenance est une rente qu'on paie chaque mois, souvent par la personne qui a le moins de temps.
  • La dérive silencieuse. Un parseur qui « marche » peut avaler discrètement les rapports d'un fournisseur au format légèrement différent. La visibilité paraît complète alors qu'il manque 10 % des données — et rien ne le signale.
  • La garde des clés DKIM oubliée. Auto-héberger la collecte fait souvent oublier que des clés privées sont détenues elles aussi, à protéger et à faire tourner. Une clé qui ne tourne jamais, ou stockée n'importe où, est une dette de sécurité — voir la rotation des clés DKIM.
  • La rétention des données personnelles négligée. Garder des rapports pleins d'IP indéfiniment « au cas où » est un risque de conformité, pas une prudence.
  • Le bus factor. La pile tient souvent dans la tête d'une seule personne. Quand elle part, la visibilité DMARC part avec elle.

Pour arbitrer plus finement les fonctionnalités qu'un outil doit couvrir, ce que doit faire un bon analyseur DMARC et comment choisir un outil DMARC détaillent les critères qui séparent une pile « qui affiche des chiffres » d'une pile qui fait réellement avancer vers reject.

En résumé

Auto-héberger DMARC est un excellent choix pour une organisation à forte culture d'ingénierie de sécurité, avec des règles de résidence strictes et peu de domaines : elle gagne une souveraineté totale et un contrôle absolu, au prix d'un travail de construction et de maintenance qu'elle est capable d'assumer. Le service géré l'emporte pour une équipe légère, avec beaucoup de domaines, qui a besoin de résultats vite : il échange un coût récurrent contre du temps et de l'expertise livrés d'emblée — et un géré souverain neutralise le seul vrai reproche qu'on lui fait, la localisation des données. Il n'y a pas de réponse universelle, seulement une réponse juste pour un profil donné : poser honnêtement les quatre axes — ingénierie, résidence, domaines, urgence — et la décision se dessine d'elle-même.

Quel que soit le camp vers lequel penche l'arbitrage, tout commence par une mesure factuelle : un passage du domaine dans l'analyseur DMARC gratuit montre l'alignement réel des sources aujourd'hui. La future pile — construite ou louée — devra restituer exactement cela, et le choix se fait alors sur des faits plutôt que sur une intuition.

Guides liés

À 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.