SPF, DKIM et DMARC expliqués aux boutiques en ligne

Pourquoi les messageries vérifient ces trois enregistrements#

N’importe qui peut saisir n’importe quelle adresse dans le champ « De » d’un e-mail. SPF, DKIM et DMARC permettent à la messagerie destinataire de savoir si un message qui prétend venir de ninefold.example vient réellement de Ninefold. Chacun est un enregistrement DNS que vous publiez sur votre domaine, et chacun répond à une question différente.

Pour une boutique, l’effet concret est l’arrivée en boîte de réception. Google demande à tous les expéditeurs de configurer SPF ou DKIM, et ceux qui envoient plus de 5 000 messages par jour vers des comptes Gmail personnels doivent disposer de SPF, DKIM et DMARC ^S4. Yahoo fixe le même socle pour ses expéditeurs de masse ^S5. Même en dessous de ces volumes, des e-mails authentifiés construisent la réputation d’expéditeur de votre propre domaine, et un enregistrement DMARC complique beaucoup l’envoi d’e-mails d’hameçonnage en votre nom.

Le rôle de chaque enregistrement#

SPF : les serveurs autorisés à envoyer pour vous

SPF est un enregistrement TXT qui liste les serveurs autorisés à envoyer des e-mails pour un domaine. Le serveur destinataire compare l’adresse IP qui s’est connectée à lui avec cette liste. SPF vérifie l’expéditeur d’enveloppe (l’adresse MAIL FROM utilisée pendant la livraison, qui reçoit aussi les rebonds), et non l’adresse « De » que voit votre client ^S1. Pour une boutique qui utilise une boîte mail professionnelle et un service d’e-mail marketing, un enregistrement type ressemble à ceci :

v=spf1 include:spf.mailbox.example include:spf.mailservice.example ~all

Chaque include ajoute la liste d’un autre fournisseur. La fin indique que faire de tout le reste : -all correspond à un échec, ~all à un échec partiel (softfail), sur lequel les destinataires ne devraient pas fonder à lui seul un rejet ^S1.

DKIM : une signature sur chaque message

DKIM ajoute une signature cryptographique aux en-têtes du message. La signature désigne un domaine signataire (d=) et un sélecteur (s=), et le destinataire récupère la clé publique dans un enregistrement DNS situé à selector._domainkey.domain ^S2. Si les en-têtes signés ou le corps ont été modifiés en chemin, la vérification échoue. Avec DKIM seul, le domaine signataire n’a pas besoin de correspondre à l’adresse « De » ^S2 : c’est précisément pour cela que DMARC existe.

DMARC : la règle qui les relie à votre adresse d’expéditeur visible

DMARC est un enregistrement TXT situé à _dmarc.yourdomain. Il demande aux destinataires de confirmer que SPF ou DKIM a réussi pour un domaine qui correspond à l’adresse « De » visible, leur indique comment traiter les e-mails en échec (none, quarantine ou reject) et précise où envoyer les rapports ^S3. Un premier enregistrement peut se limiter à v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example.

Comment ils fonctionnent ensemble : l’alignement#

SPF et DKIM peuvent tous deux réussir pour le mauvais domaine. Un service marketing peut réussir le contrôle SPF pour son propre domaine de rebond et signer en DKIM en son propre nom, alors que le champ « De » indique ninefold.example. Aucun de ces résultats ne dit quoi que ce soit sur Ninefold.

DMARC comble cette lacune grâce à l’alignement. Un message réussit DMARC lorsque SPF réussit pour un domaine aligné sur le domaine « De », ou lorsque DKIM réussit pour un domaine aligné sur celui-ci ^S3. Par défaut, l’alignement est souple : une signature DKIM de mail.ninefold.example est alignée avec une adresse « De » en ninefold.example ; l’alignement strict exige une correspondance exacte ^S3. Gmail et Yahoo énoncent la même règle pour les expéditeurs de masse : le domaine « De » doit être aligné sur le domaine SPF ou sur le domaine DKIM ^S4S5.

Un DKIM aligné compte davantage qu’un SPF aligné. Lorsqu’un message est transféré, le serveur de transfert se connecte depuis sa propre adresse IP, si bien que le SPF du domaine d’origine échoue souvent ^S1. Une signature DKIM, elle, survit tant que le message n’est pas modifié.

Ce qu’une boutique doit publier#

Avant de toucher au DNS, listez tous les services qui envoient des e-mails avec votre domaine dans l’adresse « De ». Pour une petite marque de vêtements comme Ninefold, il s’agit généralement d’une boîte mail professionnelle, des e-mails de commande et d’expédition de la plateforme e-commerce, d’un outil de support client et d’un outil d’e-mail marketing. Chacun doit être couvert.

