Limites et risques de DMARC : ce qu’il ne protège pas et ce qu’il peut casser

Une politique p=none ne bloque aucun message, alors qu’une politique p=reject mal préparée en bloque des légitimes. Entre les deux, DMARC laisse hors champ le nom d’affichage et les domaines cousins ; un compte compromis lui échappe aussi. En clair : le protocole arrête l’usurpation exacte du domaine d’expéditeur et rien d’autre, tandis que sa mise en œuvre expose à des mails clients perdus et à des expéditeurs tiers oubliés. Les limites se compensent avec d’autres outils ; les risques se maîtrisent par un déploiement progressif.

Le tableau de bord de l’outil d’emailing affiche « tout est OK » et les campagnes finissent pourtant en spam : l’authentification est un des premiers endroits à examiner. Côté fraude, le FBI chiffre à 3,05 milliards de dollars les pertes liées au Business Email Compromise (24 768 plaintes) dans son rapport IC3 2025, contre 2,77 milliards pour 2024 (21 442 plaintes).

Ce que contrôle DMARC

DMARC s’appuie sur SPF et DKIM. Un message réussit le contrôle si l’un des deux passe et si le domaine authentifié s’aligne avec celui de l’en-tête From, champ défini par la RFC 5322. Cet alignement est le point que les équipes découvrent en dernier : un SPF valide pour le domaine d’un prestataire ne suffit pas quand l’adresse affichée porte le vôtre. En cas d’échec, le destinataire applique la politique publiée par le propriétaire du domaine : quarantine envoie au spam, reject refuse le message, none ne fait rien.

Deux réglages fixent la rigueur de cet alignement. Par défaut il est « relaxed » : mail.exemple.fr s’aligne avec exemple.fr, puisqu’ils partagent le même domaine organisationnel. En mode « strict », réglé par adkim=s pour DKIM et aspf=s pour SPF, les deux noms doivent être identiques. Le strict ferme des portes ; il casse aussi tout prestataire qui signe avec un sous-domaine, ce qui se découvre rarement avant la bascule en reject.

La norme borne elle-même son périmètre. Depuis mai 2026, c’est la RFC 9989 (voie Standards Track de l’IETF, éditée par T. Herr et J. Levine) qui définit DMARC et remplace les RFC 7489 (mars 2015) et 9091 (2021). Sa section 2.2 précise que DMARC ne traite ni les domaines visuellement proches ni l’abus du nom lisible de l’expéditeur ; la section 2.4 range les attaques par display name hors du champ : le texte de 2015 disait déjà la même chose.

Display name et domaines cousins : deux angles morts documentés

Un message affiché « Service client Banque X » et envoyé depuis support@banque-x-securite.com passe DMARC sans difficulté. Le domaine d’envoi appartient à l’attaquant ; il y a publié son propre SPF et sa propre clé DKIM, donc SPF, DKIM et DMARC sont tous au vert. Le contrôle porte sur le domaine technique ; le nom que le client de messagerie met en avant n’est pas examiné.

Les domaines cousins (typosquatting, tirets ajoutés, extension différente) suivent la même logique : votre enregistrement protège votre domaine, pas ceux qui lui ressemblent. La parade relève d’une veille sur les enregistrements de domaines proches du vôtre et du filtrage côté réception.

Un compte compromis passe tous les contrôles

Une boîte dont les identifiants ont fuité envoie depuis la bonne infrastructure, avec la bonne signature. Le point d’entrée est souvent un phishing ou une fuite de données ; DMARC n’a alors rien à constater puisque le message est authentique. L’authentification multifacteur et l’alerte sur les connexions inhabituelles se trouvent en amont, hors du périmètre du protocole.

Transferts et listes de diffusion : l’alignement se brise en route

Quand un alias d’entreprise ou une liste de diffusion retransmet un message, l’IP du relais n’apparaît pas dans le SPF du domaine d’origine ; SPF échoue donc en général. Reste DKIM, qui survit tant que le contenu signé n’est pas modifié. Une liste Mailman ou Listserv qui ajoute un pied de page invalide la signature : le message légitime échoue aux deux contrôles.

