Contact

DMARC : Concevoir un enregistrement DMARC

DMARC : Générer un enregistrement DMARC

DMARC : Générer un enregistrement DMARC

Introduction

La protection des domaines email contre l’usurpation d’identité (spoofing) et le phishing est devenue une exigence opérationnelle. Depuis 2024, les principaux fournisseurs comme Google (Gmail) et Microsoft (Outlook / Microsoft 365) imposent DMARC pour les envois professionnels à volume significatif.

Le protocole DMARC (Domain-based Message Authentication, Reporting & Conformance), normalisé par la Internet Engineering Task Force dans la RFC 7489, s’appuie sur SPF et DKIM pour :

  • définir une politique de traitement des emails non conformes ;
  • fournir des rapports d’usage du domaine ;
  • réduire les abus d’identité.

L’outil DMARC Generator d’ITPlatform permet de générer un enregistrement TXT DMARC conforme et structuré, en intégrant les paramètres opérationnels critiques (policy, alignment, reporting, sous-domaines, etc.).

Problématique terrain

Dans la pratique, les équipes IT rencontrent plusieurs difficultés :

  • Enregistrements DMARC mal formés (ordre incorrect, erreurs syntaxiques).
  • Passage prématuré en p=reject provoquant des pertes de délivrabilité.
  • Absence de reporting (rua) empêchant toute visibilité.
  • Mauvais alignement DKIM/SPF en environnement multi-sources (SaaS marketing, CRM, ERP).
  • Sous-domaines oubliés.
  • Politique incohérente entre SPF/DKIM et DMARC.

Résultat :
Soit DMARC est inefficace (p=none permanent),
Soit il casse la production mail.

Un générateur structuré réduit le risque d’erreur et impose une configuration cohérente.

Explication technique structurée

1. Structure minimale DMARC

Un enregistrement DMARC valide commence toujours par :

v=DMARC1; p=policy;
  • v=DMARC1 → version obligatoire.
  • p= → politique appliquée aux emails échouant SPF/DKIM alignés.

2. Politiques disponibles

PolitiqueEffet
noneMonitoring uniquement
quarantineMise en quarantaine (spam)
rejectRejet SMTP

Recommandation terrain :
Migration progressive → none → quarantine → reject.

3. Reporting (rua / ruf)

  • rua= → rapports agrégés XML (recommandé)
  • ruf= → rapports forensiques (peu utilisés, problématiques RGPD)

Les rapports agrégés sont essentiels pour cartographier les sources d’envoi réelles.

4. Alignement (adkim / aspf)

  • r (relaxed) : sous-domaines acceptés
  • s (strict) : correspondance exacte du domaine

Strict = sécurité accrue mais exige une architecture propre.

5. Politique sous-domaines (sp)

Si absent, hérite de p=.

Utile dans les environnements :

  • multi-tenant
  • sous-domaines marketing
  • domaines techniques séparés

6. Paramètres avancés

  • pct= → pourcentage d’application (1–100)
  • fo= → conditions de reporting d’échec
  • ri= → intervalle de rapport (en secondes, défaut 86400)

Implémentation concrète

Exemple 1 : Phase d’observation

v=DMARC1; p=none; rua=mailto:dmarc@domain.tld; adkim=r; aspf=r; pct=100; ri=86400;

Publication DNS :

Type: TXT
Host: _dmarc.domain.tld
Value: "v=DMARC1; p=none; rua=mailto:dmarc@domain.tld; adkim=r; aspf=r; pct=100; ri=86400;"
TTL: 3600

Vérification :

dig +short TXT _dmarc.domain.tld

Exemple 2 : Passage progressif en quarantaine

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@domain.tld;

Augmenter progressivement :

  • 25%
  • 50%
  • 75%
  • 100%

Exemple 3 : Politique stricte production

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@domain.tld;

À appliquer uniquement si :

  • SPF couvre toutes les sources.
  • DKIM signé pour chaque flux sortant.
  • Rapports analysés au moins 2–4 semaines.

Erreurs fréquentes

1. Publier sur le mauvais host

Incorrect :

domain.tld TXT "v=DMARC1; ..."

Correct :

_dmarc.domain.tld

2. Oublier le reporting

Un DMARC sans rua = absence de visibilité.

3. Forcer strict trop tôt

adkim=s et aspf=s sur une architecture non maîtrisée = pertes de mails.

4. Multiplier les enregistrements DMARC

Un seul enregistrement DMARC par domaine.

5. Ignorer les sous-domaines actifs

Les plateformes SaaS utilisent souvent :

  • mail.domain.tld
  • mkt.domain.tld
  • crm.domain.tld

Sans sp=, comportement implicite parfois inattendu.

Bonnes pratiques professionnelles

  • Toujours démarrer en p=none.
  • Analyser les rapports agrégés avant toute montée en politique.
  • Cartographier les flux d’envoi (Postfix, Exchange, SaaS, marketing automation).
  • Isoler les flux techniques via sous-domaines dédiés.
  • Centraliser les rapports dans un outil d’analyse (parser XML).
  • Ne pas activer ruf sans analyse RGPD.
  • Maintenir cohérence SPF + DKIM + DMARC.
  • Intégrer DMARC dans les audits sécurité annuels.

En environnement PME technique ou multi-SaaS, la difficulté n’est pas la syntaxe, mais la maîtrise des flux sortants.

Conclusion pragmatique

Le DMARC Generator d’ITPlatform permet :

  • de produire un enregistrement syntaxiquement correct ;
  • de structurer une politique progressive ;
  • de limiter les erreurs DNS ;
  • d’intégrer les paramètres d’alignement et de reporting.

Cependant, un bon enregistrement DMARC ne remplace pas :

  • un SPF exhaustif ;
  • une signature DKIM systématique ;
  • une supervision régulière des rapports.

DMARC est un mécanisme de contrôle.
Pas un correctif magique.

Sa valeur dépend directement de la rigueur de l’architecture email sous-jacente.

Liens internes suggérés