SPF, DKIM et DMARC : le guide pratique pour la prospection B2B

Pourquoi vos emails de prospection peuvent-ils disparaître ?

Si vos emails arrivent en spam, sont refusés ou ne parviennent pas à certains destinataires, le problème vient parfois de l’authentification de votre domaine. SPF, DKIM et DMARC indiquent aux serveurs de réception qui a le droit d’envoyer vos messages et comment vérifier leur origine.

Pour un commercial, les symptômes sont concrets : des réponses qui se raréfient, des relances invisibles, des erreurs comme « message rejected » ou des prospects qui ne voient rien dans leur boîte principale. Ces mécanismes ne remplacent pas une bonne réputation d’envoi, un ciblage pertinent ou une personnalisation réelle, mais ils constituent la base technique de la délivrabilité.

Un domaine qui envoie des emails de prospection doit être authentifié avant de chercher à augmenter ses volumes d’envoi.

SPF, DKIM et DMARC : que fait chaque mécanisme ?

SPF vérifie si le serveur qui envoie un message est autorisé par le domaine. DKIM ajoute une signature cryptographique au message. DMARC compare ces contrôles avec l’adresse affichée au destinataire et indique au serveur quoi faire en cas d’échec.

SPF : autoriser les serveurs d’envoi

SPF, pour Sender Policy Framework, est une règle publiée dans les DNS de votre domaine. Elle contient la liste des services ou serveurs autorisés à envoyer des emails au nom de ce domaine.

Lorsque vous envoyez un message, le serveur destinataire regarde généralement le domaine technique utilisé pour le retour d’erreur, appelé enveloppe d’envoi ou Return Path. Il vérifie ensuite si l’adresse IP ou le service d’envoi figure dans l’enregistrement SPF de ce domaine.

SPF répond donc à une question précise : « Ce serveur est-il autorisé à envoyer pour ce domaine ? » Il ne signe pas le contenu du message et ne garantit pas, à lui seul, que l’adresse visible dans le champ « De » est légitime.

Le piège le plus fréquent est la présence de plusieurs enregistrements SPF pour un même domaine. Il ne faut normalement qu’une seule règle SPF, qui peut inclure plusieurs services autorisés. Une configuration du type « un SPF pour Microsoft 365, un autre pour votre outil de prospection et un troisième pour votre CRM » crée un conflit et peut provoquer un échec d’authentification.

DKIM : signer le message

DKIM, pour DomainKeys Identified Mail, ajoute une signature numérique à l’email. Le serveur destinataire utilise une clé publique publiée dans les DNS pour vérifier que le message vient bien d’un service autorisé et qu’il n’a pas été modifié pendant son acheminement.

DKIM répond à une autre question : « La signature associée à ce domaine est-elle valide et le contenu est-il resté intègre ? » La clé privée reste chez le prestataire ou le serveur qui envoie les emails. Vous ne devez jamais la publier dans les DNS ni la transmettre comme un simple texte à un tiers.

Une signature DKIM valide est particulièrement utile lorsque le message est transféré ou qu’il passe par plusieurs systèmes. Elle permet au destinataire de vérifier l’origine déclarée par la signature, même si le parcours technique du message est plus complexe que celui d’un envoi direct.

Une panne DKIM peut apparaître après un changement d’outil, une modification du sélecteur, une rotation de clé ou une erreur de saisie dans le DNS. Le commercial ne voit pas forcément la cause, mais il peut constater une hausse des messages en spam ou des refus chez certains prospects.

DMARC : relier l’identité visible et les contrôles techniques

DMARC, pour Domain-based Message Authentication, Reporting and Conformance, vérifie que le domaine affiché dans l’adresse « De » correspond à un domaine authentifié par SPF ou par DKIM. Il permet aussi au propriétaire du domaine de demander une action en cas d’échec et de recevoir des rapports.

DMARC ne remplace donc ni SPF ni DKIM. Il s’appuie sur eux pour vérifier l’alignement entre l’identité visible par le prospect et l’identité validée par les contrôles techniques.

Un message peut réussir SPF mais échouer DMARC si SPF valide un domaine technique différent de celui affiché dans le champ « De ». À l’inverse, un message peut réussir DMARC grâce à DKIM même si SPF échoue, à condition que la signature DKIM soit valide et alignée avec le domaine visible.