La RFC 9989 (section 7.4) prend l’exemple d’une banque dont des clients ont donné une adresse d’ancien élève, du type jones@alumni.example.edu, qui relaie vers une autre boîte : le message arrive depuis l’IP du relais, absente du SPF de l’expéditeur (RFC 5321 de 2008, MailFrom), sauf réécriture. Les signatures DKIM (RFC 6376 de 2011) y restent généralement valides, tant que le corps du message n’est pas modifié. Une liste de diffusion qui ajoute un pied de page les casse.

La RFC 9989 (section 7.4, qui renvoie à la RFC 7960 de 2016 sur les listes de diffusion) en tire deux consignes : un domaine en p=reject ne doit pas compter sur SPF seul et doit signer en DKIM ; un domaine dont les utilisateurs écrivent à des listes de diffusion publiques ne devrait pas publier p=reject. Le protocole ARC (Authenticated Received Chain, RFC 8617 de juillet 2019) sert à préserver le résultat d’authentification d’origine, à condition que le relais l’ait activé.

Sous-domaines : qui l’emporte, le domaine ou le sous-domaine ?

Le sous-domaine l’emporte dès qu’il publie son propre enregistrement ; sinon il hérite du parent. La RFC 9989 le dit en deux règles. Le destinataire cherche d’abord un enregistrement sur le domaine exact du From, puis remonte l’arborescence DNS (DNS tree walk, section 4.10, limité à 8 requêtes DNS) : un enregistrement propre au sous-domaine prime donc sur celui du parent. Et sans balise sp=, la politique p= du domaine principal s’applique aux sous-domaines.

Conséquence pratique : un _dmarc.newsletter.exemple.fr resté en p=none après un test laisse ce périmètre en simple surveillance alors que exemple.fr est en reject. Dans l’autre sens, un sp=none sur le domaine principal ouvre tous les sous-domaines dépourvus d’enregistrement ; utile pendant l’audit, à retirer ensuite. La balise sp= est ignorée dans un enregistrement publié sur un sous-domaine. Depuis la RFC 9091, reprise par la RFC 9989, une balise np= règle en plus le cas des sous-domaines qui n’existent pas dans le DNS.

p=none, le mode surveillance qui donne une fausse impression de sécurité

L’enregistrement existe et le contrôle de conformité passe ; rien n’est bloqué. Google précise dans sa page de déploiement, consultée le 27 octobre 2026, que sous p=none les messages sont distribués normalement. Un domaine qui y reste des années continue d’accepter les messages usurpés.

p=reject : les mails légitimes qui disparaissent

Passé en reject, un domaine voit refuser tout expéditeur dont ni le SPF ni le DKIM ne s’aligne. Le service RH envoie les bulletins de paie par un outil externe, le support passe par un helpdesk et la facturation par un module SaaS : chacun écrit au nom du domaine et sera refusé le jour de la bascule s’il n’est pas aligné. Google le dit sans détour : les messages qui échouent au contrôle sont rejetés et jamais distribués. En quarantine, ils atterrissent au mieux dans le dossier de spam. Les rapports rua du lendemain listent alors les IP dont les messages ont échoué, y compris celles que personne n’avait recensées. D’où l’intérêt de passer par quarantine, puis de signaler la phase d’essai avec t=y avant tout reject.

Les prestataires d’envoi créent le piège le plus fréquent. Sur une IP partagée ou dédiée, le SPF valide le domaine du prestataire ; l’alignement DMARC dépend alors d’une signature DKIM au nom de votre domaine, sauf Return-Path personnalisé. Sans elle, la campagne échoue dès la première bascule en reject. La clé DKIM se publie sous un sélecteur dédié, de la forme selecteur._domainkey.exemple.fr ; la signature doit porter le domaine du From.

Erreurs TXT et limite SPF de 10 requêtes DNS

