Guide de configuration des protocoles email de Red Sift

Dans ce chapitre, nous avons répondu à certaines des questions les plus courantes posées à nos Customer Success Engineers concernant SPF, DKIM et DMARC – les trois piliers de l’authentification des emails moderne. Dès 2026, ces protocoles seront requis par les principaux fournisseurs de boîtes de réception pour les expéditeurs d’emails en masse. Plongeons dans le sujet !

Utilisez cette liste pour vérifier que vous avez couvert l’essentiel. Suivez chaque étape dans l’ordre – chacune dépend de la précédente.

1. Publiez un seul enregistrement SPF TXT sur votre domaine Return-Path
2. Confirmez que chaque IP d’envoi légitime est incluse dans l’enregistrement
3. Vérifiez que vous n’avez pas dépassé la limite de 10 requêtes DNS (utilisez Red Sift's SPF Checker pour contrôler)
4. Utilisez ~all (échec souple), pas -all, pour que DMARC puisse gérer l’application
5. Assurez-vous que le domaine Return-Path soit aligné avec votre domaine visible From :

1. Confirmez que tous les services d’envoi prennent en charge et signent activement avec DKIM
2. Utilisez une taille de clé de 2048 bits ou plus
3. Vérifiez que le domaine de signature (d=) est aligné avec votre domaine From :
4. Nommez clairement les sélecteurs afin d’identifier chaque service d’envoi
5. Faites tourner les clés régulièrement et révoquez toute clé compromise

1. Publiez un enregistrement DMARC TXT – commencez par p=none pour collecter les rapports
2. Indiquez rua= vers un processeur de rapports (par ex. Red Sift OnDMARC) afin de rendre les données agrégées exploitables
3. Analysez les rapports chaque semaine pour identifier les expéditeurs inconnus ou mal configurés
4. Une fois que toutes les sources légitimes valident SPF ou DKIM avec alignement, passez à p=quarantine
5. Passez à p=reject pour bloquer complètement les emails usurpés – visez 6 à 8 semaines avec les bons outils

Bonus : sécurité du transport

1. Déployez MTA-STS d’abord en mode test, puis passez en application après examen des rapports TLS
2. Ajoutez TLS-RPT pour obtenir une visibilité sur les échecs de livraison causés par des problèmes TLS

Configurer SPF et DKIM ne garantit pas que chaque source d’envoi soit authentifiée en permanence. Quelques lacunes font échouer certains emails légitimes sans qu’aucune erreur évidente ne soit générée :

• Sous-domaines non protégés. Un sous-domaine sans son propre enregistrement SPF ou DKIM peut être usurpé, même si le domaine principal est bien sécurisé.
• Expéditeurs tiers. Les plateformes marketing, outils CRM et systèmes de support envoient souvent des messages en votre nom avec leur propre infrastructure – chaque service doit être authentifié séparément.
• Obsolescence des enregistrements DNS. Les changements d’infrastructure, comme un nouveau fournisseur d’email ou un outil retiré, laissent parfois des includes SPF ou sélecteurs DKIM périmés, ce qui peut faire échouer des envois légitimes.
• Transferts cassés. Les signatures DKIM peuvent devenir invalides lorsqu’un message passe par un service de transfert qui modifie les entêtes ou le contenu du message.
• Gestion incohérente côté client. Tous les clients de messagerie (mobiles ou desktop) n’interprètent pas les résultats d’authentification de la même façon, donc un message peut finir ailleurs selon où il est ouvert.
• Transfert de réputation. Les échecs d’authentification sont cumulatifs. Un domaine qui échoue souvent accumule une mauvaise réputation d’expéditeur, ce qui finit par nuire à la délivrabilité, même pour les messages valides.

Pour éviter ce genre de surprise, faites l’inventaire complet de chaque domaine et sous-domaine qui envoie des emails pour vous, et vérifiez le statut SPF, DKIM et DMARC de chacun.

SPF (Sender Policy Framework) est une norme d’authentification des emails développée pour lutter contre la falsification d’adresse d’expéditeur. En vérifiant l’authenticité des identités MAIL FROM ou HELO/EHLO lors de la transmission, SPF compare l’adresse IP du serveur expéditeur à une liste d’expéditeurs autorisés spécifiée dans un enregistrement TXT du DNS du propriétaire du domaine. Si l’IP expéditrice figure sur cette liste, l’authentification SPF est réussie. 

SPF cible le « domaine » figurant dans l’entête de l’email, souvent appelé Return-Path, MAIL-FROM, adresse de rebond ou envelope from. Si cette entête est absente, SPF se rabat sur le nom d’hôte « HELO/EHLO » et vérifie la présence d’un enregistrement SPF à cet emplacement.

L’entête Return-Path est une entête technique qui n’est pas visible pour l’utilisateur final – à moins qu’il sache comment afficher les entêtes complètes dans son client mail, il ne la verra pas. 

DKIM (DomainKeys Identified Mail) est utilisé pour signer différents champs d’entêtes et le corps de l’email afin d’authentifier le domaine expéditeur et d’empêcher toute modification du message lors du transit.

Pour cela, il utilise une cryptographie asymétrique, composée d’une clé publique et d’une clé privée. La clé privée est gardée secrète par le domaine expéditeur et sert à signer les emails. La clé publique est publiée dans le DNS de l’expéditeur pour permettre à tout destinataire de vérifier les messages reçus.

Lorsqu’un email est composé, ses entêtes et son corps sont signés avec la clé privée de l’expéditeur afin de créer une signature numérique, envoyée dans l’entête du mail. À réception (si DKIM est activé), le serveur récupère la clé publique et vérifie que l’email a bien été signé par le domaine expéditeur. Si la vérification réussit, cela prouve que le message vient bien du domaine expéditeur et que les entêtes et le corps n’ont pas été modifiés en cours de route.

DKIM se concentre sur l’entête “DKIM-Signature”.

Comme pour SPF, ce champ n’est pas visible pour l’utilisateur final, sauf s’il sait comment afficher les entêtes d’un email reçu.

1. La majorité des problèmes d’authentification des emails sont dus aux mêmes facteurs. Faites ces trois choses et vous résoudrez 90 % des problèmes de délivrabilité et de sécurité.
2. Publiez un enregistrement DMARC en p=reject Commencez par p=none pour collecter les rapports, mais ne vous arrêtez pas là. Une politique en mode surveillance ne vous protège pas. Passez en p=reject une fois que vous avez identifié et configuré tous vos expéditeurs légitimes. Cela indique aux serveurs récepteurs de bloquer les emails qui échouent l’authentification.
3. Assurez-vous que SPF et DKIM correspondent à votre domaine From : SPF et DKIM peuvent valider et vous pouvez néanmoins échouer DMARC si les domaines ne sont pas identiques. Vérifiez que votre domaine Return-Path (pour SPF) et le domaine de signature DKIM (d=) correspondent ou sont des sous-domaines de votre adresse From visible. C’est là que la plupart des organisations se bloquent.
4. Surveillez vos rapports DMARC chaque semaine Les rapports DMARC vous indiquent exactement qui envoie des emails en votre nom et si l’authentification passe. Utilisez une plateforme comme Red Sift OnDMARC pour transformer les bruts XML en données exploitables. Identifiez les mauvaises configurations avant qu’elles n’impactent la délivrabilité.

Pourquoi SPF & DKIM ne suffisent pas. Si DKIM peut vérifier qu’un email n’est pas exactement celui qui a été envoyé à l’origine, et si SPF peut recommander qu’un serveur récepteur rejette un email selon l’IP, aucun des deux protocoles n’est efficace pour lutter contre l’usurpation d’identité. C’est précisément pourquoi DMARC est devenu obligatoire pour les organismes envoyant des emails en masse en 2026.

La principale raison réside dans l’en-tête contrôlé par chaque protocole.

SPF vérifie l’enregistrement trouvé au domaine de l’en-tête return-path, et DKIM vérifie la clé associée au domaine d= (dans l’en-tête DKIM).

Les deux protocoles ci-dessus peuvent être configurés pour vérifier n’importe quel domaine.

Dans un email, le domaine le plus visible est celui qui figure dans l’en-tête From: – c’est lui qui détermine le nom affiché tout en haut et l’adresse que verra l’utilisateur final s’il vérifie l’expéditeur.

Cela veut dire que votre domaine pourrait être usurpé : un attaquant pourrait utiliser From: votredomaine.com, avec return-path et d= réglés sur leurdomaine.com. Si les enregistrements SPF et DKIM de leurdomaine.com sont correctement configurés, l’email passera SPF et DKIM, donnant lieu à une usurpation aboutie…

SPF et DKIM ont leur utilité, mais aucun des deux ne suffit à empêcher l’imitation.

DMARC signifie Domain-based Message Authentication, Reporting and Conformance et s’appuie sur SPF et DKIM, ajoutant un niveau supplémentaire d’authentification email et de politique d’application.DMARC est désormais exigé par les principaux fournisseurs de boîtes mail et représente la norme pour l’authentification des emails en 2026.

DMARC permet :

1. De prendre en compte les résultats de SPF et DKIM 
2. Pour valider DMARC, il faut que SPF ou DKIM soit validé et que le domaine utilisé s’aligne également sur celui du From:. Si vous souhaitez en savoir plus sur l’Identifier Alignment, cliquez ici.
3. D’envoyer les résultats SPF, DKIM et DMARC au domaine figurant dans l’adresse From: (c.-à-d. l’expéditeur).
4. Enfin, il indique aux serveurs comment traiter les messages qui échouent DMARC en spécifiant une politique dans le DNS.

En réglant la politique DMARC sur p=reject, une organisation demande aux serveurs récepteurs de rejeter tout email envoyé en son nom ne passant pas la vérification d’alignement. Cela empêchera toute tentative d’usurpation si le serveur récepteur applique correctement DMARC.

DMARC cible le domaine figurant dans l’en-tête From: ou Header from, visible pour l’utilisateur final. 

SPF vérifie si un email provient d’un expéditeur autorisé en comparant l’IP de l’expéditeur à une liste d’adresses publiées dans votre DNS. Le serveur destinataire prend le domaine de l’en-tête Return-Path et cherche un enregistrement SPF correspondant. Il inspecte si l’adresse IP expéditrice figure dans cet enregistrement. Si c’est le cas, alors SPF RÉUSSI. Sinon, SPF ÉCHOUÉ.

La logique générale :

• Si l’IP expéditrice est dans l’enregistrement SPF = SPF VALIDE
• Si l’IP n’est pas dans l’enregistrement SPF = SPF ÉCHEC

Le serveur destinataire vérifiera l’entête DKIM-Signature qui contient le sélecteur (s=) et le domaine de signature (d=) servant à chercher la clé publique. Une fois récupérée, la clé valide le message. Validation réussie = DKIM VALIDE, sinon DKIM ÉCHEC.

La logique générale :

• Validation réussie = DKIM VALIDE
• Validation échouée = DKIM ÉCHEC

Le serveur destinataire vérifiera si SPF ou DKIM VALIDE, puis si le domaine Return-Path utilisé par SPF et/ou le d= utilisé par DKIM sont alignés avec le domaine du From, et enfin, il appliquera la politique DMARC publiée par le domaine From.

La logique générale :

• SPF VALIDE et ALIGNÉ avec le domaine “From” = DMARC VALIDE, ou
• DKIM VALIDE et ALIGNÉ avec le domaine “From” = DMARC VALIDE
• SPF et DKIM échouent = DMARC ÉCHEC

DMARC exige non seulement que SPF ou DKIM soit VALIDE, mais aussi que le domaine utilisé par l’un des deux soit ALIGNÉ avec le domaine de l’adresse 

From. Ce n’est qu’à cette condition que DMARC passe.

L’alignement strict exige que Return-Path ou le domaine de signature « d= » corresponde exactement à celui du From.

L’alignement relâché accepte que Return-Path ou « d= » soit un sous-domaine de l’adresse From (ou l’inverse).

Pour en savoir plus sur l’Identifier Alignment, cliquez ici.

Si DMARC échoue, le serveur destinataire appliquera la politique définie dans votre enregistrement DMARC.

• En mode rapport uniquement (p=none) l’email sera accepté et soumis à d’autres filtres.
• En mode quarantaine (p=quarantine), l’email sera mis en quarantaine (généralement dans le dossier spam).
• En mode rejet (p=reject), la connexion avec le serveur expéditeur est bloquée et l’email n’atteindra jamais l’utilisateur final.

Peu importe la politique, les métadonnées de l’email, ainsi que le résultat de l’authentification, seront consignées puis envoyées à votre processeur de rapports DMARC. Découvrez-en plus sur les rapports DMARC ici.

Configurer SPF et DKIM parfaitement sur le papier ne garantit pas que tout fonctionne comme prévu sur tous les domaines, sous-domaines et sources d’envoi. Avant de résoudre des incidents au cas par cas, obtenez une vue d’ensemble de votre posture d’authentification.

Répertoriez chaque domaine et sous-domaine qui envoient des emails pour vous, y compris ceux utilisés par des plateformes marketing, outils CRM ou de support. Notez pour chacun le statut SPF, DKIM et DMARC.

Récupérez taux de rebonds, taux de plaintes spam et échecs de livraison sur vos principaux prestataires d’envoi. Croisez ces données avec des outils de réputation de domaine comme Google Postmaster Tools pour repérer où des lacunes d’authentification nuisent déjà à votre délivrabilité.

Pour chaque domaine, estimez les conséquences business en cas d’usurpation réussie. Un domaine utilisé uniquement en interne n’a pas le même risque que celui apparaissant sur les factures clients. Priorisez selon l’impact, pas selon la facilité de correction.

Refaites cette évaluation chaque trimestre. De nouvelles sources d’envoi ou changements d’infrastructure sont la cause la plus fréquente d’une configuration autrefois parfaite qui commence à échouer.

Les organisations imaginent parfois qu’une authentification totale implique un budget “niveau entreprise”. En réalité, le coût dépend surtout de la complexité (nombre de domaines, sous-domaines, services tiers, etc.), pas du niveau de protection obtenu.

Cinq facteurs déterminent votre position : volume d’envoi, complexité de l’infrastructure (combien de domaines, sous-domaines, services tiers), expertise interne, exigences sectorielles de conformité et besoins d’intégration spécifiques.

Quelques situations font exploser le coût d’une mauvaise authentification :

• Fusions et acquisitions. Fusionner plusieurs systèmes d’email anciens génère des failles d’authentification, recherchées par les attaquants durant la transition.
• Secteurs réglementés. Les établissements de santé et financiers sont soumis à des obligations fortes. Si un prestataire de santé envoie des communications non authentifiées, il s’expose à des amendes de plusieurs millions.
• Cibles à haute valeur. Les sociétés manipulant des données sensibles ou de gros flux financiers sont des cibles privilégiées pour la fraude email. Un industriel s’est fait détourner 2,3 millions de dollars après une usurpation de domaine.
• Opérations internationales. Plusieurs régions, langues et cadres légaux multiplient les points d’envoi à authentifier.

Sur toutes les entreprises victimes d’usurpation de domaine en 2023, les pertes dépassent 18 millions de dollars selon le FBI.

1. Vérifiez que vous avez un enregistrement SPF sur votre domaine Return-Path.
2. Vérifiez qu’il existe un enregistrement SPF sur votre domaine HELO/EHLO (utile si Return-Path est vide sur certains rebonds).
3. Assurez-vous qu’il n’y a qu’un seul enregistrement SPF par domaine.
4. Assurez-vous que la syntaxe de votre enregistrement SPF est correcte.
5. Vérifiez l’alignement entre Return-Path et From.
6. Incluez tous les expéditeurs autorisés dans l’enregistrement SPF.
7. Vérifiez qu’aucun expéditeur non autorisé n’est inclus dans votre SPF.
8. Evitez de dépasser la limite de 10 requêtes DNS. Si c’est le cas, utilisez une fonctionnalité type SPF Dynamique de Red Sift’s OnDMARC.
9. Évitez d’utiliser les mécanismes SPF obsolètes comme “ptr” dans votre enregistrement SPF.
10. Simplifiez-vous la vie en travaillant avec un fournisseur DMARC tel que Red Sift

1. Vérifiez que vos systèmes d’envoi gèrent DKIM.
2. Vérifiez que vos emails sont bien signés DKIM.
3. Assurez-vous de l’alignement du domaine de signature avec le domaine “From”.
4. Utilisez une taille de clé DKIM supérieure à 1024 bits (2048 bits conseillé)
5. Essayez de choisir des sélecteurs DKIM qui identifient clairement chaque service pour pouvoir les distinguer.
6. Révoquez toute clé ayant été compromise.
7. Faites tourner régulièrement les clés DKIM que vous contrôlez.
8. Assurez-vous de la syntaxe correcte des clés DKIM.
9. Il doit exister une clé publique pour chaque clé privée utilisée pour signer vos emails.

1. Puisque DMARC dépend à la fois de SPF et DKIM ET de leurs domaines, veillez à ce que le domaine Return-Path utilisé pour SPF corresponde exactement ou soit un sous-domaine du domaine From. Même exigence pour le domaine de signature DKIM. L’alignement approprié est essentiel pour la délivrabilité en 2026.
2. Assurez-vous que la syntaxe de votre enregistrement DMARC est correcte.
3. Assurez-vous que TOUS vos systèmes sont bien configurés pour SPF et DKIM avant d’activer la politique reject, sans quoi vos emails seront perdus.
4. Utilisez un outil ou un fournisseur tiers tel que Red Sift OnDMARC pour collecter et exploiter les rapports DMARC – vous y détecterez rapidement les systèmes mal configurés. Les plateformes modernes comme OnDMARC, en 2026, permettent de passer en enforcement en 6 à 8 semaines via automatisation et tests en temps réel.
5. Surveillez le statut de chacune de vos sources d’envoi et contrôlez que toute modification de SPF ou DKIM soit détectée. Red Sift OnDMARC intègre cette fonctionnalité de base.