Comment lire la politique DMARC d'une entreprise en dix secondes (et ce qu'elle ne vous dit pas)

Une seule requête DNS vous indique ce qu'une entreprise a demandé aux serveurs de messagerie mondiaux de faire avec les messages falsifiés envoyés en son nom. L'enregistrement est public, et la commande tient en une ligne : dig +short TXT _dmarc.example.com. Ce qui s'affiche est une courte chaîne de paramètres, et à l'intérieur se trouve une instruction — p=none, p=quarantine ou p=reject — qui indique la préférence du propriétaire du domaine lorsqu'un message utilisant ce domaine échoue l'authentification.

La spécification actuelle, RFC 9989, publiée en mai 2026 en tant que document de la piste des standards IETF, a remplacé l'ancienne RFC 7489. Elle définit les trois valeurs de manière presque lapidaire :

• p=none — « Le propriétaire du domaine n'exprime aucune préférence. »
• p=quarantine — « Le propriétaire du domaine considère que ce courrier est suspect. Il est possible que le courrier soit valide, bien que l'échec de l'authentification crée une préoccupation importante. »
• p=reject — « Le propriétaire du domaine considère que tous ces échecs indiquent clairement que l'utilisation du nom de domaine n'est pas valide. »

Relisez ces mots avec attention, car ils sont plus faibles que la plupart des explications de DMARC ne l'admettent. Une politique est une préférence, publiée par l'expéditeur pour que les destinataires la considèrent. Ce n'est pas une instruction que le destinataire est obligé d'exécuter. RFC 9989 l'affirme en une phrase : « Le traitement final de tout message est toujours une question de politique locale et reste à la discrétion du destinataire de courrier. » La même section ajoute les deux aspects de la conséquence — les destinataires « PEUVENT choisir de rejeter ou de mettre en quarantaine un message même s'il passe la vérification de validation DMARC », et ils « NE DOIVENT PAS rejeter les messages simplement en raison d'une politique publiée de « rejet » », précisément pour que le courrier légitime envoyé d'une manière que DMARC ne peut pas décrire, et les listes de diffusion, ne soient pas détruits dans le processus.

Donc qu'est-ce que p=none confesse réellement ? Moins que ce dont on l'accuse habituellement. Selon les termes de la spécification, c'est le Mode de surveillance : le propriétaire du domaine collecte les rapports agrégés et « n'exprime aucune préférence de traitement pour les messages qui échouent la validation DMARC », tandis qu'un destinataire qui déploie DMARC « peut toujours » valider l'utilisation du domaine. Ce qu'il ne fait pas, c'est désactiver quoi que ce soit au bout du destinataire. Le filtrage anti-spam de votre fournisseur, la notation de réputation, les vérifications d'URL et l'analyse des pièces jointes sont des mécanismes distincts qui fonctionnent quel que soit ce que l'expéditeur a publié. Un message falsifié arrivant à un domaine p=none n'est pas promu dans votre boîte de réception par l'enregistrement ; il est simplement remis au destinataire sans préférence affichée, et c'est le destinataire qui décide.

L'autre moitié du malentendu fonctionne dans l'autre sens. DMARC ne lit pas la partie dangereuse d'un email de phishing. Sa propre spécification énumère ce qui est délibérément exclu du champ d'application, et « l'analyse de contenu » figure sur cette liste, dans ces termes mêmes. Elle indique aussi que DMARC « ne traite pas l'utilisation de noms de domaine visuellement similaires ni l'abus du nom d'affichage lisible pour l'homme RFC5322.From » — les deux astuces qui transportent la plupart des messages d'usurpation de marque. Et sur la valeur d'une validation réussie : « une validation DMARC en elle-même ne garantit pas que la livraison dans la boîte de réception du destinataire serait sûre ou souhaitable. » Un message correctement authentifié d'un domaine jetable valide DMARC proprement. DMARC répond à la question : qui était autorisé à utiliser le domaine dans l'en-tête From : ? Rien de plus.

C'est là que les règles relatives aux expéditeurs en masse de 2024 sont régulièrement mal rapportées, y compris dans la première version de cet article. Les directives relatives aux expéditeurs de Google exigent que les expéditeurs de 5 000 messages ou plus par jour vers des comptes Gmail « Configurez l'authentification DMARC pour votre domaine d'envoi », et disent ensuite, dans le même souffle : « Votre politique d'application DMARC peut être définie sur none. » Le propre Sender Hub de Yahoo, qui doit être lu séparément plutôt que présumé copier Google, énonce l'exigence comme « Publiez une politique DMARC valide avec au moins p=none - DMARC doit réussir », et ne publie pas du tout de seuil de volume numérique. Les deux ensembles d'exigences ont pris effet à partir de février 2024. Aucun ne force quiconque à abandonner p=none. Ce que les deux forcent réellement, c'est une authentification qui s'aligne : Google exige que « le domaine dans l'en-tête From : de l'expéditeur soit aligné avec le domaine SPF ou le domaine DKIM », et Yahoo dit que l'alignement relaxé est acceptable. L'alignement, pas la sévérité, est la condition.

Ce qui laisse la vraie raison pour laquelle les domaines restent en surveillance, et elle est opérationnelle plutôt que lâche. Passer à quarantine ou reject signifie d'abord trouver chaque service qui envoie du courrier en votre nom — paie, billetterie, marketing, un bureau de support que personne n'a documenté — et authentifier chacun pour qu'il s'aligne. La norme elle-même reconnaît les risques qui rendent ce processus lent : les expéditeurs tiers ne sont ni introduits ni exclus par DMARC, la transmission et les listes de diffusion peuvent casser l'alignement sans faute de l'expéditeur, et la spécification indique aux destinataires RFC 7960 pour exactement ces modes de défaillance. Une organisation qui publie p=none et lit ses rapports fait le travail dans l'ordre que la spécification décrit. Une qui publie p=none et ignore les rapports ne le fait pas. De l'extérieur, l'enregistrement seul ne peut pas vous dire laquelle des deux vous regardez.

Vous n'avez pas besoin d'un terminal pour regarder. Des outils de recherche gratuits — dmarcian's domain checker, MXToolbox's DMARC check — récupèrent l'enregistrement et affichent la politique pour vous. Faites-le pour votre banque, votre fournisseur de paie, la compagnie aérienne sur laquelle vous voyagez. Lisez simplement la réponse pour ce qu'elle est : une déclaration d'intention du propriétaire du domaine, une entrée parmi de nombreuses autres dans une décision que votre fournisseur de messagerie prend de son côté, sur un type spécifique de falsification. C'est une chose véritablement utile à pouvoir lire en dix secondes. Ce n'est pas un jugement sur la question de savoir si le prochain message prétendant provenir de cette marque est sûr.

Correction, 20 octobre 2026. Une version antérieure de cet article décrivait p=none comme remettant les forgeries à la boîte de réception et p=reject comme le seul paramètre qui bloque un message usurpé, disait que les règles de 2024 de Google et Yahoo relatives aux expéditeurs en masse forçaient les expéditeurs à abandonner p=none, et citait un chiffre d'environ un tiers des domaines appliquant la politique. Les descriptions des politiques ont été corrigées par rapport à RFC 9989 ; Google et Yahoo acceptent en fait p=none, cité ci-dessus à partir de leur propre documentation ; et le chiffre d'application a été supprimé car le rapport sous-jacent ne publie pas son échantillon ou dénominateur. L'article précise maintenant aussi ce que DMARC n'examine pas.

@@END@@