SPF, DKIM et DMARC : comprendre la chaîne de confiance d’un email professionnel

Lorsqu'un employé envoie un devis ou qu'une campagne marketing part vers vos clients, le destinataire ne voit pas seulement le contenu du message. En arrière-plan, une vérification technique décisive a lieu entre les serveurs : l'email est-il vraiment émis par votre entreprise ? Cette question semble anodine, mais sa réponse détermine si votre communication atterrit dans la boîte de réception principale ou finit en dossier « Courrier indésirable », voire rejetée à la source. Pour les TPE et PME accompagnées par Expertis’IT, que ce soit depuis Lille pour une structure locale ou sur un périmètre national plus large, la maîtrise des protocoles d'authentification DNS n'est pas optionnelle.Le trio SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting and Conformance) constitue le socle de la réputation numérique. Sans ces mécanismes, votre domaine est vulnérable au usurpation d'identité (spoofing) et à l'hameçonnage ciblé. Ce guide détaille comment mettre en place cette chaîne de confiance technique pour garantir que vos communications professionnelles soient perçues comme légitimes par les fournisseurs de messagerie modernes.

Le rôle précis du SPF : définir qui a le droit d'envoyer

Le protocole SPF (Sender Policy Framework) fonctionne comme une liste blanche publiée dans les enregistrements DNS de votre domaine. Il indique explicitement aux serveurs destinataires quelles adresses IP ou quels services sont autorisés à envoyer des emails au nom de votre organisation.Lorsqu'un email arrive, le serveur du receveur consulte cet enregistrement TXT spécifique. Si l'IP émettrice n'y figure pas, le message est suspecté d'être frauduleux. Pour une PME utilisant Microsoft 365 ou Google Workspace tout en ayant un hébergement web externe qui envoie aussi des notifications automatiques, la configuration SPF doit être exhaustive.Une omission courante consiste à ne lister que les serveurs de messagerie principaux, oubliant ainsi les outils d'envoi transactionnel (CRM, site e-commerce) ou les prestataires externes envoyant au nom du domaine.L'enregistrement se présente sous la forme : v=spf1 include:_spf.google.com ip4:203.0.113.5 -all.Le paramètre final (-all, ?all) est critique : il définit si les emails non autorisés doivent être rejetés strictement ou simplement marqués comme suspects.

Le rôle du DKIM : signer numériquement le contenu