Les politiques DMARC sont généralement progressives. Une politique d’observation permet d’abord de recevoir des rapports sans demander le blocage des messages. Une politique plus stricte demande ensuite de placer les messages non conformes en quarantaine ou de les rejeter. Le bon niveau dépend de la cartographie réelle de tous vos émetteurs légitimes.

Dans quel ordre mettre SPF, DKIM et DMARC en place ?

Commencez par recenser tous les outils qui envoient des emails avec votre domaine, puis configurez SPF et DKIM avant d’activer DMARC. DMARC doit d’abord servir à observer les flux, car une politique trop stricte peut bloquer des messages légitimes dont vous ignoriez l’existence.

1. Recensez les expéditeurs. Listez votre messagerie, votre CRM, votre outil de marketing, votre solution de support, votre plateforme de prospection, vos formulaires et les éventuels services transactionnels. Pensez aussi aux applications anciennes qui envoient encore des notifications.
2. Nettoyez et configurez SPF. Regroupez les autorisations dans un seul enregistrement SPF. Supprimez les services qui ne sont plus utilisés et vérifiez que chaque prestataire est bien autorisé. Une règle trop large autorise davantage de sources que nécessaire, tandis qu’une règle incomplète provoque des échecs.
3. Activez DKIM pour chaque service. Le prestataire fournit généralement un sélecteur et une clé publique à ajouter aux DNS. Vérifiez ensuite qu’il signe réellement les messages avec le bon domaine, et pas uniquement avec un domaine générique qui lui appartient.
4. Ajoutez DMARC en mode observation. Publiez une politique qui demande des rapports, sans bloquer immédiatement les messages. Cette étape permet de voir les sources d’envoi oubliées et les problèmes d’alignement.
5. Analysez les rapports avant de durcir la politique. Corrigez les flux légitimes qui échouent, identifiez les sources inconnues et vérifiez les transferts. Vous pourrez ensuite augmenter progressivement le niveau de protection.

Ne commencez pas par une politique DMARC de rejet si vous n’avez pas une vision complète de vos envois. Le risque n’est pas seulement de bloquer une campagne commerciale : vous pouvez aussi interrompre des factures, des notifications, des réponses automatiques ou des emails envoyés par votre équipe.

Que se passe-t-il quand vous envoyez depuis le domaine de votre client ?

Envoyer depuis le domaine du client améliore la cohérence de l’identité commerciale, mais cela transfère aussi la responsabilité de l’authentification vers ce domaine. L’outil d’envoi ne peut pas simplement utiliser une adresse « De » du client sans configuration DNS et sans validation de son équipe technique.

Le premier point de friction est l’autorisation d’envoi. Le domaine du client doit reconnaître le service utilisé pour envoyer les emails, généralement grâce à SPF, à DKIM ou aux deux. Si le client possède déjà un SPF, il faut l’enrichir proprement, sans créer un second enregistrement concurrent.

Le deuxième point concerne la signature DKIM. Le client doit publier la clé publique correspondant à la clé privée conservée par la plateforme d’envoi. Si le sélecteur est mal recopié, si le DNS n’est pas celui du bon domaine ou si la clé a changé, la signature échoue.

Le troisième point est l’alignement DMARC. L’adresse visible peut être commerciale, tandis que le domaine technique de retour ou le domaine de signature appartient au prestataire. Cette différence peut suffire à faire échouer DMARC, même si SPF ou DKIM affiche un résultat positif séparément.

Les symptômes sont souvent progressifs : certains prospects reçoivent le message, d’autres le voient en spam, et quelques serveurs le refusent avec une erreur d’authentification. Ce comportement variable ne signifie pas forcément que la campagne est aléatoire. Les serveurs destinataires n’appliquent pas tous les mêmes règles, et chacun combine les résultats SPF, DKIM, DMARC et la réputation du domaine.

Avant tout lancement, demandez donc au client qui gère les DNS, quel outil de messagerie reste actif, quels services envoient déjà pour le domaine et si une politique DMARC est en place. Une configuration sur mesure par un intégrateur ou un responsable technique évite de traiter un problème DNS comme un simple problème de rédaction commerciale.

Comment lire un rapport DMARC sans être administrateur système ?

Un rapport DMARC agrégé est un relevé des serveurs qui ont envoyé des messages en utilisant votre domaine apparent. Pour le lire, concentrez-vous d’abord sur la source d’envoi, le volume, les résultats SPF et DKIM, puis sur la décision appliquée au message.

Vous trouverez généralement plusieurs informations utiles :

