Une politique DMARC définie sur p=none est communément appelée mode surveillance.

Elle indique aux serveurs de messagerie récepteurs d’évaluer l’authentification DMARC, de générer des rapports sur demande, mais de n’appliquer aucune action d’application DMARC lorsque les messages échouent. En pratique, cela signifie que les messages qui échouent à DMARC ne sont ni rejetés ni mis en quarantaine en raison de votre politique DMARC.

Ce paramètre est utile, mais il est souvent mal compris.

p=none n’est pas une protection. C’est de la visibilité.

Les organisations l’utilisent pour découvrir qui envoie des e-mails au nom de leur domaine, quels systèmes passent l’authentification, quels fournisseurs échouent à l’alignement, et où des tentatives d’usurpation peuvent déjà se produire.

Utilisé correctement, p=none est la phase de diagnostic qui prépare un domaine à l’application. Utilisé indéfiniment, il devient une posture de visibilité uniquement qui laisse le domaine exposé à l’usurpation de domaine exact.

I. Ce que fait réellement DMARC p=none

Lorsque vous publiez un enregistrement DMARC avec p=none, les serveurs de messagerie récepteurs peuvent toujours effectuer l’évaluation DMARC complète.

Ils vérifient si le message passe SPF ou DKIM, et si au moins un de ces identifiants authentifiés s’aligne avec le domaine From visible.

Un message passe DMARC uniquement lorsque au moins l’une des conditions suivantes est vraie :

• SPF passe et le domaine authentifié SPF s’aligne avec le domaine From visible.
• DKIM passe et le domaine de signature DKIM s’aligne avec le domaine From visible.

Le passage de SPF seul ne suffit pas. Le passage de DKIM seul ne suffit pas. L’alignement est ce qui connecte l’authentification au domaine que voit le destinataire.

Avec p=none, le récepteur est instruit de ne pas appliquer d’action de politique DMARC lorsque l’authentification échoue. Si les rapports agrégés sont configurés, le récepteur peut envoyer des rapports DMARC montrant les résultats d’authentification qu’il a observés.

Cette distinction est importante.

Un domaine avec p=none n’est pas identique à un domaine sans enregistrement DMARC. Le domaine est évalué et peut recevoir des rapports. Mais il n’est pas encore protégé par l’application DMARC.

II. Pourquoi les organisations commencent avec p=none

La plupart des organisations ne comprennent pas entièrement leur écosystème d’e-mails avant de commencer DMARC.

C’est normal.

Les e-mails quittent souvent l’organisation par plus de systèmes que prévu :

• Microsoft 365 ou Google Workspace
• Plateformes d’automatisation marketing
• Systèmes CRM
• Plateformes de billetterie de support
• Fournisseurs d’e-mails transactionnels
• Systèmes de facturation
• Plateformes RH
• Outils régionaux
• Applications héritées
• Fournisseurs tiers
• Services informatiques parallèles

Si un domaine passe directement à p=quarantine ou p=reject avant que ces sources ne soient identifiées et alignées, le courrier légitime peut échouer.

C’est pourquoi le mode surveillance est important.

p=none donne aux équipes de sécurité et informatiques un moyen sûr d’observer le comportement d’authentification réel avant le début de l’application.

Pendant cette phase, les rapports DMARC peuvent révéler :

• Des expéditeurs légitimes correctement authentifiés
• Des expéditeurs légitimes qui échouent à l’alignement SPF ou DKIM
• Des plateformes tierces envoyant sans configuration appropriée
• Des adresses IP inconnues utilisant le domaine
• Des systèmes hérités envoyant encore des e-mails
• Des sous-domaines nécessitant un examen séparé
• Des tentatives d’usurpation contre le domaine
• Des enregistrements SPF approchant les limites de recherche DNS

L’objectif n’est pas de rester à p=none.

L’objectif est d’utiliser la visibilité pour préparer le domaine à l’application.

III. Démarrez la surveillance DMARC de la bonne manière

Un enregistrement de surveillance DMARC statique de base peut ressembler à ceci :

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