Tandis que le SPF vérifie l'origine de l'email (l'IP), DKIM (DomainKeys Identified Mail) garantit l'intégrité du message. Il ajoute une signature cryptographique invisible à chaque email envoyé, liée spécifiquement aux en-têtes et au corps du texte.Cette signature permet au destinataire de vérifier que le contenu n'a pas été altéré durant la transmission entre votre serveur sortant et sa boîte de réception. Si un pirate intercepte le flux et modifie une pièce jointe ou change l'expéditeur affiché, la validation DKIM échoue.La clé publique nécessaire à cette vérification est également stockée dans les DNS du domaine émetteur sous forme d'enregistrement TXT long.C'est un élément indispensable pour éviter que vos emails ne soient perçus comme modifiés ou corrompus par les filtres anti-spam agressifs des grands fournisseurs (Gmail, Outlook).

Le rôle du DMARC : fixer la politique de gestion

DMARC est le protocole qui orchestre SPF et DKIM. Il ne vérifie pas lui-même l'email, mais il donne des instructions au serveur destinataire sur ce qu'il doit faire si les validations précédentes échouent.Sans DMARC, un email peut passer la validation SPF tout en ayant une signature DKIM invalide (et vice-versa), créant de la confusion. Le record DMARC résout cette ambiguïté et impose trois niveaux d'action : p=none : Aucun rejet automatique ; les emails non conformes passent mais sont signalés. p=quarantine : Les messages échouant aux tests SPF/DKIM sont envoyés en dossier spam ou courrier indésirable. p=reject : Le serveur destinataire refuse purement et simplement la réception de l'email non conforme. C'est le niveau maximal de protection pour votre réputation de domaine.

Méthode de déploiement sécurisée en 4 étapes

Configurer ces protocoles demande une approche méthodique pour éviter les blocages accidentels. Voici la procédure recommandée par nos techniciens lors des audits d'infrastructures et cloud :Inventaire complet des émetteurs : Lister tous les services qui envoient un email avec l'en-tête @votre-domaine.fr. Cela inclut la messagerie principale, le site web (WordPress ou autre), les outils RH, CRM et tout prestataire externe.Mise en place du SPF : Créer ou mettre à jour l'enregistrement TXT. Attention au nombre de requêtes DNS autorisées ; il est préférable d'utiliser des mécanismes include: pour les grands fournisseurs cloud plutôt que de lister manuellement chaque plage IP.Génération et publication du DKIM : Activer la signature dans l'interface d'administration (Microsoft 365, Google Workspace) ou sur le serveur SMTP dédié. Copier-coller soigneusement les clés publiques fournies vers votre zone DNS.Déployer DMARC progressivement : Commencer impérativement avec la politique p=none. Analysez les rapports reçus pendant deux à quatre semaines pour identifier les faux positifs (emails légitimes rejetés). Une fois l'analyse stabilisée, passez en mode quarantine, puis enfin en reject.

Livrables et points de contrôle techniques

Pour valider la bonne configuration, plusieurs outils permettent d'inspecter les en-têtes bruts des emails. Les livrables attendus après intervention sont :Un fichier PDF récapitulant l'inventaire des sources d'émission identifiées.L'enregistrement SPF consolidé et optimisé (sans dépassement de la limite de 10 requêtes DNS).Les clés DKIM actives pour chaque flux principal.Un enregistrement DMARC pointant vers une adresse technique dédiée à votre entreprise, permettant le suivi des tentatives d'usurpation.

Trois exemples génériques de configuration

Exemple 1 : La TPE avec Microsoft 365 uniquementIci, la simplicité règne. L'enregistrement SPF contient v=spf1 include:spf.protection.outlook.com -all. Le DKIM est activé via le centre d'administration Exchange Online pour les deux clés par défaut (selector1 et selector2). DMARC est positionné en mode rejet après une courte phase de test, car aucune autre source n'émet au nom du domaine.Exemple 2 : L'e-commerce multiserviceCette PME utilise Google Workspace pour les employés et un outil d'envoi transactionnel (comme Sendinblue ou Mailchimp) pour ses commandes clients. Le SPF doit inclure _spf.google.com ET le domaine du prestataire marketing (servers.mcsv.net). L'étape critique est de vérifier que l'en-tête 'From:' correspond bien au domaine principal, sinon la validation échoue.Exemple 3 : Le cabinet juridique avec hébergement externeCe cabinet possède un site vitrine sur un hébergeur mutualisé qui envoie des formulaires de contact. Il utilise aussi une messagerie professionnelle chez OVH ou Ionos. La configuration SPF doit lister les plages IP statiques du serveur web ET celles du fournisseur d'email, tout en activant le DKIM côté messagerie pour sécuriser la signature des courriers sensibles.

Erreurs fréquentes à éviter absolument

Même avec une bonne intention, plusieurs pièges techniques dégradent l'efficacité de la chaîne SPF/DKIM/DMARC :Dépassement des 10 requêtes DNS pour le SPF : Chaque mot-clé include:, a: ou mx: compte comme une requête. Si vous en avez plus de dix, la validation s'arrête et renvoie un résultat neutre (softfail), annulant l'intérêt du protocole.Mélanger les domaines d'affichage et d'émission : Envoyer depuis @votre-domaine.fr mais signer avec une clé DKIM appartenant à un autre domaine provoque systématiquement des échecs de validation.Oublier la migration DNS lors du changement d'hébergeur : Lors d'un transfert, les enregistrements TXT SPF et DKIM sont souvent oubliés ou écrasés par défauts d'importation, coupant net l'envoi des emails professionnels pendant plusieurs heures.

Questions fréquentes