Meilleurs fournisseurs pour la gestion de DKIM et SPF

Résumé exécutif : Ce guide traite des exigences obligatoires en matière d’authentification email SPF et DKIM, à la suite des mesures de conformité adoptées par Google, Yahoo et Microsoft en 2024-2025. Il explique comment ces protocoles collaborent avec DMARC pour protéger les domaines contre l’usurpation et garantir la délivrabilité des emails, tout en mettant en lumière les écueils courants, comme la limite de 10 recherches DNS pour SPF et une rotation insuffisante des clés DKIM.

Le guide présente Red Sift OnDMARC comme une solution complète qui simplifie la gestion grâce à un SPF Dynamique et un suivi intégré de DKIM, permettant généralement 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 placent en quarantaine les emails des expéditeurs de masse qui n’authentifient pas avec SPF, DKIM et DMARC. Le non-respect a un impact direct sur la délivrabilité et le chiffre d’affaires.
• La limite de 10 recherches SPF piège la plupart des organisations : Utiliser seulement 3 à 5 services d’email tiers peut dépasser cette limite, entraînant des échecs d’authentification aléatoires. Les solutions SPF dynamiques é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 désormais le standard minimal. M3AAWG recommande une rotation tous les six mois. Beaucoup d’organisations utilisent encore de vieilles clés 1024 bits, créant des failles de sécurité.
• L’alignement est la clé manquante : SPF et DKIM peuvent réussir mais DMARC échouer si aucun des deux n’est aligné avec votre domaine « From » visible. L’alignement DKIM est primordial pour les expéditeurs de masse, car il résiste mieux au transfert d’email que SPF.

Bien gérer SPF et DKIM n’est plus optionnel. Avec Google, Yahoo et Microsoft qui appliquent désormais des exigences strictes d’authentification email pour les expéditeurs de masse, les organisations qui gèrent mal ces protocoles risquent des échecs de délivrabilité, des vulnérabilités de sécurité et des atteintes potentielles à leur 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 : 94 % des maliciels sont diffusés via des pièces jointes d’emails [2]. C’est précisément pour cela que 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 (plus de 5 000 emails/jour) qu’ils authentifient leurs messages avec SPF et DKIM, l’un des deux devant impérativement être aligné pour se conformer à DMARC [3]. Microsoft a suivi en mai 2025 en rejetant directement tous les emails non conformes [4]. Ce ne sont pas des recommandations. Ce sont des obligations.

Ce guide aborde :

• Comment SPF et DKIM authentifient ensemble vos emails
• Les pièges classiques qui font échouer SPF et DKIM (et comment y remédier)
• Ce qu’il faut demander à un fournisseur d’authentification email
• Pourquoi DMARC constitue la pièce maîtresse de l’ensemble
• Comment Red Sift OnDMARC simplifie toute la démarche

Sender Policy Framework (SPF) agit comme la liste d’invités de votre domaine. Il s’agit d’un enregistrement DNS qui précise aux serveurs récepteurs quelles adresses IP sont autorisées à envoyer des emails utilisant votre nom de domaine [5].

Quand un email arrive, le serveur destinataire consulte l’enregistrement SPF du domaine de l’adresse de retour. Si l’adresse IP expéditrice figure sur la liste, SPF passe. Sinon, il échoue.

SPF comporte une limite critique qui prend de court la plupart des organisations : la limite de 10 recherches DNS [6]. Chaque mécanisme include, a, mx, ptr et redirect compte dans ce total. Si vous le dépassez, les serveurs récepteurs renvoient une « permerror », et vos emails commencent à échouer au hasard à l’authentification.

Voici à quelle vitesse la limite est atteinte :

• Google Workspace : 4 recherches DNS
• Microsoft 365 : 2-3 recherches DNS
• Plateformes d’automatisation marketing : 3-7 recherches DNS chacune
• Email CRM : 2-4 recherches DNS

