DMARC quarantine ou reject : quelle politique choisir (et quand changer)

Un enregistrement DMARC sans politique appliquée, c'est une caméra de surveillance qui n'enregistre pas. C'est avec la balise p= que DMARC commence vraiment à protéger votre domaine, et le choix entre quarantine et reject compte plus que la plupart des expéditeurs ne l'imaginent.

Ce guide explique ce que fait chaque politique, quand utiliser laquelle, et la marche la plus sûre pour passer de p=none à l'application.

Les trois politiques DMARC

DMARC accepte trois valeurs pour la balise p= :

Politique	Ce qui arrive aux e-mails en échec DMARC	Quand l'utiliser
p=none	Délivrés normalement ; signalés dans vos rapports	Jour 1 (visibilité seulement)
p=quarantine	Délivrés dans le dossier spam	Phase de transition
p=reject	Rejetés en bounce (non délivrés)	État final : protection complète

La balise pct= de la RFC 7489 permet d'appliquer la politique à un pourcentage des e-mails. Par exemple, p=quarantine; pct=25 demande aux destinataires de mettre en quarantaine 25 % des e-mails en échec et de laisser passer le reste. La norme actuelle, la RFC 9989 (mai 2026), supprime pct et n'en garde que l'usage de test, sous la forme t=y : considérez donc les pourcentages comme une demande que beaucoup de destinataires appliquent à leur guise.

Ce que fait vraiment p=quarantine

Les e-mails en échec DMARC sont délivrés dans le dossier spam du destinataire. Celui-ci peut toujours retrouver et récupérer le message, ce qui est utile tant que vous découvrez encore des expéditeurs légitimes pas encore alignés.

Points forts :

• Empêche la plupart des e-mails usurpés d'atteindre la boîte de réception.
• Fait apparaître les échecs d'alignement sans faire rebondir de vrais e-mails.
• Faible risque d'abîmer des e-mails légitimes pendant la transition.

Points faibles :

• Certains fournisseurs de messagerie gèrent la quarantaine de façon inégale (Microsoft est plus strict que Gmail).
• N'empêche pas le destinataire de récupérer à la main un e-mail usurpé.
• N'offre qu'une protection partielle de la marque.

Ce que fait vraiment p=reject

Les e-mails en échec DMARC sont refusés purement et simplement par le serveur destinataire. Ils n'arrivent nulle part. L'expéditeur reçoit un bounce.

Points forts :

• La meilleure protection possible contre l'usurpation.
• L'accès à BIMI (affichage du logo dans les clients de messagerie compatibles).
• La conformité aux recommandations de Gmail/Yahoo pour les expéditeurs en masse.

Points faibles :

• Tout expéditeur légitime mal aligné disparaît sans bruit.
• Les erreurs de configuration font rebondir de vrais e-mails clients.
• Il faut d'abord avoir découvert et aligné chaque expéditeur du shadow IT.

Quand choisir laquelle

Suivez cet arbre de décision :

• Vous venez de publier DMARC → p=none avec les rapports rua. Restez-y jusqu'à ce que vos rapports agrégés montrent plus de 99 % des e-mails légitimes alignés.
• Les rapports agrégés montrent >99 % d'alignement pour les expéditeurs légitimes, avec quelques inconnus → p=quarantine; pct=10. Contrôlez chaque semaine, augmentez pct progressivement.
• Les rapports agrégés montrent 100 % d'alignement des e-mails légitimes, sans inquiétude d'usurpation → p=quarantine; pct=100.
• Vous voulez une protection maximale ET chaque expéditeur légitime est vérifié comme aligné → p=reject; pct=100.
• Vous êtes une banque, un acteur de santé, une administration ou une marque souvent usurpée → passez à p=reject sans traîner. Le risque de dégâts par usurpation dépasse le risque d'erreur de configuration.

La marche sûre de p=none à p=reject

Le calendrier classique qui évite les catastrophes :

