DMARC
← Blog

Checklist d'éligibilité : un domaine est-il prêt à passer p=reject ?

Par Thomas · RSSI virtuel · 2026-07-19

Il y a deux façons de rater le passage à p=reject. La première est de ne jamais le tenter : l'enregistrement reste en p=none pendant des années, la surveillance ne protège personne, et les usurpateurs continuent d'écrire au nom du domaine. La seconde est de le tenter trop tôt : la politique se durcit avant que toutes les sources soient alignées, et les factures, relances et réinitialisations de mot de passe de l'organisation elle-même partent en indésirable. Entre les deux, il y a un état mesurable — « prêt » — et cet article en donne la checklist.

Ce n'est pas le récit pas-à-pas de la montée en politique ; ça, c'est atteindre p=reject sans casser ses emails, qui déroule la séquence none → quarantine → reject. Ici, on répond à une question antérieure et plus froide : avant de toucher au tag p, quelles cases faut-il pouvoir cocher ? La liste se lit comme une revue de pré-vol. Une seule case vide et le domaine n'est pas prêt — forcer le passage se paiera en courrier légitime perdu.

1. Toutes les sources d'envoi sont inventoriées

C'est la case qui fait échouer tout le reste quand on la bâcle. La plupart des organisations émettent depuis bien plus d'endroits qu'elles ne le pensent : la plateforme marketing, le CRM, l'outil de facturation, le support, la solution RH, la billetterie, et cette petite appli qu'une équipe a branchée il y a deux ans sans prévenir la DSI. Chaque source oubliée est un email légitime qui sera refusé le jour du passage en reject.

L'inventaire ne se fait pas de mémoire — il se lit dans les rapports agrégés DMARC. Chaque IP qui apparaît dans les rapports RUA est une source à identifier et à classer : « celle-ci est la plateforme d'emailing, celle-là le CRM, cette troisième un outil de sondage que personne ne se rappelait. » La case se coche seulement quand un nom de service peut être posé sur chaque IP à volume non négligeable. Il faut s'attendre à des surprises ; il y en a toujours. Cet inventaire gagne à vivre comme un document permanent — un simple tableau source / usage / équipe responsable / méthode d'alignement — plutôt que comme un exercice ponctuel : le jour où quelqu'un demande « on peut enfin passer en reject ? », ce tableau fait la différence entre un oui assuré et un mois de plus à deviner.

2. Chaque source légitime passe DKIM ou SPF et s'aligne

Passer l'authentification ne suffit pas : DMARC exige l'alignement. Un message doit passer SPF ou DKIM avec un domaine qui correspond à celui du From:. Un tiers qui signe les emails avec sa propre clé (d=plateforme-marketing.com) fait techniquement passer DKIM, mais pas de façon alignée — DMARC le comptera en échec. Pour qui ne sait pas encore comment les trois briques s'emboîtent, SPF, DKIM et DMARC expliqués ensemble fait le tour.

Concrètement, pour chaque source de la case 1 :

  • soit la plateforme est configurée pour une signature DKIM à la marque du domaine (d=exemple.fr) — c'est la voie la plus fiable, car les tiers alignent rarement SPF ;
  • soit leur domaine d'envoi est inclus dans le SPF et le From: visible reste sur le domaine de l'organisation.

La case se coche uniquement quand les rapports montrent, pour chaque vraie source, un passage aligné — pas juste un dkim=pass désaligné.

3. Le SPF ne dépasse pas les 10 lookups DNS

SPF plafonne à dix résolutions DNS. Au-delà, la vérification renvoie un PermError et SPF échoue — même si l'enregistrement est « correct ». Empiler les include: de chaque prestataire fait dépasser ce plafond plus vite qu'on ne le croit. Ce compteur se vérifie avant de durcir, faute de quoi tout repose sur DKIM seul à l'insu de l'équipe. Le sujet est traité en détail dans l'erreur SPF « too many DNS lookups ». Case cochée quand le SPF résout sous la barre des dix.

4. Les sous-domaines sont couverts

Un attaquant qui ne peut plus forger le domaine racine se rabat sur les sous-domaines — y compris ceux qui n'existent pas. La politique par défaut des sous-domaines hérite de p, mais elle mérite d'être pilotée explicitement avec sp, et les sous-domaines inexistants d'être verrouillés avec la balise np de DMARCbis. C'est un gain rapide et sans risque : aucun courrier légitime ne part d'un sous-domaine qui n'existe pas. Détails dans la politique de sous-domaine DMARC (sp et np). Case cochée quand sp et np sont posés et cohérents avec la racine.

5. Les rapports affluent et sont « propres » depuis plusieurs semaines

Le durcissement ne se décide pas sur une photo instantanée, mais sur une tendance. Les rapports doivent s'accumuler quelques semaines — assez pour capter les expéditeurs mensuels (facturation, relevés, campagnes trimestrielles) et pas seulement le trafic quotidien. « Propre » veut dire : les seules IP encore en échec d'alignement sont des sources non reconnues, c'est-à-dire des usurpateurs. Si des sources légitimes échouent encore, retour à la case 2. Pour s'assurer que les rapports arrivent bien, voir configurer l'adresse rua et l'absence de rapports DMARC.