La plupart des structures moyennes utilisent au moins 3 à 5 outils qui envoient des emails en leur nom. Additionnez-les, et vous dépassez déjà la limite des dix.

• SPF flattening : convertit les noms d’hôte en adresses IP (celles-ci ne comptent pas pour la limite). Hélas, les fournisseurs d’emails modifient souvent leurs plages IP : si le record aplati n’est pas mis à jour, il devient obsolète et l’authentification échoue [7].
• Macros SPF : solution plus avancée, elle résout dynamiquement les recherches lors de la requête. Cependant, certaines infrastructures anciennes ne gèrent pas les macros, entraînant des résultats inconstants [8].
• Délégation de sous-domaines : permet de créer des enregistrements SPF distincts pour plusieurs services sur des sous-domaines différents. Mais l’adresse « From » affichera alors le sous-domaine à la place du domaine principal.
• Solutions SPF dynamiques telles que Red Sift's Dynamic SPF : elles regroupent tous les expéditeurs autorisés dans un seul include qui se résout dynamiquement. Aucun changement DNS manuel, pas d’incertitude liée aux macros, ni à la complexité des sous-domaines.

Selon les recommandations M3AAWG [9] :

• Publiez un enregistrement SPF pour tous les domaines émetteurs, y compris les domaines « parkés »
• Utilisez ~all (softfail) au lieu de -all (hardfail) pour permettre à DMARC d’évaluer
• Révisez les enregistrements SPF chaque trimestre pour retirer les includes inutilisés
• Inventoriez tous vos services tiers envoyant des emails en votre nom
• Testez les modifications en mode monitoring avant toute application

DomainKeys Identified Mail (DKIM) ajoute une signature cryptographique à vos emails sortants [10]. Elle prouve deux choses : que l’email vient bien de votre domaine et que son contenu n’a pas été modifié pendant le transit.

Lorsque vous envoyez un email, votre serveur génère une signature unique avec une clé privée. Cette signature s’insère dans l’entête de l’email. Le serveur destinataire récupère la clé publique depuis le DNS et vérifie la correspondance.

La robustesse des clés compte. Les clés 1024 bits ont été la norme, mais ne sont plus considérées comme sûres. Les clés RSA 2048 bits constituent aujourd’hui le minimum conseillé [11]. Certaines organisations optent déjà pour 4096 bits pour renforcer la sécurité.

La rotation des clés est essentielle. Les clés DKIM devraient être renouvelées au moins tous les six mois, d’après M3AAWG [12]. Les émetteurs à risque, tel le secteur financier, devraient tourner leurs clés chaque mois. Cependant, la plupart des organisations mettent en place DKIM une fois… puis n’y touchent plus. Des études ont montré des clés 1024 bits en service depuis 2015 [13].

Des sélecteurs explicites (« selectors ») facilitent le suivi : nommez-les de façon descriptive comme « jan2026 » pour contrôler plus simplement la rotation et identifier qui signe quoi [14].

• Utilisez des clés 2048 bits au minimum (migrez immédiatement si vous êtes en 1024 bits)
• Effectuez une rotation au moins tous les six mois
• Maintenez deux clés actives pendant la rotation (pas d’interruption d’authentification)
• Signez tous vos emails sortants, y compris transactionnels
• Alignez le domaine de signature DKIM avec le domaine « From » pour DMARC
• Utilisez des sélecteurs distincts selon les services d’envoi
• Consignez le planning de rotation des clés et la convention de nommage

SPF et DKIM sont essentiels mais conçus à l’origine pour fonctionner séparément. C’est là qu’intervient DMARC (Domain-based Message Authentication, Reporting, and Conformance).

DMARC exige qu’au moins l’un des deux (SPF ou DKIM) réussisse ET soit aligné avec le domaine indiqué dans l’entête « From » [15]. C’est capital : les deux peuvent réussir, mais si aucun n’est aligné avec le « From », DMARC échoue.

Alignement SPF : le domaine du return-path (expéditeur envelope) doit correspondre au domaine du « From ». Or beaucoup de services tiers utilisent leur propre return-path pour la gestion des bounces, ce qui casse l’alignement SPF.