Semaine	Politique	Que faire
1 à 4	p=none	Publier l'enregistrement, analyser les rapports agrégés, identifier tous les expéditeurs
5 à 6	p=none	Aligner les expéditeurs non alignés (domaines personnalisés, CNAME de l'ESP)
7 à 8	p=quarantine; pct=10	Surveiller, corriger les nouveaux échecs
9 à 10	p=quarantine; pct=50	Idem
11 à 12	p=quarantine; pct=100	Idem
13 à 16	p=reject; pct=10 puis 50 puis 100	Montée finale

Au total : environ 4 mois entre la publication de DMARC et l'application complète de p=reject. On peut aller plus vite, mais le risque de perdre des e-mails légitimes augmente.

Ce que disent les rapports agrégés

Les rapports agrégés rua de DMARC arrivent chaque jour en pièces jointes XML, envoyés par chaque fournisseur destinataire. Ils montrent :

• Quelles IP ont envoyé des e-mails en se présentant comme votre domaine.
• Combien de messages étaient alignés avec SPF, DKIM, les deux ou aucun.
• Quelle disposition le destinataire a appliquée (none/quarantine/reject).

Passez-les dans un tableau de bord, car le XML brut devient illisible à grande échelle. L'analyseur de rapports DMARC gratuit lit les rapports que vous ouvrez, dans votre navigateur.

Les erreurs courantes qui cassent de vrais e-mails

• Passer directement à p=reject sans analyser les rapports agrégés. Les phases de découverte trouvent toujours des expéditeurs légitimes que vous aviez oubliés.
• Oublier les sous-domaines. Un p=reject sur le domaine racine couvre aussi ses sous-domaines, sauf si une balise sp= dit autre chose : un sp=none oublié exempte donc discrètement tous les sous-domaines.
• Une configuration d'ESP mal alignée. Par défaut, votre ESP signe DKIM avec son domaine ; vous devez configurer un domaine DKIM personnalisé pour l'alignement.
• Les outils d'automatisation marketing. Beaucoup d'outils SaaS envoient « depuis » votre domaine via SendGrid, Postmark, etc. Chacun doit être aligné séparément.

p=quarantine et quarantaine du filtre anti-spam

Une source de confusion : p=quarantine dit au serveur destinataire de traiter les e-mails en échec comme suspects. Le destinataire applique quand même son propre filtrage anti-spam par-dessus. Un e-mail en échec DMARC sous p=quarantine peut donc arriver en spam ou être traité encore plus sévèrement. Les deux filtres se cumulent.

FAQ

p=reject est-il sûr ? Oui, une fois que vous avez vérifié que chaque expéditeur légitime est aligné. Le risque, c'est d'appliquer la politique avant de connaître tous vos expéditeurs.

Que fait pct=0 ? En pratique, l'équivalent de p=none pour les nouveaux e-mails. Une vieille astuce pour tester un changement de politique sans toucher à la délivrance. La RFC 9989 la remplace par t=y et note que les valeurs de pct autres que 0 et 100 étaient appliquées de façon inégale d'un destinataire à l'autre.

p=reject touche-t-il les e-mails des listes de diffusion ? Oui. C'est la cause la plus fréquente de perte d'e-mails légitimes après l'application. ARC (Authenticated Received Chain) aide les listes de diffusion à préserver l'alignement. La plupart des grandes listes prennent désormais ARC en charge ; vérifiez les vôtres.

La politique des sous-domaines doit-elle être celle de la racine ? En général, oui. Définissez sp=reject explicitement. Si vous avez des sous-domaines non authentifiés, mettez-les temporairement en sp=quarantine et corrigez-les.

Ai-je besoin de DMARC si j'ai SPF et DKIM ? Oui. SPF et DKIM vérifient chacun un mécanisme ; seul DMARC impose l'alignement et vous donne des rapports. Gmail et Yahoo exigent DMARC pour les expéditeurs en masse.

En résumé

p=none sert à apprendre. p=quarantine sert à la transition. p=reject sert à protéger. Sauter directement à p=reject est la façon la plus courante de perdre de vrais e-mails clients. Prenez ces quatre mois. La protection mérite d'être bien faite.

👉 Pour continuer : Corriger SPF, DKIM et DMARC · Les exigences de Gmail et Yahoo pour les expéditeurs · Essayer le générateur DMARC

Sources

• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) : la norme DMARC actuelle, avec les politiques p, sp et np, l'indicateur de test t, et les raisons de la suppression de pct.
• RFC 7489: DMARC (2015 informational version) : la version de 2015 qui définissait pct et la règle selon laquelle p s'applique aux sous-domaines quand sp est absent.
• RFC 8617: The Authenticated Received Chain (ARC) Protocol : comment des intermédiaires comme les listes de diffusion transmettent des résultats d'authentification que DMARC ferait sinon échouer.
• Set up DMARC (Google Workspace Help) : la recommandation de Google de commencer à p=none et de passer progressivement à l'application en lisant les rapports.