Cet enregistrement peut fonctionner, mais seulement si les rapports sont effectivement reçus, analysés, examinés et exploités.

C’est là que de nombreuses organisations échouent.

Les rapports DMARC arrivent généralement sous forme de fichiers XML. Ils peuvent provenir de nombreux récepteurs, couvrir de grands volumes de messages et nécessiter une analyse pour identifier quels expéditeurs sont légitimes, lesquels sont mal configurés et lesquels sont non autorisés.

Un enregistrement statique sans surveillance active crée un faux sentiment de progrès.

La meilleure approche consiste à démarrer la surveillance DMARC via Skysnag et à obtenir un enregistrement DMARC géré généré pour votre domaine.

Commencez ici :

https://app.skysnag.com/en/register/

Skysnag aide à collecter et analyser les rapports DMARC afin que les équipes puissent identifier les expéditeurs, corriger les lacunes d’authentification et progresser vers l’application en toute confiance.

IV. Ce qui peut mal tourner avec p=none

Le mode surveillance peut échouer silencieusement s’il n’est pas implémenté correctement.

Échecs de livraison de rapports

Si la boîte aux lettres dans la balise rua= ne peut pas recevoir de rapports, l’organisation perd sa visibilité.

Les causes courantes incluent :

• Adresse de rapport incorrecte
• Limites de taille de boîte aux lettres
• Filtrage ou mise en quarantaine des e-mails de rapport
• Problèmes d’autorisation de destination de rapport externe
• Personne ne surveille la boîte aux lettres de rapport
• Pièces jointes de rapport bloquées par les outils de sécurité de messagerie

C’est l’une des raisons pour lesquelles les rapports DMARC manuels ne passent pas à l’échelle.

Si les rapports ne sont pas collectés et examinés, p=none devient un enregistrement DNS avec peu de valeur opérationnelle.

Rapports incomplets

Tous les récepteurs n’envoient pas de rapports agrégés DMARC.

Les grands fournisseurs de boîtes aux lettres envoient généralement des rapports, mais les petits fournisseurs, les systèmes hérités et certaines passerelles d’entreprise peuvent ne pas le faire. Cela signifie que les rapports DMARC fournissent une visibilité utile, mais pas une vue globale complète de chaque message.

Les organisations doivent traiter les rapports DMARC comme un signal fort, pas comme un ensemble de données parfait.

Délai de rapport

Les rapports agrégés DMARC ne sont pas des alertes en temps réel.

Ils arrivent généralement après le traitement des messages, souvent avec un délai. Cela signifie qu’ils sont excellents pour l’analyse des tendances, la découverte d’expéditeurs et la planification de l’application, mais ils ne doivent pas être traités comme une détection instantanée de phishing.

Résultats d’authentification mal interprétés

Une erreur courante consiste à traiter le passage de SPF ou le passage de DKIM comme un passage de DMARC.

DMARC nécessite un alignement avec le domaine From visible. Un fournisseur tiers peut passer SPF en utilisant son propre domaine, ou signer DKIM avec son propre domaine, tout en échouant à l’alignement DMARC pour votre domaine.

C’est l’un des problèmes les plus importants à résoudre avant l’application.

V. Quand p=none vous laisse exposé

p=none donne de la visibilité, mais ne stoppe pas l’usurpation de domaine exact.

Si un attaquant envoie un e-mail prétendant provenir de votre vrai domaine et que le message échoue à SPF, DKIM et l’alignement DMARC, votre politique p=none indique au récepteur de ne pas mettre en quarantaine ou rejeter le message en raison de DMARC.

Le fournisseur récepteur peut toujours filtrer le message en utilisant ses propres systèmes de spam, phishing, réputation et sécurité. Mais votre politique DMARC elle-même ne demande pas au récepteur de le bloquer.

Cela crée une fenêtre d’exposition réelle.

Les attaquants peuvent tenter :

• L’usurpation de domaine exact
• L’usurpation d’identité de cadres
• De faux messages de facture
• Le phishing d’identifiants
• La fraude au paiement de fournisseur
• De fausses alertes de support ou de sécurité
• L’abus de sous-domaines non protégés

