Tout le monde sait qu'il faut passer sa politique DMARC à p=reject. Presque personne ne le fait. La raison est simple, et elle n'a rien de technique : le jour où vous basculez, si vous vous êtes trompé, les factures de votre ERP cessent d'arriver chez vos clients — et personne ne vient vous le dire. Les mails ne rebondissent pas avec un message clair ; ils disparaissent.
Ce risque est réel. Il est aussi entièrement évitable, à condition de ne pas confondre « publier un enregistrement DNS » et « conduire une migration ».
Pourquoi p=none ne protège de rien
Un rappel utile, parce que la confusion est fréquente. Une politique p=none demande aux serveurs destinataires : « dites-moi ce que vous recevez en mon nom, mais ne changez rien ». C'est un mode observation. Un attaquant qui usurpe votre domaine pendant que vous êtes en p=none verra ses messages livrés normalement — vous en aurez simplement le rapport quelques heures plus tard.
p=quarantine demande de traiter les échecs comme suspects, p=reject de les refuser. Seule la dernière ferme réellement la porte.
Ce qui casse réellement, et pourquoi
Dans les migrations que nous conduisons, les mails légitimes qui échouent à DMARC tombent presque toujours dans l'une de ces catégories.
Les services tiers qui envoient en votre nom. Outil de facturation, plateforme de recrutement, solution de signature électronique, routeur d'e-mails marketing, système de ticketing. Chacun a été branché un jour par une équipe différente, et personne ne tient la liste. C'est de très loin la première cause d'échec.
Les alignements manquants. Un message peut passer SPF et rester en échec DMARC : DMARC exige que le domaine validé par SPF corresponde à celui affiché dans l'en-tête From:. Beaucoup de plateformes envoient avec leur propre domaine d'enveloppe, ce qui valide SPF techniquement mais ne vous aligne pas.
Les redirections. Une adresse qui fait suivre le courrier vers une autre boîte casse SPF par construction — le serveur qui relaie n'est pas dans votre enregistrement. DKIM survit à la redirection, sauf si un équipement intermédiaire modifie le message.
Les listes de diffusion. Même mécanique, aggravée par les listes qui réécrivent l'objet ou ajoutent un pied de page : la signature DKIM saute.
La méthode, dans l'ordre
1. Publier en observation, et attendre vraiment
Publiez p=none avec une adresse de rapport agrégé, et laissez tourner. Deux semaines suffisent rarement : il faut couvrir au moins un cycle de facturation, une campagne marketing, une paie. Nous comptons quatre à six semaines sur un domaine principal.
L'objectif de cette phase n'est pas de collecter des rapports. C'est de constituer l'inventaire complet de ce qui envoie en votre nom — y compris ce que vous ignoriez.
2. Trier l'inventaire en trois piles
Chaque source identifiée va dans l'une des trois :
| Pile | Décision | Exemple typique |
|---|---|---|
| Légitime, à aligner | Configurer SPF et DKIM chez le prestataire | ERP, outil RH, marketing |
| Légitime, à supprimer | Couper la source, migrer l'usage | Vieux serveur d'impression, script oublié |
| Illégitime | Ne rien faire — c'est ce que p=reject bloquera | Hameçonnage, usurpation |
Cette troisième pile est celle qui justifie l'opération. Sur un domaine d'ETI un peu connu, elle représente couramment plusieurs milliers de messages par mois.
3. Aligner, sans toucher à la politique
Chez chaque prestataire légitime : activer la signature DKIM avec votre domaine, et vérifier que le domaine d'enveloppe est bien aligné. C'est du travail de configuration, prestataire par prestataire, et c'est la partie la plus longue. Elle ne présente aucun risque : tant que la politique reste p=none, rien ne peut être rejeté.
Privilégiez DKIM à SPF partout où c'est possible. DKIM survit aux redirections, ne consomme pas de résolution DNS, et ne dépend pas des adresses IP du prestataire — qui changeront sans vous prévenir.
4. Basculer par paliers, avec un pourcentage
DMARC accepte une balise pct qui n'applique la politique qu'à une fraction du trafic. C'est le filet de sécurité :
v=DMARC1; p=quarantine; pct=25; rua=mailto:...
Notre progression de référence, une étape par semaine, en vérifiant les rapports entre chaque :
p=quarantine; pct=25p=quarantine; pct=100p=reject; pct=25p=reject; pct=100
Un incident à 25 % se voit dans les rapports et se corrige avant qu'il ne touche les trois quarts restants. C'est toute l'idée.
5. Ne pas s'arrêter là
Un domaine à p=reject n'est pas un domaine réglé définitivement. Une acquisition, un nouvel outil SaaS, un prestataire qui change d'infrastructure : chacun de ces événements peut réintroduire une source non alignée. Sans surveillance, vous le découvrirez le jour où un client vous dira ne rien avoir reçu.
Combien de temps, en vrai
Sur un domaine principal avec une dizaine de sources légitimes, comptez six à dix semaines du premier enregistrement à p=reject; pct=100. L'essentiel de ce temps est de l'attente délibérée, pas de la charge de travail.
Sur un parc de cinquante domaines — le cas d'un groupe qui acquiert régulièrement — le travail n'est pas cinquante fois plus long : la plupart des domaines secondaires n'envoient rien du tout et peuvent passer directement en p=reject avec un SPF vide. Ce sont d'ailleurs les plus urgents : un domaine qui n'envoie jamais de courrier est la cible d'usurpation la plus facile qui soit, parce que personne ne surveille ce qui en part.