Déployer SPF DKIM DMARC jusqu’à reject

SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting and Conformance) réduisent l’usurpation du domaine dans les e-mails sortants. Le compromis est net : on gagne une protection réelle contre le phishing utilisant le domaine, mais on paie par un inventaire exhaustif des émetteurs et une exploitation continue. Passer directement en rejet est une mauvaise idée, même emballée dans une slide de conformité.

→ Lire l’explication complète de la marmotte

Préparer l’inventaire des émetteurs et le DNS

Avant toute modification, recenser chaque système qui envoie avec une adresse du domaine : plateforme de messagerie, relais SMTP (Simple Mail Transfer Protocol), outil marketing, ERP (Enterprise Resource Planning), gestionnaire de tickets, outil RH, imprimantes multifonctions, alertes de supervision et prestataires SaaS (Software as a Service). L’adresse visible dans le champ From: compte autant que l’infrastructure d’envoi.

Cet inventaire doit associer, pour chaque émetteur, le domaine utilisé dans From:, son mode de relais, ses adresses IP (Internet Protocol) ou ses mécanismes d’authentification, son propriétaire et sa fréquence d’émission. Un ERP qui n’envoie que les relances de paiement reste un émetteur de production. Il devient surtout visible le jour où DMARC bloque la relance et que la comptabilité découvre la cryptographie par téléphone.

Prévoir également l’accès au DNS (Domain Name System), idéalement via une zone gérée par infrastructure-as-code, avec revue et journalisation des changements. SPF et DMARC sont des enregistrements TXT ; DKIM publie aussi une clé publique dans un enregistrement TXT, sous un nom déterminé par un sélecteur. Les modifications DNS doivent respecter le TTL (Time To Live) existant : réduire le TTL avant une migration facilite le retour arrière, sans supprimer le délai de propagation chez les résolveurs qui ont déjà mis l’ancienne valeur en cache.

Consulter les principes de gestion des identités aide à désigner un propriétaire pour chaque compte de service SMTP. Un domaine dont personne ne possède les flux sortants ne peut pas atteindre p=reject sans casse aléatoire.

Étape 1 : publier un SPF unique et borné

SPF autorise des serveurs à envoyer pour le domaine figurant dans l’enveloppe SMTP, aussi appelée MAIL FROM ou Return-Path. Il ne protège pas directement le champ From: affiché au lecteur. Cette limite explique pourquoi SPF seul ne règle pas l’usurpation visible.

Publier un unique enregistrement SPF à la racine du domaine. Plusieurs enregistrements SPF sont interprétés comme une erreur permanente (permerror) par les récepteurs. La politique doit lister les plages IP administrées et inclure uniquement les fournisseurs nécessaires.

; example.com : un seul SPF, avec relais interne et prestataire marketing
example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.24 include:spf.mail.example.net include:_spf.marketing.example -all"

; politique DMARC initiale, rapports uniquement, à publier après DKIM
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100"

Le suffixe -all annonce que toute autre source doit échouer. Pendant la phase initiale, ce choix reste recommandé : les destinataires qui appliquent SPF signalent immédiatement les sources oubliées, tandis que DMARC en p=none ne demande pas de blocage. Utiliser ~all pour cacher les échecs ne résout aucun inventaire ; cela transforme seulement une erreur exploitable en brouillard administratif.

SPF impose une limite de dix recherches DNS, incluant les mécanismes include, a, mx, exists et redirect. Dépasser cette limite produit un permerror. Les prestataires qui empilent des inclusions méritent une vérification manuelle : la magie du DNS cesse précisément à la onzième requête, ce qui manque de glamour mais fonctionne ainsi.

Ne jamais publier +all. Cette valeur autorise Internet entier à envoyer pour le domaine et équivaut à installer une serrure décorative sur une porte sans mur.

Étape 2 : signer chaque flux avec DKIM

DKIM ajoute une signature cryptographique aux messages sortants. Le serveur signe certaines en-têtes et une représentation du corps avec une clé privée ; le destinataire récupère la clé publique dans le DNS pour vérifier que le message provient d’un système autorisé à signer pour le domaine.