Pour un domaine toujours à p=none, DMARC peut montrer que ces tentatives se produisent. Il ne les empêche pas d’être livrées.

VI. Pourquoi rester trop longtemps à p=none est un risque

De nombreuses organisations publient p=none, reçoivent des rapports et n’avancent jamais.

C’est l’échec le plus courant.

La phase de surveillance devrait avoir un objectif et une fin définis.

Si un domaine reste à p=none pendant des mois ou des années, l’organisation peut avoir une visibilité sur les abus mais aucune application DMARC contre eux.

C’est une position faible pour tout domaine utilisé pour :

• Communication client
• Communication employé
• Facturation et factures
• Réinitialisations de mot de passe
• Notifications de compte
• Alertes de sécurité
• Communication fournisseur
• Communication de direction
• Flux de travail réglementés ou à haute confiance

Pour ces domaines, la surveillance devrait mener à l’action.

VII. Quand p=none peut être approprié

p=none est approprié lorsqu’une organisation commence DMARC, découvre les expéditeurs ou valide les corrections d’authentification.

Il peut également être utile pour les domaines nouvellement acquis, les environnements complexes ou les domaines où les sources d’e-mails sont encore en cours de cartographie.

Les utilisations valides courantes incluent :

• Déploiement DMARC initial
• Découverte de source d’e-mail
• Examen d’expéditeur tiers
• Test d’alignement SPF et DKIM
• Planification de migration
• Évaluation d’acquisition de domaine
• Examen de système hérité
• Validation pré-application

Mais p=none ne devrait pas devenir l’état final pour les domaines d’envoi importants.

Pour les domaines auxquels les clients, employés ou partenaires font confiance, l’objectif à long terme devrait généralement être l’application via p=quarantine ou p=reject, une fois que le courrier légitime est correctement aligné.

VIII. Passer de p=none à l’application

Le chemin de la surveillance à l’application devrait être basé sur des preuves.

Avant de passer à l’application, confirmez :

• Tous les expéditeurs légitimes sont identifiés.
• Les expéditeurs critiques passent DMARC.
• Les fournisseurs tiers sont correctement alignés.
• Les enregistrements SPF ne dépassent pas les limites de recherche.
• DKIM est activé là où nécessaire.
• Les sous-domaines sont examinés.
• Les expéditeurs inconnus sont enquêtés.
• Les responsables métier comprennent le changement.
• Les procédures de retour en arrière sont définies.
• Les rapports DMARC sont activement surveillés.

Une fois ces conditions remplies, les organisations peuvent commencer à déplacer des domaines ou sous-domaines sélectionnés vers l’application.

Un chemin d’application pratique ressemble à ceci :

1. Commencer avec p=none pour la découverte.
2. Remédier aux sources légitimes qui échouent à l’authentification ou à l’alignement.
3. Déplacer les sous-domaines à faible risque ou bien compris vers p=quarantine.
4. Surveiller l’impact et résoudre les problèmes restants.
5. Déplacer les domaines matures et critiques pour l’entreprise vers p=quarantine.
6. Passer à p=reject lorsque la confiance est élevée.

Cette approche progressive est plus sûre que de changer tous les domaines en même temps.

Elle évite également de s’appuyer sur un déploiement basé sur des pourcentages, qui n’est plus le modèle préféré pour les programmes DMARC actuels.

IX. Malentendus courants sur p=none

« p=none signifie que nous sommes protégés »

Faux.

p=none signifie que vous surveillez. Il n’indique pas aux récepteurs de mettre en quarantaine ou de rejeter les messages qui échouent à DMARC.

« SPF et DKIM suffisent »

Pas toujours.

SPF et DKIM ne deviennent utiles pour DMARC que lorsqu’ils s’alignent avec le domaine From visible. Sans alignement, un message peut passer SPF ou DKIM et toujours échouer à DMARC.

« Les rapports nous disent tout »

Non.

Les rapports DMARC sont utiles, mais ils sont retardés, incomplets et dépendent des récepteurs qui les envoient.

Ils ne montrent pas chaque message globalement, et les rapports agrégés n’incluent pas le contenu des messages.

