Les emails non autorisés envoyés depuis votre domaine peuvent contourner l’authentification SPF et DKIM, atteindre les boîtes de réception en semblant légitimes, et endommager la confiance avant que vous ne détectiez le problème. L’application de la politique DMARC (p=none, p=quarantine, p=reject) contrôle comment les serveurs destinataires traitent les messages non authentifiés prétendant provenir de votre domaine.

La plupart des organisations commencent le déploiement DMARC à p=none pour collecter de la visibilité sans risque d’application. Le défi est de savoir quand progresser vers p=quarantine et p=reject sans perturber les emails légitimes ou exposer des lacunes dans la couverture d’authentification.

Ce guide explique ce que fait chaque niveau de politique DMARC, quand la progression de politique peut échouer, et comment organiser l’application en fonction de la maturité de l’expéditeur, de la fonction commerciale et de la préparation opérationnelle.

I. Ce que Contrôlent Réellement les Niveaux de Politique DMARC

La politique DMARC (p=) indique aux serveurs de messagerie destinataires comment traiter les messages qui échouent l’alignement DMARC. Les trois niveaux d’application sont :

• p=none : Surveillance uniquement. Les résultats d’authentification sont rapportés, mais le serveur destinataire n’applique aucune mesure basée sur DMARC.
• p=quarantine : Lorsqu’elle est respectée par le serveur destinataire, les messages non authentifiés sont généralement déplacés vers les dossiers spam ou courrier indésirable.
• p=reject : Lorsqu’elle est respectée par le serveur destinataire, les messages non authentifiés sont refusés lors de la livraison SMTP et ne devraient pas atteindre la boîte de réception ni le dossier spam.

Ce Qui Peut Mal Tourner avec l’Application de la Politique DMARC

L’application de la politique DMARC dépend de trois conditions qui peuvent échouer indépendamment :

1. Échec d’alignement malgré la réussite de l’authentification : SPF ou DKIM peuvent authentifier avec succès, mais si le domaine dans l’en-tête From: ne s’aligne pas avec le domaine SPF ou le domaine de signature DKIM, DMARC échoue. Cela se produit couramment lorsque des expéditeurs tiers signent avec leur propre domaine ou lorsque le transfert de courrier brise l’alignement SPF.
2. Le serveur destinataire ne respecte pas la politique : Certaines listes de diffusion, transferts et serveurs de messagerie mal configurés ignorent la politique DMARC. Même à p=reject, un petit pourcentage de courrier peut toujours être livré si l’infrastructure réceptrice n’applique pas DMARC.
3. Lacunes d’application silencieuses : Passer directement de p=none à p=reject sans validation par étapes peut bloquer des emails légitimes qui n’étaient pas visibles dans les rapports agrégés, tels que les expéditeurs à faible volume, les outils informatiques parallèles ou les scénarios de transfert.

La réussite DMARC ne garantit pas le placement en boîte de réception. L’échec DMARC ne signifie pas toujours un rejet immédiat. Les fournisseurs de messagerie évaluent DMARC parallèlement à la réputation, au contenu, aux taux de plainte, au contexte de transfert et aux signaux d’abus internes.

II. p=none : Visibilité Sans Application

À p=none, DMARC est actif, mais la politique indique aux serveurs destinataires de surveiller et rapporter les résultats d’authentification sans prendre de mesure d’application.

Quand p=none Est Approprié

• Déploiement DMARC initial : Vous avez besoin de visibilité sur quels expéditeurs s’authentifient avec succès et lesquels ne le font pas avant d’appliquer la politique.
• Environnements d’envoi complexes : Votre domaine est utilisé par plusieurs unités commerciales, plateformes tierces, outils de support, systèmes marketing et expéditeurs transactionnels qui n’ont pas été inventoriés.
• Comportement de transfert ou de liste de diffusion inconnu : Vous vous attendez à ce que le courrier légitime passe par des services de transfert ou des listes de diffusion qui peuvent briser l’alignement SPF.

Ce Qui Peut Échouer à p=none

Même à p=none, DMARC peut produire des signaux d’échec :

• SPF réussit mais l’alignement échoue : Un service tiers s’authentifie avec SPF mais utilise son propre domaine dans l’expéditeur d’enveloppe (Return-Path), donc la vérification d’alignement avec le domaine de l’en-tête From: échoue.
• DKIM réussit mais l’alignement échoue : Un expéditeur signe l’email avec DKIM, mais le domaine de signature (d=) ne correspond pas au domaine organisationnel dans l’en-tête From:.
• Les rapports agrégés ne sont pas collectés ou analysés : Publier un enregistrement DMARC avec rua=mailto:[email protected] ne parse pas, n’agrège pas ou n’agit pas automatiquement sur les rapports XML envoyés par les serveurs destinataires.