Alignement DKIM : le domaine dans la signature DKIM (valeur d=) doit correspondre au « From ». L’alignement DKIM est généralement plus fiable car il résiste mieux au transfert d’email (ce qui n’est pas le cas de SPF).

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

Vous pouvez choisir des niveaux d’alignement différents dans le même enregistrement DMARC, grâce aux balises `aspf` et `adkim`. La plupart des organisations optent pour un SPF relâché et un DKIM strict, car SPF casse souvent avec les retours-path tiers et les transferts, tandis que DKIM suit le message et tient bon même sous règle stricte [22].

Si vous ne l’avez pas encore fait, commencez par relaxed pour les deux. Analysez quelques semaines de rapports DMARC, repérez quels émetteurs tiendraient en strict, puis resserrez seulement l’attribut dont vous maîtrisez la source d’envoi.

Point à surveiller si vous avez lu d’anciennes documentations : la RFC 9989 (DMARCbis) a remplacé la RFC 7489. L’alignement ne change pas, mais la façon dont le « domaine organisationnel » est déterminé oui : l’ancien standard utilisait la Public Suffix List, le nouveau fait une recherche arborescente DNS [23].

Les politiques DMARC évoluent en trois phases :

• p=none : mode monitoring, réception seulement de rapports, aucun impact sur les emails.
• p=quarantine : les emails échoués vont en spam/courrier indésirable.
• p=reject : les emails échoués sont purement bloqués.

Le passage du monitoring à l’application prend en général 4 à 8 semaines [16]. Ce temps est nécessaire pour recenser tous les émetteurs légitimes, corriger leur SPF et DKIM, et éliminer les problèmes d’alignement avant activation du rejet/quarantaine.

Votre fournisseur doit résoudre la limite des 10 recherches DNS sans créer de nouveaux problèmes. Les solutions qui reposent sur un « flattening » manuel échouent dès qu’une adresse IP change ; les macros ne sont pas forcément compatibles avec tous les serveurs récepteurs.

Le SPF Dynamique de Red Sift OnDMARC utilise un seul include dynamique qui authentifie tous les expéditeurs autorisés à l’exécution. Aucun changement DNS manuel, pas de souci de compatibilité macro, ni d’échec d’authentification aléatoire.

Recherchez des fournisseurs qui :

• Supportent les clés 2048 bits (voire 4096 bits)
• Automatisent la rotation des clés selon un calendrier défini
• Maintiennent plusieurs clés actives lors des transitions
• Assurent le suivi des selectors utilisés pour chaque service d’envoi
• Vous alertent en cas de clés faibles ou expirantes

SPF et DKIM n’existent que pour permettre l’application DMARC. Votre fournisseur doit proposer :

• Rapports agrégés avec taux de réussite/échec d’authentification
• Rapports forensiques détaillant les échecs
• Visibilité claire sur les services qui s’authentifient (ou non)
• Des recommandations concrètes pour résoudre les problèmes

Gérer SPF, DKIM et DMARC nécessite de fréquentes modifications DNS. Un fournisseur permettant l’administration de tous ces enregistrements depuis sa plateforme évite d’accéder à plusieurs systèmes DNS et limite les erreurs de configuration.

OnDMARC permet de configurer SPF, DKIM, DMARC, BIMI et MTA-STS depuis une interface unique. Un seul changement DNS suffit pour démarrer ; tout le reste passe par la plateforme.

L’authentification email n’est pas un simple geste technique. Elle a un impact direct sur le chiffre d’affaires et le niveau de sécurité de votre organisation.

Si SPF ou DKIM échouent, vos emails risquent de ne jamais arriver à destination. Les campagnes marketing tombent à plat, les relances commerciales restent sans réponse, les échanges clients finissent en dossiers indésirables… L’impact financier se cumule vite.

