# C'est quoi DMARC ? Alignement, politiques et les RFC 2026 URL: https://notificationharbor.com/fr/journal/cest-quoi-dmarc Type: blog Locale: fr Published: 2026-09-29 Updated: 2026-09-29 --- > DMARC indique aux destinataires ce qu'il faut faire quand le mail prétend venir de votre domaine mais échoue l'authentification. Voici les trois politiques. C'est quoi DMARC ? C'est un enregistrement DNS qui indique aux serveurs de réception de mail ce qu'il faut faire quand un message prétend venir de votre domaine mais échoue l'authentification, et où envoyer les rapports à ce sujet. DMARC n'authentifie rien par lui-même. Il vérifie que SPF ou DKIM a réussi ET que le domaine validé correspond au domaine visible dans l'en-tête From. Cette correspondance s'appelle l'alignement, et c'est là que la plupart des équipes se plantent. Un message peut passer SPF, passer DKIM, et échouer DMARC. ## DMARC est une couche de politique au-dessus de SPF et DKIM SPF énumère les adresses IP autorisées à envoyer pour un domaine. DKIM signe le message pour que le destinataire vérifie qu'il n'a pas été altéré et que le domaine signataire l'a autorisé. Aucun des deux ne regarde l'adresse From visible par l'utilisateur. DMARC comble cette lacune. Il pose une seule question : le domaine en en-tête From visible s'aligne-t-il avec le domaine passé par SPF ou DKIM ? Si oui, le message passe. Si non, le destinataire applique votre politique. ![Engineer reviewing DNS records in a terminal on a laptop at a desk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp) L'enregistrement se place sur `_dmarc.votredomaine.com` en tant qu'enregistrement TXT. Un enregistrement minimal et valide ressemble à ceci : `_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rapports@example.com"`Trois tags font le vrai travail. `p` est la politique, `rua` est l'adresse pour les rapports cumulatifs, et `adkim` / `aspf` définissent le niveau de strictesse de l'alignement. Tout le reste est optionnel. ## L'alignement, c'est là que les bonnes mises en place échouent SPF authentifie le domaine d'enveloppe, le domaine Return-Path. DKIM authentifie le domaine dans le tag `d=` de la signature. DMARC a besoin qu'au moins l'un des deux correspond au domaine From : soit exactement (strict), soit au niveau du domaine organisationnel (relaxed, le défaut). Voici l'échec qu'on observe le plus souvent dans les traces. Une équipe envoie par un tiers, le tiers signe avec son propre domaine (`d=provider-mail.net`) et utilise son propre domaine de retour. SPF passe, DKIM passe, et DMARC échoue parce qu'aucun des deux domaines ne correspond à `example.com`. La solution est un domaine d'envoi custom : une clé DKIM publiée sous votre domaine, et idéalement un return-path custom sur un sous-domaine. Tous les fournisseurs sérieux le supportent. Peu l'activent par défaut. ## Les trois politiques : none, quarantine, reject Le tag `p` a trois valeurs, et ce ne sont pas des échelons qu'on monte sur calendrier. - **`p=none`** : le destinataire livre normalement et vous envoie des rapports. À utiliser les 2-4 premières semaines, pendant que vous inventoriez les expéditeurs. - **`p=quarantine`** : le destinataire route les échecs vers le spam ou la corbeille. À utiliser une fois que les rapports montrent tous les sources légitimes alignées. - **`p=reject`** : le destinataire refuse les échecs au stade SMTP. À utiliser une fois que quarantine a tourné propre pendant un cycle d'envoi complet. `p=none` est de la surveillance, pas de la protection. Un domaine en `none` depuis deux ans a une case cochée et aucune défense contre l'usurpation. Échappez à la tentation de le laisser là parce que rien n'a cassé. `p=reject` est la destination de tout domaine qui envoie uniquement du mail que vous contrôlez. Les domaines avec beaucoup de trafic de listes de diffusion ou de redirecteurs legacy ont besoin de plus d'attention, parce que les redirections cassent souvent SPF et peuvent casser DKIM si l'intermédiaire édite le corps du message. ## Pourquoi les règles de Gmail et Yahoo ont rendu cela urgent Depuis février 2024, les [directives d'expéditeur de Google](https://support.google.com/mail/answer/81126) exigent que quiconque envoie plus de 5 000 messages par jour aux comptes Gmail publie un enregistrement DMARC, avec SPF et DKIM en place. La politique peut être `none`. Google demande aussi aux expéditeurs en masse de garder le taux de spam signalé par l'utilisateur dans Postmaster Tools en dessous de 0,30 %, et recommande de rester sous 0,10 %. [Yahoo Sender Hub](https://senders.yahooinc.com/best-practices/) énonce la même exigence fondamentale : un enregistrement DMARC valide d'au moins `p=none`, avec le domaine From aligné au domaine SPF ou DKIM. L'alignement relaxed est acceptable. Notez ce qui est et n'est pas dans ces règles. L'exigence est un enregistrement publié et un alignement passant, pas de l'application. C'est un plancher. Ce n'est pas une ligne d'arrivée. ![Lowered customs barrier at a harbor container yard at dusk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp) ## Les rapports cumulatifs sont le produit, la politique est l'interrupteur L'adresse `rua` reçoit des rapports XML quotidiens de chaque destinataire qui honore DMARC. Chaque rapport énumère les adresses IP sources, les compteurs de messages, les résultats SPF et DKIM, et si l'alignement tenait. C'est ainsi que vous trouvez l'expéditeur oublié : l'ancienne export CRM, l'outil de facturation qu'un contractant a câblé en 2022, le formulaire marketing sur un sous-domaine que personne ne possède. Le XML brut est illisible à volume. Routez `rua` vers une boîte aux lettres qu'un parseur peut ingérer, ou vers un service de rapportage DMARC hébergé, et regardez les données groupées par source. Ce que vous voulez voir est chaque source légitime montrant 100 % alignée, et tout le reste clairement inconnu. Un déploiement pratique suit cet ordre : - Publiez `p=none` avec une adresse `rua`. - Collectez deux à quatre semaines de rapports. Construisez l'inventaire des expéditeurs. - Corrigez chaque source non alignée légitime avec un domaine DKIM custom ou un return-path custom. - Passez à `p=quarantine`. Surveillez les tickets d'assistance concernant les messages manquants. - Passez à `p=reject` quand quarantine n'affiche aucun échec légitime. Livrez chaque étape séparément. Changer la politique et ajouter un nouveau fournisseur d'envoi la même semaine rend tout régression impossible à attribuer. ## DMARCbis change les tags, pas votre enregistrement En 2026, l'IETF a publié RFC 9989, RFC 9990, et RFC 9991, qui obsolescent RFC 7489. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) est la spec DMARC centrale. Le rapportage d'agrégation et le rapportage d'échec sont passés dans leurs propres documents. Les changements pratiques pour un propriétaire d'enregistrement sont mineurs : - `pct`, `rf`, et `ri` sont supprimés. - `t` (mode test) remplace `pct` comme interrupteur tout ou rien : `t=y` rapporte sans appliquer. - `np` définit une politique pour les sous-domaines inexistants, ce qui bloque l'usurpation d'adresses comme `abc123.example.com`. - `psd` marque les domaines de suffixe public, et une marche en arbre DNS remplace l'ancienne recherche de liste de suffixes publics. Les enregistrements `v=DMARC1` existants restent valides. Rien ne casse si vous ne changez rien aujourd'hui. Le support des nouveaux tags par les fournisseurs se fera de manière inégale, donc un tag qui semble ne rien faire signifie généralement que le destinataire ne l'a pas encore implémenté. Le tag `np` est celui qui vaut la peine d'être adopté tôt. Mettre `np=reject` pendant que `p` est toujours `none` ferme le chemin d'abus de faux sous-domaines sans engager le reste de votre mail à l'application. ## Les sous-domaines, et pourquoi le défaut hérite Un enregistrement DMARC sur le domaine organisationnel s'applique aussi aux sous-domaines, à moins que vous ne le remplaciez avec `sp`. Cet héritage est utile et aussi un piège. Si le marketing envoie depuis `news.example.com` par un fournisseur séparé, il hérite de la politique parentale. Déplacez le parent à `p=reject` avant que ce fournisseur ait DKIM alignée et la newsletter se retrouve au sol. Publiez un enregistrement `_dmarc.news.example.com` séparé quand un sous-domaine a sa propre flotte d'expéditeurs et son propre rythme de déploiement. Une architecture plus propre sépare les flux par sous-domaine dès le départ. Le mail transactionnel sur l'un, le mail de cycle de vie sur un autre, le mail humain sur la racine. Chacun reçoit ses propres clés DKIM, sa propre réputation, et son propre enregistrement DMARC. ## Lisez l'en-tête Authentication-Results avant de deviner Quand un message échoue, le serveur destinataire enregistre pourquoi. Dans Gmail, « Afficher l'original » expose l'en-tête `Authentication-Results`, et il vous dit plus qu'importe quel tableau de bord. `Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.provider-mail.net; dkim=pass header.d=provider-mail.net; dmarc=fail (p=NONE) header.from=example.com`Lisez-le de gauche à droite. SPF a réussi pour `bounce.provider-mail.net`. DKIM a réussi pour `provider-mail.net`. DMARC a échoué parce que l'en-tête From dit `example.com` et aucun des deux domaines passants n'y correspond. La note `(p=NONE)` affiche la politique que le destinataire a vue. À `none`, ce message a été livré quand même. À `reject`, il aurait rebondi avec une erreur 5.7.x, et l'expéditeur l'aurait sù d'un client. Deux vérifications attrapent la plupart de ces cas. Confirmez que la valeur `header.d` dans le résultat DKIM est votre domaine. Puis confirmez que le domaine `smtp.mailfrom` est votre domaine ou un sous-domaine de celui-ci. ## SPF a une limite de recherches que DMARC expose SPF autorise dix recherches DNS par évaluation. Chaque `include:` pour un fournisseur en dépense quelques-unes, et les includes imbriquées en dépensent plus. Franchissez dix et SPF retourne une erreur permanente, qui compte comme un échec. Les équipes avec cinq ou six outils d'envoi frappent cela sans le remarquer, parce que les échecs SPF étaient invisibles avant le rapportage DMARC. Une fois que les rapports `rua` arrivent, le motif est évident : une source échoue soudainement SPF partout sur tous les destinataires le jour où quelqu'un a ajouté un autre `include:`. C'est une autre raison de compter sur l'alignement DKIM comme chemin primaire. DKIM survit à la plupart des redirections, n'a pas de budget de recherches, et est lié au message plutôt qu'à l'adresse IP de connexion. Gardez SPF valide, mais ne construisez pas votre passage DMARC sur lui seul. ## Ce que DMARC ne fera pas DMARC prévient l'usurpation de domaine exact. Il n'arrête pas les domaines similaires (`examp1e.com`), il ne juge pas le contenu, et il n'arrange pas une mauvaise réputation d'expéditeur. Un domaine parfaitement aligné qui envoie à des listes achetées atterrit toujours dans le spam. Il ne remplace pas non plus la surveillance. L'alignement peut se casser en silence : une modification DNS supprime un sélecteur DKIM, un fournisseur réitère les clés, un nouvel outil commence à envoyer sans votre connaissance. Les rapports c'est comment vous le découvrez avant que vos utilisateurs le fassent. Traitez l'enregistrement DMARC comme n'importe quelle autre pièce de config de production. Il appartient au contrôle de version, les changements passent par la revue, et la boîte aux lettres `rua` a besoin d'un propriétaire. ![Cream envelope being sealed with a red wax stamp](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp) ## Avant de publier l'enregistrement Passez par ceci une fois. Ça prend moins d'une heure pour un seul domaine. - Énumérez chaque système qui envoie du mail en tant que votre domaine : produit, facturation, support, CRM, marketing, invitations de calendrier. - Confirmez que chacun signe DKIM avec votre domaine, pas celui du fournisseur. - Définissez un return-path custom où le fournisseur le permet. - Choisissez une destination `rua` que quelqu'un lira. - Commencez par `p=none`, et mettez la date à laquelle vous prévoyez de le revoir sur le calendrier. - Vérifiez le taux de spam dans Google Postmaster Tools chaque semaine pendant le déploiement. ## Par où continuer Si vous n'avez jamais regardé vos rapports, publiez `p=none` avec une adresse `rua` aujourd'hui et lisez ce qui arrive dans deux semaines. Le premier rapport nomme presque toujours au moins un expéditeur que personne ne se souvenait. L'étape concrète suivante est de décider lequel de ceux-ci vous gardez. ## FAQ ### DMARC est-il obligatoire ? Pour les expéditeurs en masse, pratiquement oui. Google exige un enregistrement DMARC pour les expéditeurs de plus de 5 000 messages par jour vers Gmail, et Yahoo exige une politique valide d'au moins p=none. L'application n'est pas requise, mais l'enregistrement et l'alignement le sont. ### Que signifie p=none dans DMARC ? Cela signifie surveillance seulement. Les destinataires livrent les messages échoués normalement et vous envoient des rapports. Cela satisfait le minimum de Google et Yahoo mais ne fournit aucune protection contre l'usurpation. ### Un email peut-il réussir SPF et DKIM et échouer DMARC ? Oui. DMARC exige que le domaine validé par SPF ou DKIM s'aligne avec le domaine From. Un mail envoyé par un fournisseur qui signe avec son propre domaine réussit les deux vérifications mais échoue l'alignement. ### Combien de temps dois-je rester en p=none ? Généralement deux à quatre semaines de rapports cumulatifs, assez longtemps pour voir chaque expéditeur légitime, y compris les bas volume. Bougez une fois que chaque source légitime se montre alignée. ### DMARC affecte-t-il la délivrabilité ? Indirectement. Un enregistrement publié et aligné est une exigence de base à Gmail et Yahoo, et une faille d'alignement peut pousser le mail au spam ou déclencher un refus sous une politique d'application. Il n'arrange pas une mauvaise réputation d'expéditeur ou des taux de plainte élevés. ### Qu'est-ce qui a changé avec DMARCbis et RFC 9989 ? RFC 9989 obsolète RFC 7489. Il supprime pct, rf et ri, ajoute t, np et psd, et remplace les recherches de liste de suffixes publics par une marche en arbre DNS. Les enregistrements v=DMARC1 existants restent valides.