Objectif
Authentifier les e-mails envoyés par un domaine en combinant SPF, DKIM et DMARC de manière cohérente. La procédure recense toutes les sources, construit un SPF maintenable, active DKIM sur chaque plateforme, publie DMARC en observation selon RFC 9989, puis contrôle l’alignement dans les vrais messages reçus avant tout renforcement.
Prérequis
- Contrôle DNS du domaine.
- Liste de toutes les sources d’envoi : Microsoft 365
- Accès aux consoles permettant d’activer DKIM sur chaque service.
- Boîte ou service de collecte pour les rapports DMARC agrégés.
- Adresse de test chez plusieurs fournisseurs pour contrôler les en-têtes.
Procédure pas à pas
Inventorier toutes les sources d’envoi
Listez pour chaque service le domaine visible From, le domaine MAIL FROM/envelope sender, l’IP ou include SPF, et le domaine DKIM d=. Les services oubliés sont la première cause de régression lorsqu’on durcit l’authentification. Incluez aussi les équipements rarement utilisés comme multifonctions et applications de supervision.
- Chaque source possède un propriétaire et une méthode SPF/DKIM identifiée.
Contrôler les enregistrements existants
Résolvez les TXT du domaine et repérez SPF, DMARC et sélecteurs DKIM. Vérifiez qu’il n’existe pas deux SPF ni plusieurs DMARC concurrents. Conservez l’état initial avant modification.
Resolve-DnsName -Type TXT <DOMAINE>Resolve-DnsName -Type TXT _dmarc.<DOMAINE>- La configuration actuelle est sauvegardée et les conflits DNS sont connus.
Construire un SPF unique et minimal
Fusionnez les sources légitimes dans un seul record. Pour Microsoft 365, utilisez l’include officiel adapté ; pour les autres services, suivez leur documentation. Retirez les sources anciennes et surveillez le nombre de recherches DNS générées par include, a, mx et redirect. Terminez par ~all pendant l’inventaire si nécessaire, puis -all lorsque toutes les sources sont maîtrisées.
v=spf1 include:<FOURNISSEUR> ip4:<IP-AUTORISEE> ~all- Un seul SPF valide couvre les émetteurs légitimes.
Activer DKIM sur chaque plateforme
Dans Microsoft 365, publiez les CNAME DKIM fournis pour le domaine personnalisé puis activez la signature. Pour les autres SaaS, utilisez leur sélecteur et domaine de signature personnalisé. Vérifiez que la signature d= est alignée avec le From visible selon le niveau d’alignement choisi.
Resolve-DnsName -Type CNAME <SELECTEUR>._domainkey.<DOMAINE>- Les messages de chaque source importante retournent dkim=pass.
Publier DMARC en observation selon RFC 9989
Publiez un DMARC simple en p=none avec rua. N’utilisez pas pct dans une nouvelle configuration. Les rapports permettent d’identifier les sources et l’alignement avant enforcement. Si un service tiers reçoit les rapports, vérifiez l’autorisation prévue par le standard.
v=DMARC1; p=none; rua=mailto:dmarc-reports@<DOMAINE>; adkim=r; aspf=r- Le record DMARC est unique et les rapports commencent à arriver.
Tester les messages réellement reçus
Envoyez depuis chaque source vers plusieurs boîtes externes. Dans les en-têtes, contrôlez Authentication-Results : spf, smtp.mailfrom, dkim, header.d, dmarc et header.from. Sur Microsoft 365, Message Trace et les outils d’authentification facilitent le diagnostic.
- Chaque flux légitime produit DMARC pass via SPF ou DKIM aligné.
Corriger les sources non alignées
Un SPF pass n’aide pas DMARC si MAIL FROM n’est pas aligné avec le From. De même, un DKIM pass signé uniquement avec le domaine du prestataire peut rester non aligné. Configurez les domaines personnalisés de bounce ou de signature proposés par le SaaS.
- Les sources métier ne reposent plus sur des domaines non alignés.
Renforcer progressivement DMARC
Après une période représentative, passez éventuellement à p=quarantine puis p=reject selon la procédure dédiée. Ne copiez pas de vieux exemples pct. Conservez les rapports et testez les mailing lists/redirections qui peuvent casser SPF ou DKIM.
- Le renforcement ne bloque pas de source légitime connue.
Superviser les changements futurs
Ajoutez l’authentification e-mail à la checklist d’onboarding de tout nouveau SaaS. Un nouvel outil marketing ou formulaire web ne doit pas être autorisé à envoyer avant que son SPF/DKIM et son alignement DMARC soient validés. Supprimez les anciennes autorisations lorsqu’un service est arrêté.
- La configuration reste maintenable et les rapports signalent rapidement une nouvelle source.
Validation
La procédure est validée lorsque :
- Un seul SPF existe par domaine et il couvre les sources légitimes.
- DKIM est actif et aligné pour les principales plateformes.
- DMARC est publié selon le standard actuel sans dépendre du tag pct.
- Les messages réels montrent SPF/DKIM/DMARC cohérents dans Authentication-Results.
- Les rapports agrégés sont suivis et intégrés au processus de changement.
Retour arrière
- Restaurer le précédent SPF documenté si une source critique a été oubliée, puis corriger l’inventaire.
- Désactiver temporairement une signature DKIM défaillante uniquement sur la plateforme concernée pendant sa correction.
- Repasser DMARC à p=none si un enforcement plus strict bloque des flux légitimes.
- Conserver les rapports afin de confirmer l’effet du rollback.
Dépannage / erreurs fréquentes
- SPF permerror : rechercher plusieurs records SPF ou trop de recherches DNS.
- DKIM fail : vérifier le sélecteur, la clé DNS, le domaine d= et les modifications du message en transit.
- DMARC fail avec SPF pass : vérifier l’alignement entre smtp.mailfrom et header.from.
- DMARC fail avec DKIM pass : vérifier l’alignement entre header.d et header.from.
- Microsoft 365 marque encore un message comme spoof : lire Authentication-Results et CompAuth avant d’ajouter une allow-list.