« Nous pouvons rester à p=none pour toujours »

Techniquement oui, mais du point de vue de la sécurité, cela signifie que le domaine reste en mode surveillance uniquement.

Pour les domaines importants, p=none devrait être une phase, pas une stratégie permanente.

« L’application cassera les e-mails »

L’application peut casser les e-mails légitimes si elle est mise en œuvre sans découverte.

C’est pourquoi la surveillance existe.

Le but de p=none est de trouver et de corriger les problèmes avant l’application, pas d’éviter l’application de manière permanente.

X. Qu’en est-il des rapports forensiques ?

DMARC prend en charge les rapports d’échec via la balise ruf=, mais elle ne devrait pas être activée à la légère.

Les rapports d’échec peuvent contenir des informations sensibles au niveau des messages, selon l’implémentation du récepteur. Ils ont également une adoption limitée parmi les principaux fournisseurs de boîtes aux lettres en raison de préoccupations de confidentialité.

Pour la plupart des organisations, les rapports agrégés via rua= devraient être le point de départ par défaut.

Utilisez les rapports forensiques uniquement après un examen juridique, de confidentialité, de sécurité et de rétention.

XI. Pourquoi les outils comptent

La surveillance DMARC n’est utile que si les rapports deviennent exploitables.

Les rapports XML bruts sont difficiles à examiner manuellement. Ils doivent être normalisés, regroupés par expéditeur, interprétés pour l’alignement SPF et DKIM, et suivis dans le temps.

Skysnag Protect aide à automatiser ce processus en donnant aux équipes une visibilité sur :

• Les expéditeurs autorisés
• Les sources non autorisées
• L’alignement SPF et DKIM
• Les tendances de passage et d’échec DMARC
• L’activité des sous-domaines
• La préparation à l’application
• Les échecs d’authentification
• Les changements d’expéditeur dans le temps

Cela aide les organisations à passer de la surveillance passive à la protection active.

Démarrez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit :

https://app.skysnag.com/en/register/

XII. Liste de vérification de mise en œuvre

Utilisez cette liste de vérification pour rendre p=none efficace.

• [ ] Publier un enregistrement de surveillance DMARC avec rapports agrégés.
• [ ] Utiliser une destination de rapport surveillée, pas une boîte aux lettres non gérée.
• [ ] Confirmer que les rapports DMARC sont reçus et analysés.
• [ ] Identifier toutes les sources d’envoi légitimes.
• [ ] Classifier les sources inconnues comme légitimes, mal configurées ou non autorisées.
• [ ] Valider l’alignement SPF pour chaque expéditeur.
• [ ] Valider l’alignement DKIM pour chaque expéditeur.
• [ ] Examiner les limites de recherche DNS SPF.
• [ ] Confirmer que les fournisseurs tiers prennent en charge l’authentification alignée.
• [ ] Éviter les rapports forensiques sauf si les équipes juridiques et de confidentialité l’approuvent.
• [ ] Examiner les sous-domaines séparément.
• [ ] Définir les critères pour passer à la quarantaine ou au rejet.
• [ ] Établir des procédures de retour en arrière avant l’application.
• [ ] Surveiller les rapports en continu après les changements de politique.

XIII. Points Clés

DMARC p=none est le mode surveillance.

Il permet aux serveurs de messagerie destinataires d’évaluer DMARC et d’envoyer des rapports, mais il ne leur demande pas de bloquer ou de mettre en quarantaine les messages ayant échoué.

Cela le rend utile pour la découverte, mais insuffisant pour une protection à long terme.

Les organisations doivent utiliser p=none pour identifier les expéditeurs légitimes, détecter les échecs d’authentification, corriger l’alignement des tiers et préparer l’application.

Le principal écueil est de rester indéfiniment en p=none.

Pour les domaines importants, la surveillance devrait conduire à p=quarantine ou p=reject une fois que le courrier légitime est correctement aligné.

L’application de DMARC est ce qui réduit le risque d’usurpation de domaine exact. La surveillance est la façon d’y parvenir en toute sécurité.

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