SPF, DKIM et DMARC : configurer son domaine contre le spam

Un e-mail légitime qui finit en spam peut venir d'un domaine dont l'authentification est absente ou mal configurée. SPF, DKIM et DMARC sont trois enregistrements DNS (l'annuaire qui publie les informations d'un domaine) qui permettent au serveur destinataire de vérifier que votre message vient bien de vous. Vous saurez quoi publier, dans quel ordre, comment vérifier et comment durcir la politique sans bloquer vos propres messages.

En bref

• SPF liste les serveurs autorisés à envoyer pour votre domaine. DKIM signe chaque message avec une clé dont la partie publique est dans le DNS. DMARC exige qu'au moins l'un des deux réussisse et soit « aligné » avec l'adresse visible, et indique quoi faire en cas d'échec.
• Ordre conseillé : SPF, DKIM, DMARC en p=none, lecture des rapports, quarantine, puis reject.
• Un seul SPF par domaine, et pas plus de 10 requêtes DNS pendant son évaluation.
• Depuis mai 2026, DMARC est défini par la RFC 9989, qui remplace la RFC 7489 et supprime le tag pct.
• Gmail et Yahoo exigent SPF ou DKIM de tous depuis février 2024, et les trois mécanismes pour les gros volumes.

Pourquoi vos e-mails arrivent en spam

Le protocole d'envoi d'e-mails (SMTP) ne vérifie pas que l'expéditeur a le droit d'utiliser le domaine qu'il affiche. Les messageries s'appuient donc sur trois contrôles et les messages non authentifiés « peuvent être marqués comme spam ou rejetés avec une erreur 5.7.26 » selon Google. L'authentification est nécessaire mais pas suffisante : la réputation de l'adresse IP et le taux de plaintes comptent aussi.

Ce que fait chaque mécanisme

L'enveloppe (MAIL FROM) est l'adresse de retour utilisée entre serveurs, invisible pour le lecteur ; l'adresse From est celle qu'il voit. SPF contrôle la première, pas la seconde : n'importe quel domaine peut publier un SPF valide pour lui-même. C'est DMARC qui relie le résultat à l'adresse visible, par l'alignement.

La RFC 9989, publiée en mai 2026, remplace la RFC 7489 (et la RFC 9091) ; plusieurs conseils répandus ont changé, notamment sur pct.

Prérequis

• Un accès à la zone DNS de votre domaine. Les trois enregistrements sont de type TXT (un champ de texte du DNS). Si votre interface propose un vrai type d'enregistrement « SPF » (type 99), préférez TXT : la RFC 7208 indique que ce type alternatif a été abandonné. Un assistant SPF qui crée lui-même un TXT convient.
• Les exemples ci-dessous sont en syntaxe de fichier de zone. Dans les champs « Nom » et « Valeur » d'une interface, saisissez @ (ou rien) pour le SPF, mail._domainkey pour le DKIM et _dmarc pour DMARC, valeurs sans guillemets. Si l'interface ajoute le domaine seule, ne le répétez pas.
• La liste de tout ce qui envoie des e-mails avec votre domaine : messagerie, outil de newsletter, facturation, CRM, formulaire de contact du site. Un oubli ici finira en spam.
• Si votre serveur de messagerie tourne sur un VPS (voir se connecter en SSH à un VPS), le port 25 sortant (celui du courrier entre serveurs) doit être ouvert et le DNS inverse (PTR) valide, car Gmail l'exige. Le PTR se règle chez l'hébergeur de l'IP, pas dans votre zone DNS. Certains hébergeurs, comme OVHcloud, bloquent le port 25 par défaut et recommandent le port 587. Ce port sert à relayer vos envois par un service SMTP authentifié (dont l'include ira dans le SPF) et ne remplace pas le port 25 entre serveurs : pour envoyer directement, demandez le déblocage.

1. Publier le SPF