Durée Recommandée à p=none

Restez à p=none jusqu’à ce que :

1. Vous ayez identifié toutes les sources d’envoi légitimes.
2. Tous les expéditeurs légitimes passent soit SPF avec alignement, soit DKIM avec alignement.
3. Les rapports agrégés montrent un succès d’authentification cohérent pendant au moins deux cycles commerciaux complets (généralement 30-60 jours pour la plupart des organisations, plus long pour les expéditeurs saisonniers).

Dans un déploiement Skysnag géré, utilisez la destination de rapports générée par Skysnag. Ce qui suit n’est qu’un exemple manuel :

v=DMARC1; p=none; rua=mailto:[email protected]

Un enregistrement statique traditionnel peut fonctionner, mais seulement si les rapports sont activement reçus, parsés, analysés et utilisés. Skysnag automatise ce processus et met en évidence les lacunes d’authentification qui nécessitent une correction avant l’application de la politique.

III. p=quarantine : Application par Étapes

À p=quarantine, les serveurs destinataires qui respectent la politique DMARC déplacent généralement les messages non authentifiés vers les dossiers spam ou courrier indésirable au lieu de les livrer dans la boîte de réception.

Quand Passer à p=quarantine

Passez à p=quarantine lorsque :

1. Les rapports agrégés montrent que les expéditeurs légitimes passent systématiquement l’alignement DMARC.
2. Les échecs d’authentification dans les rapports correspondent à une utilisation non autorisée connue, des expéditeurs mal configurés ou des tentatives d’usurpation.
3. Vous avez validé que les emails commerciaux critiques (notifications transactionnelles, réponses de support, réinitialisations de mot de passe, factures) passent les tests d’alignement.

Ce Qui Peut Échouer à p=quarantine

p=quarantine introduit un risque d’application qui n’existe pas à p=none :

• Email légitime mis en quarantaine en raison du transfert : Le transfert de courrier brise souvent l’alignement SPF. Si un expéditeur légitime ne s’appuie que sur SPF et que le message est transféré, DMARC échoue et le message peut être mis en quarantaine.
• Expéditeurs à faible volume non visibles dans les rapports : Un expéditeur qui envoie un email à votre domaine une fois par trimestre peut ne pas apparaître dans les rapports agrégés pendant la période de surveillance, mais pourrait être bloqué lorsque l’application commence.
• Listes de diffusion et services de digest : Certains logiciels de liste de diffusion réécrivent l’en-tête From:, causant un échec d’alignement même lorsque l’expéditeur original s’est authentifié avec succès.

Échelonner p=quarantine par Domaine ou Sous-domaine

Au lieu d’appliquer p=quarantine globalement, échelonnez l’application en isolant différents flux de courrier :

• Sous-domaines transactionnels d’abord : noreply.example.com ou notifications.example.com ont généralement moins d’expéditeurs et des modèles d’authentification plus prévisibles.
• Domaines marketing ou bulk ensuite : Ces domaines sont des cibles courantes d’usurpation et ont souvent des configurations SPF et DKIM matures.
• Domaine d’entreprise principal en dernier : @example.com couvre souvent la plus large gamme d’expéditeurs, y compris les emails des employés, les intégrations tierces et les systèmes hérités.

Exemple d’enregistrement DMARC pour un sous-domaine à p=quarantine :

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

Évitez de vous appuyer sur le déploiement basé sur le pourcentage comme stratégie principale. Les programmes actuels conscients de DMARC devraient échelonner l’application par domaine, sous-domaine, groupe d’expéditeurs et fonction commerciale.

Dans un déploiement Skysnag géré, utilisez la destination de rapports générée par Skysnag.

IV. p=reject : Application Complète

À p=reject, les serveurs destinataires qui respectent la politique DMARC refusent les messages non authentifiés lors de la livraison SMTP. Le message ne devrait pas atteindre la boîte de réception ni le dossier spam.

Quand Passer à p=reject

Passez à p=reject lorsque :

1. Vous avez fonctionné à p=quarantine pendant au moins 30 jours sans mettre en quarantaine d’email légitime.
2. Les rapports agrégés ne montrent aucun échec DMARC inattendu d’expéditeurs connus.
3. Vous avez validé les scénarios de transfert de courrier (transfert d’anciens élèves, transfert de tickets de support, règles de transfert personnelles) et confirmé que les expéditeurs critiques utilisent DKIM (qui survit au transfert) ou que les services de transfert sont exclus du domaine d’application.

Ce Qui Peut Échouer à p=reject

