SPF, DKIM et DMARC : comment configurer l’envoi de sa newsletter pas à pas

Une newsletter peut être bien écrite, attendue par ses abonnés et pourtant finir dans les courriers indésirables. Souvent, la cause n’est ni le texte ni la mise en page : c’est l’identité de l’expéditeur, que les messageries ne parviennent pas à vérifier. Trois enregistrements DNS servent à la prouver : SPF, DKIM et DMARC.

Ce guide explique comment configurer SPF, DKIM et DMARC pour une newsletter, dans l’ordre où il faut le faire, avec des enregistrements commentés sur un domaine fictif, exemple.fr. Il s’adresse aux éditeurs, aux boutiques et aux PME qui envoient depuis un outil d’emailing et veulent comprendre ce qu’ils publient dans leur zone DNS.

Feuillet 01Pourquoi l’authentification décide de l’arrivée en boîte de réception

Le courrier électronique est né à une époque où personne n’imaginait l’usurpation à grande échelle : n’importe quel serveur peut écrire n’importe quelle adresse dans le champ « De ». Avant d’examiner le contenu, elles se demandent si le message vient vraiment du domaine annoncé. Sans authentification, la réponse est « on ne sait pas », et le doute se paie en filtrage.

Depuis février 2024, Google et Yahoo exigent des expéditeurs en volume (au-delà d’environ 5 000 messages par jour vers des adresses Gmail, selon les consignes de Google) un domaine authentifié par SPF et DKIM, une politique DMARC publiée, un domaine visible aligné, la désinscription en un clic pour les messages marketing et un taux de plaintes maintenu bas. Microsoft a annoncé des exigences comparables en 2025. Même pour une liste modeste, ces règles décrivent ce que les filtres attendent d’un expéditeur sérieux.

Feuillet 02SPF : déclarer qui a le droit d’envoyer pour votre domaine

SPF (Sender Policy Framework) est un enregistrement TXT qui liste les serveurs et les services autorisés à envoyer des emails au nom de votre domaine. Le serveur destinataire lit l’adresse technique d’expédition, celle de l’enveloppe (le Return-Path), puis vérifie que l’adresse IP émettrice figure dans la liste publiée par ce domaine.

exemple.fr.   TXT   "v=spf1 include:_spf.google.com include:spf.emailing.example ~all"

• v=spf1 : la version, toujours en tête de ligne.
• include: : la délégation à un service qui publie ses propres serveurs, ici la messagerie de l’équipe et l’outil d’emailing.
• ~all : tout le reste échoue « en douceur », alors que -all demande un rejet franc. Avec DMARC en place, c’est DMARC qui tranche.

Deux règles évitent l’essentiel des ennuis. Un domaine ne doit porter qu’un seul enregistrement SPF : avec deux lignes, la vérification échoue purement et simplement. Et l’évaluation est limitée à dix recherches DNS, chaque include, a ou mx en consommant au moins une ; au-delà, SPF renvoie une erreur permanente. Retirez donc les services abandonnés avant d’en ajouter.

Attention enfin : SPF vérifie le domaine de l’enveloppe, pas celui que voit le lecteur. Si votre outil d’emailing utilise son propre domaine comme Return-Path, SPF réussit, mais pour lui. C’est l’alignement, présenté plus bas, qui règle cette question.

Feuillet 03DKIM : signer chaque envoi

DKIM (DomainKeys Identified Mail) ajoute à chaque message une signature cryptographique, dans un en-tête DKIM-Signature. Votre outil signe avec une clé privée ; la clé publique est publiée dans votre DNS, sous un nom construit à partir d’un sélecteur. Le destinataire la récupère, vérifie la signature et s’assure que le message n’a pas été modifié en route.

s1._domainkey.exemple.fr.   CNAME   s1.dkim.emailing.example.
s2._domainkey.exemple.fr.   CNAME   s2.dkim.emailing.example.

La plupart des outils proposent, comme ici, des CNAME qui pointent vers des clés qu’ils hébergent : ils peuvent ainsi les renouveler sans que vous touchiez à votre zone. D’autres fournissent une clé publique à coller dans un TXT de la forme v=DKIM1; k=rsa; p= suivie d’une longue chaîne. Préférez alors une clé de 2 048 bits et vérifiez que la valeur n’a pas été tronquée au copier-coller, une cause d’échec très banale.

Chaque service peut avoir sa propre clé, sous un sélecteur différent. Ce qui compte pour la suite, c’est la valeur d= de la signature, le domaine au nom duquel le message est signé : si elle vaut emailing.example et non exemple.fr, DKIM réussit, mais toujours pas pour vous.

Feuillet 04DMARC : la règle qui relie SPF et DKIM à votre domaine

DMARC est un enregistrement TXT publié à une adresse précise, _dmarc.exemple.fr. Il exige qu’au moins un des deux contrôles réussisse et soit aligné sur le domaine du champ « De », indique la politique à appliquer en cas d’échec et demande l’envoi de rapports.

_dmarc.exemple.fr.   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr; adkim=r; aspf=r"