Un mot sur les secrets qui sous-tendent tout ça : les clés DKIM privées sont des identifiants critiques. Les stocker dans un fichier traînant sur un serveur ou dans un ticket est un risque en soi ; un coffre-fort dédié comme Hucency Vault (de l'éditeur cybersécurité Hucency) évite qu'une clé de signature fuite et permette à un tiers d'usurper un envoi aligné — le seul cas où p=reject ne protège plus.

6. L'outillage et la cadence de surveillance sont prêts

Durcir la politique n'est pas un « publie-et-oublie ». Il faut prévoir qui regarde les rapports après le changement, à quelle fréquence, et pendant combien de temps. Une bonne pratique : passer en quarantine, surveiller quelques jours, puis en reject. Historiquement on échelonnait avec pct ; DMARCbis (2026) retire pct au profit d'un mode test (t=y) et d'une montée appuyée sur l'observation. Le déploiement progressif est détaillé dans déployer DMARC progressivement.

7. L'arbitrage est tranché : quarantine ou reject ?

Toutes les organisations n'ont pas besoin d'aller jusqu'à reject du premier coup. p=quarantine est déjà une défense réelle et reste réversible si quelque chose a échappé à l'inventaire. Le choix dépend de la tolérance au risque et de la criticité du flux — c'est l'objet de p=quarantine ou p=reject : lequel choisir. Case cochée quand la décision est prise consciemment, pas par défaut.

Les pièges qui vident une case déjà cochée

Une checklist n'est utile que si les cases restent cochées. Trois régressions classiques défont un travail pourtant bien fait :

  • Une nouvelle source apparaît sans prévenir. Le marketing lance une plateforme d'A/B testing, la RH change d'outil de paie, une filiale émet sous la marque. Chacune arrive non alignée et sera refusée en reject. La parade n'est pas de tout figer, mais de garder un œil sur les rapports après le durcissement : une nouvelle IP en échec d'alignement est soit un usurpateur, soit une source à intégrer — et il vaut mieux trancher avant qu'un email important ne tombe.
  • Une clé DKIM expire ou est mal roulée. Une rotation ratée casse l'alignement d'un coup, pour une source entière. C'est pour ça que la case 5 demande une tendance, pas une photo — et que la rotation doit être documentée et surveillée.
  • Un renouvellement SPF fait repasser sous les dix lookups… puis au-dessus. Ajouter un include: de trop rebascule en PermError. Le compteur de la case 3 n'est pas un contrôle unique, c'est une hygiène permanente.

Rien de tout cela n'est une raison de rester en p=none — ce serait renoncer à toute protection par peur d'un incident réversible. C'est une raison de traiter la surveillance post-durcissement comme faisant partie du projet, pas comme une corvée optionnelle.

Ce que p=reject ne couvre pas (et ne doit pas faire relâcher)

Cocher les sept cases protège de l'usurpation directe du domaine : plus personne ne peut envoyer un From: contact@exemple.fr falsifié qui atterrisse en boîte. Mais DMARC ne bloque ni les domaines ressemblants (exemp1e.fr, exemple-support.fr), ni le display-name spoofing (le nom de l'entreprise affiché sur une adresse Gmail quelconque), ni les comptes légitimes compromis. p=reject est une couche nécessaire, pas une couche unique. Le mentionner ici évite le faux sentiment de sécurité qui suit souvent une migration réussie — la case « savoir ce que ça ne couvre pas » est mentale, mais elle compte.

Le verdict

Sept cases cochées, le domaine est éligible — le durcissement peut suivre. Une seule case vide, et c'est la prochaine tâche, précise. La beauté de la checklist, c'est qu'elle transforme une décision anxiogène (« et si tout cassait ? ») en une revue factuelle : soit les données disent oui, soit elles pointent exactement ce qui manque, sans place pour l'intuition ni pour l'espoir.

Un dernier réflexe avant de publier le nouvel enregistrement : un passage du domaine dans l'analyseur DMARC gratuit montre, du dehors, ce que verront les destinataires — alignement, politique, sous-domaines, SPF. C'est la vérification finale qui rattrape les fautes de frappe et les régressions de dernière minute. Et pour suivre une progression dans le temps plutôt que sur une photo, l'Observatoire DMARC situe le domaine par rapport à son secteur. p=reject n'est pas un acte de bravoure ; c'est une checklist entièrement cochée.

Appliquer DMARC, concrètement

Thomas, le RSSI virtuel de DMARC.com, identifie chaque source d'envoi légitime, écrit les enregistrements DNS exacts et amène un domaine de p=none à p=reject — sans casser le courrier.

Atteindre p=reject — gratuit

Guides liés

À propos de l'auteur

Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.