Defaults.Exposed › Corrections › Guides

DMARC de p=none à p=reject sans perdre d'e-mails légitimes : le déploiement par paliers (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

Faites passer DMARC de p=none à p=reject en quatre paliers : surveillez les rapports rua pendant 2 à 4 semaines, corrigez chaque expéditeur légitime, montez p=quarantine avec pct, puis rejetez — ne sautez jamais directement à reject. 70 368 600 des 261 086 232 domaines évalués sont bloqués en SPF souple sans application DMARC, selon le recensement Defaults.Exposed.

Voici le runbook opérationnel : un tableau de paliers avec critères de sortie, l’enregistrement de chaque palier, la subtilité du pct de la RFC 7489 qui change ce que « 50 % » signifie en reject, et la balise sp= pour les sous-domaines. Si vous décidez encore s’il faut appliquer, lisez d’abord les 6 stades de maturité DMARC — c’est le cadre ; et si les niveaux de politique eux-mêmes sont nouveaux pour vous, ce que p=none, p=quarantine et p=reject signifient vraiment est l’introduction. Cette page, c’est le passage à l’acte.

Pourquoi ne pas sauter directement à p=reject ?

Parce que p=reject demande à chaque serveur de réception qui l’honore de refuser le courrier qui échoue à DMARC — et tant que vous n’avez pas lu vos rapports, vous ne savez pas ce qui échoue. Presque chaque domaine qui active la surveillance découvre des expéditeurs légitimes oubliés : le CRM, l’outil de facturation, un formulaire de contact. Sautez à reject le premier jour et ce courrier ne va pas en spam ; il disparaît au moment du SMTP. Perdre une salve de factures apprend à une organisation à craindre DMARC, et l’enregistrement est ramené à p=none définitivement — sur 261 086 232 domaines évalués, 37 312 637 stationnent exactement là, et seuls 10,59 % (27 640 987) atteignent un jour une politique appliquée.

L’autre raison est l’alignement. DMARC ne passe que quand SPF ou DKIM passe et s’aligne avec le domaine From visible — SPF sur le domaine du Return-Path (RFC5321.MailFrom), DKIM sur le d= de la signature. Les expéditeurs tiers passent généralement SPF sur leur domaine, pas le vôtre, raison pour laquelle le palier « corriger chaque source » consiste surtout à activer le DKIM sur domaine personnalisé de chaque prestataire — décortiqué dans DMARC échoue mais SPF et DKIM passent.

Quels sont les quatre paliers du déploiement ?

Données au 2026-06-29 ; comportement des politiques selon la RFC 7489.

Le palier 3 est celui où les domaines calent ou paniquent. La mise en spam est récupérable — les utilisateurs retrouvent le courrier, vous desserrez pct, vous corrigez la source. Le rejet n’est pas récupérable, raison pour laquelle une quarantine à pct=100 qui tourne proprement est le ticket d’entrée du palier 4.

Comment mener le déploiement, étape par étape ?

1. Lancez le scan gratuit sur defaults.exposed avant de toucher au DNS. Il confirme votre politique actuelle et si SPF et DKIM sont en place en dessous — les deux jambes sur lesquelles repose l’application.
2. Activez la surveillance si ce n’est pas fait. Publier p=none avec rua= est l’étape de cinq minutes de « DMARC policy not enabled ». Collectez 2 à 4 semaines de rapports — assez pour attraper les expéditeurs mensuels comme les salves de facturation.
3. Inventoriez chaque source des rapports. Triez les expéditeurs entre les vôtres, ceux de vos prestataires, et l’inconnu. Les rapports bruts arrivent en XML — un outil de traitement de rapports (ou le tableau de bord de votre prestataire) les transforme en inventaire d’expéditeurs lisible.
4. Faites passer chaque source légitime en aligné. Activez le DKIM sur domaine personnalisé de chaque prestataire (généralement deux enregistrements CNAME dans son tableau de bord) pour que les signatures portent votre domaine, pas le sien. Préférez DKIM pour l’alignement : il survit au transfert, SPF non.
5. Attendez une quinzaine propre. Ne sortez du palier 2 que lorsque les échecs signalés sont exclusivement du trafic que vous ne reconnaissez pas — l’usurpation que vous voulez bloquer.
6. Passez à p=quarantine; pct=10 — modifiez l’enregistrement TXT _dmarc existant (exemple concret : configuration DMARC chez IONOS), et surveillez la syntaxe : une coquille dans la balise de politique peut annuler l’enregistrement entièrement. Montez pct à 25, 50, 100 sur 2 à 4 semaines, en surveillant rapports et tickets d’assistance. Du légitime en spam : redescendez pct, corrigez la source, reprenez.
7. Passez à p=reject après 1 à 2 semaines propres à pct=100. Gardez rua= actif en permanence — chaque nouvel outil qu’adopte votre entreprise est un futur expéditeur en échec.

Que fait réellement pct ? La subtilité de la RFC 7489

pct demande aux serveurs de réception d’appliquer votre politique à ce pourcentage du courrier en échec. La subtilité, tirée de la RFC 7489 §6.6.4 : le courrier échantillonné hors politique ne retombe pas sur « distribuer normalement » — il reçoit la politique immédiatement moins sévère. Sous p=quarantine; pct=25, les 75 % restants sont traités comme p=none et distribués. Mais sous p=reject; pct=50, les 50 % restants sont mis en quarantaine, pas distribués. Il n’existe pas de reject en douceur : dès que votre enregistrement dit reject, chaque message en échec est au minimum mis en spam chez les serveurs qui honorent la politique.

