En février 2024, Google et Yahoo ont imposé DMARC à tout expéditeur dépassant 5 000 messages par jour vers leurs utilisateurs. Résultat attendu : une accélération de l’adoption. Résultat réel, selon les données Valimail 2024 : sur les quelque 20 millions de domaines qui ont publié un enregistrement DMARC, environ 11,6 millions restent bloqués à p=none, en mode observation, sans protection active. Seulement 28,5 % ont atteint p=reject. Entre les deux, p=quarantine est souvent mal comprise : beaucoup la traitent comme une destination, alors qu’elle fonctionne comme une phase instrumentée.
Réponse directe : p=quarantine s’active quand vos rapports RUA montrent que vos sources légitimes sont alignées SPF ou DKIM sur votre domaine expéditeur. Le tag pct= sert à monter la pression progressivement, en limitant les dégâts si une source a été oubliée. Une fois que vos agrégats atteignent un taux d’alignement stable au-dessus de 95 %, la transition vers p=reject devient lisible dans vos données.
Ce que p=quarantine fait réellement et ce qu’elle ne garantit pas
Quand un MTA destinataire reçoit un message qui échoue au check DMARC sur votre domaine expéditeur, la politique quarantine lui demande d’acheminer ce message vers le dossier spam du destinataire, sans le rejeter définitivement.
Les messages de spoofing ou de phishing qui usurpent votre domaine finissent en indésirables chez le destinataire, au lieu d’atterrir en boîte de réception. Mieux que p=none, qui ne change rien au routage. Mais un message mis en quarantine peut être retrouvé par l’utilisateur final, ce qui laisse une fenêtre pour l’ingénierie sociale. p=quarantine réduit l’exposition sans l’éliminer ; sa vraie valeur tient aux données qu’elle expose pendant le déploiement.
La RFC 9989 (qui remplace RFC 7489 depuis mai 2026) est explicite : quarantine est une recommandation au récepteur, pas une instruction impérative. Gmail dépose le message en spam. Outlook peut appliquer un marquage ou sa propre logique de filtrage. Un MTA mal configuré peut simplement livrer le message normalement.
Les 3 signaux qui indiquent que p=none a rempli son rôle
Toutes vos sources d’envoi légitimes apparaissent dans les agrégats et passent l’alignement DKIM ou SPF. Si une plateforme d’emailing, un outil de ticketing ou un serveur SMTP interne n’est pas dans vos rapports, il n’est pas encore configuré ou il envoie en dehors de votre enregistrement SPF. Déployer quarantine dans cet état, c’est risquer de mettre ces messages en spam.
Deuxième signal : aucune IP légitime n’échoue de façon répétée dans vos agrégats. Des échecs isolés (tests, forwarding ponctuel) sont normaux. Des échecs récurrents sur un volume significatif signalent une configuration incomplète à corriger avant de progresser.
Troisième signal : la part de messages non alignés est majoritairement du spoofing réel, pas vos propres envois mal configurés. Si vos rapports RUA montrent que 80 % des échecs viennent d’IPs inconnues, p=none a fait son travail. Si 40 % viennent de vos propres serveurs, corrigez d’abord.
Déployer p=quarantine avec pct= : la montée en puissance semaine par semaine
Le tag pct= indique au MTA destinataire le pourcentage des messages échouants sur lesquels appliquer la politique déclarée. À pct=10, 90 % des messages qui échouent au check DMARC sont traités comme si la politique était p=none (livrés normalement) ; seuls 10 % sont mis en quarantine.
Cela a une implication souvent mal comprise : pct= ne protège pas les 90 % restants. Si une source de spoofing échoue au check, elle passe quand même dans 90 % des cas à pct=10. Le tag est conçu pour protéger votre déploiement, en limitant l’impact d’une source légitime oubliée pendant la montée en charge.
« The pct tag was conceived as a way to allow domain owners to do a slow rollout of DMARC enforcement, building their confidence in the setup over time. » (Valimail, documentation technique du tag pct=)
Séquence recommandée, à ajuster selon le volume et la stabilité de vos agrégats :
- Semaines 1-2 :
v=DMARC1; p=quarantine; pct=5; rua=mailto:.... Observer les rapports quotidiennement. Vérifier que le ratio d’alignement sur vos sources légitimes reste stable. - Semaines 3-4 : monter à
pct=10. Aucune nouvelle source légitime apparue en échec ? Continuer. - Semaines 5-6 :
pct=25. C’est souvent ici qu’une source oubliée se manifeste, les volumes devenant significatifs dans les agrégats. - Semaines 7-9 :
pct=50. Le delta entre vos agrégats précédents et actuels doit rester sous 2 points de taux d’échec. Au-delà, investigation avant de continuer. - Semaines 10-12 :
pct=100. Stabiliser deux à trois semaines avant d’envisager p=reject.
La cadence ci-dessus est indicative. Des domaines à fort volume peuvent compresser chaque palier à 5 jours si leurs rapports RUA sont exploités en temps réel. Des domaines mixtes avec de nombreuses sources tierces gagnent à tenir chaque palier trois semaines.
Lire ses rapports RUA pour savoir quand passer à p=reject
Un rapport agrégat RUA contient, par expéditeur et par IP source, le nombre de messages reçus, le résultat SPF, le résultat DKIM et l’évaluation DMARC finale. Les outils comme EasyDMARC, DMARC Analyzer ou Dmarcian les visualisent par graphes de tendance. Sans outil, un grep sur les champs <disposition> et <dkim>/<spf> dans les fichiers XML suffit à identifier les patterns critiques.
Le premier chiffre à surveiller : le taux d’alignement global, c’est-à-dire le pourcentage de messages qui passent DMARC sur l’ensemble du trafic sortant légitime. En pratique, 95 % est le seuil minimal avant de considérer reject ; 98 % est le seuil habituel retenu par les équipes postmaster expérimentées avant de désactiver pct= et de passer à l’enforcement total. En dessous de 95 %, il reste des sources légitimes mal configurées.
Le second : la stabilité sur au moins 4 semaines consécutives. Un taux d’alignement élevé sur une seule semaine peut refléter un creux saisonnier ou une période de faible volume. Quatre semaines en continu éliminent ces biais. À noter : les rapports RUF (forensiques, message par message) donnent plus de granularité mais sont moins largement supportés par les MTA destinataires. Les décisions de passage à p=reject se basent sur les agrégats RUA ; les RUF servent au diagnostic ponctuel.
Les erreurs qui bloquent la transition ou la font rater
Cinq ans après le déploiement du standard, le blocage le plus fréquent reste identique : des sources d’envoi légitimes configurées en dehors du domaine principal sans alignement DKIM. Une plateforme CRM qui envoie en From: @votre-domaine.com sans DKIM signé sur votre domaine, c’est un échec DMARC garanti à chaque envoi. Et à pct=100 p=quarantine, tous ces messages finissent en spam.
Le piège classique ici est de confondre SPF pass et alignement DMARC. SPF peut passer si l’IP d’envoi est dans votre enregistrement SPF mais l’alignement DMARC exige que le domaine dans le Return-Path (SPF) ou dans la signature DKIM corresponde au domaine du From:. Beaucoup de plateformes tierces envoient avec leur propre Return-Path pour gérer les bounces, ce qui casse l’alignement SPF même si SPF passe.
Deuxième erreur : maintenir p=quarantine indéfiniment sans progression pct=. Selon les données EasyDMARC 2025 portant sur 1,8 million de domaines, près d’un domaine sur cinq avec DMARC actif est en couverture partielle (quarantine ou rollout progressif) sans jamais avancer vers l’enforcement.
Troisième point souvent négligé : le forwarding email. Les messages transférés par un serveur intermédiaire cassent généralement SPF (l’IP du forwarder n’est pas dans votre enregistrement SPF) et peuvent casser DKIM si le corps est modifié. Ces échecs apparaissent dans vos RUA et font baisser artificiellement votre taux d’alignement global. Identifier les IPs de forwarding dans vos agrégats avant de comptabiliser votre taux réel évite de retarder inutilement le passage à p=reject.
La progression vers p=reject tient à une lecture régulière des RUA. Le standard BIMI, qui exige p=reject comme condition préalable, commence à peser dans les arbitrages ; les agrégats DMARC ne couvrent pas cette couche d’authentification.