Prenons un exemple : si votre organisation envoie 50 000 emails/mois et qu’une mauvaise authentification réduit la délivrabilité de 10 %, cela représente 5 000 emails non délivrés. En marketing ou commercial, cela signifie directement une perte d’opportunités et de chiffre d’affaires.

Wise, spécialiste du transfert d’argent international, est monté à 99 % de délivrabilité après avoir déployé OnDMARC [20]. Ce succès découle d’une configuration correcte de SPF et DKIM pour tous les services d’envoi.

Les attaques de phishing usurpant votre domaine nuisent à bien plus que votre réputation. Elles détruisent la confiance des clients, exposent à des risques juridiques et servent de rampe aux attaques BEC (compromission de messagerie) chiffrées en millions.

Selon l’IC3 du FBI, 21 442 plaintes BEC ont été comptabilisées en 2024, pour un total de 2,77 milliards de dollars de pertes [21]. Nombre de ces attaques commencent par une usurpation que l’authentification email aurait pu empêcher.

Avec une protection SPF/DKIM/DMARC appliquée, les fraudeurs ne peuvent plus faire passer leurs emails comme provenant de votre organisation. Les messages usurpés sont bloqués avant d’atteindre clients, partenaires ou collaborateurs.

Les agences publiques exigent de plus en plus l’authentification email. Le NIST recommande DMARC dans ses directives cybersécurité fédérales. Le NCSC britannique milite activement pour DMARC. La Commission européenne a publié des recommandations sur l’authentification du courriel.

Dans les secteurs réglementés (santé, finance...), une authentification correcte n’est pas un choix : elle prouve la diligence exigée pour protéger les communications sensibles.

OnDMARC adopte une approche globale de l’authentification email, en gérant SPF, DKIM et DMARC comme un système intégré plutôt que des protocoles indépendants.

• Gestion SPF : le SPF Dynamique lève la limite des 10 recherches via un include unique dynamique. Tous les expéditeurs s’authentifient via un seul mécanisme à mise à jour automatique, sans macros, ce qui maximise la compatibilité [17].
• Gestion DKIM : OnDMARC suit les clés DKIM pour tous les services d’envoi, alerte en cas de signature faible/manquante et guide la configuration correcte. L’intégration avec les fournisseurs majeurs d’email simplifie la mise en place DKIM.
• 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 continuellement les rapports DMARC et propose des correctifs prescriptifs.
• Au-delà de l’authentification : OnDMARC inclut DNS Guardian pour surveiller les risques de takeover de sous-domaine et les attaques SubdoMailing, ainsi que le support BIMI et la gestion VMC pour afficher les logos de marque validés en boîte de réception.

Fournisseurs d’envoi email comme SendGrid et Amazon SES gèrent la signature DKIM sur leurs flux, mais ne s’occupent pas de vos enregistrements SPF ni des rapports DMARC. Il vous reste à gérer l’authentification sur l’ensemble de vos services d’envoi.

Services de flattening SPF comme AutoSPF ou SafeSPF résolvent la limite de recherches mais vous obligent à déléguer la gestion SPF à une infrastructure tierce : toute interruption côté fournisseur affecte directement vos flux email.

Plateformes DMARC only  : proposent du reporting mais ne règlent pas les éventuelles erreurs de configuration SPF ou DKIM. Visibilité sans outils de résolution.

Outils gratuits de MxToolbox, URIports, etc. valident la configuration mais n’offrent pas de gestion continue, ni d’automatisation, ni d’aide à la remédiation.

Commencez par recenser tous les services envoyant des emails en votre nom, y compris :

• Email interne (Microsoft 365, Google Workspace)
• Plateformes marketing automation
• Outils CRM avec envoi email
• Services d’email transactionnel
• Solutions RH et recrutement
• Support client
• Logiciels finance et compta

Auditez votre enregistrement SPF (includes inutilisés, décompte de recherches DNS). Vérifiez la présence d’un DKIM par service d’envoi.

Élaborez un inventaire des services d’envoi :

