Guide de configuration des protocoles email de Red Sift

Dans ce chapitre, nous avons répondu aux questions les plus fréquemment posées à nos Customer Success Engineers à propos de SPF, DKIM et DMARC — les trois piliers de l’authentification moderne des emails. Dès 2026, ces protocoles seront requis par les principaux fournisseurs de messagerie pour les expéditeurs de courriels en masse. Explorons-les ensemble !

SPF (Sender Policy Framework) est une norme d’authentification email développée pour lutter contre la falsification de l’adresse de l’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’émetteurs autorisés spécifiée dans un enregistrement TXT au sein du DNS du propriétaire du domaine. Si l’adresse IP de l’expéditeur correspond à la liste autorisée, l’authentification SPF est réussie. 

SPF se concentre sur le « domaine » présent dans l’en-tête de l’email, connu sous divers noms tels que Return-Path, MAIL-FROM, adresse de rebond ou Envelope from. Si cet en-tête est absent, SPF se rabat sur le nom d’hôte “HELO/EHLO” et vérifie s’il existe un enregistrement SPF à cet endroit.

L’en-tête Return-Path est un en-tête technique non visible par l’utilisateur final : à moins de savoir afficher les en-têtes d’un email dans leur client de messagerie, ils ne le verront pas. 

DKIM (DomainKeys Identified Mail) permet de signer différents champs d’en-tête et le corps du message afin d’authentifier le domaine expéditeur et prévenir la modification du message durant le transit.

Cela est rendu possible grâce à la cryptographie asymétrique, composée d’une paire de clés publique et privée. La clé privée appartient au domaine de l’expéditeur et sert à signer les courriels. La clé publique est publiée dans le DNS de l’expéditeur pour que toute personne recevant ses messages puisse la récupérer.

Lorsqu’un email est rédigé, ses en-têtes et son corps sont signés grâce à la clé privée de l’expéditeur pour créer une signature numérique, qui est envoyée sous forme d’un champ d’en-tête avec le mail. Du côté du destinataire (si DKIM est activé), le serveur récupère la clé publique et vérifie si le message a bien été signé par le domaine expéditeur. Si la signature est validée, cela prouve que le domaine expéditeur est bien l’expéditeur réel et que les en-têtes et le corps du message n’ont pas été altérés pendant la transmission.

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

Comme pour SPF, cet en-tête n’est pas visible par l’utilisateur final à moins de savoir afficher les en-têtes de l’email reçu.

1. La plupart des problèmes d’authentification email sont dus aux mêmes causes. Si vous appliquez correctement ces trois conseils, vous résoudrez 90 % de vos soucis de délivrabilité et de sécurité.
2. Publiez un enregistrement DMARC en p=reject Démarrez en p=none pour collecter les rapports, mais n’en restez pas là. Une politique uniquement en mode surveillance ne vous protège pas. Passez à p=reject une fois que vous avez identifié et configuré tous vos expéditeurs légitimes. Cela indique aux serveurs destinataires de bloquer les emails qui échouent à l’authentification.
3. Assurez-vous que SPF et DKIM sont alignés avec votre domaine From: SPF et DKIM peuvent réussir indépendamment, mais vous pouvez quand même échouer DMARC si les domaines ne correspondent pas. Vérifiez que votre domaine Return-Path (pour SPF) et votre domaine de signature DKIM (d=) correspondent ou sont des sous-domaines de votre adresse From: visible. C’est là que de nombreuses organisations rencontrent des difficultés.
4. Surveillez vos rapports DMARC chaque semaine Les rapports DMARC vous indiquent précisément qui envoie des emails en votre nom et si ces envois passent l’authentification. Utilisez une plateforme telle que Red Sift OnDMARC pour transformer du XML brut en données exploitables. Détectez les mauvaises configurations avant qu’elles n’engendrent des problèmes de délivrabilité.

Pourquoi SPF & DKIM ne suffisent pas : Même si DKIM permet de vérifier qu’un email n’a pas été modifié et que SPF peut recommander à un serveur destinataire de rejeter un email en fonction de l’IP, ces deux protocoles ne sont pas efficaces pour empêcher l’usurpation. C’est précisément la raison pour laquelle DMARC sera obligatoire pour les organisations envoyant des emails en masse en 2026.

