SPF, DKIM et DMARC : les trois enregistrements qui sauvent vos emails

Configuration des enregistrements DNS de type TXT pour l'authentification des emails

À la une

SPF, DKIM et DMARC sont trois enregistrements DNS de type TXT qui permettent aux serveurs de réception de vérifier qu’un email provient bien d’un expéditeur autorisé. Sans eux, les messages légitimes envoyés depuis un nom de domaine risquent d’atterrir en spam, voire d’être rejetés silencieusement par les fournisseurs de messagerie comme Gmail, Outlook ou Yahoo.

Depuis février 2024, Google exige que tout expéditeur de plus de 5 000 messages par jour dispose des trois protocoles configurés sur son domaine. Yahoo applique des règles similaires. On le verra plus bas, la mise en place reste accessible à quiconque sait ajouter un enregistrement DNS.

Sommaire

C’est quoi SPF, DKIM et DMARC ?
SPF : déclarer les serveurs autorisés à envoyer pour votre domaine
DKIM : signer chaque message avec une clé cryptographique
DMARC : la politique qui décide du sort des emails non conformes
Configurer les trois en pratique : l’ordre et la syntaxe
Vérifier que tout fonctionne : outils et erreurs courantes

C’est quoi SPF, DKIM et DMARC ?

Ces trois sigles désignent des mécanismes d’authentification du courrier électronique, chacun agissant à un niveau différent. SPF (Sender Policy Framework) indique quels serveurs ont le droit d’envoyer des emails au nom d’un domaine. DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque message pour garantir qu’il n’a pas été altéré en transit. DMARC (Domain-based Message Authentication, Reporting and Conformance) réunit les deux précédents et fixe une politique : accepter, quarantiner ou rejeter les messages qui échouent aux vérifications.

Les trois fonctionnent ensemble. Un domaine qui ne configure que SPF sans DKIM laisse la porte ouverte à l’usurpation par modification du contenu. Un domaine qui active DKIM sans SPF permet à n’importe quel serveur d’expédier en son nom. DMARC, lui, n’a aucun sens sans au moins l’un des deux autres puisqu’il s’appuie sur leurs résultats pour prendre sa décision. Le RFC 7489 publié par l’IETF définit le fonctionnement de DMARC et son articulation avec SPF et DKIM.

SPF : déclarer les serveurs autorisés à envoyer pour votre domaine

Comment configurer un SPF ? Il suffit d’ajouter un enregistrement DNS de type TXT à la racine du domaine. Cet enregistrement liste les adresses IP ou les noms d’hôtes autorisés à expédier du courrier pour ce domaine. Un serveur de réception qui reçoit un email consulte le SPF du domaine expéditeur, compare l’IP d’envoi à la liste, puis décide.

Voici la syntaxe d’un enregistrement SPF classique :

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.5 -all

Le mécanisme include délègue la vérification aux serveurs du prestataire cité. Le mécanisme ip4 autorise une adresse IP précise. La directive finale -all (avec le tiret) signifie que tout serveur non listé est explicitement refusé. Avec ~all (tilde), les messages non conformes sont marqués comme suspects mais pas rejetés. La première option offre une protection plus stricte.

Deux contraintes techniques à connaître : un enregistrement SPF ne doit pas dépasser 10 recherches DNS (lookups). Chaque include en consomme au moins une. Au-delà, le SPF est invalide et les serveurs le traitent comme un échec. Par ailleurs, un seul enregistrement SPF par domaine est autorisé. Si le domaine en contient deux, les deux sont ignorés. Pour les domaines hébergés chez un prestataire classique, l’enregistrement fourni dans la documentation de l’hébergeur couvre la plupart des cas, comme détaillé dans le guide des enregistrements DNS A, CNAME, MX et TXT.

Voir aussi Avec ou sans www : le choix importe moins que la cohérence

DKIM : signer chaque message avec une clé cryptographique

Comment configurer le DKIM ? Le principe repose sur une paire de clés asymétriques. Le serveur d’envoi signe l’en-tête et le corps du message avec une clé privée. Le serveur de réception récupère la clé publique via un enregistrement DNS de type TXT, puis vérifie la signature. Si le contenu a été modifié entre l’envoi et la réception, la vérification échoue.

L’enregistrement DNS DKIM se place sur un sous-domaine dont le nom suit le format selecteur._domainkey.example.fr. Le sélecteur est une chaîne libre choisie par l’administrateur ou imposée par le fournisseur de messagerie. Exemple d’enregistrement :

google._domainkey.example.fr  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

La valeur du champ p= contient la clé publique encodée en base64. La longueur recommandée est de 2048 bits au minimum. Les clés de 1024 bits, encore acceptées, sont considérées comme vulnérables par la communauté de sécurité depuis plusieurs années.

Chez la plupart des hébergeurs web et des fournisseurs de messagerie professionnelle, la clé DKIM est générée automatiquement. Il reste à copier l’enregistrement fourni dans la zone DNS du domaine. Quiconque utilise une adresse email liée à son propre nom de domaine doit s’assurer que cet enregistrement est bien en place. La propagation DNS peut prendre quelques heures après l’ajout.

DMARC : la politique qui décide du sort des emails non conformes

Comment configurer un DMARC ? L’enregistrement DMARC est un TXT placé sur le sous-domaine _dmarc.example.fr. Il définit ce que le serveur de réception doit faire quand un message échoue à la fois au contrôle SPF et au contrôle DKIM (ou plus précisément, quand l’alignement entre le domaine vérifié et le domaine visible dans le champ From échoue).

Un enregistrement DMARC de départ ressemble à ceci :