Une erreur de configuration suffit à neutraliser DMARC sans alerte. Le DNS ne la signale pas : l’enregistrement se publie sans validation, donc une faute de frappe dans la zone ne se révèle qu’à la lecture des rapports, quelques jours plus tard. Un enregistrement coupé en deux chaînes mal jointes, un guillemet typographique collé depuis un traitement de texte ou un point-virgule oublié entre deux balises suffisent. Deux enregistrements DMARC sur le même nom ? La RFC 9989 écarte alors tous les enregistrements trouvés à cet endroit (section 4.10). Un v=DMARC1 mal orthographié fait ignorer l’enregistrement entier ; une balise inconnue est ignorée sans alerte ; une faute dans rua= prive de rapports sans rien casser visiblement. Une adresse de rapport hébergée sur un autre domaine exige en plus un enregistrement d’autorisation chez ce dernier (RFC 9990).

Côté SPF, la RFC 7208 (section 4.6.4) plafonne l’évaluation à 10 requêtes DNS : include, a, mx, ptr, exists et redirect comptent, pas ip4 ni ip6. Les requêtes à vide sont limitées à 2. Au-delà, le résultat est permerror (plafond déjà présent dans la RFC 4408 d’avril 2006) et SPF cesse de contribuer à DMARC. Chaque outil ajouté via un include rapproche le domaine de ce seuil.

Limites et risques en un tableau

Déployer de none à reject sans perdre de mails

Le parcours tient en trois temps : recenser les expéditeurs, observer en none, puis durcir par paliers via quarantine avant reject. Tout commence par l’inventaire des expéditeurs : outil d’emailing, CRM, helpdesk, paie, facturation, serveurs applicatifs. Les équipes en oublient toujours un ; les rapports agrégés rua servent à le retrouver, puisqu’ils listent chaque IP ayant envoyé au nom du domaine avec son résultat SPF et DKIM.

Les étapes sont toujours les mêmes : p=none, lecture des rapports, quarantine, puis reject. Dans l’aide Google Workspace, Google recommande de configurer SPF et DKIM au moins 48 heures avant de publier DMARC, de rester en p=none une semaine avec une lecture quotidienne des rapports, puis de passer en quarantine sur un faible pourcentage de messages : 10 % pour une petite organisation, 1 % pour une grande (page « Déploiement DMARC recommandé »). Un enregistrement de départ ressemble à v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@exemple.fr, publié en TXT sur _dmarc.exemple.fr. Attention : la balise pct= de la RFC 7489 n’existe plus dans la RFC 9989, qui note qu’elle était appliquée très inégalement hors des valeurs 0 et 100 et la remplace par t=y (essai) ou t=n : avec t=y, un message en échec sous p=reject est traité comme sous p=quarantine ; sous p=quarantine, comme sous p=none. L’exemple de la page Google utilise encore pct=5. La RFC 9989 elle-même recommande de publier p=none au moins un mois en s’appuyant sur les rapports agrégés.

Le temps passé à chaque étape dépend du nombre de flux : avec peu de sources d’envoi, une semaine de rapports peut suffire à les recenser ; avec 20 outils, les expéditeurs oubliés se découvrent rapport après rapport. Pendant la montée, un sp= distinct permet de durcir le domaine principal tandis que les sous-domaines non audités restent en none.

Gmail, Yahoo et la délivrabilité

Depuis le 1er février 2024, Google exige des expéditeurs de plus de 5 000 messages par jour vers Gmail un SPF et un DKIM valides, plus une politique DMARC ; elle peut rester sur none. Le taux de spam affiché dans Google Postmaster Tools doit rester sous 0,30 %, avec une cible sous 0,10 % (consignes aux expéditeurs de Google). Yahoo, qui applique ses règles aux expéditeurs en masse depuis février 2024, demande aussi un DMARC au minimum en none, avec un domaine From aligné sur SPF ou DKIM (bonnes pratiques Yahoo). Le détail côté Gmail se trouve dans l’article sur les exigences Gmail pour les expéditeurs.

DMARC ouvre donc la porte de la boîte de réception sans fixer la réputation d’expéditeur. Cette réputation dépend du taux de plaintes et des rebonds : un domaine en reject qui envoie à une liste pleine d’adresses mortes alimente les rebonds durs et abîme sa délivrabilité. Passer un échantillon de la liste dans un outil de vérification avant la prochaine campagne montre ce taux avant que Gmail ne le mesure.

Votre prochain rapport rua contient-il une source d’envoi que personne dans l’équipe ne reconnaît ?