Configurer SPF, DKIM et DMARC

À quoi sert chacun des trois

Ces trois protocoles répondent à la même question posée par le serveur qui reçoit votre email : « ce message vient-il vraiment de ce domaine, ou quelqu'un l'usurpe-t-il ? ». Ils y répondent de manière complémentaire, et c'est leur combinaison qui protège votre délivrabilité.

SPF (Sender Policy Framework) est une liste d'autorisation. Vous publiez, dans votre DNS, la liste des serveurs qui ont le droit d'envoyer des emails en votre nom. Quand un message arrive, le récepteur regarde l'adresse IP émettrice et vérifie qu'elle figure bien dans cette liste. C'est un contrôle sur l'enveloppe de l'email, pas sur son contenu.

DKIM (DomainKeys Identified Mail) est une signature cryptographique. Votre serveur d'envoi signe chaque message avec une clé privée ; le récepteur récupère la clé publique correspondante dans votre DNS et vérifie la signature. Si elle est valide, deux choses sont prouvées : le message vient bien de votre domaine, et il n'a pas été modifié en route. C'est un contrôle sur l'intégrité du message.

DMARC (Domain-based Message Authentication, Reporting and Conformance) est la couche de décision. Il fait deux choses. D'abord, il vérifie l'alignement : le domaine visible dans le champ « De : » doit correspondre au domaine validé par SPF et/ou DKIM — c'est ce qui empêche un fraudeur d'usurper votre nom même en passant SPF sur son propre domaine. Ensuite, il donne une politique (« que faire si ça échoue ») et demande des rapports pour que vous surveilliez qui envoie en votre nom.

Retenez la hiérarchie : SPF et DKIM sont les deux tests, DMARC est l'arbitre qui exige qu'au moins l'un des deux passe et soit aligné, puis applique votre politique. Configurer SPF et DKIM sans DMARC, c'est installer deux serrures sans jamais fermer la porte.

Où ça se configure

Les trois enregistrements vivent au même endroit : votre zone DNS. C'est l'annuaire technique de votre domaine, hébergé chez celui à qui vous avez acheté le nom (le registrar) ou chez votre hébergeur si vous y avez délégué la gestion DNS. Vous n'y touchez rien dans votre boîte mail ni dans votre outil d'envoi côté interface — tout se joue dans le panneau DNS.