_dmarc.example.fr  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

Balise	Valeurs possibles	Effet
p (policy)	none, quarantine, reject	none : surveille sans bloquer. quarantine : place en spam. reject : refuse le message.
rua	adresse mailto	Adresse qui reçoit les rapports agrégés quotidiens au format XML.
ruf	adresse mailto	Adresse qui reçoit les rapports forensiques (détails message par message). Peu de fournisseurs les envoient.
pct	1 à 100	Pourcentage de messages soumis à la politique. Permet un déploiement progressif.
adkim	r (relaxed) ou s (strict)	Alignement DKIM. En mode strict, le domaine de la signature doit correspondre exactement au domaine From.
aspf	r (relaxed) ou s (strict)	Alignement SPF. Même logique que pour DKIM.

Commencer avec p=none pendant quelques semaines permet de recevoir les rapports sans risquer de bloquer des messages légitimes. Ces rapports révèlent les sources d’envoi réelles du domaine : outil de newsletter, CRM, plateforme transactionnelle. Une fois toutes les sources identifiées et couvertes par SPF et DKIM, la politique passe à quarantine puis à reject.

Configurer les trois en pratique : l’ordre et la syntaxe

L’ordre recommandé est toujours le même. D’abord SPF, parce que c’est l’enregistrement le plus simple à poser et le plus rapide à vérifier. Ensuite DKIM, qui demande de récupérer la clé publique auprès du fournisseur de messagerie. Enfin DMARC, qui n’a de sens qu’une fois les deux premiers actifs.

Quelques points de vigilance pratiques :

Un domaine qui envoie via plusieurs services (hébergeur web, messagerie professionnelle, outil marketing) doit tous les inclure dans le SPF et disposer d’une signature DKIM pour chacun.
Les sous-domaines héritent de la politique DMARC du domaine parent, sauf si un enregistrement DMARC spécifique est posé sur le sous-domaine. La balise sp= dans l’enregistrement parent permet de définir une politique différente pour les sous-domaines.
Ne jamais oublier le point-virgule entre chaque balise DMARC. Une erreur de syntaxe rend l’enregistrement entier invalide.
Les modifications DNS prennent effet après propagation. Le délai varie de quelques minutes à 48 heures selon le TTL en place, comme expliqué dans l’article sur la propagation DNS.

Pour les utilisateurs de Microsoft 365 ou Google Workspace, la documentation officielle de chaque plateforme fournit les valeurs exactes à copier. Ces valeurs changent rarement, mais vérifier la documentation à jour reste préférable à recopier un tutoriel ancien.

Vérifier que tout fonctionne : outils et erreurs courantes

Une fois les trois enregistrements posés, comment s’assurer qu’ils sont corrects ? Plusieurs outils en ligne permettent d’interroger la zone DNS et de simuler une vérification. MXToolbox analyse SPF, DKIM et DMARC en quelques secondes. L’outil affiche les erreurs de syntaxe, le nombre de lookups DNS du SPF et la validité de la clé DKIM.

Les erreurs les plus fréquentes :

Deux enregistrements SPF sur le même domaine. Résultat : les deux sont invalides. La solution consiste à fusionner les directives dans un seul enregistrement TXT.
Dépassement des 10 lookups SPF. Chaque include peut lui-même contenir des include imbriqués. Un outil comme MXToolbox affiche le total réel. Pour réduire le nombre, remplacer certains include par des blocs ip4 ou ip6 directs.
Clé DKIM tronquée. Certains registrars limitent la longueur d’un champ TXT à 255 caractères. La clé doit alors être découpée en plusieurs chaînes entre guillemets, concaténées automatiquement par le serveur DNS.
DMARC en reject sans phase d’observation. Passer directement à reject bloque potentiellement des messages légitimes envoyés par un service oublié dans le SPF.

Pour aller plus loin dans la compréhension des différents types d’enregistrements, le détail des enregistrements A, CNAME, MX et TXT complète utilement la lecture. Et si le domaine approche de son expiration, mieux vaut anticiper : un domaine expiré perd ses enregistrements DNS, y compris SPF, DKIM et DMARC.

Questions fréquentes

Peut-on configurer DMARC sans DKIM ?: Techniquement oui, DMARC fonctionne si au moins SPF ou DKIM passe avec un alignement correct. Mais la protection reste incomplète : un email transféré (forwarding) casse souvent le SPF, et sans DKIM valide, le message sera rejeté. Activer les deux est vivement recommandé.
Les enregistrements SPF, DKIM et DMARC ralentissent-ils la réception des emails ?: Non. Les vérifications ajoutent quelques millisecondes au traitement côté serveur de réception. Ce délai est imperceptible pour l’utilisateur final.
Faut-il configurer ces enregistrements si le domaine n’envoie pas d’emails ?: Oui, et c’est même recommandé. Un domaine sans envoi de courrier devrait publier un SPF v=spf1 -all et un DMARC v=DMARC1; p=reject pour empêcher quiconque d’usurper ce domaine dans des campagnes de phishing.

À retenir

Poser d’abord le SPF (un seul enregistrement TXT, 10 lookups maximum), puis le DKIM (clé publique fournie par le prestataire de messagerie), puis le DMARC (commencer par p=none).
Analyser les rapports DMARC pendant deux à quatre semaines avant de passer en quarantine puis en reject.
Vérifier la configuration avec un outil comme MXToolbox après chaque modification et après la propagation DNS.
Inclure dans le SPF tous les services qui envoient au nom du domaine : hébergeur, suite collaborative, outil marketing, CRM.

Damien Roux

Damien Roux est l'hébergement web. de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress