Guide de configuration des protocoles email de Red Sift

Dans ce chapitre, nous répondons aux questions les plus fréquemment posées à nos Customer Success Engineers concernant SPF, DKIM et DMARC — les trois piliers de l'authentification moderne des e-mails. Dès 2026, ces protocoles seront exigés par les principaux fournisseurs de messagerie pour les expéditeurs de courriels volumineux. Entrons dans le vif du sujet !

Utilisez cette liste pour vérifier que vous avez bien couvert les essentiels. Cochez-les dans l’ordre — chaque étape dépend de la précédente.

1. Publiez un seul enregistrement SPF TXT sur votre domaine Return-Path
2. Vérifiez que chaque IP expéditrice légitime est incluse dans l'enregistrement
3. Vérifiez que vous n'avez pas dépassé la limite de 10 recherches DNS (utilisez le SPF Checker de Red Sift pour le vérifier)
4. Utilisez ~all (échec souple), pas -all, afin que DMARC puisse gérer l’application de la politique
5. Assurez-vous que le domaine Return-Path est aligné avec votre domaine From: visible

1. Vérifiez que tous les services d’envoi prennent en charge et signent effectivement avec DKIM
2. Utilisez une taille de clé de 2048 bits ou supérieure
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 régulièrement les clés et révoquez celles compromises

1. Publiez un enregistrement TXT DMARC — commencez avec p=none pour collecter les rapports
2. Pointez rua= vers un processeur de rapports (ex. Red Sift OnDMARC) pour exploiter les données agrégées
3. Passez en revue les rapports chaque semaine afin d'identifier les expéditeurs inconnus ou mal configurés
4. Une fois que toutes les sources légitimes passent SPF ou DKIM avec alignement, passez à p=quarantine
5. Passez à p=reject pour bloquer totalement les e‑mails usurpés — visez 6 à 8 semaines avec les bons outils

Bonus : Sécurisation du transport

1. Déployez MTA-STS en mode test dans un premier temps, puis appliquez-le après analyse des rapports TLS
2. Ajoutez TLS-RPT pour obtenir de la visibilité sur les échecs de livraison causés par des problèmes TLS

SPF (Sender Policy Framework) est une norme d’authentification email développée pour lutter contre la falsification d’adresse expéditrice. En vérifiant l'authenticité des identités MAIL FROM ou HELO/EHLO pendant la transmission, SPF compare l’adresse IP du serveur d’envoi à une liste d'expéditeurs autorisés définie dans un enregistrement TXT du DNS du propriétaire du domaine. Si l’adresse IP d’envoi correspond à la liste, l’authentification SPF réussit. 

SPF se concentre sur le « domaine » situé dans l'en-tête de l’e-mail, connu sous divers noms : Return-Path, MAIL-FROM, adresse de rebond ou Envelope from. Si cet en-tête est manquant, SPF se rabat sur le nom d’hôte “HELO/EHLO” et vérifie s’il existe un enregistrement SPF associé à ce nom.

L’en-tête Return-Path est technique et n’est pas visible par l’utilisateur final : à moins de savoir comment afficher les en-têtes dans leur client mail, ils ne le verront pas. 

DKIM (DomainKeys Identified Mail) sert à signer différents champs d'en-tête et le corps du message pour authentifier le domaine d'envoi et empêcher la modification du message pendant le transit.

Il utilise la cryptographie asymétrique composée d’une clé publique et d’une clé privée. La clé privée appartient au domaine expéditeur et signe les e-mails. La clé publique est publiée dans le DNS de l’expéditeur afin que toute personne recevant leurs messages puisse la récupérer.

Lors de la rédaction d’un e‑mail, ses en-têtes et son corps sont signés avec la clé privée de l’expéditeur pour créer une signature numérique, qui est envoyée en tant qu’en‑tête supplémentaire. Côté destinataire (si DKIM est activé), le serveur récupère la clé publique et vérifie si l'adresse expéditrice a bien signé le message. Si la signature est validée, cela prouve que l’expéditeur a bien envoyé le message et qu’aucune modification du corps ou des en-têtes n’est intervenue pendant la transmission.

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

Comme pour SPF, cet en-tête n’est pas visible pour l’utilisateur final, sauf s’il sait comment afficher les en-têtes de l’e-mail.

1. La plupart des problèmes liés à l’authentification des e-mails proviennent des mêmes causes. Faites correctement ces trois choses et vous résoudrez 90 % de vos problèmes de délivrabilité et de sécurité.
2. Publiez un enregistrement DMARC avec p=reject Commencez par p=none pour collecter les rapports, mais n’en restez pas là. Une politique en mode monitoring ne vous protège pas. Passez à p=reject après avoir identifié et configuré toutes les sources d'envoi légitimes. Cela indique aux serveurs destinataires de bloquer les messages qui échouent à l’authentification.
3. Assurez-vous que SPF et DKIM sont alignés avec votre domaine From: SPF et DKIM peuvent tous deux passer, mais DMARC échouera si les domaines ne correspondent pas. Vérifiez que votre domaine Return-Path (pour SPF) et votre domaine de signature DKIM (d=) sont identiques ou des sous-domaines de votre adresse From: visible. C’est là que la plupart des organisations rencontrent des difficultés.
4. Surveillez vos rapports DMARC chaque semaine Les rapports DMARC vous révèlent qui envoie des e-mails en votre nom et si l'authentification fonctionne. Utilisez un outil comme Red Sift OnDMARC pour transformer les données XML brutes en actions concrètes. Détectez les mauvaises configurations avant qu'elles ne deviennent des problèmes de délivrabilité.

Pourquoi SPF & DKIM ne suffisent pas. Même si DKIM permet de vérifier qu’un message n’a pas été manipulé, et SPF recommande à un serveur destinataire de rejeter un e‑mail selon l’IP, ni l’un ni l’autre n’empêchent efficacement l'usurpation. C’est précisément pour cela que DMARC devient obligatoire pour les expéditeurs de courriels en masse en 2026.

La principale raison est l’en-tête vérifié pour chaque protocole.

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

Ces protocoles peuvent pointer sur n’importe quel domaine.

Dans un e-mail, le domaine principal de l’expéditeur est celui situé en From:. C’est ce domaine qui s’affiche pour l’utilisateur final s’il vérifie l’expéditeur.

Ainsi, votre domaine d’e-mail pourrait être usurpé car un attaquant pourrait mettre From: yourdomain.com et return-path et d= sur theirdomain.com. Tant que les enregistrements SPF et DKIM de leurdomain.com sont corrects, le mail passerait SPF et DKIM — et donc usurperait votre domaine avec succès.

SPF et DKIM ont leur utilité, mais ni l’un ni l’autre, seuls, ne suffisent à empêcher l’imitation.

DMARC signifie Domain-based Message Authentication, Reporting and Conformance et repose sur SPF et DKIM, en ajoutant une couche d’authentification et d’application de la politique. DMARC est désormais requis par les principaux fournisseurs de boîtes de réception et représente la norme industrielle d’authentification des e-mails pour 2026.

Ce que fait DMARC :

1. Il prend en compte les résultats de SPF et DKIM 
2. Pour réussir avec DMARC, il faut que SPF OU DKIM passe et que le domaine employé par l’un des deux soit aussi aligné avec le domaine From:. Pour tout savoir sur l’alignement, cliquez ici.
3. Il retourne les résultats SPF, DKIM et DMARC au domaine From: (l’expéditeur).
4. Enfin, il indique aux serveurs comment traiter les e‑mails échouant à la validation DMARC via la politique DNS.

En configurant DMARC à p=reject, une organisation informe les serveurs destinataires qu’ils doivent rejeter tous les e-mails envoyés pour son domaine qui n’ont pas passé l’alignement. Cela stoppe toute tentative d’imitation là où le serveur applique correctement DMARC.

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

SPF vérifie si un e-mail a été expédié par un serveur autorisé, en contrôlant la liste d’adresses IP autorisées publiée dans votre DNS. Le serveur destinataire prend le domaine figurant dans l’en-tête Return-Path et cherche un enregistrement SPF. Il vérifie si l’IP expéditrice du mail figure dans l’enregistrement SPF. Si oui, le SPF RÉUSSIT. Si l’IP n’est pas présente, SPF ÉCHOUE.

La logique globale est :

• Si l’IP expéditrice figure dans l’enregistrement SPF = SPF RÉUSSI
• Si l’IP expéditrice NE figure PAS dans l’enregistrement SPF = SPF ÉCHOUÉ