La principale raison tient à l’en-tête vérifié par chaque protocole.

SPF vérifie l’enregistrement trouvé sur le domaine dans l’en-tête return-path, et DKIM vérifie la clé du 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 principal de l’expéditeur est celui qui apparaît dans l’en-tête From:, cet en-tête détermine le nom mis en avant en haut des messages — l’adresse visible de l’expéditeur par l’utilisateur final.

Autrement dit, votre domaine peut être usurpé, car un attaquant peut définir From: sur yourdomain.com et return-path ainsi que d= sur theirdomain.com. Si les enregistrements SPF et DKIM de leur domaine sont bien configurés, l’email passera SPF et DKIM, ce qui permet d’usurper votre domaine avec succès.

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

DMARC signifie Domain-based Message Authentication, Reporting and Conformance et s’appuie sur SPF et DKIM en apportant une couche supplémentaire d’authentification des emails et d’application de politique. DMARC est désormais requis par les principaux fournisseurs de messagerie et représente la norme de l’industrie pour l’authentification des emails en 2026.

DMARC fait plusieurs choses :

1. Il prend en compte les résultats de SPF et DKIM 
2. Pour que DMARC soit validé, il faut que SPF ou DKIM réussisse et que le domaine utilisé corresponde au domaine trouvé dans l’adresse From. Si vous souhaitez en savoir davantage sur l’alignement des identifiants, cliquez ici.
3. Il rapporte les résultats SPF, DKIM et DMARC au domaine trouvé dans l’adresse From (c’est-à-dire l’expéditeur).
4. Enfin, il indique aux serveurs comment traiter les emails qui échouent à la validation DMARC en spécifiant une politique dans le DNS.

En définissant la politique DMARC sur p=reject, une organisation recommande aux serveurs destinataires de rejeter tout email envoyé en son nom qui n’a pas passé le contrôle d’alignement. Cela empêche toutes les tentatives d’imitation dès lors que le serveur destinataire implémente correctement DMARC.

DMARC se concentre sur le domaine trouvé dans l’en-tête From: ou Header from qui est visible pour l’utilisateur final. 

SPF vérifie si un email a été envoyé par un expéditeur autorisé en contrôlant la liste d’IP autorisées publiée dans votre DNS. Le serveur destinataire récupère le domaine du Return-Path et recherche un enregistrement SPF existant. Il vérifie alors si l’IP expéditrice figure dedans. Si c’est le cas, l’email est autorisé et SPF RÉUSSI. Sinon, SPF ÉCHOUÉ.

La logique générale est la suivante :

• Si l’IP expéditrice figure dans l’enregistrement SPF = SPF RÉUSSI
• Si l’IP expéditrice n’y figure pas = SPF ÉCHOUÉ

Le serveur destinataire va vérifier l’en-tête DKIM-Signature qui contient le sélecteur (s=) et le domaine de signature (d=), deux balises utilisées pour retrouver la clé publique. Une fois récupérée, la clé publique valide le message. Si la validation réussit, alors DKIM RÉUSSI, sinon DKIM ÉCHOUÉ.

La logique générale est la suivante :

• Si la validation réussit = DKIM RÉUSSI
• Si la validation échoue = DKIM ÉCHOUÉ

Le serveur destinataire va vérifier si SPF ou DKIM a RÉUSSI, puis vérifier si le domaine Return-Path (pour SPF) et/ou le domaine d= (pour DKIM) est aligné avec le domaine From:, et enfin il extrait la politique DMARC publiée par le domaine identifié dans l’adresse “From” et s’y conforme.

La logique générale est la suivante :

• Si SPF RÉUSSI et ALIGNÉ avec le domaine “From” = DMARC RÉUSSI, ou
• Si DKIM RÉUSSI et ALIGNÉ avec le domaine “From” = DMARC RÉUSSI
• Si SPF et DKIM ÉCHOUÉS = DMARC ÉCHOUÉ