Lancez d'abord dig TXT exemple.fr +short ou nslookup -type=TXT exemple.fr. Si une ligne v=spf1 existe, notez-la et modifiez-la au lieu d'en créer une seconde, en gardant ses include et ses ip4. Sinon, créez un seul enregistrement TXT à la racine du domaine :

exemple.fr.   TXT   "v=spf1 mx include:_spf.google.com ip4:203.0.113.10 ~all"

Lecture, de gauche à droite :

• v=spf1 : version, obligatoire et placée en premier.
• mx : autorise les serveurs désignés par les enregistrements MX du domaine (ceux qui reçoivent son courrier).
• include:_spf.google.com : reprend la liste d'un tiers (ici Google). Utilisez l'include de votre prestataire.
• ip4:203.0.113.10 (ou ip6:) : autorise directement une adresse IP, par exemple celle de votre serveur.
• ~all : règle finale pour tout le reste. ~ (softfail) est une déclaration faible (l'expéditeur « n'est probablement pas autorisé »), -all (fail) est plus ferme. Gardez ~all au départ : avec -all, un message qui échoue, transféré compris, peut être refusé dès la réception.

Cet exemple est à adapter : gardez include:_spf.google.com seulement si vous envoyez via Google, et remplacez 203.0.113.10, adresse d'exemple, par l'IP de votre serveur.

Chaque include, a, mx, ptr, exists et chaque redirect consomme une requête DNS, et la RFC 7208 limite le total à 10 : au-delà, le résultat est permerror (une erreur permanente, donc un échec). ip4, ip6 et all n'en consomment aucune ; les include imbriqués comptent. L'exemple en utilise 2. Le mécanisme ptr est marqué « do not use » par la RFC 7208 : retirez-le d'un vieux SPF.

2. Activer DKIM

DKIM utilise une paire de clés. La clé privée reste sur le serveur qui envoie et signe chaque message ; la clé publique est publiée en TXT sous un nom construit à partir d'un sélecteur, un nom libre qui permet d'avoir plusieurs clés en parallèle. Avec le sélecteur mail et le domaine exemple.fr, le destinataire interroge mail._domainkey.exemple.fr : le sélecteur est le s= de la signature, le domaine son d=.

Avec une messagerie hébergée ou un service d'envoi, le service affiche le sélecteur et la valeur : copiez-les, le reste de cette section ne vous concerne pas. Avec votre propre serveur Postfix et OpenDKIM sous Debian 13 ou Ubuntu 24.04, créez une clé de 2048 bits (-b 2048 est déjà la valeur par défaut sous Debian) dans un dossier dédié :

sudo apt install opendkim opendkim-tools
sudo mkdir -p /etc/opendkim/keys/exemple.fr && cd /etc/opendkim/keys/exemple.fr
sudo opendkim-genkey -b 2048 -d exemple.fr -s mail
sudo chown opendkim:opendkim mail.private && sudo chmod 600 mail.private

Si une clé existe déjà, prenez un nouveau sélecteur (par exemple 2026a) pour ne pas écraser celle en service. La commande crée mail.private (clé privée, à garder secrète) et mail.txt. Ce fichier contient l'enregistrement TXT en syntaxe de fichier de zone, avec une valeur découpée en plusieurs chaînes entre guillemets. Publiez la valeur sans guillemets, parenthèses ni commentaire, de cette forme (clé tronquée) :

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Avec 2048 bits, la valeur dépasse 255 caractères, limite d'une chaîne TXT : certaines interfaces la découpent seules, sinon publiez-la en plusieurs chaînes entre guillemets, que le destinataire concatène (RFC 6376, section 3.6.2.2). Il reste à déclarer la clé dans la configuration d'OpenDKIM (tables KeyTable et SigningTable) et à le brancher sur Postfix par un milter (un filtre qui signe les messages sortants), selon sa documentation. Vérifiez ensuite dkim=pass au test de bout en bout, avant DMARC.

v=DKIM1 doit être le premier tag, k=rsa le type de clé, p= la clé publique en base64 (un codage en texte). Un p= vide signifie que la clé est révoquée.

