Passer DMARC en p=reject sans bloquer vos propres emails ? Signaux à lire, inventaire des flux, calendrier réaliste et plan de repli : la méthode.
Un domaine en p=reject dit aux messageries une chose simple : si un email se réclame de moi sans pouvoir le prouver, refusez-le. Sur le papier, c’est la meilleure protection contre l’usurpation. Dans les faits, peu d’entreprises françaises franchissent le pas. D’après l’Afnic, 19,5 % des domaines en .fr publiaient un enregistrement DMARC en 2025, et 20,6 % de ceux-là seulement appliquaient une politique de rejet. En croisant les deux chiffres, on tombe à environ un .fr sur vingt-cinq.
On comprend la prudence. Un reject mal préparé ne bloque pas que les fraudeurs. Il bloque aussi vos factures, vos relances commerciales, et la newsletter envoyée par ce prestataire que personne n’avait pensé à déclarer.
Les trois politiques DMARC graduent la réponse demandée au serveur destinataire. p=none ne demande rien : vous recevez des rapports, point. p=quarantine réclame un classement en courrier indésirable. p=reject demande le refus pur et simple, pendant la transaction SMTP.
Demander n’est pas obtenir, cela dit. La RFC 9989, qui a remplacé en mai 2026 la spécification DMARC d’origine, rappelle que le récepteur garde le dernier mot : il « MUST NOT reject incoming messages solely on the basis of a “p=reject” policy ». Faute d’autres éléments d’analyse, il doit traiter l’échec comme un quarantine. Le reject reste une instruction forte. Pas un interrupteur.
Tout se joue dans les rapports agrégés, ces fichiers XML que les messageries envoient à l’adresse indiquée dans la balise rua. Sans rua, passer en reject revient à avancer les yeux bandés. L’Afnic relève pourtant que 49,7 % des .fr dotés d’un DMARC restent en p=none sans la moindre adresse de rapport.
Trois signaux rendent la bascule envisageable. Vous avez rattaché chaque adresse IP qui envoie en volume au nom de votre domaine à un service connu. Chacune passe SPF ou DKIM avec un domaine aligné sur celui du champ From, la condition qui fait réussir DMARC. Et les échecs restants viennent soit de sources inconnues (des usurpateurs, donc), soit de transferts automatiques. Si un seul flux légitime échoue encore, on attend.
Notre guide pour configurer SPF, DKIM et DMARC détaille la mise en place de chaque protocole. L’enjeu, ici, c’est la suite : s’assurer que chaque expéditeur signe bien à votre nom.
Les rapports DMARC font ressortir les gros émetteurs. Les petits passent sous le radar, parce qu’un outil qui envoie trente emails par semaine se noie dans les statistiques. Et c’est souvent lui qui coince le jour du reject.
Faites le tour, service par service. Le CRM et ses séquences commerciales, le logiciel de facturation, l’outil RH qui envoie les convocations, le support client, les formulaires du site, le standard qui transfère les messages vocaux par email, et bien sûr le routeur emailing. Pour chacun, une seule question : avec quel domaine signe-t-il en DKIM ?
Le cas du routeur mérite qu’on s’y arrête. Beaucoup de plateformes signent par défaut avec leur propre domaine et utilisent leur propre adresse de retour (le return-path). Le message passe SPF et DKIM, mais pour le domaine du prestataire, pas pour le vôtre. Résultat, DMARC échoue alors que tout semble en ordre. La correction passe par une signature DKIM à votre nom, publiée dans votre DNS, ou par un return-path personnalisé sur un sous-domaine qui vous appartient.
Microsoft conseille d’ailleurs d’isoler les envois en masse sur un sous-domaine dédié, du type news.votredomaine.fr, et de commencer la bascule par les sous-domaines à faible volume pour traiter le domaine parent en dernier. Un sous-domaine qui publie son propre enregistrement DMARC suit son propre calendrier. Pratique quand le marketing n’est pas prêt mais que la direction veut verrouiller le domaine principal.
Sur le tempo, les recommandations divergent. Dans son guide de déploiement pour Workspace, Google demande que SPF et DKIM fonctionnent depuis au moins 48 heures avant d’ajouter DMARC, puis conseille environ une semaine en p=none avec une lecture quotidienne des rapports. Vient ensuite un quarantine appliqué à une fraction croissante des messages, 10 % pour une petite structure, 1 % pour une grande. Google qualifie même le reject d’étape optionnelle.
La RFC 9989 se montre bien plus prudente pour les domaines dont les utilisateurs écrivent sur des listes de diffusion : au moins un mois en p=none, puis une durée équivalente en quarantine.
Pour une PME qui envoie campagnes, factures et emails commerciaux depuis le même domaine, nous conseillons de viser deux à trois mois. Quelques semaines pour l’inventaire et les corrections, un mois de quarantine progressif, puis le reject. Pensez aussi à abaisser le TTL de l’enregistrement DNS à quelques minutes avant chaque changement. Si un flux oublié tombe, le retour en quarantine se propagera presque tout de suite.
Jusqu’ici, la montée en charge reposait sur pct, qui appliquait la politique à un pourcentage des messages en échec. Google et Microsoft le citent encore dans leur documentation. La RFC 9989 l’a pourtant supprimé, avec un constat assez sévère : ce tag « was usually not accurately applied, unless the value specified was either 0 or 100 ».
Son remplaçant s’appelle t=y, un mode test qui demande au récepteur d’appliquer la politique d’un cran en dessous. Un p=reject; t=y se comporte donc comme un quarantine. Petit piège tout de même : la norme impose d’ignorer les balises inconnues. Un serveur qui n’a pas encore adopté DMARCbis lira votre p=reject sans tenir compte du t=y. Pendant la transition, le plus sûr reste de passer réellement par p=quarantine plutôt que de miser sur le mode test.
Certains échecs ne dépendent pas de vous. Un transfert automatique casse SPF, puisque le message repart d’un serveur que vous n’avez jamais déclaré. Une liste de diffusion qui ajoute un pied de page ou retouche l’objet du message casse la signature DKIM. Microsoft le reconnaît sans détour : « it’s almost inevitable that you’re going to get some false positives ».
Le protocole ARC (RFC 8617) atténue le problème en conservant les résultats d’authentification d’origine tout au long du trajet, encore faut-il que l’intermédiaire le prenne en charge. Pour un domaine dont les salariés participent à des listes professionnelles ou associatives, le reject a donc un coût, et la RFC conseille de prévenir les utilisateurs que leur participation risque d’être perturbée. À vous de le peser face au risque d’usurpation qui, pour un domaine utilisé en prospection B-to-B, se paie directement en réputation.
Techniquement, oui. Mais sans phase de quarantine, un flux légitime mal aligné se fait refuser sans que personne ne s’en aperçoive côté émetteur. Google comme Microsoft recommandent une progression par étapes, avec un quarantine monté graduellement avant le rejet. Gardez vos rapports agrégés actifs pendant toute la transition.
Avec quarantine, le serveur accepte le message en échec DMARC mais le classe en courrier indésirable, où le destinataire peut encore le retrouver. Avec reject, il le refuse pendant la transaction SMTP et l’expéditeur reçoit un rebond. Le reject protège mieux contre l’usurpation, mais une erreur de configuration y coûte aussi plus cher.
Non. Google et Microsoft demandent aux expéditeurs de plus de 5 000 messages par jour un enregistrement DMARC aligné, et p=none suffit pour être conforme. Le reject relève d’un choix de sécurité. Exception notable : BIMI, qui affiche votre logo dans la boîte de réception, exige une politique en quarantine ou en reject.
Le temps de connaître tous vos expéditeurs. Google parle d’environ une semaine, la RFC 9989 d’au moins un mois pour les domaines exposés aux listes de diffusion. Si vous utilisez plusieurs outils d’envoi, un mois est un minimum raisonnable, car certains flux ne partent qu’en fin de mois, comme les factures.
Repassez tout de suite en p=quarantine pour limiter les dégâts pendant l’enquête. Cherchez ensuite dans les rapports agrégés l’adresse IP en échec, retrouvez le service qui l’utilise, puis corrigez sa signature DKIM ou son return-path. Ne revenez au reject qu’après un cycle complet d’envois sans échec sur ce flux.
Les documentations de Google et Microsoft le mentionnent toujours, mais la RFC 9989, publiée en mai 2026, l’a retiré de la norme au profit du tag t. Vous pouvez encore l’utiliser pendant la transition, sans en attendre une application précise : la RFC elle-même constate que seules les valeurs 0 et 100 étaient correctement appliquées.
Vos campagnes partent d’un routeur et vous préparez le passage en reject ? Vérifiez d’abord que la signature DKIM est bien à votre nom. Ediware fournit une clé DKIM spécifique à chaque domaine client, et notre équipe répond à vos questions de configuration, au téléphone et en français. Contactez-nous.
Ce contenu est réalisé par Ediware. Consultez les sites officiels pour les informations les plus récentes.