Meilleurs fournisseurs pour la gestion DKIM et SPF

Résumé exécutif : Ce guide traite des exigences désormais obligatoires concernant l'authentification des emails via SPF et DKIM, suite aux mesures des autorités de Google, Yahoo et Microsoft en 2024-2025. Il explique comment ces protocoles fonctionnent conjointement avec DMARC pour protéger les domaines contre l'usurpation et garantir la délivrabilité des emails, tout en soulignant les pièges courants comme la limite de 10 recherches DNS pour SPF et l'absence de rotation des clés DKIM.

Le guide présente Red Sift OnDMARC comme une solution complète qui simplifie la gestion grâce à Dynamic SPF et au suivi intégré DKIM, permettant généralement d'atteindre l'application complète de DMARC en 6 à 8 semaines.

À retenir :

• L'authentification des emails n'est plus optionnelle : Google, Yahoo et Microsoft rejettent ou mettent en quarantaine les emails des expéditeurs de masse qui n'utilisent pas SPF, DKIM et DMARC. Le non-respect impacte directement la délivrabilité et les revenus.
• La limite de 10 recherches SPF surprend la plupart des organisations : L'utilisation de seulement 3 à 5 services email tiers peut dépasser cette limite et entraîner des échecs d'authentification aléatoires. Les solutions Dynamic SPF éliminent ce problème sans les risques du flattening manuel.
• Les clés DKIM nécessitent une gestion active : Les clés 2048 bits sont le standard minimal, et M3AAWG recommande une rotation tous les six mois. Beaucoup d'organisations utilisent encore de vieilles clés 1024 bits, créant ainsi des vulnérabilités de sécurité.
• L'alignement est la pièce manquante : SPF et DKIM peuvent réussir mais DMARC échoue si aucun n'est aligné avec votre domaine visible « From ». C'est pourquoi l'alignement DKIM est le plus important pour les expéditeurs de masse, car il survit mieux au transfert que le SPF.

Bien configurer SPF et DKIM n'est plus une option. Avec l'application stricte des exigences d'authentification email par Google, Yahoo et Microsoft pour les expéditeurs de masse, les organisations qui ne gèrent pas correctement ces protocoles font face à des échecs de délivrabilité, des vulnérabilités de sécurité et des risques pour leur image de marque.

On estime à 3,4 milliards le nombre d'emails de phishing envoyés chaque jour [1]. L'email reste la surface d'attaque privilégiée des cybercriminels, avec 94 % des malwares véhiculés via des pièces jointes dans les emails [2]. C'est précisément la raison pour laquelle les principaux fournisseurs de messagerie ont décidé d'imposer des règles strictes.

Depuis février 2024, Google et Yahoo exigent des expéditeurs de masse (5 000+ emails/jour) qu'ils authentifient leurs emails avec SPF et DKIM, avec au moins un aligné pour la conformité DMARC [3]. Microsoft a suivi le mouvement en mai 2025, rejetant purement et simplement les emails non conformes [4]. Il ne s'agit plus de recommandations. Ce sont des obligations.

Ce guide aborde :

• Comment SPF et DKIM fonctionnent ensemble pour authentifier vos emails
• Les pièges classiques qui compromettent SPF et DKIM (et comment les corriger)
• Ce qu'il faut rechercher chez un fournisseur d'authentification email
• Pourquoi DMARC relie le tout
• Comment Red Sift OnDMARC simplifie l'ensemble du processus

Sender Policy Framework (SPF) est la liste des invités de votre domaine pour l'envoi d'emails. Il s'agit d'un enregistrement DNS indiquant aux serveurs de réception quelles adresses IP sont autorisées à envoyer des emails au nom de votre domaine [5].

Lorsqu'un email arrive, le serveur du destinataire vérifie l'enregistrement SPF du domaine présent dans l'adresse de retour (return-path). Si l'IP de l'expéditeur figure sur la liste, le SPF valide. Sinon, il échoue.

SPF a une limitation critique qui piège la plupart des organisations : la limite de 10 recherches DNS [6]. Tout include, a, mx, ptr ou redirect dans votre enregistrement SPF compte dans cette limite. Si vous la dépassez, les serveurs de réception renvoient un « permerror » et vos emails échouent par intermittence l'authentification.

