Commencer par un inventaire complet des expéditeurs
Qui peut envoyer des e-mails avec le domaine de votre entreprise ? Répondez avec la comptabilité, l’équipe commerciale et l’informatique. Outre les boîtes habituelles, il peut s’agir du logiciel de facturation, d’un service de newsletters, du formulaire de contact, d’un outil de gestion des demandes ou de scanners. Recensez les usages réels, au-delà des licences officiellement achetées.
Pour chaque service, notez son rôle, l’adresse d’expéditeur visible, le prestataire et un interlocuteur métier. Identifiez aussi les personnes autorisées à modifier les enregistrements DNS et l’endroit où ces changements sont consignés. Cet inventaire sert de cahier des charges, puis de référence lors de l’ajout ou de l’arrêt d’un service.
Incluez les autres domaines de l’entreprise. Un domaine enregistré qui ne doit jamais envoyer d’e-mails nécessite lui aussi une configuration contre l’usurpation. Le NCSC recommande de prendre en compte tous les domaines de l’organisation. [5]
Ce que vérifient SPF, DKIM et DMARC
SPF vérifie si le serveur d’envoi est autorisé pour le domaine technique de l’enveloppe SMTP. Ce domaine peut différer de celui de l’expéditeur visible. Les serveurs autorisés sont indiqués dans le DNS.
DKIM associe un domaine de signature au message. Le destinataire vérifie la signature cryptographique avec une clé publique DNS. Elle couvre certaines parties du message, sans chiffrer l’e-mail ni confirmer l’identité d’une personne.
DMARC réussit si SPF ou DKIM réussit et si le domaine authentifié s’aligne sur celui du champ From visible. L’alignement strict exige des domaines identiques ; l’alignement souple accepte un même domaine organisationnel. Un résultat SPF ou DKIM positif sans cet alignement ne suffit pas. [1] [2] [3]
Choisir la politique en connaissance de cause
p=none ne demande aucun traitement particulier des échecs DMARC. p=quarantine demande un traitement comme message suspect ; p=reject demande le rejet. Le service destinataire décide du traitement effectif. Aucun réglage ne garantit la remise des messages légitimes.
Convenez avec l’informatique d’une période d’observation et d’une analyse des rapports demandés. Prévoyez une durée couvrant les factures mensuelles et les envois occasionnels. Une seule semaine calme renseignerait peu sur ces usages. Faites expliquer les services d’envoi inconnus avant de les autoriser ou de les désactiver. [4]
Les preuves à demander au prestataire
Notre liste de vérification proposée relie les réglages à l’activité quotidienne. Demandez un relevé concis des résultats pour chaque service d’envoi. Une capture d’écran avec trois voyants verts ne démontre pas que votre facturation ou votre formulaire de contact envoie correctement les messages.
- Un inventaire tenu à jour des services d’envoi, des domaines et des interlocuteurs métier.
- Un véritable message de test par service, avec les résultats SPF, DKIM et DMARC constatés à la réception.
- Les domaines effectivement vérifiés et la preuve de leur alignement, au-delà d’une simple mention de réussite.
- Des tests distincts pour les transferts et listes de diffusion nécessaires, avec les problèmes documentés.
- Une politique cible justifiée, une date de changement et un plan précis de retour arrière en cas de problème de remise.
- Un responsable des rapports, des questions ouvertes et des nouveaux contrôles après un changement de prestataire.
Les attaques qui restent possibles
Un domaine ressemblant au vôtre peut réussir ses propres contrôles SPF, DKIM et DMARC. Un nom d’affichage familier ne prouve pas davantage l’identité. L’authentification ne rend pas le contenu du message digne de confiance.
DMARC n’empêche pas non plus la compromission d’une véritable boîte mail. L’attaquant peut alors utiliser un service d’envoi autorisé. Vérifiez toute instruction inhabituelle de paiement ou de changement de coordonnées bancaires par un canal indépendant déjà connu. [6] [7]
Prévoir la maintenance dès le départ
Désignez un responsable avant de clôturer le projet. Un nouveau logiciel marketing, un changement de prestataire web ou le remplacement de l’outil comptable doit déclencher une révision de l’inventaire. Consignez le service ajouté ou supprimé, les tests effectués et les questions encore ouvertes. La configuration reste ainsi compréhensible lorsque les interlocuteurs changent.
À lire aussi
Sources et approfondissements
- IETF · RFC 7208: Sender Policy Framework (SPF)
- IETF · RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- IETF · RFC 9989: DMARC, May 2026
- Microsoft Learn · DMARC policy and deployment
- NCSC · Email security and anti-spoofing
- Microsoft Learn · Spoofing and impersonation
- Microsoft Learn · Limits of anti-spoofing protection
Publié le:
Sources primaires vérifiées le 29.09.2026.
Les sources et les limites sont indiquées dans l’article.
