La checklist DMARC 2026 : de zéro à p=reject

Étape 3 — Mettre en place DKIM

Là où SPF autorise des serveurs, DKIM signe cryptographiquement les messages : chaque e-mail porte une signature que le destinataire vérifie via une clé publique publiée en DNS. Une signature valide survit aux transferts, là où SPF casse — c'est pourquoi DKIM est le pilier d'alignement le plus robuste. Le point qui déroute au début, c'est le sélecteur : cette étiquette (s1._domainkey, google._domainkey…) qui permet à un domaine de porter plusieurs clés en parallèle. Le sélecteur, expliqué lève le voile ; le pilier DKIM couvre la génération de clé et le reste. La bonne cible : une clé de 2048 bits.

Étape 4 — Publier DMARC en p=none avec rua

Maintenant seulement vient la publication de DMARC — et elle se fait en p=none. Ce n'est pas une protection, c'est un microscope : p=none ne bloque rien, il demande simplement à recevoir des rapports. La balise décisive à ce stade est rua, l'adresse qui collecte les rapports agrégés quotidiens. Sans rua, c'est l'aveuglement ; avec, apparaît enfin la liste de ceux qui émettent sous le nom du domaine. Un enregistrement minimal ressemble à v=DMARC1; p=none; rua=mailto:rapports@exemple.fr. La tentation d'aller plus vite est à écarter : p=none est la marche d'observation, et la sauter, c'est bloquer à l'aveugle.

Étape 5 — Lire les rapports agrégés

Une fois les rapports arrivés, il faut les lire — et c'est là que beaucoup abandonnent, parce que le format brut est du XML illisible à l'œil nu. Ces rapports agrégés indiquent, source par source, combien de messages ont passé ou échoué SPF et DKIM, et surtout l'alignement. Apprendre à les décoder est le vrai tournant du projet : c'est ce qui transforme un « DMARC est publié » en un « on sait ce que fait le domaine ». Comprendre les rapports agrégés DMARC explique quoi regarder et dans quel ordre. Deux ou trois semaines de données sont nécessaires avant de conclure quoi que ce soit.

Étape 6 — Corriger l'alignement, source par source

C'est le cœur du travail, et la marche la plus longue. Les rapports vont révéler des sources légitimes qui échouent l'alignement : un prestataire qui signe sous son propre domaine (d=), un serveur oublié, un include SPF manquant. Chacune se corrige — publier la clé DKIM du prestataire, ajouter l'include, activer la signature. L'objectif : que 100 % du courrier légitime passe SPF ou DKIM aligné. Pas de durcissement tant qu'il reste une source légitime en échec ; c'est elle qui sautera. Cette phase de remédiation méthodique est exactement ce que décrit la checklist de none à reject — chaque source doit être cochée avant d'avancer.

Étape 7 — Monter en quarantine

Quand les rapports sont propres — plus aucune source légitime en échec — vient la première marche d'application : p=quarantine. Le courrier qui échoue DMARC part alors en spam plutôt que d'être livré. Et c'est ici que DMARCbis change la méthode : l'ancien pct=25, imprévisible, est retiré du standard. À la place vient le mode test t=y, qui dit aux destinataires « j'expérimente, remontez-moi les échecs sans encore durcir strictement ». La montée se pilote par l'observation des rapports, pas par un pourcentage hasardeux. La balise t de DMARCbis détaille ce mécanisme ; pour bien saisir la différence de fond entre les deux paliers, quarantine ou reject, lequel choisir tranche la question.

Étape 8 — Monter en p=reject

C'est la marche que tout le reste préparait. En p=reject, le courrier frauduleux est refusé avant d'atteindre la boîte du destinataire — l'usurpation du domaine devient impossible, pas seulement signalée. Les étapes 1 à 7 menées sérieusement font de ce passage un non-événement : les sources sont alignées, les rapports sont propres, il ne reste que les fraudeurs à bloquer. La méthode complète, avec les précautions pour ne casser aucun flux, est décrite dans atteindre p=reject sans casser ses emails. La bascule n'a lieu que quand plusieurs semaines de rapports en quarantine confirment que seul l'illégitime échoue.