Utilisé délibérément, c’est un atout — p=reject; pct=1 se comporte comme « mettre presque tout en quarantaine, rejeter un filet », une rampe d’accès finale légitime. Deux précautions : les serveurs de réception n’implémentent pas tous l’échantillonnage à l’identique, traitez donc pct comme un cadran approximatif ; et retirez la balise (ou mettez pct=100) une fois le palier 4 stable, pour que votre enregistrement dise ce que vous pensez.

Et les sous-domaines — la balise sp= ?

Par défaut, les sous-domaines héritent de la politique du domaine organisationnel : p=reject sur yourdomain.com couvre aussi mail.yourdomain.com. La balise sp= leur permet de diverger, dans des directions utiles comme dangereuses. Utile : p=quarantine; sp=reject verrouille les sous-domaines depuis lesquels vous n’envoyez jamais pendant que l’apex est encore en pleine montée — les usurpateurs ciblent délibérément les sous-domaines des domaines sous surveillance. Dangereux : un sp=none oublié exempte silencieusement chaque sous-domaine de la politique reject que vous avez mis six semaines à gagner. Vérifiez-le au palier 4 ; si un sous-domaine a réellement besoin d’une politique plus souple, publiez un enregistrement _dmarc sur ce sous-domaine plutôt que de les assouplir tous.

NIS2 oblige-t-elle les entreprises de l’UE à faire tout cela ?

DMARC fonctionne à l’identique partout — rien dans ce runbook ne change à une frontière de l’UE. Ce qui change, c’est la traction réglementaire. L’article 21(2)(j) de NIS2 impose aux entités concernées de sécuriser leurs communications, et le règlement d’exécution (UE) 2024/2690 de la Commission détaille les exigences techniques pour les entités d’infrastructure numérique qu’il couvre — son annexe (point 6.7.2(k)) exige un plan de mise en œuvre pour déployer les normes modernes de sécurité e-mail convenues internationalement, et le point 6.7.2(l) exige les bonnes pratiques de sécurité DNS. Une politique DMARC appliquée, avec SPF et DKIM en dessous, est le contrôle auditable reconnu contre l’usurpation ; p=none est démontrablement de la surveillance, pas de la sécurisation. Si vos clients sont dans le périmètre, leurs questionnaires fournisseurs demandent de plus en plus exactement cela.

Questions fréquentes

Combien de temps prend le déploiement complet ? Six à dix semaines, typiquement : 2 à 4 semaines de surveillance, 1 à 3 semaines de correction des sources, 2 à 4 semaines de montée en quarantine, puis reject. C’est du temps calendaire, pas de l’effort — surtout de l’attente que les rapports confirment chaque changement. Les 89,41 % des 261 086 232 domaines évalués sans politique appliquée (données au 2026-06-29) ne sont pour la plupart pas en cours de déploiement ; ils n’ont jamais lancé le chronomètre.

Puis-je sauter quarantine et utiliser p=reject avec un pct bas à la place ? Vous le pouvez — selon la RFC 7489 §6.6.4, p=reject; pct=10 signifie 10 % rejetés et 90 % en quarantaine, en gros la fin du palier 3. Mais p=quarantine d’abord est plus facile à raisonner, et les serveurs de réception varient dans la fidélité de leur échantillonnage. Dans tous les cas, les paliers 1 et 2 sont non négociables : aucune variante d’application n’est sûre tant que des expéditeurs légitimes échouent encore.

Et le courrier que je ne peux pas corriger — redirections et listes de diffusion ? Le transfert casse SPF par conception, et certaines listes de diffusion réécrivent le contenu, cassant aussi DKIM. Le DKIM aligné survit au transfert ordinaire, ce qui règle l’essentiel ; le petit résidu est la raison d’être du palier quarantine — le courrier mis en spam est récupérable pendant que vous évaluez. Détails dans le courrier transféré échoue à SPF.

S’arrêter à p=quarantine, est-ce suffisant ? C’est l’essentiel de la valeur, et bien mieux que les 37 312 637 domaines stationnés à p=none (sur 261 086 232 évalués, données au 2026-06-29) — mais le courrier usurpé atteint encore les dossiers spam, où les gens vont le repêcher. Reject est le point d’arrivée : seuls 10,59 % des domaines évalués appliquent tout court, et finir est ce que créditent les vérificateurs, les assureurs et les questionnaires.

Envoyez le rapport au propriétaire

Si vous menez ce déploiement pour un client ou un employeur, la ligne d’arrivée se montre. Relancez le scan gratuit une fois p=reject résolu et transmettez le rapport noté : le domaine passant à une politique appliquée, horodaté et en langage clair. Cette page unique répond à la ligne « sécurité e-mail » des renouvellements de cyberassurance et des questionnaires fournisseurs poussés par NIS2 mieux qu’une capture d’écran de panneau DNS — et elle rend visibles six semaines de travail soigneux et invisible à la personne qui le paie.

Vérifiez votre politique DMARC gratuitement

Voyez quelle est votre politique actuelle — et si SPF et DKIM peuvent porter l’application — en privé, visible du propriétaire uniquement.

Vérifiez votre domaine → · Corriger DMARC → · « DMARC policy not enabled » — l’honnête premier pas → · Données agrégées uniquement. Données stockées et traitées dans l’UE.