Activer DKIM sur chaque plateforme, pas seulement sur la messagerie principale. Les outils marketing et ERP doivent signer avec un domaine aligné sur le champ From:. Un fournisseur qui signe uniquement avec son propre domaine peut passer sa vérification DKIM, mais échouera l’alignement DMARC pour le domaine de l’entreprise.

Utiliser RSA (Rivest, Shamir, Adleman) en 2048 bits ou Ed25519 lorsque le fournisseur et les destinataires le prennent en charge. Éviter RSA 1024 bits, obsolète pour une nouvelle configuration. Créer un sélecteur distinct par système, par exemple m365, marketing, erp. Cette séparation permet de révoquer une clé compromise ou de migrer un prestataire sans interrompre les autres signatures.

Le nom DNS suit le modèle <selecteur>._domainkey.<domaine>. Une clé privée DKIM appartient au système d’envoi ou à son prestataire, jamais à un poste d’administration, un dépôt Git ou une variable de pipeline lisible par une armée de comptes de service. Pour les environnements auto-hébergés, placer la clé dans un gestionnaire de secrets avec contrôle d’accès, journalisation et sauvegarde chiffrée. Une HSM (Hardware Security Module) peut protéger une clé lorsque le MTA (Mail Transfer Agent) le supporte réellement, pas juste dans la brochure.

Signer au minimum From, To, Subject, Date, Message-ID et les en-têtes métier sensibles. Vérifier que les modifications en transit, notamment les listes de diffusion, ne cassent pas systématiquement la signature. DKIM ne garantit ni la légitimité du contenu ni l’absence de compromission du compte expéditeur. Une boîte compromise peut signer parfaitement un e-mail frauduleux, avec une politesse cryptographique irréprochable.

Étape 3 : publier DMARC en observation

DMARC relie le champ From: visible aux résultats SPF et DKIM. Pour réussir, SPF ou DKIM doit réussir et être aligné avec le domaine du From:. L’alignement strict, adkim=s et aspf=s, exige une correspondance exacte ; l’alignement relâché accepte aussi les sous-domaines.

Commencer avec une politique d’observation :

; Rapports agrégés quotidiens vers une boîte ou un collecteur dédié
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100"

rua reçoit les rapports agrégés, généralement XML (Extensible Markup Language), décrivant les sources, volumes et résultats. ruf demande des rapports détaillés, mais de nombreux fournisseurs les ignorent ou les limitent pour des raisons de confidentialité. Prévoir une boîte dédiée ou un collecteur capable de parser XML, stocker les rapports et produire une vue par source IP, domaine d’enveloppe, sélecteur DKIM et résultat d’alignement.

Le mode p=none ne force aucun traitement de rejet. Il permet d’observer les usages réels sans casser les flux. Il ne bloque donc pas l’usurpation : c’est une phase de mesure, pas une protection finale. Pour les sous-domaines, ajouter ultérieurement sp=none, puis une politique spécifique, évite de découvrir qu’un sous-domaine oublié expédie des messages depuis un prestataire fossilisé.

Étape 4 : analyser les rapports et corriger les écarts

Analyser les rapports pendant plusieurs cycles complets d’activité métier, incluant facturation, campagnes, clôtures et alertes planifiées. Rechercher quatre catégories : sources attendues et conformes, sources attendues mais non alignées, sources inconnues qui usurpent le domaine, sources temporaires qui doivent être supprimées.

Pour chaque échec légitime, corriger d’abord DKIM et l’alignement du From:. Ajouter une IP dans SPF ne doit être qu’un second choix, car SPF casse fréquemment lors du transfert de message. Les redirections et listes de diffusion modifient le chemin SMTP ; DKIM survit mieux lorsque les en-têtes signés et le corps ne sont pas réécrits.

Vérifier les erreurs d’alignement causées par From: notifications.example.com alors que DKIM signe mail.example.com. En alignement strict, ces domaines diffèrent. Deux options existent : signer pour le sous-domaine exact, ou assumer l’alignement relâché après avoir validé la délégation. Le choix dépend de la gouvernance des sous-domaines : strict quand leurs propriétaires sont distincts, relâché quand ils appartiennent à une même chaîne d’envoi contrôlée.