• Nom du service / fournisseur
• Volume et type d’emails (marketing, transactionnel, interne)
• Mécanisme SPF utilisé
• Sélecteur DKIM et taille de clé
• État de l’alignement (aligné ou pas avec votre domaine « From »)

Cet inventaire sera votre référence pour toute la gestion future.

Ajoutez ou mettez à jour les clés DKIM pour chaque service d’envoi. Privilégiez 2048 bits, documentez la convention de nommage de vos selectors.

Pour configurer DKIM avec les principales plateformes :

• Microsoft 365 : CNAME pointant vers l’infrastructure DKIM de Microsoft. Rotation automatique entre deux selectors gérée par Microsoft.
• Google Workspace : Génération via la console Admin et publication du TXT DNS. À envisager : sélecteurs personnalisés pour la gestion.
• Plateformes marketing : ajout CNAME/TXT requis. Vérifiez que la plateforme accepte l’alignement DKIM avec votre domaine « From ».

Optimisez le SPF ou mettez en place un SPF Dynamique pour rester sous la limite, tout en autorisant tous les émetteurs légitimes.

Publiez un enregistrement DMARC en p=none pour commencer à recevoir les rapports sans impacter la délivrabilité. Renseignez le tag rua avec une adresse que vous contrôlez (ou celle de votre fournisseur DMARC).

Passez en revue les rapports DMARC pour identifier :

• Expéditeurs légitimes non authentifiés correctement
• Problèmes d’alignement (SPF/DKIM validé mais non aligné)
• Sources d’envoi inconnues ou non autorisées
• Anomalies de volume révélatrices de spoofing

Corrigez chaque service, au besoin en collaborant avec des fournisseurs tiers (pour DKIM ou return-path personnalisé).

Problèmes typiques rencontrés :

• Services tiers utilisant leur propre domaine pour la signature DKIM au lieu du vôtre
• Plateformes marketing dont le return-path casse l’alignement SPF
• Systèmes anciens sans prise en charge DKIM
• Services non référencés (Shadow IT) envoyant sans l’accord du SI

Passez du mode p=none à p=quarantine pour tester l’application sans bloquer tous les emails échoués. Surveillez les spams/users.

Débutez par un pourcentage faible via le tag pct (ex : pct=10) pour appliquer la politique à une fraction des emails échoués, puis augmentez graduellement.

Une fois sûr que tout email légitime s’authentifie, passez en p=reject (rejet total des non-conformes).

Surveillez ensuite en continu. Toute nouvelle source d’envoi ou modification de configuration peut briser l’authentification. La vigilance évite les mauvaises surprises côté délivrabilité.

• Symptômes : SPF passe chez certains destinataires, échoue chez d’autres. Les rapports DMARC révèlent des résultats SPF incohérents.
• Cause probable : Vous avez dépassé la limite de 10 requêtes DNS. Certains serveurs évaluent tout votre enregistrement avant d’atteindre la limite et acceptent ; d’autres atteignent la limite plus tôt (= permerror).
• Solution : Auditez votre enregistrement SPF pour supprimer les include inutiles. Retirez les mécanismes liés aux services que vous n'utilisez plus. Mettez en place un SPF dynamique ou déléguez à un sous-domaine pour rester sous la limite.

• Symptômes : Après une migration de plateforme d’emailing (ex. d’un outil d’automatisation marketing à un autre), DKIM commence à échouer.
• Cause probable : Les anciennes clés DKIM sont toujours présentes dans le DNS alors que la nouvelle plateforme utilise d’autres sélecteurs. Ou bien la nouvelle plateforme 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 en utilisant le sélecteur spécifié par la plateforme. Vérifiez que la plateforme signe bien avec la valeur d= de votre domaine, et non la leur. Supprimez les anciennes clés une fois que la nouvelle configuration fonctionne.

