Déployer DMARC de observation à reject

Déployer DMARC de observation à reject

Un domaine déjà couvert par SPF (Sender Policy Framework) et DKIM (DomainKeys Identified Mail) n’est pas pour autant protégé contre l’usurpation visible dans les boîtes de réception. DMARC (Domain-based Message Authentication, Reporting, and Conformance) permet d’imposer l’alignement entre l’identité affichée et les mécanismes d’authentification, à condition de ne pas brûler les étapes.

Explication de la marmotte

Une politique de messagerie ressemble au contrôle d’accès d’un immeuble : porter un uniforme ne suffit pas, il faut aussi que le nom affiché corresponde à la liste des personnes attendues. Le contrôle évite qu’un inconnu utilise le nom sur la boîte aux lettres pour entrer et tromper les occupants.

→ Lire l’explication complète de la marmotte

Préparer DMARC avant la phase d’observation

Le compromis central est brutal : p=reject réduit fortement l’usurpation du domaine, mais rejette aussi les flux légitimes oubliés. La recommandation est nette : commencer par p=none, inventorier les émetteurs réels à partir des rapports, corriger SPF et DKIM, puis monter progressivement vers quarantine et reject. Passer directement à reject n’est acceptable que si chaque source d’envoi est connue, contrôlée et testée. Cette condition est rare. Les slides de vendeur connaissent toujours tous les flux ; les zones DNS, beaucoup moins.

DMARC évalue deux résultats :

• SPF doit réussir et son domaine d’enveloppe, le MAIL FROM, doit être aligné avec le domaine visible dans l’en-tête From.
• DKIM doit réussir et le domaine d= de la signature doit être aligné avec le domaine visible dans From.

L’alignement peut être relâché (adkim=r, aspf=r) ou strict (adkim=s, aspf=s). En mode relâché, les sous-domaines sont admis : mail.exemple.fr s’aligne avec exemple.fr. En mode strict, les domaines doivent être identiques. Démarrer en relâché est généralement le bon choix pour un domaine existant. Le strict est pertinent seulement après inventaire des domaines d’envoi et validation des prestataires, notamment ceux qui signent depuis des sous-domaines dédiés.

Avant toute publication, recenser :

1. Les plateformes qui envoient avec le domaine dans From : messagerie collaborative, relais SMTP (Simple Mail Transfer Protocol), applications métier, outils de ticketing, marketing, facturation, monitoring et équipements réseau.
2. Le domaine d’enveloppe utilisé par chaque source, qui peut différer du From.
3. Le sélecteur DKIM, le domaine d=, l’algorithme de signature et la rotation prévue.
4. Les transferts automatiques, listes de diffusion et relais sortants. Ils cassent souvent SPF parce que l’adresse IP du relais ne figure pas dans l’enregistrement SPF du domaine d’origine.
5. Les sous-domaines qui envoient réellement des courriels ou qui doivent explicitement ne jamais en envoyer.

Le DNS (Domain Name System) doit accepter des enregistrements TXT (Text) suffisamment longs et publiés chez l’autorité DNS effectivement servie. Vérifier les délégations, les environnements séparés et les éventuels proxys DNS. Une modification dans une console qui ne pilote pas la zone faisant autorité est une forme assez élaborée de décoration intérieure.

Les clés DKIM doivent être en RSA (Rivest-Shamir-Adleman) d’au moins 2048 bits ou en Ed25519 lorsque l’émetteur et les destinataires le supportent. Une clé RSA de 1024 bits reste parfois fonctionnelle, ce qui ne la rend pas fréquentable. Prévoir deux sélecteurs actifs permet de publier une nouvelle clé, basculer les signatures, attendre l’expiration des messages en transit, puis retirer l’ancienne clé.

Pour les fondations de confiance liées à DNS et aux certificats, consulter aussi PKI et TLS et les principes de cryptographie appliquée. DMARC ne chiffre rien, ne protège pas le contenu et ne remplace pas une architecture de messagerie correctement segmentée.

