Un domaine peut afficher SPF, DKIM et DMARC parfaitement configurés et rester, en pratique, aussi usurpable qu’un domaine sans aucune authentification. La raison tient en trois caractères : p=none. Tant que la politique reste à cette valeur, les serveurs destinataires signalent les fraudes sans jamais les bloquer. Le durcissement vers quarantine puis reject est la seule étape qui protège vraiment, et les rapports agrégés sont ce qui permet de le franchir sans envoyer par erreur ses propres messages à la poubelle.
Ce que p=none protège, et ce qu’il ne protège pas
DMARC (RFC 7489) ajoute deux garanties à SPF et DKIM. La première est l’alignement : le domaine visible dans l’en-tête From: doit correspondre au domaine validé par SPF ou par DKIM. La seconde est une politique publiée, qui indique au serveur destinataire quoi faire d’un message non aligné. C’est cette politique que porte la balise p.
Avec p=none, la consigne envoyée aux destinataires est explicite : « constate, mais ne bloque pas ». Un message usurpant le domaine passe donc exactement comme avant l’installation de DMARC. Le seul gain à ce stade est l’observation : le domaine commence à recevoir des rapports décrivant qui envoie en son nom. C’est une étape de collecte indispensable, mais la confondre avec une protection est l’erreur la plus répandue en délivrabilité.
Anatomie d’un rapport agrégé
Un rapport agrégé (balise rua) est un fichier XML qu’un serveur destinataire génère, par défaut une fois par jour, pour un domaine donné. Il ne contient aucun contenu de message : uniquement des adresses IP source, des volumes, et le résultat de l’évaluation SPF, DKIM et DMARC. Voici un extrait réduit à l’essentiel.
<record>
<row>
<source_ip>203.0.113.24</source_ip>
<count>148</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>exemple.fr</header_from>
</identifiers>
<auth_results>
<spf><domain>mailer.prestataire.com</domain><result>pass</result></spf>
</auth_results>
</record>Ce bloc décrit 148 messages émis depuis une même IP, se présentant comme exemple.fr. SPF passe, mais sur le domaine mailer.prestataire.com : il y a authentification, pas alignement. DKIM échoue. Résultat DMARC : non aligné. Sous p=none, la disposition reste none et le message part quand même. Sous p=reject, ces 148 messages seraient refusés. Toute la question est de savoir s’ils sont légitimes.
| Champ XML | Ce qu’il révèle | Usage en diagnostic |
|---|---|---|
source_ip | L’adresse d’envoi réelle | Identifier le service émetteur |
count | Le volume sur la période | Prioriser les flux importants |
policy_evaluated/dkim|spf | L’alignement retenu par DMARC | Repérer les échecs d’alignement |
header_from | Le domaine affiché | Confirmer l’usurpation d’identité |
auth_results | Le domaine réellement authentifié | Distinguer prestataire légitime et fraude |
Un rapport agrégé ne dit pas si un email est arrivé : il dit qui a le droit d’écrire au nom du domaine, et qui s’en écarte.
Lire les rapports pour trouver les expéditeurs légitimes en échec
À la main, les rapports deviennent illisibles dès quelques prestataires. Le réflexe utile n’est pas de tout inspecter, mais d’isoler une seule catégorie : les sources non alignées à fort volume. Ce sont elles qui casseront lors du durcissement si elles sont légitimes, ou qui prouvent la fraude si elles ne le sont pas. Un script de quelques lignes suffit à extraire cette liste d’un rapport décompressé.
import xml.etree.ElementTree as ET
tree = ET.parse("rapport_agrege.xml")
for rec in tree.findall(".//record"):
dkim = rec.findtext("row/policy_evaluated/dkim")
spf = rec.findtext("row/policy_evaluated/spf")
if dkim != "pass" and spf != "pass": # non aligné sur les deux
ip = rec.findtext("row/source_ip")
count = rec.findtext("row/count")
frm = rec.findtext("identifiers/header_from")
print(f"{count:>6} {ip:Chaque ligne de sortie est une question à trancher : cette IP appartient-elle à un service utilisé légitimement (routeur marketing, facturation, CRM, formulaire du site) ou à un tiers qui usurpe le domaine ? Pour les premiers, la réponse est de corriger leur SPF ou d'activer leur signature DKIM avant de durcir. Pour les seconds, le durcissement est précisément l'objectif : ils seront bloqués.
La montée en puissance : de none à reject
Le passage ne se fait jamais d'un bloc. Il suit une rampe, où chaque palier est maintenu assez longtemps pour qu'un rapport agrégé confirme l'absence d'expéditeur légitime en échec. La balise pct permet historiquement de n'appliquer la politique qu'à une fraction des messages, pour observer l'effet avant de généraliser.
; palier intermédiaire : quarantine sur un quart du trafic
_dmarc.exemple.fr. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; adkim=s; aspf=s"| Politique | Action du destinataire | Quand l'adopter |
|---|---|---|
p=none | Aucun blocage, rapports seulement | Collecte initiale, inventaire des sources |
p=quarantine | Message rangé en indésirables | Toutes les sources légitimes sont alignées |
p=reject | Message refusé à la remise | Aucun échec légitime sur plusieurs cycles de rapports |
Un rythme réaliste maintient chaque palier une à deux semaines : p=none, puis p=quarantine; pct=25, puis pct=100, puis p=reject. La révision en cours de la spécification tend à déconseiller pct au profit d'un déploiement progressif par sous-domaines et d'une politique distincte via la balise sp ; le principe reste identique, seule la mécanique du palier change.
Rapports d'échec (ruf) et boucles de rétroaction
À côté des rapports agrégés, la balise ruf demande des rapports d'échec, message par message, au format ARF (RFC 5965). Ils sont plus précis, mais rarement envoyés : la plupart des grands destinataires les suppriment pour ne pas transmettre de données personnelles. Compter dessus revient à se priver de visibilité.
Point de vigilance. Les rapports d'échec peuvent contenir des en-têtes, voire des extraits de messages réels. Diriger ruf vers une boîte partagée ou un prestataire d'analyse expose ces données. La collecte quotidienne d'informations de délivrabilité passe mieux par les tableaux de bord postmaster des grands opérateurs et par les rapports agrégés, qui ne transportent aucun contenu.
Ce qu'il faut retenir
DMARC ne protège qu'à partir de quarantine. Le chemin vers reject est une affaire de lecture, pas de configuration : chaque palier attend qu'un rapport agrégé confirme qu'aucune source légitime ne tombe. La séquence est toujours la même : collecter en none, aligner les expéditeurs réels repérés dans les rapports, durcir par paliers, vérifier, refuser. Un domaine resté des mois en p=none n'est pas en cours de sécurisation : il est en attente.
Sur les domaines que j'accompagne, le point de blocage n'est presque jamais technique : c'est la peur de casser un flux oublié. Ma règle est devenue simple : je ne durcis jamais un palier sans avoir, sous les yeux, deux cycles de rapports agrégés propres. Cette discipline m'a évité plus d'un lundi matin passé à comprendre pourquoi les factures ne partaient plus. Le durcissement DMARC n'est pas risqué en soi ; le faire à l'aveugle l'est. — Simon Janvier
Pour aller plus loin
Spécification DMARC et schéma des rapports agrégés : RFC 7489 (IETF).
