« En 2022, nous avons commencé à exiger une forme d’authentification pour tous les emails envoyés vers une adresse Gmail. Le nombre de messages non authentifiés reçus par les utilisateurs Gmail a chuté de 75 % », écrivait Neil Kumaran, Group Product Manager Gmail Security & Trust chez Google, dans un billet officiel du blog Google publié en octobre 2023.
Passer un domaine de p=none à p=reject suit 3 phases obligatoires : observation des rapports agrégés pendant 2 à 4 semaines, correction des sources non alignées, puis montée progressive du taux d’application (pct=) jusqu’au rejet complet. Comptez 8 à 12 semaines pour un domaine avec peu de sources d’envoi, davantage si la liste de destinataires n’a jamais été nettoyée.
Depuis novembre 2025, Gmail ne se contente plus d’un avertissement temporaire sur le trafic non conforme : il rejette directement au niveau SMTP. Une bascule mal calée sur ce calendrier explique une partie des chutes de score seedlist constatées sans raison apparente après une mise à jour Gmail, sans que rien n’ait changé côté DNS.
Vérifier que SPF et DKIM sont alignés avant de toucher au DNS
DMARC s’appuie sur l’alignement SPF, la signature DKIM et, plus rarement, la validation ARC pour le mail transféré. Sans ça, DMARC n’a rien à valider. Publier un enregistrement DMARC alors que SPF échoue sur la moitié du trafic ne fait que remplir les rapports d’échecs inutiles à trier.
Vérifiez que chaque source d’envoi légitime (CRM, facturation, plateforme d’emailing) passe SPF ou DKIM en alignement relaxed avec le domaine visible dans l’en-tête From. Le PTR record (reverse DNS) de vos IP d’envoi compte aussi. Google et Yahoo l’exigent depuis février 2024 au-delà de 5 000 messages par jour vers leurs domaines.
Publier l’enregistrement DMARC en p=none (phase 1)
Ouvrez la zone DNS de votre domaine et ajoutez un enregistrement TXT sur _dmarc.votredomaine.fr. Contenu : v=DMARC1; p=none; rua=mailto:rapports@votredomaine.fr; fo=1. Réglez le TTL à 3600 puis sauvegardez la modification depuis l’interface DNS de votre hébergeur ou registrar. Ça prend cinq minutes.
Un deuxième enregistrement TXT présent sur le même sous-domaine invalide toute la politique : les serveurs de réception ne savent plus lequel appliquer et traitent souvent le domaine comme non protégé. Vérifiez qu’un seul enregistrement existe avec la commande dig TXT _dmarc.votredomaine.fr dans un terminal.
La balise rua pointe vers l’adresse ou l’outil qui recevra les rapports agrégés au format XML, envoyés une fois par jour par chaque grand récepteur (Gmail, Yahoo, Microsoft, Outlook.com). C’est la seule source de vérité sur qui envoie réellement en votre nom.
Lire les rapports RUA et corriger les sources non alignées
Chaque rapport XML contient une balise policy_evaluated avec une disposition, c’est-à-dire le sort réel du message côté récepteur, aligné ou non avec la politique publiée. Ouvrir ces fichiers à la main devient vite ingérable au-delà de quelques dizaines par semaine. Un parseur open source comme parsedmarc agrège les résultats par source IP et par volume. Un outil hébergé type dmarcian ou EasyDMARC fait le même travail avec un tableau de bord (Validity propose une variante orientée grands comptes).
La documentation officielle de Google et Microsoft donne les prérequis DNS mais rarement le seuil qui dit quand avancer sans risque. dmarcian recommande un compliance rate supérieur à 98 % par domaine avant de passer à la phase suivante : en dessous, une partie du trafic légitime finira quarantinée ou rejetée dès l’enforcement activé.
Ne sautez pas cette phase. Chaque source qui échoue encore (ancien serveur SMTP, outil marketing oublié, sous-domaine de test) doit être corrigée ou déplacée sous son propre sous-domaine avec sa propre politique sp= avant de resserrer quoi que ce soit.
Passer à p=quarantine avec une montée progressive du pct=
Une fois le compliance rate stabilisé, modifiez la balise en p=quarantine; pct=10;. La balise pct= fixe le pourcentage de messages non alignés soumis à la politique choisie et expose 10 % du trafic non conforme à la quarantaine sans engager tout le domaine. Surveillez les rapports une semaine, montez à 25, puis 50, puis 100 si aucun email légitime n’atterrit en spam à chaque palier.
Yahoo applique une nuance propre au protocole : certains messages non authentifiés reçoivent une évaluation dmarc=bestguesspass dans ses propres en-têtes de réception, une estimation interne qui ne correspond à aucune balise DMARC officielle. Un domaine qui voit ce résultat dans les retours Yahoo bénéficie d’une tolérance temporaire du récepteur, sans que cela reflète une vraie conformité DMARC.
Passer à p=reject : les seuils qui déclenchent le go
Le passage en p=reject suit la même logique de rampe que la quarantaine : pct=10, puis palier par palier jusqu’à 100, en conservant le monitoring RUA actif en continu. Deux seuils Google conditionnent la suite, mesurés dans Google Postmaster Tools : un spam rate reporté sous 0,10 %, avec interdiction d’atteindre 0,30 % ou plus. Microsoft applique son équivalent via SNDS (Smart Network Data Services) pour les domaines qui envoient vers Outlook.com et Hotmail.com. Le tableau de bord SNDS affiche un indicateur de réputation par plage d’IP (vert, jaune, rouge), calculé sur le volume de plaintes et les pièges à spam touchés, à surveiller au même titre que le compliance rate des rapports DMARC.
« En avril 2024, nous avons commencé à rejeter un pourcentage du trafic non conforme et nous augmentons progressivement ce taux de rejet » (consignes expéditeurs de Google, citées par MarTech, 2024).
Ce mécanisme tourne indépendamment du pct= choisi sur votre propre enregistrement DMARC : Google applique sa propre montée en charge côté réception, en plus de la politique publiée côté émetteur. Les deux ramps ne sont pas synchronisées, ce qui explique des variations de délivrabilité même quand le DNS n’a pas bougé.
Fin 2025, Red Sift a mesuré que seulement 2,5 % des 73,3 millions de domaines analysés appliquaient effectivement p=reject, contre 14,9 % ayant publié au minimum un enregistrement DMARC en p=none. Un rapport distinct de Valimail (2024) évaluait à 28,5 % la part des domaines ayant déjà un enregistrement DMARC qui atteignaient p=reject. La majorité des organisations reste donc en observation permanente, sans protection réelle contre l’usurpation. Un domaine qui atteint p=reject à pct=100 devient également éligible à BIMI (affichage du logo de marque dans la boîte de réception), sous réserve d’un certificat VMC pour les domaines vérifiés Gmail.
Le mail transféré casse l’alignement DMARC
Un message relayé par une règle de transfert ou une liste de diffusion perd généralement son alignement SPF : l’IP d’envoi change alors que l’en-tête From reste celui de l’expéditeur d’origine. La signature DKIM survit si le corps du message n’est pas modifié en chemin, ce qui sauve l’alignement dans la majorité des cas de simple redirection. La validation ARC (ARC sealing) aide certains récepteurs à reconstruire la chaîne de confiance. Tous ne la reconnaissent pas encore.
Un rejet SMTP 550 5.1.1 user unknown est un hard bounce classique, sans rapport avec l’authentification DMARC : l’adresse destinataire n’existe plus. Confondre les deux dans un rapport agrégé fait perdre du temps à corriger une source qui n’a jamais posé de problème d’authentification. Avant d’augmenter le pct= vers 100, passez la liste de destinataires actifs au crible : ça évite ce genre de faux positif et limite l’impact d’une hygiène de liste dégradée sur le complaint rate au moment de l’enforcement.
Questions fréquentes sur le passage de p=none à p=reject
Combien de temps faut-il pour passer de p=none à p=reject ? Entre 8 et 12 semaines pour un domaine avec peu de sources d’envoi déjà propres. Un domaine avec des dizaines d’outils marketing ou de sous-domaines historiques prend souvent plusieurs mois de plus pour identifier et corriger chaque source.
Que se passe-t-il exactement en p=quarantine ? Les messages qui échouent à l’alignement SPF ou DKIM sont livrés dans le dossier spam du destinataire plutôt que rejetés. Le volume concerné dépend directement du pct= configuré sur l’enregistrement.
DMARC est-il obligatoire pour envoyer vers Gmail et Yahoo ? Un enregistrement DMARC en p=none minimum est exigé depuis février 2024 pour tout expéditeur dépassant 5 000 messages par jour vers ces domaines. En dessous de ce volume, DMARC reste recommandé mais non imposé par le mandat.
Votre enregistrement DMARC est publié en p=none et les rapports RUA arrivent. Corrigez chaque source non alignée avant de toucher au pct=. Lancez ensuite une vérification de votre liste de destinataires actifs avant la première montée vers p=quarantine.