Concrètement, vous y ajoutez des enregistrements de type TXT (pour SPF, DMARC, et souvent DKIM) ou CNAME (pour DKIM chez certains fournisseurs). Chaque enregistrement a un nom (l'hôte : la racine du domaine, un sélecteur, ou _dmarc) et une valeur (le contenu). C'est tout. La difficulté n'est pas technique, elle est dans la rigueur : une virgule au mauvais endroit et la vérification échoue silencieusement.

La configuration pas à pas

Voici la séquence complète, dans l'ordre. Ne sautez pas d'étape, et surtout ne commencez pas par durcir DMARC : on publie d'abord, on observe, on durcit ensuite.

1. Localiser sa zone DNS

   Connectez-vous chez votre registrar ou votre hébergeur et trouvez la section « Zone DNS », « Enregistrements DNS » ou « Gestion DNS ». C'est là que vous verrez déjà des enregistrements existants (souvent un A, un MX, parfois un vieux TXT). Repérez le bouton d'ajout d'enregistrement : vous en aurez besoin trois fois.

2. Publier l'enregistrement SPF

   Ajoutez un unique enregistrement TXT à la racine du domaine (nom : @ ou vide selon l'interface). Sa valeur liste vos sources d'envoi via des directives include, et se termine par une politique. Exemple générique pour un domaine qui envoie via Google :

   Type : TXT
   Nom  : @
   Valeur : v=spf1 include:_spf.google.com ~all

   Le ~all final signifie « softfail » : tout serveur non listé est marqué comme suspect sans être rejeté d'emblée — le bon réglage pour démarrer. Si vous cumulez plusieurs services, fusionnez-les dans le même enregistrement, jamais dans un second : v=spf1 include:_spf.google.com include:servers.example-esp.com ~all.

3. Activer DKIM et publier la clé

   DKIM se génère depuis votre outil d'envoi (messagerie professionnelle, plateforme d'emailing). Activez DKIM dans ses réglages : l'outil crée une paire de clés et vous donne un sélecteur et une clé publique à publier. Selon le fournisseur, c'est un TXT ou un CNAME. Exemple de forme (les valeurs entre crochets vous sont fournies par l'outil) :

   Type : TXT
   Nom  : selecteur1._domainkey
   Valeur : v=DKIM1; k=rsa; p=[clé publique fournie par votre outil d'envoi]

   Ne fabriquez jamais la clé vous-même et ne la retapez pas à la main : copiez-collez exactement ce que l'outil affiche. Une seule casse ou un saut de ligne manquant invalide la signature.

4. Publier un DMARC en observation

   Ajoutez un TXT au nom _dmarc. On démarre en p=none : cette politique ne bloque rien, elle se contente de collecter des rapports. C'est votre phase de reconnaissance.

   Type : TXT
   Nom  : _dmarc
   Valeur : v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr; fo=1

   L'adresse rua reçoit les rapports agrégés quotidiens. Utilisez une adresse que vous relevez réellement, ou une boîte dédiée. Le fo=1 demande un rapport dès qu'un mécanisme échoue.

5. Lire les rapports et cartographier ses sources

   Pendant quelques semaines, vous recevez des rapports XML. Objectif : dresser la liste de toutes vos sources d'envoi légitimes (messagerie, CRM, outil de facturation, plateforme marketing) et vérifier qu'elles passent SPF et/ou DKIM en alignement. Toute source légitime qui échoue doit être corrigée avant de durcir.

6. Durcir progressivement la politique

   Quand vos sources légitimes sont toutes alignées, remontez d'un cran : p=quarantine (les échecs partent en spam), observez encore, puis p=reject (les échecs sont refusés). Vous pouvez durcir en douceur avec pct, qui n'applique la politique qu'à un pourcentage du trafic :

   Valeur : v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@votredomaine.fr

Décoder un rapport DMARC

Les rapports arrivent en deux formats. Les rapports agrégés (RUA), quotidiens, sont ceux qui comptent pour piloter votre configuration : c'est un fichier XML, envoyé par chaque récepteur (Google, Microsoft, etc.), qui résume ce qu'il a vu passer en votre nom. Il ne contient aucun contenu d'email, seulement des statistiques par source.

Sans outil de visualisation, un rapport agrégé est illisible à l'œil, mais on y cherche toujours les mêmes informations pour chaque groupe d'envois : l'adresse IP source, le volume de messages, et surtout le résultat SPF, le résultat DKIM, et l'alignement pour chacun. Schématiquement, une ligne dit :

<record>
  <source_ip>203.0.113.10</source_ip>   <!-- qui a envoyé -->
  <count>42</count>                      <!-- combien de mails -->
  <policy_evaluated>
    <dkim>pass</dkim>                     <!-- DKIM aligné ? -->
    <spf>pass</spf>                       <!-- SPF aligné ? -->
  </policy_evaluated>
</record>

La lecture est simple : pour chaque source, au moins l'un des deux (dkim ou spf) doit être à pass. Une source que vous reconnaissez et qui échoue ? C'est un correctif à faire avant de durcir. Une source que vous ne reconnaissez pas et qui échoue ? C'est soit un outil oublié, soit une tentative d'usurpation — dans les deux cas, votre politique DMARC est en train de faire son travail. La plupart des équipes passent par un service qui transforme ces XML en tableau de bord lisible ; l'important est de comprendre ce que la donnée brute raconte.

Les erreurs fréquentes

La plupart des configurations qui échouent butent sur les trois mêmes pièges. Les connaître, c'est s'épargner des heures de diagnostic.

• Deux enregistrements SPF. C'est l'erreur numéro un : on ajoute un nouveau service et on crée un second v=spf1 au lieu de fusionner. Résultat, la vérification devient invalide. Règle absolue : un seul enregistrement SPF par domaine, on y ajoute des include.
• Dépassement des 10 lookups DNS. SPF autorise au maximum dix résolutions DNS (chaque include en consomme au moins une). Au-delà, la vérification renvoie une erreur permanente et vos emails perdent le bénéfice de SPF. Si vous accumulez les services, il faut « aplatir » l'enregistrement ou en retirer.
• Oublier l'alignement. Passer SPF ou DKIM ne suffit pas pour DMARC : le domaine validé doit s'aligner avec le domaine du champ « De : ». Un email qui passe SPF sur le domaine d'un prestataire mais affiche votre domaine en « De : » échouera à DMARC. C'est souvent ce qui coince avec les outils tiers : il faut configurer un domaine personnalisé côté prestataire pour rétablir l'alignement.

Un dernier réflexe utile : après chaque modification, testez avec un outil de lookup DNS et envoyez-vous un email de test vers une adresse externe pour vérifier les en-têtes d'authentification. Ne vous fiez jamais au seul fait que « l'enregistrement est publié ».

Durcir puis vérifier

Une fois vos trois enregistrements en place et vos sources alignées, la configuration n'est pas figée : elle se surveille. Un nouvel outil qui se met à envoyer en votre nom apparaîtra dans vos rapports ; une clé DKIM peut expirer ou tourner. L'authentification email n'est pas un « je l'ai fait une fois », c'est un socle qu'on entretient.

Et souvenez-vous de l'ordre : ce socle technique conditionne tout le reste de votre prospection. Le meilleur message, la meilleure cible, ne servent à rien si le domaine n'est pas authentifié. Pour la vue d'ensemble, lisez notre guide délivrabilité email : arriver en boîte de réception, et pour la méthode complète d'envoi, le guide du cold email. Si vous automatisez avec un modèle, gardez en tête que l'IA n'améliore pas la délivrabilité — elle ne fait qu'accélérer votre passage en spam quand le socle manque.