Étape 9 — Verrouiller les sous-domaines

p=reject protège le domaine racine, mais un attaquant est malin : il visera factures.exemple.fr ou un sous-domaine qui n'a jamais existé. Deux balises ferment cette porte. sp fixe la politique des sous-domaines existants ; np, nouveauté DMARCbis, couvre les sous-domaines inexistants — la cible favorite, car forger un nom qui n'existe pas ne déclenche aucune alerte côté DNS. Poser np=reject est gratuit et sans le moindre risque pour le courrier légitime. La politique de sous-domaine (sp) et la balise np pour les sous-domaines inexistants détaillent chacune leur rôle. C'est ici que le DNS Tree Walk de DMARCbis fait son travail en coulisses, en rattachant proprement chaque sous-domaine à sa politique.

Étape 10 — La récompense : BIMI

Une fois en p=reject, un bénéfice visible se débloque : BIMI affiche le logo officiel de la marque à côté de ses messages dans les boîtes compatibles (Gmail, Apple Mail…). Ce n'est pas qu'une coquetterie — c'est un signal de confiance qui améliore l'ouverture et complique l'imitation. BIMI exige p=reject ou p=quarantine : c'est littéralement la carotte au bout du parcours. Configurer BIMI et afficher son logo dans Gmail montre comment publier l'enregistrement et, le cas échéant, obtenir le certificat qui l'accompagne. C'est la médaille méritée après la montée.

Ce que la checklist ne dit pas assez fort

À la relecture des dix étapes, une chose saute aux yeux : huit sur dix ne sont pas de la configuration, mais de l'observation et de la correction. Publier trois balises prend cinq minutes ; savoir quand les durcir prend des semaines de lecture de rapports. C'est tout l'inverse de l'intuition, et c'est précisément là que la plupart des domaines calent — non pas faute de savoir écrire un enregistrement, mais faute d'avoir tenu la discipline d'alignement assez longtemps. Le décor 2026 ne change pas cette vérité : DMARCbis modernise l'outillage (Tree Walk, np, t=), il ne raccourcit pas la montée. La bascule complète vers le nouveau standard, une fois à p=reject, est balisée séparément, mais elle n'est jamais la première urgence — l'application l'est.

Une nuance qui sauve des projets : une checklist n'est pas une course. Aucun prix n'est décerné pour être arrivé à p=reject en une semaine, aucune pénalité pour y avoir mis trois mois. Ce qui compte, ce n'est pas la vitesse de la montée — c'est sa sécurité. Un domaine passé trop vite à p=reject, qui bloque ses propres factures un lundi matin, a échoué plus complètement qu'un domaine resté patiemment en quarantine le temps d'aligner sa dernière source. On avance d'une marche quand la précédente est solide, pas avant. C'est aussi ennuyeux que ça, et c'est aussi efficace que ça.

Où en est le domaine, tout de suite

La première marche est gratuite et prend dix secondes. Un passage du domaine dans notre analyseur DMARC gratuit rend un verdict immédiat sur la politique courante, les enregistrements SPF et DKIM, et l'étape exacte de la checklist où le domaine se situe. Pour comparer une posture à celle de son secteur — et constater combien de domaines stagnent encore en p=none —, l'Observatoire DMARC donne le panorama.

Tenir cette checklist à la main, source par source et semaine après semaine, est faisable mais fastidieux. C'est exactement ce que Thomas, le RSSI virtuel, automatise : il inventorie les sources depuis les rapports, nomme chacune, génère le DNS exact à publier (balises DMARCbis comprises : np, t), mesure la préparation par domaine et indique la marche précise où durcir sans risque. Analyser un domaine gratuitement · explorer l'Observatoire · commencer avec Thomas.