SPF DKIM DMARC : faire arriver les e-mails de votre site

Un message de contact qui n'arrive jamais, une confirmation de commande classée en spam, un lien de réinitialisation de mot de passe introuvable : les problèmes d'e-mails sont parmi les plus frustrants pour les propriétaires de sites. Dans la grande majorité des cas, la cause est la même : le domaine n'est pas correctement authentifié. Trois mécanismes complémentaires, le trio SPF DKIM DMARC, permettent aux messageries de vérifier que vos e-mails viennent bien de vous. Voici comment ils fonctionnent et comment les mettre en place.

Pourquoi vos e-mails finissent en spam

N'importe qui peut envoyer un e-mail en indiquant votre adresse comme expéditeur : le protocole SMTP ne vérifie rien par lui-même. Les fraudeurs en profitent pour l'hameçonnage. En réaction, Gmail, Outlook et les autres messageries se méfient des messages dont l'expéditeur ne peut pas être authentifié.

Depuis février 2024, Google et Yahoo exigent même SPF, DKIM et DMARC pour les expéditeurs qui envoient plus de 5 000 messages par jour vers leurs utilisateurs, et une authentification minimale pour tous les autres, comme le précisent les consignes de Google pour les expéditeurs. Un petit site n'atteint pas ce volume, mais les filtres anti-spam appliquent la même logique : un message non authentifié part avec un handicap.

SPF : la liste des serveurs autorisés

SPF (Sender Policy Framework) est un enregistrement DNS qui liste les serveurs autorisés à envoyer des e-mails pour votre domaine. À la réception, la messagerie vérifie que le serveur d'envoi figure dans cette liste.

exemple.fr.  IN TXT  "v=spf1 mx ip4:203.0.113.10 include:_spf.fournisseur-mail.fr -all"

• mx autorise les serveurs de messagerie du domaine ;
• ip4: autorise une adresse précise, par exemple celle du serveur qui héberge le site ;
• include: délègue à un prestataire (votre messagerie, un service d'envoi de newsletters) ;
• -all demande de rejeter tout le reste, tandis que ~all demande seulement de considérer le reste comme suspect.

Deux pièges fréquents : il ne doit exister qu'un seul enregistrement SPF par domaine, et la vérification ne doit pas dépasser 10 consultations DNS (chaque include en compte au moins une). Au-delà, SPF échoue.

DKIM : une signature cryptographique

DKIM (DomainKeys Identified Mail) ajoute à chaque message une signature numérique, calculée avec une clé privée conservée par le serveur d'envoi. La clé publique correspondante est publiée dans le DNS :

mail2026._domainkey.exemple.fr.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

Le préfixe mail2026 est le sélecteur : il permet d'avoir plusieurs clés (une par service d'envoi) et de les renouveler sans interruption. La messagerie du destinataire vérifie la signature avec la clé publique : si le message a été modifié en route ou ne vient pas d'un serveur détenteur de la clé, la vérification échoue.

Contrairement à SPF, DKIM résiste au transfert d'un message : la signature reste valide même si l'e-mail passe par un serveur intermédiaire.

DMARC : la politique et les rapports

DMARC (Domain-based Message Authentication, Reporting and Conformance), défini à l'origine par la RFC 7489, relie les deux mécanismes précédents à l'adresse d'expéditeur visible par le destinataire. Il indique aussi ce que la messagerie doit faire en cas d'échec :

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

• p=none : ne rien bloquer, simplement envoyer des rapports ;
• p=quarantine : placer les messages non authentifiés en spam ;
• p=reject : les refuser purement et simplement.

L'adresse indiquée dans rua reçoit chaque jour des rapports agrégés des grandes messageries : combien de messages ont été reçus en votre nom, depuis quels serveurs, et s'ils ont passé les contrôles. Ces rapports, au format XML, se lisent plus facilement avec un outil d'analyse.

La méthode pour déployer sans casse

1. Inventoriez tout ce qui envoie des e-mails en votre nom : votre messagerie, le serveur du site (formulaires, notifications), l'outil de newsletter, le logiciel de facturation, le CRM… ;
2. Publiez un SPF qui couvre tous ces services ;
3. Activez DKIM chez chaque prestataire et publiez les clés fournies ;
4. Publiez DMARC en p=none et lisez les rapports pendant quelques semaines ;
5. Corrigez les sources oubliées, puis passez à p=quarantine, et enfin à p=reject.

Passer directement à p=reject sans cette phase d'observation, c'est risquer de bloquer ses propres factures ou sa newsletter.

Le cas des formulaires de contact

Une erreur classique : le formulaire envoie un e-mail avec l'adresse du visiteur en expéditeur (From: visiteur@gmail.com). Votre serveur n'est évidemment pas autorisé à envoyer au nom de gmail.com, et le message est rejeté. La bonne pratique consiste à envoyer depuis une adresse de votre domaine (par exemple noreply@exemple.fr) et à placer l'adresse du visiteur dans l'en-tête Reply-To. Vous répondez d'un clic, et l'authentification passe. J'en parle aussi dans mon article sur les formulaires de contact.

Vérifier sa configuration

Envoyez un message vers une boîte Gmail, ouvrez-le et choisissez « Afficher l'original » : Gmail indique le résultat des contrôles SPF, DKIM et DMARC (PASS ou FAIL). Plusieurs services en ligne gratuits analysent aussi vos enregistrements DNS et signalent les erreurs.

Ces réglages se font dans la zone DNS de votre nom de domaine, et sont à vérifier à chaque changement d'hébergeur ou de prestataire de messagerie. Ils participent aussi à la protection de votre marque contre l'usurpation, un enjeu de sécurité souvent négligé.

Les e-mails de votre site n'arrivent pas, ou vous voulez vérifier votre configuration ? Je peux auditer et corriger vos enregistrements DNS : contactez-moi.