Guide pratique DMARCbis : Protéger votre domaine, gérer les nouveaux rapports

Vous venez de lire l’article technique sur DMARCbis ? Bien. Maintenant, la vraie question : qu’est-ce que je fais concrètement avec mon domaine ?

Ce guide est fait pour vous, que vous soyez administrateur DNS, responsable sécurité ou propriétaire de PME. Vous trouverez ici un plan d’action progressif, des exemples concrets et une checklist avant mise en production.

Objectif : Protéger votre domaine contre l’usurpation d’identité (spoofing) sans casser vos flux email légitimes.

Étape 1 : Auditer votre configuration actuelle

Récupérer votre enregistrement DMARC

Recherchez l’enregistrement TXT _dmarc.votredomaine.com dans votre gestionnaire DNS, ou utilisez un outil en ligne comme senderaudit.com.

Exemple d’enregistrement typique :

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Ce que vous devez vérifier

Tester les deux méthodes de découverte

Important pour DMARCbis : Vérifiez que le DNS Tree Walk et la PSL trouvent la même policy pour votre domaine. Une divergence peut mener à un comportement imprévisible selon le receiver.

Utilisez senderaudit.com pour ce test ou un validateur supportant RFC 9989.

Les 3 phases pour atteindre p=reject

Phase 1, Monitoring (0 à 3 mois)

Policy recommandée :

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Vous activez uniquement les rapports RUA sans toucher aux emails. C’est la phase d’observation.

Ce que vous apprenez :

• Qui envoie depuis votre domaine (services legit, scripts, ESP…)
• Taux de pass/fail SPF et DKIM
• IPs inconnues ou suspectes

Exemple de rapport simplifié :

→ Salesforce avec SPF Fail : Vous devez ajouter include:salesforce.com à votre SPF. → IP inconnue tout Fail : Probablement un attaquant. Ignorez pour l’instant (il sera bloqué quand vous passerez en reject).

Checklist Phase 1

• p=none déployé
• Rapports RUA reçus et lus
• Faux positifs identifiés (services légitimes qui échouent)
• SPF et DKIM corrigés pour les services légitimes

Phase 2, Mode test (3 à 6 mois)

Policy recommandée :

_dmarc.example.com  TXT  "v=DMARC1; p=reject; t=y; sp=quarantine; np=reject; rua=mailto:dmarc@example.com"

Le tag t=y est la nouveauté clé de DMARCbis. Il dit aux receivers : “Je teste reject, mais appliquez quarantine ou none pour l’instant.”

Sur np= : dans la plupart des cas, un sous-domaine inexistant ne doit jamais émettre d’email. C’est pourquoi np=reject est généralement le choix le plus protecteur, même en phase de test (t=y le ramènera alors en pratique vers quarantine).

Les rapports RUA incluront désormais testing: y, confirmation que le mode test est actif.

Exemple de rapport RFC 9990 :

{
  "policy_published": {
    "domain": "example.com",
    "discovery_method": "treewalk",
    "p": "reject",
    "sp": "quarantine",
    "np": "reject",
    "testing": "y"
  }
}

Ce que vous observez :

• discovery_method : treewalk ou psl, quelle méthode le receiver utilise
• testing : doit être y pour confirmer le mode test
• Faux positifs résiduels que vous n’avez pas encore corrigés

Pourquoi t=y est supérieur à l’ancienne méthode :

Checklist Phase 2

• Policy avec t=y; p=reject déployée
• Rapports reçus avec testing: y
• Champ discovery_method visible
• Aucun service critique bloqué
• Faux positifs résolus (SPF/DKIM corrigés)

Phase 3, Production (6 mois et +)

Policy recommandée :

_dmarc.example.com  TXT  "v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com"

Vous retirez t=y et passez en production réelle. Les emails qui ne passent pas DMARC sont désormais rejetés à la source.

Décomposition des tags :

Checklist Phase 3

• Phase 2 complétée sans faux positifs majeurs
• Toutes les intégrations tiers vérifiées (CRM, ESP, helpdesk…)
• p=reject déployé (sans t=y)
• Plan de rollback prêt (vers p=quarantine en cas de problème)

Timeline recommandée