Publier p=none et collecter les rapports agrégés

Le premier enregistrement DMARC se publie à _dmarc.exemple.fr sous forme TXT. La balise p=none demande aux destinataires de ne pas appliquer de rejet sur la base de DMARC, tout en générant des rapports agrégés. Ces rapports, au format XML (Extensible Markup Language), décrivent les messages observés par domaine source, adresse IP, résultat SPF, résultat DKIM et disposition appliquée.

Utiliser une boîte dédiée ou un collecteur spécialisé pour l’adresse rua (Reporting URI for Aggregate data). Une adresse personnelle ou une boîte partagée sans rétention transforme vite l’observabilité en compost numérique. Les rapports peuvent être compressés en ZIP ou GZIP et arriver en nombre selon la diffusion du domaine.

; Enregistrement TXT à publier dans la zone exemple.fr
; rua reçoit les rapports agrégés, ruf est volontairement absent.
_dmarc.exemple.fr. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"

Ne pas activer ruf (Reporting URI for Forensic data) par défaut. Les rapports détaillés sont peu pris en charge, peuvent contenir des fragments de messages et posent des problèmes de confidentialité. Ils ne remplacent pas les journaux du fournisseur de messagerie ni les traces du relais SMTP.

Le tag pct définit le pourcentage de messages soumis à la politique. Avec p=none, il n’apporte presque rien car la politique ne demande aucune action de filtrage. Garder pct=100 en observation produit une image complète. Lors de la montée vers quarantine ou reject, pct permet un déploiement progressif, mais ne garantit pas une répartition homogène par application, destinataire ou type de message. C’est un coupe-circuit statistique, pas une stratégie de recette.

Ajouter sp=none seulement si les sous-domaines doivent explicitement rester en observation. Sans sp, les sous-domaines héritent de p. Cette héritage est souvent oublié, puis un sous-domaine de campagne se retrouve traité comme le domaine principal. Les sous-domaines d’envoi doivent plutôt posséder leur propre politique DMARC, leur SPF et leurs clés DKIM.

Lire les rapports DMARC sans confondre passage et alignement

L’analyse doit porter sur les enregistrements dont le champ header_from correspond au domaine protégé. Un rapport indique souvent spf=pass et dkim=pass, mais DMARC peut échouer si aucun des deux domaines authentifiés ne s’aligne avec le domaine affiché dans From.

Classer chaque source observée dans quatre catégories :

Situation	Interprétation	Action
DKIM aligné en succès	Cas préféré	Conserver la signature et contrôler la rotation
SPF aligné en succès, DKIM absent ou non aligné	Fonctionnel mais fragile	Ajouter DKIM aligné
SPF et DKIM en succès, aucun alignement	Configuration incomplète	Modifier le domaine d’enveloppe ou d=
Échecs SPF et DKIM	Flux non autorisé ou mal configuré	Identifier la source avant toute exception

DKIM aligné doit devenir le mécanisme principal. SPF dépend de l’adresse IP émettrice et casse au transfert. DKIM survit normalement au relais, sauf modification d’éléments signés, réécriture du corps ou ajout de pied de page par une liste de diffusion. Signer des en-têtes stables, notamment From, To, Subject, Date et Message-ID, puis mesurer les échecs. Signer tout ce qui bouge dans la chaîne de transport est une invitation à collectionner les faux négatifs.

Les adresses IP inconnues ne sont pas automatiquement frauduleuses. Un prestataire peut mutualiser des adresses, changer d’infrastructure ou utiliser un sous-traitant. Il faut rapprocher l’adresse IP, le domaine DKIM, le domaine d’enveloppe et la nature du message. Une exception SPF ajoutée sur la seule base d’une adresse IP vue dans un rapport est une mauvaise pratique : les plages évoluent, les attaques aussi, et les enregistrements SPF finissent alors en roman-fleuve illisible.