Voici comment ce total grimpe très vite :

• Google Workspace : 4 recherches DNS
• Microsoft 365 : 2-3 recherches DNS
• Plateformes d'automatisation marketing : 3-7 recherches DNS chacune
• Envoi d'emails depuis un CRM : 2-4 recherches DNS

La plupart des organisations moyennes utilisent au moins 3 à 5 outils pour envoyer des emails en leur nom. Additionnez-les et vous dépassez rapidement 10 recherches sans vous en rendre compte.

• Le flattening SPF convertit les noms d'hôtes en adresses IP, qui ne comptent pas dans la limite. Le problème ? Les prestataires d'email changent fréquemment leurs IP. Quand cela arrive, votre enregistrement aplati devient obsolète et l'authentification échoue [7].
• Les macros SPF offrent une solution plus sophistiquée en résolvant dynamiquement les recherches. Cependant, certains serveurs de réception anciens ne les supportent pas totalement, ce qui peut provoquer des résultats incohérents [8].
• La délégation de sous-domaines consiste à créer des enregistrements SPF séparés pour chaque service en les déplaçant sur des sous-domaines. Cela fonctionne, mais votre adresse « From » affichera ce sous-domaine au lieu du domaine principal.
• Les solutions Dynamic SPF comme Dynamic SPF de Red Sift regroupent tous les expéditeurs autorisés via un unique include résolu dynamiquement. Plus besoin de modifier le DNS à la main, pas de souci de compatibilité macro, ni de complexité sur les sous-domaines.

Selon les recommandations de M3AAWG [9] :

• Publier des enregistrements SPF pour tous les domaines d'envoi, y compris les domaines non utilisés
• Utiliser ~all (softfail) plutôt que -all (hardfail) pour permettre l'évaluation DMARC
• Auditer les SPF tous les trimestres pour retirer les includes inutilisés
• Recenser tous les services tiers envoyant pour votre compte
• Tester les modifications en mode monitoring avant l'application

DomainKeys Identified Mail (DKIM) ajoute une signature cryptographique à vos emails sortants [10]. Cette signature prouve deux choses : l'email provient bien de votre domaine, et son contenu n'a pas été modifié pendant le transport.

Quand vous envoyez un email, votre serveur de messagerie génère une signature unique grâce à une clé privée. Elle est ajoutée dans l'en-tête de l'email. Le serveur récepteur récupère la clé publique dans le DNS et vérifie la correspondance.

La robustesse des clés compte. Les clés 1024 bits étaient la norme pendant des années, mais ne sont plus considérées comme sûres. Les clés RSA 2048 bits sont désormais la longueur minimale recommandée [11]. Certaines organisations passent déjà à du 4096 bits pour plus de sécurité.

La rotation des clés est essentielle. Les clés DKIM doivent être renouvelées au moins tous les 6 mois selon les recommandations M3AAWG [12]. Les expéditeurs à risques comme les banques doivent le faire mensuellement. Or, beaucoup d'entreprises n'ont jamais revu leur configuration initiale. Des chercheurs ont trouvé des clés 1024 bits encore actives depuis 2015 [13].

Les conventions de nommage des sélecteurs facilitent le suivi des clés actives. Utiliser des sélecteurs explicites comme « jan2026 » facilite l'audit et l'identification des services qui signent [14].

• Utiliser des clés 2048 bits minimum (migrer au plus vite depuis 1024 bits)
• Rotater les clés au minimum tous les six mois
• Maintenir deux clés actives simultanément pendant la rotation
• Signer tous les emails sortants, y compris les notifications transactionnelles
• Aligner le domaine DKIM de signature sur votre domaine « From » pour DMARC
• Utiliser des sélecteurs distincts pour chaque service d'envoi
• Documenter le planning de rotation et la convention de nommage des sélecteurs

SPF et DKIM sont essentiels, mais n'ont pas été conçus pour être reliés. D'où DMARC (Domain-based Message Authentication, Reporting, and Conformance).

DMARC requiert qu'au moins SPF ou DKIM réussisse ET soit aligné avec le domaine du champ « From » [15]. C'est une distinction clé. Vous pouvez avoir SPF et DKIM validés séparément, mais si aucun n'est aligné avec votre domaine « From », DMARC échoue.