Documenter les exceptions avec une date de retrait. Une exception SPF sans propriétaire devient une dette technique qui sait envoyer des e-mails, ce qui est une forme particulièrement tenace de dette technique.

Étape 5 : passer de quarantine à reject

Une fois tous les émetteurs légitimes conformes, passer à p=quarantine; pct=25. La quarantaine demande aux destinataires de traiter les messages en échec comme suspects, souvent en spam. Contrôler les rapports et les tickets métier, puis augmenter pct à 50, 75 et 100. Le paramètre pct s’applique aux messages auxquels la politique est demandée ; il ne compense pas une couverture mal vérifiée.

Après une période stable à 100 %, publier p=reject. Le rejet demande aux destinataires de refuser les messages qui échouent DMARC. C’est la cible recommandée pour le domaine principal et ses sous-domaines maîtrisés. Ajouter sp=reject uniquement après validation spécifique des sous-domaines, car leur inventaire est souvent moins propre que celui du domaine parent.

; Politique finale, domaine et sous-domaines, alignement strict
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100"

Conserver les rapports après le durcissement. Un nouveau fournisseur, une migration de messagerie ou une rotation DKIM peut créer un échec sans avertissement visible. La supervision doit alerter sur toute nouvelle source, toute hausse d’échec d’alignement et toute disparition des rapports d’un grand fournisseur de messagerie.

La rotation DKIM consiste à publier un nouveau sélecteur, activer la signature avec la nouvelle clé, attendre l’expiration des messages encore en transit, puis retirer l’ancien enregistrement. Ne pas remplacer la clé sous le même sélecteur : des messages en file ou archivés deviendraient invérifiables. Les principes de cryptographie appliquée restent les mêmes : une clé privée compromise impose un remplacement, pas une séance de méditation devant le DNS.

🐝 Ce qui arrive si on s’en passe

Sans ces trois enregistrements, rien n’empêche un tiers d’écrire n’importe quelle adresse du domaine dans le champ From: : le message arrive complet, avec le bon nom affiché, et le destinataire n’a aucun élément vérifiable pour le distinguer d’un envoi légitime. L’absence de rapports agrégés supprime aussi la visibilité : aucune remontée n’indique quelles adresses IP expédient au nom du domaine, ni depuis quand, ce qui rend une campagne d’usurpation invisible jusqu’aux plaintes des destinataires. En analyse d’incident, il devient impossible de démontrer qu’un message attribué au domaine n’en provenait pas, faute de signature à vérifier ou de trace d’alignement. Enfin, les récepteurs qui ne trouvent aucune politique appliquent leurs propres heuristiques : le classement des envois réels dépend alors de réputations d’adresses IP partagées, sans recours ni levier de correction.

🦫 Explication de la marmotte 🍫

Un domaine d’entreprise peut être utilisé dans la partie visible d’un e-mail sans que l’expéditeur soit réellement autorisé. Trois contrôles permettent de réduire ce problème.

Le premier publie, dans le système qui associe les noms de domaine aux informations techniques, la liste des serveurs autorisés à envoyer des messages. Le second ajoute une signature mathématique aux messages sortants. Le destinataire récupère une information publique publiée par le domaine et vérifie que la signature correspond au message reçu. Chaque outil d’envoi doit disposer de cette signature, y compris les outils oubliés comme la facturation ou les alertes.

Le troisième contrôle vérifie que le nom affiché dans l’e-mail correspond bien à un serveur autorisé ou à une signature valide. Il indique aussi aux destinataires quoi faire lorsqu’une vérification échoue.

La mise en place commence sans blocage, afin de recevoir des rapports sur tous les serveurs qui envoient des messages. Ces rapports servent à détecter les outils légitimes non configurés et les tentatives d’usurpation. Ensuite, les outils légitimes sont corrigés un par un. Quand les rapports ne montrent plus d’émetteur attendu en échec, la politique demande d’abord de placer les messages douteux en courrier indésirable, puis de les refuser. Si un nouvel outil envoie sans être déclaré ou signé, ses messages peuvent être rejetés : il faut donc surveiller les rapports, renouveler les clés de signature et maintenir l’inventaire des émetteurs.

Pages voisines

La citent

Déployer SPF DKIM DMARC jusqu'à reject

Elle cite

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