Mois 0     Mois 3     Mois 6     Mois 12+
   |          |          |          |
Phase 1    Phase 2    Phase 3    Maintenance
p=none     t=y+reject  reject     Surveillance
           ↑
     Mode test DMARCbis

Exploiter les nouveaux tags de DMARCbis

t=y : Tester sans risque

Remplacez ceci (RFC 7489, ambigu) :

v=DMARC1; p=none; pct=0; rua=mailto:...

Par ceci (RFC 9989, explicite) :

v=DMARC1; p=reject; t=y; rua=mailto:...

Les receivers sauront que vous testez. Les rapports confirmeront testing: y. Pas de surprise.

np= : Protéger les sous-domaines inexistants

Imaginez un attaquant envoyant depuis support.invoice.example.com, un sous-domaine qui n’existe pas dans votre DNS. Avec np=reject, ces emails sont rejetés même si la policy principale n’en parle pas.

Quand utiliser np=reject :

• ✅ Votre structure de sous-domaines est stable
• ✅ Vous voulez une protection maximale

Quand éviter np=reject :

• ❌ Vous créez des sous-domaines dynamiquement
• ❌ Vous êtes en phase de migration DNS

sp= : Stratégie progressive pour les sous-domaines

Vos sous-domaines n’ont pas tous le même niveau de maturité DMARC. sp= vous permet d’appliquer une politique plus souple sans toucher à la policy principale.

Stratégie recommandée (progressive) :

v=DMARC1; p=reject; sp=quarantine; np=quarantine; rua=mailto:...

→ Domaine principal : protection maximale. Sous-domaines : quarantine (marge d’erreur).

Stratégie maximale (tout strict) :

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:...

→ À utiliser quand tous les sous-domaines ont SPF et DKIM configurés.

Lire et agir sur les rapports RUA

Structure du nouveau rapport (RFC 9990)

Les rapports agrégés incluent maintenant des champs supplémentaires qui vous donnent plus de contexte :

{
  "report_metadata": {
    "org_name": "Gmail",
    "report_id": "google-20260619",
    "date_range": { "begin": "2026-06-18", "end": "2026-06-19" }
  },
  "policy_published": {
    "domain": "example.com",
    "discovery_method": "treewalk",
    "p": "reject",
    "sp": "quarantine",
    "np": "none",
    "testing": "n"
  },
  "records": [
    {
      "source_ip": "192.0.2.100",
      "count": 50,
      "policy_evaluated": {
        "disposition": "pass",
        "dkim": "pass",
        "spf": "pass"
      },
      "auth_results": {
        "spf": { "domain": "mail.example.com", "scope": "mfrom", "result": "pass" },
        "dkim": { "domain": "example.com", "selector": "default", "result": "pass" }
      }
    }
  ]
}

Champs nouveaux à surveiller :

Interpréter les résultats par scénario

Tous PASS ✅

Aucune action. Vos emails sont correctement authentifiés.

FAIL SPF, PASS DKIM ⚠️

"dkim": "pass", "spf": "fail"

→ Un service envoie en votre nom mais son IP n’est pas dans votre SPF. → Action : Identifier le service (reverse DNS de l’IP), ajouter include: dans votre SPF.

FAIL DKIM, PASS SPF ⚠️

"dkim": "fail", "spf": "pass"

→ Un service envoie sans signature DKIM valide. → Action : Configurer DKIM sur ce service, ou contacter votre ESP pour activer la signature.

FAIL les deux ❌

"dkim": "fail", "spf": "fail"

→ Très probablement un attaquant usurpant votre identité. → Action : Aucune (sera bloqué en p=reject). Documenter pour audit.

Gérer la rétrocompatibilité

Risque 1 : Tags dépréciés ignorés

Si vous avez pct=50 pour tester avec 50% des emails, un receiver RFC 9989 l’ignore et applique 100%.

Solution : Remplacer par t=y; p=reject.

Risque 2 : Divergence PSL vs Tree Walk

Pour les domaines avec une structure complexe (*.co.uk, structures imbriquées), les deux méthodes peuvent trouver des policies différentes.

Comment détecter :

1. Tester votre domaine avec PSL et Tree Walk (outil RFC 9989)
2. Observer le champ discovery_method dans vos rapports RUA
3. Si vous voyez des psl et treewalk avec des résultats différents → enquêter