• Symptômes : Les rapports DMARC indiquent que SPF et DKIM sont valides mais DMARC échoue tout de même.
• Cause probable : Ni SPF ni DKIM ne sont alignés avec votre domaine d’expéditeur (« From »). Le service est authentifié, mais pas d’une façon utile pour DMARC.
• Solution : Vérifiez le domaine du return-path (pour l’alignement SPF) et la valeur d= dans les signatures DKIM (pour l’alignement DKIM). Travaillez avec le service d’envoi pour configurer des domaines personnalisés correspondant à votre adresse d’expéditeur.

• Symptômes : La vérification DKIM échoue avec des erreurs de « signature invalide ». La clé est pourtant publiée correctement dans le DNS.
• Cause probable : Le contenu de l’email a été modifié pendant son transit. Les listes de diffusion qui ajoutent des pieds de page, les passerelles de sécurité qui réécrivent les URL, ou encore les services de transfert peuvent casser la signature DKIM.
• Solution : Ce problème échappe souvent à votre contrôle. Assurez-vous d’avoir aussi un alignement SPF en solution de repli. Envisagez de mettre en place ARC (Authenticated Received Chain) si c’est votre organisation qui modifie les emails en transit.

La gestion du SPF et de DKIM n’est plus un simple "plus", c’est devenu une exigence. Google, Yahoo et Microsoft appliquent désormais des standards d’authentification stricts : les emails non conformes sont refusés, et non plus simplement pénalisés en délivrabilité.

Les défis sont réels : la limite de 10 recherches SPF impose une maintenance permanente, la rotation des clés DKIM nécessite de la coordination, et l’alignement DMARC introduit une complexité supplémentaire.

Mais la solution n’a pas besoin d’être compliquée. Des plateformes comme Red Sift OnDMARC centralisent la gestion SPF, DKIM et DMARC dans une seule interface, automatisent les tâches fastidieuses et vous guident clairement vers une conformité totale.

Les organisations qui maîtrisent ces sujets protègent leur domaine du spoofing, améliorent la délivrabilité de leurs emails et anticipent les exigences croissantes des fournisseurs de messagerie. Celles qui ne le font pas verront leurs messages atterrir en indésirables… ou ne pas arriver du tout.

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

[2] Verizon. « Rapport 2024 sur l’investigation des fuites de données (Data Breach Investigations Report). » https://www.verizon.com/business/resources/reports/dbir/ 

[3] Yahoo. « Bonnes pratiques pour les expéditeurs. » https://senders.yahooinc.com/best-practices/ 

[4] Microsoft. « Renforcement de l’écosystème email : les nouvelles exigences d’Outlook pour les expéditeurs à volume élevé. » 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. « La limite de recherches SPF expliquée. » https://www.mailhardener.com/blog/spf-lookup-limit-explained 

[7] URIports. « Les macros SPF : dépasser la limite de 10 recherches DNS. » https://www.uriports.com/blog/spf-macros-max-10-dns-lookups/ 

[8] Mailhardener. « Ne pas aplatir votre enregistrement SPF. » https://www.mailhardener.com/blog/do-not-flatten-spf 

[9] M3AAWG. « Recommandations de meilleures pratiques d’authentification email. » 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. « Clés DKIM 2048 bits : longueur et meilleures pratiques. » https://www.twilio.com/en-us/blog/insights/2048-bit-dkim-keys 

[12] M3AAWG. « Bonnes pratiques pour la rotation des clés DKIM. » https://www.m3aawg.org/DKIMKeyRotation 

[13] Suped. « À quelle fréquence changer vos clés DKIM et quelle longueur choisir. » https://www.suped.com/knowledge/email-authentication/dmarc/how-often-should-you-rotate-your-dkim-keys-and-what-key-length-is-best 

[14] Mailgun. « Comment puis-je changer ma clé DKIM ? » 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 email 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. « Meilleures pratiques SPF, DKIM et DMARC. » https://www.uriports.com/blog/spf-dkim-dmarc-best-practices/ 

[20] Red Sift. « Réussites clients OnDMARC. » https://redsift.com/customers/customer-success 

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