DMARC : passer de p=none à p=reject sans perdre de courrier

Dernière mise à jour : 4 novembre 2026

La plupart des domaines qui publient un DMARC s'arrêtent à p=none. C'est compréhensible (personne ne veut bloquer ses propres factures), mais il faut être clair sur ce que cela signifie : un DMARC en p=none n'empêche absolument rien. Il observe. N'importe qui peut usurper votre domaine, et aucun destinataire ne le rejettera.

C'est une étape, pas une destination.

Ce que DMARC fait réellement

DMARC ne vérifie rien par lui-même. Il s'appuie sur SPF et DKIM, et ajoute deux choses qui leur manquaient.

L'alignement. SPF authentifie l'enveloppe SMTP, DKIM authentifie une signature : ni l'un ni l'autre ne regarde l'adresse que votre destinataire voit affichée. DMARC exige que le domaine authentifié corresponde à celui du champ De :. C'est ce qui ferme la porte à l'usurpation.

Une instruction. DMARC dit aux serveurs destinataires quoi faire quand l'alignement échoue. C'est le fameux tag p.

Un message passe DMARC si au moins un des deux mécanismes réussit et s'aligne. Les deux ne sont pas nécessaires.

Les trois politiques

p=none : observer, ne rien faire. Les messages usurpés arrivent normalement. Utile uniquement pour collecter des rapports.

p=quarantine : les messages qui échouent partent en indésirables. La protection commence réellement ici.

p=reject : les messages qui échouent sont refusés au niveau du serveur. Ils n'atteignent jamais la boîte, pas même le dossier spam.

L'étape que presque tout le monde oublie

Avant de parler de durcissement, il faut regarder une chose : votre DMARC contient-il un tag rua ?

v=DMARC1; p=none; rua=mailto:rapports-dmarc@exemple.fr
        

Sans rua, vous ne recevez aucun rapport. Votre DMARC en p=none ne sert alors littéralement à rien : il n'empêche rien et ne vous apprend rien. C'est la configuration la plus répandue, et la plus inutile.

Avec rua, les grands opérateurs (Google, Microsoft, Yahoo et quelques centaines d'autres) vous envoient chaque jour un rapport XML listant qui a envoyé du courrier en votre nom, depuis quelles adresses, et si cela passait l'authentification.

C'est la seule action vraiment urgente. Elle est gratuite, sans aucun risque, et réversible. Ajoutez-la aujourd'hui, même si vous ne touchez à rien d'autre pendant six mois.

La progression, étape par étape

Étape 1 : Observer, deux à quatre semaines

Publiez p=none avec un rua, et ne changez rien d'autre. Laissez les rapports s'accumuler le temps d'un cycle complet d'activité : une facturation mensuelle, une infolettre trimestrielle, une campagne saisonnière.

C'est la durée qui compte, pas le volume. Un service qui n'envoie qu'une fois par trimestre n'apparaîtra pas dans deux semaines de rapports : et c'est exactement celui que vous bloquerez par surprise.

Étape 2 : Inventorier vos expéditeurs

Les rapports sont du XML brut, peu lisible à l'œil. Plusieurs services gratuits les agrègent en tableaux ; vous pouvez aussi les ouvrir dans un tableur.

Ce que vous cherchez : toutes les sources qui envoient en votre nom et échouent à l'alignement. Vous en découvrirez presque certainement que vous aviez oubliées : un outil de facturation, un formulaire de contact, un CRM, une application métier, le serveur d'un prestataire.

Pour chacune, deux questions seulement : est-ce légitime, et si oui comment l'aligner ?

Étape 3 : Aligner les sources légitimes

Pour chaque expéditeur légitime, la correction dépend du cas :

• un prestataire d'emailing : activez sa « domain authentication », qui publie des enregistrements DKIM à votre nom. C'est la meilleure solution, car DKIM survit au transfert de messages ;
• un serveur interne : ajoutez son adresse au SPF, en surveillant la limite de dix résolutions ;
• un outil qui envoie depuis sa propre adresse : faites-lui utiliser un sous-domaine à vous, ou acceptez qu'il n'envoie plus en votre nom.

Reprenez les rapports jusqu'à ce que tout ce qui est légitime passe. Ce qui reste en échec est soit une usurpation, soit un service oublié.

Étape 4 : Protéger les sous-domaines d'abord

C'est le levier le plus rentable, et le moins connu. Le tag sp fixe une politique pour vos sous-domaines, indépendamment du domaine principal :

v=DMARC1; p=none; sp=reject; rua=mailto:rapports-dmarc@exemple.fr
        

Pourquoi c'est intéressant : vos sous-domaines inexistants (facture., compta., support.) sont des cibles classiques d'hameçonnage, précisément parce qu'ils ne publient rien. Les verrouiller ne présente aucun risque, puisque aucun message légitime n'en part.

Vous obtenez une vraie protection contre un vecteur d'attaque courant, tout en laissant votre domaine principal en observation. Attention toutefois : un sous-domaine qui publie son propre DMARC n'hérite pas du sp du parent, il faut le durcir séparément.

Étape 5 : Passer en quarantaine

Quand les rapports sont propres, passez à p=quarantine. Les messages non alignés partent en indésirables : si vous avez manqué un expéditeur légitime, ses messages sont récupérables, et quelqu'un vous le signalera.

Restez-y deux à quatre semaines. Continuez à lire les rapports.

Étape 6 : Rejeter

p=reject. Les messages usurpant votre domaine sont refusés avant livraison. Votre domaine n'est plus utilisable pour de l'hameçonnage à votre nom.

Ce qu'on vous dira à tort

« Il faut passer SPF en -all avant p=reject. » Non. Avec un DMARC en application, c'est DMARC qui tranche. Et -all casse les messages transférés, car SPF échoue dès qu'un intermédiaire relaie le message. Beaucoup de grands expéditeurs gardent délibérément ~all : PayPal, par exemple, combine p=reject et ~all. Ce n'est pas une négligence, c'est un choix.

« pct= permet un déploiement progressif. » Ce tag applique la politique à un pourcentage des messages. Il est en cours d'abandon dans la révision de la norme et son comportement est inégal selon les opérateurs. Préférez la progression par étapes décrite ci-dessus, plus prévisible.

« DMARC protège contre tous les hameçonnages. » Non : il protège contre l'usurpation de votre domaine exact. Un attaquant qui enregistre un domaine ressemblant au vôtre n'est pas concerné. C'est une autre bataille.

Vérifier où vous en êtes

Radar DNS affiche votre politique effective, la présence du rua, la couverture des sous-domaines et l'héritage par le domaine parent : un sous-domaine sans DMARC propre est couvert par celui de son domaine racine, ce que beaucoup d'outils signalent à tort comme « absent ».