SPF limite également le nombre de recherches DNS à dix pendant son évaluation. Empiler des include: de prestataires peut produire un permerror, donc un échec permanent, même quand tous les prestataires sont autorisés sur le papier. Réduire les dépendances, utiliser des sous-domaines dédiés par émetteur et vérifier le compteur de consultations avant chaque ajout.

Les collecteurs doivent conserver les rapports bruts, les résultats normalisés et une table d’inventaire des flux approuvés. Une rétention de plusieurs mois permet de repérer les envois rares : factures périodiques, relances, messages de reprise ou systèmes dont l’existence n’apparaît que lorsqu’ils échouent. Vingt ans de messagerie apprennent que le flux oublié n’est jamais le bulletin hebdomadaire ; c’est toujours celui qui porte le mot « urgent » dans son objet.

Passer de quarantine à reject sans casser les flux légitimes

Après une période d’observation couvrant les cycles métier connus, corriger tous les flux légitimes visibles. La condition de passage est précise : chaque flux autorisé doit obtenir un succès DMARC par SPF aligné ou, de préférence, DKIM aligné. Les échecs résiduels doivent être attribués à une usurpation, à du courrier indésirable ou à un flux explicitement abandonné.

La progression recommandée est :

1. Publier p=quarantine; pct=25, surveiller les rapports et les journaux de délivrabilité.
2. Monter pct à 50 puis 100 après stabilisation des sources autorisées.
3. Publier p=reject; pct=25, puis augmenter jusqu’à 100.
4. Retirer les exceptions temporaires, documenter les émetteurs et imposer DMARC comme critère d’intégration de toute nouvelle plateforme.

quarantine demande au destinataire de traiter le message avec méfiance, souvent en courrier indésirable. reject demande son refus pendant la transaction SMTP. La décision reste appliquée par le destinataire : DMARC ne force pas un fournisseur à agir, il fournit une politique exploitable. Certains destinataires appliquent des heuristiques supplémentaires, notamment sur la réputation, le contenu ou l’historique d’envoi.

Configurer fo=1 peut demander davantage de rapports lors d’échecs d’authentification, mais son effet dépend du fournisseur de rapports. Ne pas fonder l’exploitation sur cette balise. La supervision doit plutôt suivre les taux DMARC par source, l’apparition de nouveaux domaines d=, les erreurs SPF permanentes, les sélecteurs DKIM inconnus et les variations de volume.

Le passage à reject ne garantit pas que tous les messages frauduleux disparaissent. Il ne protège que le domaine concerné dans le champ From. Un attaquant peut utiliser un domaine ressemblant, un domaine compromis, un affichage trompeur ou une conversation existante. La lutte contre le phishing exige aussi filtrage entrant, protection des comptes, authentification multifacteur et sensibilisation. Les menaces réseau et leur réponse rappellent la même règle : un contrôle isolé ne devient pas une architecture parce qu’il possède un acronyme.

Exploitation DMARC, rotation et reprise

L’enregistrement DMARC est une politique de sécurité : gérer ses modifications via contrôle de version, validation DNS et journal de changement. Toute nouvelle source d’envoi doit fournir son domaine d’enveloppe, son domaine DKIM, ses sélecteurs, ses adresses d’émission et un test de réception externe avant autorisation. L’ajout tardif après une alerte de rejet est une procédure d’intégration inversée, donc une procédure de crise.

Les clés DKIM privées restent dans le composant signataire ou dans un HSM (Hardware Security Module) lorsque la plateforme le permet. Elles ne doivent pas être exportées dans un dépôt CI/CD (Continuous Integration and Continuous Delivery), une image de conteneur ou une variable d’environnement durable. Une fuite de clé DKIM permet de signer des messages qui satisferont DMARC tant que la clé publique reste publiée.