DMARC requiert non seulement que SPF ou DKIM RÉUSSISSE, mais aussi que le domaine utilisé par l’un d’eux soit ALIGNÉ avec le domaine trouvé dans

l’adresse “From”. Ce n’est qu’alors que DMARC sera validé.

L’alignement strict oblige le domaine Return-Path ou le domaine de signature “d=” à être strictement identique au domaine de l’adresse “From”.

L’alignement relaxé permet que le domaine Return-Path ou le domaine “d=” soit un sous-domaine de “From”, et inversement.

Si vous souhaitez en savoir plus sur l’alignement des identifiants, cliquez ici.

Si DMARC échoue, le serveur destinataire suivra généralement la politique que vous avez définie dans votre enregistrement DMARC.

• Si vous êtes en mode rapport seulement (p=none) l’email sera accepté et soumis à d’autres critères de filtrage.
• En mode quarantaine (p=quarantine), l’email sera mis en quarantaine et généralement envoyé dans le dossier spam du destinataire.
• En mode rejet (p=reject), le serveur destinataire coupera la connexion avec le serveur expéditeur et l’email n’arrivera jamais à l’utilisateur final.

Peu importe la politique, les métadonnées du mail seront consignées avec l’état de l’authentification et transmises à votre outil d’analyse des rapports DMARC. En savoir plus sur les rapports DMARC ici.

1. Assurez-vous d’avoir un enregistrement SPF sur votre domaine Return-Path.
2. Assurez-vous d’en avoir un sur le domaine HELO/EHLO en cas de rebonds avec Return-Path vide.
3. Assurez-vous qu’il n’y a qu’un seul enregistrement SPF par domaine.
4. Vérifiez que la syntaxe SPF est correcte.
5. Assurez-vous que le domaine Return-Path est aligné avec le domaine From.
6. Assurez-vous que vos expéditeurs autorisés figurent dans l’enregistrement SPF.
7. Vérifiez que les expéditeurs non autorisés ne sont pas présents dans votre SPF.
8. Respectez la limite de 10 recherches DNS imposée par SPF. Si vous dépassez cette limite, envisagez d’utiliser une fonctionnalité telle que Dynamic SPF de Red Sift OnDMARC.
9. N’utilisez pas de mécanismes SPF obsolètes comme “ptr” dans votre enregistrement.

1. Assurez-vous que les systèmes d’envoi utilisés prennent en charge DKIM.
2. Assurez-vous que les emails sont signés DKIM.
3. Vérifiez que le domaine de signature est aligné avec le domaine “From”.
4. Utilisez une clé DKIM de plus de 1024 bits (2048 conseillée).
5. Choisissez des sélecteurs DKIM permettant d’identifier clairement le service d’envoi, pour plus de clarté.
6. Révoquez toute clé compromise.
7. Faites tourner (renouvelez) régulièrement vos clés DKIM.
8. Assurez-vous que la syntaxe de la clé DKIM est correcte.
9. Vérifiez qu’il existe une clé publique pour chaque clé privée correspondante utilisée pour signer vos emails.

1. Puisque DMARC repose sur SPF et DKIM ainsi que sur les domaines utilisés, veillez à ce que le domaine Return-Path pour SPF soit identique ou un sous-domaine de “From”. Il en va de même pour le domaine de signature DKIM. Une configuration correcte de l’alignement est cruciale pour la délivrabilité en 2026.
2. Vérifiez que la syntaxe de l’enregistrement DMARC est correcte.
3. Configurez bien tous vos systèmes avec SPF et DKIM avant de passer en rejet, sans quoi vos emails pourraient être perdus.
4. Utilisez une solution ou un prestataire tiers tel que Red Sift OnDMARC pour recevoir et interpréter les rapports DMARC et identifier les systèmes mal configurés. Les plateformes DMARC modernes comme OnDMARC permettent d’atteindre l’application des politiques en 6 à 8 semaines grâce au dépannage automatisé et aux tests en temps réel.
5. Surveillez l’état de chacune de vos sources d’envoi et détectez toute modification SPF/DKIM. Red Sift OnDMARC inclut cette fonctionnalité nativement.