p=reject représente la posture d’application la plus forte, mais des lacunes d’application existent toujours :

• Le transfert brise SPF, DKIM non configuré : Si un expéditeur ne s’appuie que sur SPF et que le message est transféré, l’alignement SPF échoue. Si DKIM n’est pas configuré, le message échoue DMARC et est rejeté.
• Listes de diffusion ou boîtes partagées : Certains logiciels de liste de diffusion et plateformes de boîte partagée réécrivent les en-têtes de message de manière à briser l’alignement, même lorsque le message original s’est authentifié avec succès.
• Serveurs destinataires non conformes : Certains serveurs destinataires ne respectent pas la politique DMARC, en particulier les infrastructures de messagerie plus anciennes ou les systèmes qui privilégient la réputation historique de l’expéditeur par rapport aux signaux d’authentification.

Même à p=reject, l’investigation est plus difficile car la surveillance montre les résultats d’authentification, mais le domaine n’indique pas aux destinataires de bloquer l’utilisation non authentifiée. Les organisations qui nécessitent l’attribution d’incidents d’usurpation ou de phishing fonctionnent généralement à p=reject pour réduire l’ambiguïté dans l’analyse médico-légale.

V. Politique de Sous-domaine : Contrôler sp= Indépendamment

DMARC permet une application de politique séparée pour les sous-domaines en utilisant la balise sp=.

Exemple d’enregistrement DMARC avec politique de sous-domaine :

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]

Cette configuration applique p=reject sur example.com mais applique p=quarantine à tous les sous-domaines sauf si un sous-domaine publie son propre enregistrement DMARC.

Quand Utiliser sp= pour un Déploiement par Étapes

Utilisez sp= lorsque :

• Les flux de courrier des sous-domaines sont moins matures : Les sous-domaines marketing, de staging ou hérités peuvent avoir une authentification incohérente, donc appliquer sp=quarantine fournit une application sans le risque de rejeter du courrier légitime.
• L’authentification des sous-domaines est gérée séparément : Différentes unités commerciales gèrent l’email des sous-domaines indépendamment, et vous voulez appliquer la politique sur le domaine principal pendant que les propriétaires de sous-domaines valident leurs expéditeurs.

Ce Qui Peut Échouer avec sp=

• Les enregistrements DMARC de sous-domaine remplacent sp= : Si un sous-domaine publie son propre enregistrement DMARC, la valeur sp= dans l’enregistrement du domaine organisationnel est ignorée. Cela peut créer des lacunes de politique si les propriétaires de sous-domaines publient p=none alors que le domaine organisationnel fonctionne à p=reject.

VI. Comment Échelonner la Progression de la Politique DMARC en 2026

Échelonner l’application de la politique DMARC par groupe d’expéditeurs, fonction commerciale et maturité du flux de courrier réduit le risque d’application et améliore la couverture d’authentification.

Étape 1 : Déployer p=none et Collecter les Rapports

Commencez la surveillance DMARC via Skysnag et obtenez un enregistrement DMARC géré généré pour votre domaine. Cela fournit un parsing automatique des rapports et une identification des expéditeurs.

Étape 2 : Identifier les Expéditeurs Légitimes

Examinez les rapports agrégés pour identifier :

• Quels expéditeurs passent l’alignement SPF
• Quels expéditeurs passent l’alignement DKIM
• Quels expéditeurs échouent les deux (généralement du courrier non autorisé ou usurpé)

Pour les expéditeurs qui échouent l’alignement :

• Configurez la signature DKIM si l’expéditeur le prend en charge (DKIM survit au transfert)
• Ajoutez le mécanisme d’inclusion SPF de l’expéditeur si l’expéditeur utilise votre domaine dans l’expéditeur d’enveloppe
• Migrez vers un sous-domaine si l’expéditeur ne peut pas s’authentifier avec votre domaine principal

Étape 3 : Valider les Emails Commerciaux Critiques

Avant de passer à l’application, validez que les emails critiques passent DMARC :

• Email transactionnel (réinitialisations de mot de passe, notifications de compte, confirmations de commande)
• Systèmes de tickets de support (Zendesk, Freshdesk, Intercom, plateformes de service d’assistance)
• Plateformes marketing (Mailchimp, SendGrid, HubSpot, Marketo)
• Applications internes (systèmes RH, plateformes de dépenses, CRM, ERP)
• Outils SaaS tiers (notifications Slack, alertes GitHub, outils de surveillance)

Si un expéditeur critique échoue DMARC, résolvez la lacune d’authentification avant l’application.

Étape 4 : Passer à p=quarantine sur les Sous-domaines Isolés

Appliquez p=quarantine aux sous-domaines avec des modèles d’envoi prévisibles en premier :