Comment corriger :

• Ajouter psd=y si votre domaine est un Public Suffix
• Créer des enregistrements _dmarc explicites sur les sous-domaines concernés

Risque 3 : SPF HELO vs MAIL FROM

Certaines configurations de mail server utilisent un domaine HELO différent du domaine MAIL FROM. Avec RFC 9989, seul MAIL FROM compte.

Vérification : Envoyez un email de test et vérifiez dans les headers le Return-Path (= MAIL FROM). C’est ce domaine qui doit être couvert par votre SPF.

Checklist complète avant p=reject

Configuration DNS

• SPF record valide et complet (tous les senders inclus)
• DKIM record présent avec sélecteur actif
• DMARC record testé avec validateur DMARCbis
• PSL et Tree Walk donnent le même résultat
• Tags dépréciés (pct=, rf=, ri=) supprimés

Phases complétées

• Phase 1 (monitoring) : minimum 3 mois
• Phase 2 (mode test) : minimum 3 mois, avec t=y
• Aucun faux positif critique identifié
• Rapports RUA analysés sur 2-3 cycles

Services tiers

• Tous les ESP (SendGrid, Mailchimp, etc.) : SPF include + DKIM configurés
• CRM (Salesforce, HubSpot…) : SPF include configuré
• Helpdesk (Zendesk, Intercom…) : DKIM configuré
• Plateformes e-commerce (Shopify…) : SPF + DKIM vérifiés

Post-déploiement

• Monitoring RUA actif (dashboard ou email)
• Alerte en cas de faux positif massif
• Plan de rollback vers p=quarantine documenté

FAQ pratiques

J’ai besoin de p=reject rapidement, je ne peux pas attendre 6 mois.

Accélérez les phases :

• Phase 1 : 2-4 semaines (monitoring intensif)
• Phase 2 : 1-2 mois (avec t=y)

Ne sautez pas les phases, le risque est de bloquer vos propres emails. Si la rapidité prime, passez d’abord à p=quarantine (plus sûr que reject direct).

Comment distinguer une IP attaquante d’un service légitime dans les rapports ?

• ✅ Service légitime : IP stable, reverse DNS avec nom de service reconnu, DKIM ou SPF passant
• ❌ Attaquant : IP variable ou inconnue, reverse DNS absent, DKIM et SPF échouant

Utilisez nslookup <ip> et whois <ip> pour identifier une IP.

np=reject bloque mes sous-domaines créés dynamiquement. Que faire ?

Deux options :

1. Passer à np=quarantine (moins strict, mais toujours protecteur)
2. Créer des enregistrements _dmarc explicites sur les sous-domaines connus :

   _dmarc.api.example.com  TXT  "v=DMARC1; p=none"
   

Je vois discovery_method: psl dans mes rapports. Est-ce un problème ?

Pas immédiatement. Les receivers migrent progressivement vers tree walk. Vérifiez qu’il n’y a pas de divergence entre PSL et tree walk pour votre domaine. Si les résultats sont identiques, psl est sans impact.

Dois-je activer ruf= (rapports d’échec individuels) en plus de rua= ?

Probablement non pour la plupart des domaines. rua= (rapports agrégés) suffit pour le monitoring. ruf= est utile uniquement en cas d’enquête de sécurité sur des attaques ciblées, et génère beaucoup plus de données.

Conclusion

La migration vers DMARCbis n’est pas urgente, mais elle est stratégique. Vos policies actuelles continuent de fonctionner, mais les nouvelles fonctionnalités (t=y, np=, tree walk) vous donnent des outils plus puissants et plus clairs.

Votre plan d’action :

1. Aujourd’hui : Auditez votre config. Supprimez pct=.
2. Ce mois : Passez en p=none; rua=mailto:... si ce n’est pas fait.
3. Dans 3 mois : Passez en p=reject; t=y (mode test DMARCbis).
4. Dans 6 mois : Passez en p=reject production.
5. En continu : Lisez vos rapports RUA chaque semaine.

Besoin d’analyser votre configuration dès maintenant ? Utilisez senderaudit.com pour un audit complet de votre domaine.