Vous avez publié votre record DMARC avec p=none. C’est un bon début, mais p=none ne bloque rien : les emails frauduleux passent quand même. L’objectif final est p=reject, et ce guide vous accompagne dans cette migration sans casser vos flux légitimes.

Pourquoi p=none ne suffit pas

Avec p=none, vous demandez aux fournisseurs de messagerie de ne rien faire quand un email échoue DMARC. Vous recevez les rapports RUA, mais :

  • Les emails usurpant votre domaine arrivent en inbox
  • Votre domaine peut être utilisé pour du phishing
  • Google et Yahoo exigent désormais un DMARC publié, mais les bénéfices réels commencent à p=quarantine ou p=reject

La timeline recommandée

SemainePolitiqueObjectif
S1-S2p=none; rua=mailto:...Collecter les rapports, inventorier les sources
S3-S4Analyse des rapportsIdentifier chaque source IP, corriger SPF/DKIM
S5-S6p=quarantine; pct=10Tester sur 10% du trafic
S7-S8p=quarantine; pct=50Monter progressivement
S9-S10p=quarantine; pct=100Observer pendant 2 semaines
S11-S12p=reject; pct=10Début du rejet progressif
S13-S14p=reject; pct=50Montée en charge
S15+p=reject; pct=100; sp=rejectProtection complète

Cette timeline est indicative. L’essentiel est de ne jamais sauter d’étape sans avoir vérifié que les rapports sont propres.

Étape 1 : inventorier toutes les sources

Pendant les premières semaines en p=none, les rapports DMARC révèlent toutes les IP qui envoient des emails au nom de votre domaine. Classez-les :

Sources légitimes connues

  • Votre serveur mail (IP propre)
  • Votre ESP principal (Brevo, Mailchimp, SendGrid…)
  • Google Workspace / Microsoft 365

Shadow IT (sources légitimes mais non gérées)

  • Outils marketing (HubSpot, Salesforce, Intercom…)
  • Services transactionnels (Stripe, Zendesk, Freshdesk…)
  • Outils internes avec envoi email

Sources non légitimes

  • IP inconnues avec DKIM et SPF qui échouent → usurpation

Le dashboard Sender Audit classe automatiquement les sources par statut pour faciliter ce tri.

Étape 2 : corriger les sources légitimes

Pour chaque source légitime qui échoue :

SPF manquant

Ajoutez le mécanisme include: correspondant dans votre record SPF :

v=spf1 include:_spf.google.com include:spf.brevo.com include:sendgrid.net -all

DKIM manquant

Activez DKIM personnalisé chez chaque ESP/service. Typiquement : ajoutez un CNAME ou TXT dans votre DNS, puis activez dans l’interface du service.

Vérifiez avec le DKIM Checker.

Alignement cassé

SPF ou DKIM passent, mais le domaine n’est pas aligné avec le From:. C’est fréquent avec les services qui utilisent leur propre domaine en Return-Path. Solution : configurez un domaine de bounce personnalisé, ou appuyez-vous sur DKIM (qui s’aligne via le d=).

Étape 3 : gérer le shadow IT

C’est souvent l’étape la plus longue. Le shadow IT, ce sont les services que des équipes utilisent pour envoyer des emails depuis votre domaine, sans que l’IT le sache.

Comment les trouver : les rapports DMARC montrent des IP inconnues avec un spf=pass (elles sont dans votre SPF) mais dkim=fail.

Que faire :

  1. Identifiez le service via rDNS ou whois de l’IP
  2. Contactez l’équipe concernée
  3. Configurez DKIM pour ce service, ou
  4. Retirez l’autorisation SPF si le service ne devrait pas envoyer avec votre domaine

Étape 4 : monter progressivement

Le tag pct=

Le tag pct= (pourcentage) permet de n’appliquer la politique qu’à une fraction du trafic :

v=DMARC1; p=quarantine; pct=10; rua=mailto:your-rua@example.com

Ici, 10% des emails qui échouent DMARC seront mis en spam. Les 90% restants sont traités comme p=none. C’est votre filet de sécurité.

Utilisez le DMARC Generator pour ajuster facilement les tags pct= et p=.

De quarantine à reject

quarantine envoie les emails échoués en spam. reject les bloque complètement. La transition de l’un à l’autre est moins risquée car vous avez déjà validé que vos flux légitimes passent DMARC.

Étape 5 : protéger les sous-domaines

N’oubliez pas le tag sp= (subdomain policy). Sans lui, les sous-domaines héritent de la politique du domaine parent. Mais un attaquant peut utiliser facturation.votredomaine.com pour du phishing.

v=DMARC1; p=reject; sp=reject; rua=mailto:your-rua@example.com

Les 5 pièges à éviter

  1. Passer directement à p=reject sans période d’observation : vous risquez de bloquer vos propres emails
  2. Ne pas surveiller les rapports à chaque étape : un nouveau service SaaS ajouté par une équipe peut casser
  3. Oublier les sous-domaines : sp=none par défaut laisse la porte ouverte
  4. SPF avec ~all au lieu de -all : en mode quarantine/reject, le softfail SPF affaiblit la protection
  5. Ignorer les services transactionnels : confirmations de commande, factures, notifications, ils utilisent souvent votre domaine

Checklist de migration

  • Record DMARC publié avec rua=
  • Rapports collectés pendant au moins 2 semaines
  • Toutes les sources légitimes identifiées
  • SPF corrigé (toutes les sources incluses, -all)
  • DKIM activé sur tous les ESP/services
  • Shadow IT traité
  • p=quarantine testé avec pct= progressif
  • p=reject testé avec pct= progressif
  • sp=reject ajouté
  • Monitoring continu en place

Pour aller plus loin