1. Un seul enregistrement SPF qui inclut tous les services qui envoient au nom de votre domaine.
2. DKIM activé dans chacun de ces services, avec votre domaine comme domaine signataire. Chaque service vous fournit son propre enregistrement et son propre sélecteur : plusieurs enregistrements DKIM peuvent donc coexister.
3. Un seul enregistrement DMARC, en commençant par p=none avec une adresse de rapport, pour voir qui envoie en votre nom avant d’appliquer quoi que ce soit. Le guide de configuration DMARC détaille le passage à quarantine puis à reject.

L’authentification n’est qu’une partie de ce qu’attendent les messageries. Elles examinent aussi la désinscription en un clic et votre taux de plaintes pour spam ; le guide des bases de la délivrabilité couvre le reste.

Les erreurs fréquentes#

• Deux enregistrements SPF. Un domaine ne peut avoir qu’un seul enregistrement commençant par v=spf1 ; avec deux, SPF renvoie une erreur permanente pour chaque message ^S1. Fusionnez-les en un seul.
• Trop de requêtes DNS. Chaque include, a, mx, ptr, exists et redirect coûte une requête DNS, et SPF s’arrête sur une erreur au-delà de 10 ^S1. Retirez les services que vous n’utilisez plus au lieu d’empiler les includes.
• DKIM signé avec le domaine du fournisseur. La signature réussit, mais elle n’est pas alignée sur votre adresse « De ». Configurez DKIM sur votre propre domaine dans chaque outil.
• Passer directement à p=reject. Un expéditeur oublié, comme les e-mails de confirmation de commande de votre plateforme e-commerce, se met à échouer sans bruit. Commencez par p=none et lisez d’abord les rapports.
• Aucune adresse de rapport. Un enregistrement DMARC sans rua ne vous donne aucune donnée exploitable. Yahoo recommande vivement une balise rua fonctionnelle pendant la configuration ^S5.

Comment vérifier vos enregistrements#

Une requête DNS vous montre ce qui est publié, et la lecture d’un vrai message vous montre ce que les destinataires ont réellement vu.

• Depuis un terminal : dig +short TXT ninefold.example affiche l’enregistrement SPF, dig +short TXT _dmarc.ninefold.example affiche DMARC, et dig +short TXT selector._domainkey.ninefold.example affiche une clé DKIM une fois le sélecteur connu.
• Depuis un navigateur : n’importe quel outil de recherche DNS qui interroge les enregistrements TXT donne les mêmes réponses.
• Depuis un vrai message : envoyez un test à une adresse Gmail, ouvrez-le, choisissez Plus, puis Afficher l’original ^S6. L’en-tête indique un résultat SPF, DKIM et DMARC pour ce message, ainsi que les domaines pour lesquels chacun a réussi.

DMARC relève désormais du processus de normalisation de l’IETF (standards track) : la RFC 9989, publiée en mai 2026, remplace la RFC 7489 ^S3S7. Les enregistrements commencent toujours par v=DMARC1 : un enregistrement rédigé selon les anciennes règles continue donc de fonctionner ^S3.

Configurer l’authentification avec Tellnod dans Claude ou ChatGPT#

Tellnod est un connecteur MCP qui permet de rédiger, prévisualiser et envoyer des e-mails marketing depuis Claude ou ChatGPT. Vous pouvez envoyer dès le premier jour depuis une adresse au nom de votre boutique sur le domaine partagé de Tellnod, par exemple hello@yourshop.tellnodmail.com, sans modifier votre DNS, dans la limite de 500 destinataires par campagne et de 1 000 e-mails par mois. Vérifier votre propre domaine lève ces limites ; c’est la configuration que nous recommandons.

Pour vérifier votre domaine, demandez-le dans la conversation, par exemple : « Configure ninefold.example comme domaine d’envoi. » Tellnod vous fournit les enregistrements SPF, DKIM et DMARC et les vérifie pour vous. Si quelqu’un d’autre gère votre DNS, demandez : « Crée un lien de configuration pour notre développeur web. » Cette personne peut ajouter les enregistrements en un clic chez les fournisseurs DNS compatibles, ou les copier, sans créer de compte, et vous êtes prévenu dans la conversation et par e-mail dès que le domaine est vérifié. Les modifications DNS prennent généralement quelques minutes, mais peuvent demander jusqu’à 48 heures.

L’authentification ne change rien au fonctionnement de l’envoi : chaque campagne affiche un aperçu sur ordinateur et sur mobile, et rien ne part tant que vous n’avez pas cliqué sur Confirm sur la carte de confirmation. Pour commencer, connectez Tellnod à Claude ou ChatGPT ; la page des tarifs présente l’offre gratuite et les offres payantes.

Questions fréquentes#