• p= : la politique. none observe sans bloquer, quarantine dirige les échecs vers les indésirables, reject les refuse.
• rua= : l’adresse des rapports agrégés, des fichiers XML quotidiens qui listent, source par source, les messages envoyés en votre nom et leurs résultats.
• adkim=r et aspf=r : l’alignement relâché, qui accepte un sous-domaine. Un message signé par news.exemple.fr est aligné avec un champ « De » en exemple.fr.
• sp=, facultatif : une politique propre aux sous-domaines, qui sinon héritent de celle du domaine principal.

Un message passe DMARC si SPF réussit sur un domaine d’enveloppe aligné, ou si DKIM réussit avec une signature d= alignée : un seul des deux suffit. En pratique, DKIM est le pilier le plus solide, car il survit aux transferts, là où SPF échoue dès qu’un message est réacheminé.

Feuillet 05Configurer SPF, DKIM et DMARC pour une newsletter envoyée depuis votre domaine

Une newsletter doit partir d’une adresse de votre domaine, par exemple lettre@exemple.fr, jamais d’une messagerie gratuite, dont les politiques DMARC interdisent l’envoi en son nom par un service tiers. Beaucoup d’éditeurs choisissent un sous-domaine dédié, comme news.exemple.fr, pour séparer en partie la réputation des envois marketing de celle des emails de l’équipe.

Étape par étape dans votre outil d’emailing

1. Inventoriez tout ce qui envoie au nom de votre domaine : messagerie de l’équipe, outil de newsletter, boutique, facturation, CRM, formulaires du site.
2. Dans l’outil d’emailing, ouvrez la rubrique d’authentification du domaine et déclarez votre domaine ou le sous-domaine choisi.
3. Publiez les enregistrements fournis : en général deux ou trois CNAME pour DKIM et un enregistrement pour le domaine de rebond personnalisé, qui aligne SPF. Si l’outil demande un include, modifiez la ligne SPF existante.
4. Laissez passer la propagation (de quelques minutes à quelques heures selon le TTL), puis lancez la vérification.
5. Publiez l’enregistrement DMARC en p=none avec une adresse rua.
6. Envoyez un test vers une boîte personnelle et affichez le message original : l’en-tête Authentication-Results doit indiquer spf=pass, dkim=pass avec header.d=exemple.fr, et dmarc=pass.

Contrôlez aussi la désinscription : pour les envois marketing, les grandes messageries attendent les en-têtes List-Unsubscribe et List-Unsubscribe-Post, qui permettent la désinscription en un clic. La plupart des outils les ajoutent d’office ; vérifiez qu’ils sont actifs.

Durcir la politique DMARC par paliers grâce aux rapports

La politique p=none ne protège rien : elle sert à observer. Pendant quelques semaines, lisez les rapports agrégés avec un outil d’analyse DMARC, car le XML brut se lit mal. Trois cas apparaissent : les sources légitimes et alignées, à laisser telles quelles ; les sources légitimes en échec (un outil oublié, un sous-domaine non signé), à corriger ; les sources inconnues, souvent des usurpations, que la politique finira par bloquer.

Quand toutes les sources légitimes passent, montez à p=quarantine, observez de nouveau, puis passez à p=reject. Ne retirez jamais l’adresse rua : chaque nouvel outil devra être authentifié avant son premier envoi, et les rapports vous le rappelleront. Si ces rapports arrivent sur un autre domaine, celui-ci doit publier une autorisation dédiée, faute de quoi rien ne vous parviendra.

Feuillet 06Check-list et erreurs de configuration les plus fréquentes

La check-list avant le prochain envoi

• L’adresse d’expédition utilise votre domaine ou un sous-domaine dédié.
• Un seul enregistrement SPF, sous dix recherches DNS, qui couvre tous les services.
• Une signature DKIM active pour chaque outil, avec d= sur votre domaine.
• Un domaine de rebond personnalisé, pour que SPF soit aligné lui aussi.
• Un enregistrement DMARC sur _dmarc, avec une adresse rua qui reçoit bien les rapports.
• Des rapports relus, sans source légitime en échec.
• La désinscription en un clic active.
• Un test dont l’en-tête affiche spf=pass, dkim=pass et dmarc=pass.

Une version à cocher de cette liste vous attend sur l’accueil : la check-list délivrabilité interactive.

Les erreurs les plus fréquentes

Courrier des lecteursQuestions fréquentes sur SPF, DKIM et DMARC

Post-scriptumEn résumé : un domaine qui signe ses lettres

Configurer SPF, DKIM et DMARC pour une newsletter revient à apposer un cachet que les messageries savent lire : SPF dit qui a le droit d’envoyer, DKIM signe chaque message, DMARC vérifie que tout cela correspond à votre domaine. Commencez par l’inventaire, publiez les enregistrements de votre outil, observez les rapports, puis durcissez par paliers.

Ce socle posé, la délivrabilité se joue sur la qualité de la liste : c’est l’objet de la lettre sur les moyens de réactiver ou nettoyer les abonnés inactifs.