L'alignement SPF signifie que le domaine du return-path (envelope sender) correspond au domaine « From ». Beaucoup de services tiers utilisent leur propre domaine en return-path, ce qui rompt l'alignement SPF.

L'alignement DKIM signifie que le domaine DKIM (valeur d=) correspond au domaine « From ». L'alignement DKIM est généralement plus fiable car il survit au transfert d'email, contrairement au SPF.

C'est pourquoi Google, Yahoo et Microsoft exigent spécifiquement DKIM pour les expéditeurs de masse. Le SPF seul ne suffit pas pour les nouveaux standards.

Les politiques DMARC évoluent selon trois niveaux :

• p=none : Surveillance uniquement, sans impacter la délivrabilité.
• p=quarantine : Envoi des emails échoués vers les spams/indésirables.
• p=reject : Rejet total des emails non conformes.

La montée en régime prend généralement de 4 à 8 semaines [16]. Il s'agit de recenser tous les expéditeurs légitimes, de configurer correctement SPF et DKIM, et de corriger les problèmes d'alignement avant l'application stricte.

Votre fournisseur doit résoudre la limite des 10 recherches DNS sans introduire de nouveaux problèmes. Les solutions reposant sur un flattening manuel échouent quand les adresses IP changent. Les solutions à base de macros ne fonctionnent pas toujours avec toutes les infrastructures de réception.

Dynamic SPF de Red Sift OnDMARC utilise un seul include dynamique pour authentifier tous les expéditeurs approuvés, au moment de la requête. Aucune mise à jour DNS manuelle, aucune inquiétude concernant la compatibilité des macros, pas d'échec d'authentification aléatoire.

Choisissez des fournisseurs qui :

• Supportent les clés 2048 bits (et idéalement 4096 bits)
• Automatisent la rotation des clés selon un planning défini
• Maintiennent plusieurs clés actives pendant les transitions
• Suivent l'utilisation des sélecteurs sur tous les services d'envoi
• Alertent en cas de clés faibles ou expirantes

SPF et DKIM servent à permettre l'application DMARC. Votre fournisseur devra offrir :

• Des rapports agrégés sur les taux d'authentification réussie/échouée
• Des rapports forensiques détaillant précisément les échecs
• Une visibilité claire sur les services qui authentifient ou non correctement
• Des recommandations concrètes pour résoudre les problèmes

La gestion SPF, DKIM et DMARC impose d'intervenir fréquemment sur le DNS. Les fournisseurs permettant de gérer tous les enregistrements depuis leur plateforme évitent de multiplier les accès DNS séparés et réduisent le risque d'erreur.

OnDMARC permet de configurer SPF, DKIM, DMARC, BIMI et MTA-STS depuis une seule interface. Une intervention DNS suffit pour démarrer ; le reste s'opère sur la plateforme.

L'authentification email n'est pas qu'une simple vérification technique. Elle impacte directement la santé financière et la cybersécurité de votre organisation.

En cas d'échec SPF ou DKIM, vos emails peuvent ne jamais arriver à destination. Les campagnes marketing font flop. Les démarches commerciales restent sans réponse. Les messages clients finissent en indésirables. Les conséquences financières s'accumulent vite.

Prenons l'exemple suivant : votre organisation envoie 50 000 emails par mois, et une mauvaise authentification provoque une baisse de 10 % de délivrabilité, soit 5 000 emails qui n'atteignent pas leur cible. Pour les équipes commerciales ou marketing, cela représente un manque à gagner direct.

Wise, société de transfert d'argent internationale, a vu son taux de délivrabilité grimper à 99 % après la mise en place de OnDMARC [20]. Ce résultat est lié à une configuration correcte de SPF et DKIM sur tous leurs services d'envoi.

Les attaques de phishing usurpant votre domaine ne ternissent pas seulement votre image ; elles érodent la confiance client, exposent votre structure à des risques juridiques et peuvent faciliter le Business Email Compromise (BEC) pour des millions d'euros.

L'Internet Crime Complaint Center du FBI a recensé 21 442 plaintes BEC en 2024, représentant 2,77 milliards de dollars de pertes [21]. Beaucoup de ces attaques débutent via des usurpations de domaine que l'authentification email aurait pu empêcher.