Le serveur récepteur contrôle l’en-tête DKIM-Signature, qui contient le sélecteur (s=) et le domaine de signature (d=) utilisés pour retrouver la clé publique. Une fois récupérée, la clé valide le message. Si la validation fonctionne, DKIM PASSE. Si la validation échoue, DKIM ÉCHOUE.

La logique globale :

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

Le serveur destinataire vérifie si SPF ou DKIM RÉUSSI, puis il examine 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 From: pour s’y conformer.

La logique globale est :

• 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 ÉCHOUENT = DMARC ÉCHOUÉ

DMARC exige non seulement que SPF ou DKIM réussisse, mais aussi que les domaines employés par ces protocoles s’ALIGNE à celui du 

champ “From”. Alors seulement DMARC PASSERA.

L’alignement strict exige que le domaine Return-Path ou le domaine de signature d= corresponde exactement au domaine de l’adresse From:.

L’alignement relaxé permet au domaine Return-Path ou au domaine d= d’être un sous-domaine du From:, ou vice versa.

Pour tout savoir sur l’alignement, cliquez ici.

Si DMARC échoue, le serveur applique la politique précisée dans votre enregistrement DMARC.

• En mode rapport seulement (p=none), le mail est accepté et soumis à d’autres filtres.
• En mode quarantaine (p=quarantine), le mail est mis en quarantaine et envoyé normalement en spam.
• En mode rejet (p=reject), le serveur coupe la connexion et le message n’atteint jamais l’utilisateur final.

Quelle que soit la politique, les métadonnées sont journalisées avec le résultat d’authentification et transmises à votre processeur de rapports DMARC. Pour en savoir plus sur les rapports DMARC, cliquez ici.

1. Veillez à ce qu'il y ait un enregistrement SPF sur votre domaine Return-Path.
2. Assurez-vous d’avoir un enregistrement SPF sur votre domaine HELO/EHLO, pour les NPAI (retours) avec Return-Path vide.
3. Un seul enregistrement SPF par domaine.
4. Vérifiez la syntaxe de l’enregistrement SPF.
5. Assurez-vous que le domaine Return-Path est aligné avec From.
6. Vérifiez que tous les expéditeurs autorisés figurent dans le SPF.
7. Vérifiez que les expéditeurs non autorisés ne sont pas dans le SPF.
8. Veillez à ne pas dépasser la limite de 10 recherches DNS. Si c’est le cas, pensez à utiliser des fonctionnalités comme OnDMARC Dynamic SPF de Red Sift.
9. N’utilisez pas de mécanismes SPF obsolètes comme « ptr » dans votre SPF.
10. Simplifiez-vous la vie avec un partenaire DMARC comme Red Sift

1. Vérifiez que vos systèmes d’envoi gèrent DKIM.
2. Assurez-vous que les e-mails sont signés DKIM.
3. Vérifiez l’alignement du domaine de signature avec “From”.
4. Utilisez des clés DKIM supérieures à 1024 bits (2048 conseillés)
5. Autant que possible, choisissez des sélecteurs DKIM identifiant clairement chaque service d’envoi.
6. Révoquez toute clé compromise.
7. Effectuez une rotation régulière des clés DKIM.
8. Vérifiez la syntaxe de la clé DKIM.
9. Assurez-vous qu’il y a une clé publique pour chaque clé privée utilisée pour signer vos messages.

1. Comme DMARC dépend de SPF et DKIM et des domaines associés, assurez-vous que le domaine Return-Path (SPF) est identique ou un sous-domaine du domaine “From”. Pareil pour le domaine de signature DKIM. Un bon alignement est essentiel pour la délivrabilité en 2026.
2. Vérifiez la syntaxe de l’enregistrement DMARC.
3. Configurez tous vos systèmes avec SPF et DKIM AVANT le passage à la politique reject, sinon vos e-mails seraient perdus.
4. Utilisez une solution ou un prestataire externe comme Red Sift OnDMARC pour recevoir les rapports DMARC, comprendre les données et détecter les systèmes mal configurés. Les plateformes DMARC de 2026, comme OnDMARC, permettent d’atteindre l’application de la politique en 6-8 semaines grâce à l’automatisation et aux tests en temps réel.
5. Surveillez le statut de chaque source d’envoi et identifiez tout changement SPF/DKIM. C’est une fonction centrale de Red Sift OnDMARC.