• La source ou l’adresse IP : elle permet d’identifier le service qui a envoyé les messages. Comparez-la avec vos outils connus, sans conclure trop vite qu’une adresse inconnue est malveillante.
• Le nombre de messages : un faible volume peut correspondre à un test, à une notification ou à un ancien outil encore actif. Un volume important mérite une vérification prioritaire.
• Le résultat SPF : il indique si le serveur d’envoi était autorisé pour le domaine technique contrôlé.
• Le résultat DKIM : il indique si la signature était valide. Vérifiez aussi le domaine associé à cette signature.
• L’alignement : il compare les domaines authentifiés avec celui affiché dans l’adresse « De ». C’est souvent ici que se trouve la différence entre un contrôle réussi et un DMARC réussi.
• La disposition : elle indique si le message a été accepté, placé en quarantaine ou rejeté selon la politique observée.

Imaginez un rapport qui montre une série de messages provenant de votre outil de prospection, avec SPF réussi, DKIM réussi et DMARC réussi. Le flux est probablement cohérent. Si SPF et DKIM réussissent mais que DMARC échoue, recherchez un problème d’alignement. Si les deux contrôles échouent, vérifiez d’abord l’autorisation du service, la signature et le domaine réellement utilisé.

Une source inconnue ne doit pas être supprimée automatiquement. Il peut s’agir d’un outil légitime, d’un prestataire d’emailing oublié, d’un transfert ou d’un service qui utilise un sous-domaine. Contactez les équipes concernées, comparez les dates et volumes, puis décidez s’il faut autoriser, corriger ou bloquer cette source.

Les rapports DMARC sont souvent transmis au format XML, ce qui les rend peu lisibles dans une boîte de réception classique. Vous pouvez utiliser un analyseur spécialisé ou demander une synthèse à votre équipe technique. Vous n’avez pas besoin de comprendre chaque champ pour agir : l’objectif est d’identifier les émetteurs, les échecs répétés et les problèmes d’alignement.

Que vérifier quand un email est refusé ou arrive en spam ?

Commencez par distinguer un refus technique, un classement en spam et une absence de réponse. Ces trois symptômes peuvent avoir des causes différentes, même lorsque le message semble identique du point de vue du commercial.

• Message refusé immédiatement : consultez le code d’erreur et recherchez une mention de SPF, DKIM, DMARC, de réputation ou de politique de domaine.
• Message classé en spam : vérifiez l’authentification, mais aussi la réputation du domaine, la qualité des adresses, les plaintes, le contenu et le comportement d’envoi.
• Message non visible : contrôlez l’adresse utilisée, le suivi de remise, les règles de filtrage du prospect et l’existence éventuelle d’une boîte partagée.
• Résultats différents selon les prospects : comparez les domaines destinataires. Chaque organisation peut appliquer ses propres règles de filtrage.

Ne modifiez pas simultanément le DNS, le contenu, le volume et les adresses d’envoi. Changez un élément à la fois lorsque c’est possible, conservez les messages d’erreur et observez les rapports. Cette méthode vous aide à relier une correction à une amélioration réelle.

La checklist avant une campagne de prospection

Avant d’envoyer une campagne depuis un domaine, vérifiez que l’identité utilisée est autorisée, signée et alignée. Une vérification simple en amont évite de découvrir un problème après plusieurs relances invisibles.

• Le domaine affiché dans l’adresse « De » est-il bien celui du client ?
• Le service d’envoi est-il autorisé dans le SPF du domaine concerné ?
• Un seul enregistrement SPF est-il publié ?
• La signature DKIM utilise-t-elle le domaine du client ou un domaine correctement aligné ?
• La politique DMARC est-elle connue et compatible avec le scénario d’envoi ?
• Les outils qui envoient déjà des emails pour ce domaine ont-ils été recensés ?
• Un message de test a-t-il été contrôlé chez plusieurs destinataires ?
• Les rapports DMARC sont-ils consultés après le lancement ?

Dans une démarche de prospection pilotée par les données, l’authentification doit être traitée comme une condition de départ, pas comme une correction de dernière minute. Les textes personnalisés, les relances automatiques et l’envoi depuis le domaine du client ne peuvent produire des réponses que si les messages atteignent réellement les boîtes de réception.

Pour cadrer l’envoi depuis le domaine de votre entreprise ou de vos clients, échangez avec Opticontact afin de préparer une configuration adaptée à vos outils et à votre organisation.