Quand votre domaine est protégé par SPF, DKIM et DMARC en mode enforcement, les attaquants ne peuvent plus usurper votre nom. Leurs messages frauduleux sont bloqués avant même d'atteindre vos clients, partenaires et collaborateurs.

Les administrations et régulateurs exigent de plus en plus l'authentification email. NIST recommande DMARC dans les directives fédérales, le National Cyber Security Centre britannique (NCSC) promeut DMARC, et la Commission européenne publie des lignes directrices sur l'authentification email.

Dans les secteurs régulés comme la santé ou la finance, l'authentification email n'est pas facultative : elle prouve la diligence dans la protection des communications sensibles.

OnDMARC propose une approche globale de l'authentification email, gérant SPF, DKIM et DMARC comme un ensemble intégré au lieu de protocoles isolés.

• Gestion SPF : Dynamic SPF supprime la limite des 10 recherches grâce à un include dynamique unique. Tous les expéditeurs autorisés s'authentifient via un même mécanisme mis à jour automatiquement. Sans macros, donc meilleure compatibilité [17].
• Gestion DKIM : OnDMARC suit les clés DKIM sur tous les services, alerte en cas de clés faibles ou manquantes, et conseille sur la configuration optimale. La plateforme s'intègre avec les principaux prestataires pour configurer DKIM simplement.
• Application DMARC : Les organisations utilisant OnDMARC atteignent le mode enforcement (p=reject ou p=quarantine) en moyenne en 6 à 8 semaines [18]. La plateforme analyse en continu les rapports DMARC et propose des corrections concrètes.
• Au-delà de l'authentification email : OnDMARC intègre DNS Guardian pour surveiller les prises de contrôle de sous-domaines et les attaques SubdoMailing, ainsi que le BIMI intégré avec obtention de VMC pour afficher votre logo de marque vérifié dans les boîtes de réception.

Les fournisseurs de services email comme SendGrid et Amazon SES gèrent la signature DKIM pour les emails transmis, mais pas le SPF ni le reporting DMARC. Vous devrez toujours gérer l'authentification pour TOUS vos services d'envoi.

Les services de flattening SPF comme AutoSPF et SafeSPF résolvent la limite de recherches mais vous obligent à externaliser votre SPF sur l'infrastructure d'un tiers. Une panne de service impacte directement votre délivrabilité.

Les plateformes DMARC-only proposent le reporting mais n'adressent pas forcément les vrais problèmes de configuration SPF/DKIM. Vous voyez l'erreur, mais n'avez pas les outils de correction.

Les outils gratuits (MxToolbox, URIports, etc.) valident la configuration mais n'offrent ni gestion continue, ni automatisation ou support pour l'application stricte.

Commencez par recenser tous les services envoyant des emails depuis votre domaine, notamment :

• Email entreprise (Microsoft 365, Google Workspace)
• Outils de marketing automation
• CRMs avec fonctions email
• Services d'emails transactionnels
• Plateformes RH et recrutement
• Solutions support client
• Logiciels finance et comptabilité

Audit de votre SPF : traquez les include inutilisés et le nombre total de recherches DNS. Vérifiez que DKIM est configuré sur chaque service d'envoi.

Créez un inventaire des services d'envoi précisant :

• Nom du service et fournisseur
• Volume d'emails et type (marketing, transactionnel, interne)
• Include SPF utilisé actuellement
• Sélecteur DKIM et longueur de clé
• Status d'alignement (match avec le domaine « From » ou non)

Cet inventaire devient votre référence pour configurer l'authentification.

Ajoutez ou mettez à jour les clés DKIM pour chaque service d'envoi. Priorisez les clés 2048 bits et consignez la convention de nommage des sélecteurs.

Pour la configuration DKIM avec les principaux fournisseurs :

• Microsoft 365 : utilisez des enregistrements CNAME pointant vers l'infrastructure DKIM de Microsoft. Microsoft gère la rotation automatique entre deux sélecteurs.
• Google Workspace : générez les clés via la console Admin puis publiez les TXT dans le DNS. Privilégiez des sélecteurs personnalisés pour simplifier la gestion.
• Plateformes marketing : la plupart requièrent d'ajouter des CNAME ou TXT. Vérifiez que la plateforme supporte l'alignement DKIM avec votre domaine From.