Taille : la RFC 6376 impose au moins 1024 bits aux clés durables ; Gmail exige « 1024 bits ou plus » et recommande 2048, Yahoo demande 1024 au minimum. Préférez 2048 si votre fournisseur DNS l'accepte.

3. Publier DMARC en mode observation

Quand SPF et DKIM fonctionnent (spf=pass et dkim=pass au test de bout en bout), publiez DMARC sans rien bloquer. Créez d'abord la boîte dmarc@exemple.fr : une adresse d'un autre domaine doit autoriser la réception de vos rapports.

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

• p= : la politique demandée en cas d'échec. none : observation seule. quarantine : message jugé suspect (en pratique, dossier spam). reject : l'échec est traité comme un usage non valide du domaine, le message est refusé.
• rua=mailto: : l'adresse qui reçoit les rapports agrégés, des statistiques envoyées par les messageries sur les messages vus en votre nom, avec leur résultat SPF et DKIM. La RFC demande aux récepteurs d'en envoyer au moins un par jour. Ces rapports sont des fichiers XML, souvent compressés : n'y mettez pas votre boîte principale et lisez-les avec un outil gratuit de rapports DMARC.
• sp= (facultatif) : politique des sous-domaines (la RFC 9989 intègre np pour ceux qui n'existent pas, issu de la RFC 9091). adkim= et aspf= : alignement r (relaxed, par défaut) ou s (strict).

Un message réussit DMARC si le domaine de l'adresse From est aligné avec une identité authentifiée : le domaine de l'enveloppe validé par SPF, ou le domaine d= d'une signature DKIM valide. En mode relaxed, le même domaine organisationnel (le domaine que vous avez enregistré, sans ses sous-domaines) suffit : mail.exemple.fr est aligné avec exemple.fr ; en mode strict, les domaines doivent être identiques.

Un SPF ou un DKIM « valide » ne suffit donc pas : un message signé par une plateforme tierce, avec un From sur votre domaine, échoue à DMARC tant que la signature n'est pas faite avec votre propre domaine. Dans le service tiers, cherchez l'option d'authentification de domaine (ou de DKIM personnalisé), publiez les enregistrements fournis (des TXT, ou des CNAME, des alias qui renvoient vers le DNS du service), puis vérifiez que dkim= affiche header.d=exemple.fr.

Vérifier que tout fonctionne

Après avoir enregistré les TXT, laissez passer le temps de propagation DNS. Un nom interrogé avant sa publication peut rester vide dans le cache de votre résolveur : interrogez alors le serveur DNS du domaine (dig NS exemple.fr +short donne son nom, puis dig TXT _dmarc.exemple.fr @ns1.hebergeur.tld).

Sous Windows, nslookup est déjà installé. Voici le résultat pour gmail.com au 9 octobre 2026, avec le nom et l'adresse du résolveur masqués (les libellés changent selon la langue de Windows) :

nslookup -type=TXT gmail.com

Réponse ne faisant pas autorité :
Serveur :   <résolveur masqué>
Address:  <adresse masquée>

gmail.com	text =

	"v=spf1 redirect=_spf.google.com"
gmail.com	text =

	"yahoo-verification-key=dKYwfVbaxatmcXiXy6LDAxMRirqpOq5tj98iJv9qWVk="
gmail.com	text =

	"yahoo-verification-key=+eZwIPSgRxkAUzDtqT8Qhk+j4A1JF6V/wtGoyGTkELY="
gmail.com	text =

	"globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="

« Réponse ne faisant pas autorité » signifie que la réponse vient d'un résolveur (en général son cache) et non du serveur DNS faisant autorité. Plusieurs TXT peuvent coexister sur un même nom, mais un seul doit commencer par v=spf1. Ici, redirect= reporte toute la politique SPF sur _spf.google.com.

Pour DMARC, interrogez le nom _dmarc :

nslookup -type=TXT _dmarc.gmail.com

Réponse ne faisant pas autorité :
Serveur :   <résolveur masqué>
Address:  <adresse masquée>

_dmarc.gmail.com	text =

	"v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"

Pour DKIM, interrogez de même selecteur._domainkey.exemple.fr : il faut connaître le sélecteur.

Sous Linux et macOS, les mêmes questions se posent avec dig (paquet bind9-dnsutils sous Debian et Ubuntu, bind-utils sous Fedora, RHEL et Rocky Linux). L'option +short n'affiche que les valeurs :

dig TXT exemple.fr +short
dig TXT _dmarc.exemple.fr +short
dig TXT mail._domainkey.exemple.fr +short

La première affiche tous les TXT du domaine (dont le SPF), la deuxième la politique DMARC. Une réponse vide pour _dmarc signifie en général qu'aucun DMARC n'est publié, sauf cache négatif récent (voir plus haut).

Test de bout en bout : envoyez un message vers une adresse Gmail, ouvrez-le, puis choisissez « Plus » puis « Afficher l'original » (aide Gmail). Dans les en-têtes, cherchez la ligne Authentication-Results, au format de la RFC 8601 : elle indique le résultat de chaque contrôle (spf=, dkim=, dmarc=).

Monter la politique DMARC par paliers

Ne passez jamais directement à p=reject : une source oubliée verrait tous ses messages refusés. Avant chaque changement, notez l'ancienne valeur pour revenir à p=none si besoin, baissez le TTL (la durée de cache) de _dmarc à 300 secondes la veille, et listez les sous-domaines qui envoient (newsletter, support) : ils suivent p= sauf si sp= dit autre chose.

1. p=none, avec rua. Lisez les rapports pour repérer chaque source qui envoie en votre nom et corrigez les sources légitimes en échec (SPF, surtout DKIM aligné). La RFC 9989 prévient que cela peut prendre « de nombreux mois » de rapports : attendez au moins un cycle complet de vos envois, facturation mensuelle comprise.
2. p=quarantine une fois les rapports propres : les échecs vont en spam au lieu d'être refusés. Relisez les rapports avant de continuer.
3. p=reject, la cible, quand la quarantaine n'a plus révélé de source légitime en échec. Le rejet peut casser les listes de diffusion et les transferts (voir « Problèmes fréquents »), et la RFC 9989 (section 7.4) déconseille (« SHOULD NOT ») p=reject aux domaines dont les utilisateurs écrivent à des listes de diffusion.

_dmarc.exemple.fr.   TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr"

Et le tag pct ? Les anciens guides font monter pct de 10 à 100. La RFC 9989 l'a supprimé et le registre IANA des tags DMARC le marque « historic » : il n'était appliqué avec exactitude que pour 0 et 100. Il est remplacé par t, avec t=y (test) et t=n (par défaut). Un enregistrement hérité contenant pct=10 peut donc être appliqué à 100 % par un récepteur qui suit la nouvelle norme. Le vrai filet de sécurité reste l'observation en p=none.

Ce que publient de grands domaines

Relevé du 9 octobre 2026 via le DNS en HTTPS de Google : gmail.com et debian.org publient p=none, github.com p=quarantine, yahoo.com et wikipedia.org p=reject. Le p=none n'est donc pas un échec.

example.com publie le SPF v=spf1 -all (aucun serveur autorisé) et un DMARC p=reject; sp=reject; adkim=s; aspf=s. Ne publiez ceci que sur un domaine qui n'envoie et ne reçoit aucun e-mail (vérifiez formulaires, alias, applications), après avoir noté l'ancien SPF et l'ancien DMARC ; sur un domaine actif, restez sur la montée par paliers. La RFC 7208 prévoit ce SPF pour un domaine qui n'envoie pas d'e-mail. Si le domaine ne reçoit rien non plus, un MX nul (valeur 0 .) le signale.

Les exigences de Gmail, Yahoo et Microsoft

Au 9 octobre 2026, d'après les pages officielles :