La rotation DKIM exige de publier la nouvelle clé avant usage, de basculer la signature, de surveiller les rapports, puis de retirer l’ancien sélecteur après expiration du trafic en transit. Une sauvegarde DNS doit inclure les enregistrements DMARC, SPF et DKIM, mais restaurer une ancienne clé privée compromise est interdit : la reprise doit générer une nouvelle paire de clés et révoquer le sélecteur exposé par retrait DNS.

🐝 Ce qui arrive si on s’en passe

Sans enregistrement DMARC, un message falsifié portant exactement le domaine dans le champ From n’est soumis à aucune politique publiée : le destinataire applique ses seules heuristiques, et le propriétaire du domaine ne reçoit aucun rapport signalant les campagnes d’usurpation en cours. Les plaintes et signalements provoqués par ces envois frauduleux dégradent la réputation du domaine, donc la délivrabilité du courrier légitime. Les sous-domaines inexistants ou non émetteurs restent usurpables faute de politique héritée. Depuis février 2024, Gmail et Yahoo exigent un enregistrement DMARC (au minimum p=none) des expéditeurs dépassant 5 000 messages quotidiens : son absence entraîne refus ou classement en indésirables. BIMI, qui affiche le logo de la marque dans les clients compatibles, exige une politique quarantine ou reject et reste donc inaccessible.

🦫 Explication de la marmotte 🍫

Un message électronique contient une adresse visible, celle affichée dans le champ « De ». Des fraudeurs peuvent écrire cette adresse sans posséder le domaine concerné. La politique décrite ici demande aux serveurs qui reçoivent les messages de vérifier si l’expéditeur a une autorisation liée au domaine affiché.

Deux contrôles existent. Le premier vérifie si le serveur qui envoie le message fait partie des serveurs autorisés par le propriétaire du domaine. Le second vérifie une signature ajoutée au message avec une clé secrète, puis contrôlée avec une clé publique publiée dans le système qui traduit les noms de domaine en adresses. Au moins un contrôle doit réussir en utilisant un nom de domaine suffisamment proche de celui affiché.

La mise en place commence sans blocage. Les serveurs destinataires envoient alors des rapports indiquant quels systèmes ont expédié des messages et si les contrôles ont réussi. Ces rapports servent à découvrir les applications oubliées, les prestataires et les erreurs de configuration.

Une fois les sources légitimes corrigées, la politique demande d’abord de placer les messages en échec dans les courriers indésirables, puis de les refuser. Si une application légitime n’est pas configurée, ses messages peuvent être refusés : c’est pourquoi l’inventaire et la surveillance restent nécessaires. Cette protection ne bloque pas les faux domaines ressemblants ni le vol d’un compte de messagerie.

À lire aussi

• Comment former contre le phishing sans culpabiliserFormer sans culpabiliser réduit le phishing quand la formation s'appuie sur des contrôles techniques, des signalements sans sanction et des exercices mesurables.
• Pourquoi le phishing fonctionne malgré la formationL’ingénierie sociale exploite les contraintes humaines et organisationnelles que la formation seule ne neutralise pas.
• Mener une simulation de phishing interne éthique avec GoPhishGuide pas-à-pas pour conduire une simulation de phishing interne éthique, de l'autorisation de la direction à la formation ciblée, avec GoPhish, un domaine de simulation dédié et des résultats jamais nominatifs.
• Micro-formations de sensibilisation sécurité régulièresGuide pratique pour déployer un programme de sensibilisation à la sécurité fondé sur des micro-formations régulières plutôt qu’une session annuelle.

Pages voisines

La citent

• Comment contrer le spear phishing et la fraude au président
• Comment former contre le phishing sans culpabiliser
• OSINT défensif : mesurer et réduire l'exposition publique

Déployer DMARC de observation à reject

Elle cite

• ⇄Lien dans les deux sens :Déployer SPF DKIM DMARC jusqu'à reject
• ⇄Lien dans les deux sens :Détecter le contenu IA malveillant : limites
• Déployer FIDO2 pour comptes à privilèges

⇄ : les deux pages se citent l’une l’autre.