Optimisez votre SPF ou implémentez Dynamic SPF pour rester sous la limite de recherches tout en autorisant tous les expéditeurs légitimes.

Publiez un enregistrement DMARC en p=none afin de recevoir les rapports agrégés sans impacter la délivrabilité. Renseignez le tag rua avec une adresse mail accessible (ou l'adresse de reporting de votre prestataire DMARC) pour recevoir ces rapports.

Analysez les rapports DMARC pour repérer :

• Des expéditeurs légitimes non authentifiés correctement
• Des problèmes d'alignement (SPF/DKIM valide mais non aligné)
• Des sources inconnues ou non autorisées
• Des volumes inhabituels suspects d'usurpation

Corrigez la configuration pour chaque service, parfois en contactant les prestataires pour activer une signature DKIM personnalisée ou ajuster le return-path.

Problèmes fréquents rencontrés :

• Services tiers signant les emails DKIM avec leur propre domaine au lieu du vôtre
• Retours de parcours marketing qui brisent l'alignement SPF
• Systèmes anciens sans support DKIM
• Services « shadow IT » envoyant des emails sans validation interne

Passez de p=none à p=quarantine pour tester l'application, sans bloquer tous les emails échoués. Surveillez l'arrivée en spam pour contrôler l'impact.

Commencez avec un faible pourcentage via le tag pct (ex. pct=10), n'appliquant la politique qu'à une fraction des emails non conformes. Augmentez progressivement au fil de la confiance.

Une fois sûrs que tous les emails légitimes s'authentifient, passez la politique en p=reject pour une protection maximale.

Continuez le monitoring même après application stricte. De nouveaux services ou des modifications de plateformes peuvent casser l'authentification à tout moment. La vigilance évite les mauvaises surprises côté délivrabilité.

• Symptômes : SPF valide chez certains destinataires mais échoue chez d'autres. Les rapports DMARC montrent des résultats SPF incohérents.
• Cause probable : La limite des 10 recherches DNS est dépassée. Certains serveurs analysent l'ensemble avant la limite (SPF passe), d'autres bloquent sur le permerror.
• Solution : Auditez votre SPF pour supprimer les includes inutiles, retirez les services obsolètes, et implémentez Dynamic SPF ou de la délégation par sous-domaine.

• Symptômes : Après migration (ex. changement de plateforme marketing), DKIM échoue.
• Cause probable : Les anciennes clés DKIM restent dans le DNS alors que la nouvelle plateforme utilise d'autres sélecteurs, ou n'est pas configurée pour signer avec votre domaine.
• Solution : Générez de nouvelles clés DKIM pour la nouvelle plateforme. Publiez-les dans le DNS avec le sélecteur indiqué. Vérifiez que la plateforme signe bien avec le d= de votre domaine. Supprimez les anciennes clés une fois la configuration validée.

• Symptômes : Les rapports DMARC montrent SPF et DKIM OK, mais DMARC échoue.
• Cause probable : Ni SPF ni DKIM ne sont alignés avec le domaine From. L'authentification fonctionne, mais pas pour DMARC.
• Solution : Vérifiez le domaine return-path (alignement SPF) et la valeur d= DKIM (alignement DKIM). Collaborez avec les fournisseurs pour signer avec des domaines personnalisés.

• Symptômes : Echec de la vérification DKIM avec erreurs de « signature invalide », bien que la clé soit bien publiée dans le DNS.
• Cause probable : Le contenu de l’e-mail a été modifié pendant son transit. Les listes de diffusion qui ajoutent des pieds de page, les passerelles de sécurité de messagerie qui réécrivent les URLs ou les services de transfert peuvent casser les signatures DKIM.
• Solution : Cela dépasse souvent votre contrôle. Assurez-vous d’avoir une alignement SPF comme solution de repli. Envisagez d’implémenter ARC (Authenticated Received Chain) si vous êtes l’organisation qui modifie les e-mails en transit.

La gestion de SPF et DKIM est passée du statut d’optionnelle à celle d’obligatoire. Google, Yahoo et Microsoft appliquent désormais des normes d’authentification strictes, et les e-mails non conformes sont rejetés et non plus seulement pénalisés dans leur délivrabilité.

Les difficultés sont réelles : la limite des 10 requêtes de SPF nécessite une maintenance constante, la rotation des clés DKIM demande une coordination minutieuse, et tout aligner pour DMARC ajoute une complexité supplémentaire.

Mais la solution n’a pas à être compliquée. Des plateformes telles que Red Sift OnDMARC réunissent la gestion du SPF, du DKIM et du DMARC dans une seule interface, automatisent les tâches fastidieuses et fournissent des conseils clairs pour atteindre une application complète des protocoles.

Les organisations qui maîtrisent cela protègent leurs domaines contre l’usurpation, améliorent la délivrabilité de leurs e-mails et respectent les exigences de plus en plus strictes des fournisseurs de messagerie. Ceux qui échouent verront leurs e-mails arriver dans les spams, voire ne pas arriver du tout.

[1] SalesHive. « DKIM, DMARC, SPF: Meilleures pratiques pour la sécurité et la délivrabilité des e-mails en 2025. » https://saleshive.com/blog/dkim-dmarc-spf-best-practices-email-security-deliverability/ 

[2] Verizon. « 2024 Data Breach Investigations Report. » https://www.verizon.com/business/resources/reports/dbir/ 

[3] Yahoo. « Sender Best Practices. » https://senders.yahooinc.com/best-practices/ 

[4] Microsoft. « Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders. » https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook's-new-requirements-for-high‐volume-senders/4399730 

[5] IETF. « RFC 7208: Sender Policy Framework. » https://datatracker.ietf.org/doc/html/rfc7208 

[6] Mailhardener. « The SPF Lookup Limit Explained. » https://www.mailhardener.com/blog/spf-lookup-limit-explained 

[7] URIports. « SPF Macros: Overcoming the 10 DNS Lookup Limit. » https://www.uriports.com/blog/spf-macros-max-10-dns-lookups/ 

[8] Mailhardener. « Do Not Flatten Your SPF Record. » https://www.mailhardener.com/blog/do-not-flatten-spf 

[9] M3AAWG. « Email Authentication Recommended Best Practices. » https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf 

[10] IETF. « RFC 6376: DomainKeys Identified Mail Signatures. » https://datatracker.ietf.org/doc/html/rfc6376 

[11] Twilio SendGrid. « 2048 Bit DKIM Keys: Length and Best Practices. » https://www.twilio.com/en-us/blog/insights/2048-bit-dkim-keys 

[12] M3AAWG. « DKIM Key Rotation Best Common Practices. » https://www.m3aawg.org/DKIMKeyRotation 

[13] Suped. « How Often Should You Rotate Your DKIM Keys and What Key Length is Best. » https://www.suped.com/knowledge/email-authentication/dmarc/how-often-should-you-rotate-your-dkim-keys-and-what-key-length-is-best 

[14] Mailgun. « How Can I Rotate My DKIM Key? » https://help.mailgun.com/hc/en-us/articles/16956951504539-How-can-I-rotate-my-DKIM-key 

[15] IETF. « RFC 7489: Domain-based Message Authentication, Reporting, and Conformance. » https://datatracker.ietf.org/doc/html/rfc7489 

[16] Red Sift. « OnDMARC. » https://redsift.com/pulse-platform/ondmarc 

[17] Red Sift. « SPF, DKIM & DMARC: Protocoles e-mail essentiels expliqués. » https://redsift.com/guides/email-protocol-configuration-guide/all-you-need-to-know-about-spf-dkim-and-dmarc 

[18] Cisco. « Cisco Secure Email + Red Sift Domain Protection. » https://docs.ces.cisco.com/docs/red-sift-cisco-secure-email 

[19] URIports. « SPF, DKIM, and DMARC Best Practices. » https://www.uriports.com/blog/spf-dkim-dmarc-best-practices/ 

[20] Red Sift. « OnDMARC Customer Success. » https://redsift.com/customers/customer-success 

[21] Bright Defense. « 200+ statistiques sur le phishing pour 2026. » https://www.brightdefense.com/resources/phishing-statistics/