• noreply.example.com
• notifications.example.com
• marketing.example.com

Surveillez les emails légitimes mis en quarantaine. Si aucun n’apparaît après 30 jours, poursuivez.

Étape 5 : Passer à p=reject sur les Sous-domaines Validés

Appliquez p=reject aux sous-domaines où l’authentification est mature et où aucun email légitime n’a été mis en quarantaine.

Étape 6 : Passer le Domaine Principal à p=quarantine

Après que l’application du sous-domaine soit stable, passez le domaine organisationnel principal (example.com) à p=quarantine.

Étape 7 : Passer le Domaine Principal à p=reject

Après avoir fonctionné à p=quarantine sans problème pendant au moins 30 jours, passez le domaine principal à p=reject.

VII. Échecs Courants de Progression de Politique et Comment les Éviter

1. Email Légitime Rejeté en Raison du Transfert

Condition d’échec : Un utilisateur transfère un email de [email protected] vers un compte Gmail personnel. Le message transféré échoue l’alignement SPF car l’expéditeur d’enveloppe affiche toujours example.com, mais l’IP d’envoi est maintenant le serveur de transfert. Si DKIM n’est pas configuré, le message échoue DMARC et est rejeté.

Comment éviter : Configurez DKIM sur tous les expéditeurs légitimes. Les signatures DKIM survivent au transfert car elles voyagent avec le corps du message, contrairement à SPF qui dépend de l’IP d’envoi.

2. Liste de Diffusion ou Boîte Partagée Brise l’Alignement

Condition d’échec : Une liste de diffusion ou une plateforme de boîte partagée réécrit l’en-tête From: pour se conformer à la politique d’envoi de la plateforme. L’en-tête réécrit ne s’aligne plus avec le domaine de l’expéditeur original, causant un échec DMARC.

Comment éviter : Identifiez le comportement de la liste de diffusion et de la boîte partagée pendant la phase p=none. Si la plateforme ne peut pas préserver l’alignement, envisagez d’utiliser un sous-domaine avec une politique assouplie ou de migrer vers une plateforme qui prend en charge l’envoi conforme DMARC.

3. Expéditeurs Informatiques Parallèles Découverts Après l’Application

Condition d’échec : Une unité commerciale utilise un outil tiers non autorisé pour envoyer des emails depuis @example.com. L’outil n’apparaît pas dans les rapports agrégés car il envoie rarement. Lorsque p=reject est appliqué, l’email de l’outil est bloqué, perturbant un processus commercial.

Comment éviter : Effectuez une découverte des expéditeurs dans les unités commerciales avant l’application. Utilisez Skysnag Protect pour identifier les sources d’envoi non autorisées et valider la couverture d’authentification.

VIII. Retour en Arrière de la Politique DMARC : Quand Réduire l’Application

Si l’application entraîne le blocage d’emails légitimes, réduisez temporairement la politique :

1. Passez de p=reject à p=quarantine
2. Identifiez l’expéditeur causant l’échec dans les rapports agrégés
3. Résolvez la lacune d’authentification (ajoutez l’inclusion SPF, configurez DKIM, migrez vers un sous-domaine)
4. Validez la correction dans les rapports
5. Retournez à p=reject

Réduire temporairement l’application est plus sûr que de laisser des emails légitimes bloqués pendant le dépannage.

IX. Comment Skysnag Soutient la Progression de Politique

Passer de p=none à p=quarantine à p=reject nécessite une visibilité continue, une validation des expéditeurs et des preuves d’application.

Skysnag Protect fournit :

• Parsing automatique des rapports DMARC et identification des expéditeurs
• Détection des lacunes d’authentification pour les expéditeurs légitimes
• Notation de préparation à l’application avant les changements de politique
• Gestion et validation de la politique des sous-domaines

Utilisez Skysnag Protect pour identifier les expéditeurs légitimes, détecter les sources non autorisées et progresser vers l’application sans perturber les emails commerciaux.

X. Points clés à retenir

• L’application de la politique DMARC dépend de l’alignement, pas seulement de la réussite de l’authentification
• Le transfert rompt l’alignement SPF mais les signatures DKIM survivent, rendant DKIM essentiel pour la préparation à l’application
• L’application progressive par sous-domaine et groupe d’expéditeurs réduit les risques par rapport au déploiement basé sur un pourcentage
• p=quarantine expose les lacunes d’application sans le risque de rejet complet
• p=reject offre la protection la plus forte mais nécessite la validation des scénarios de transfert et des expéditeurs à faible volume
• L’application dépend du respect de la politique par les serveurs de réception, ce qui n’est pas universel

Commencez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit.