SPF, DKIM, DMARC : configurer un domaine d'envoi

Pourquoi un domaine dédié à l'envoi

La prospection à froid comporte un risque : une partie des destinataires ne connaît pas l'expéditeur, et certains signaleront le message comme spam. Si ce message part de votre domaine principal, c'est la réputation de toute votre messagerie qui en pâtit, factures et échanges clients compris. La parade classique consiste à envoyer depuis un domaine proche de votre marque, par exemple votremarque-conseil.fr (illustratif), qui redirige vers votre site.

Un domaine dédié n'est pas un domaine anonyme : le destinataire doit pouvoir identifier qui lui écrit, comme le demande la CNIL. On ne cherche pas à se cacher, on cloisonne les risques.

Ce qu'exigent les messageries

Depuis février 2024, Google demande à tous les expéditeurs vers Gmail de configurer SPF ou DKIM, et aux gros expéditeurs, à partir d'environ 5 000 messages par jour vers des comptes Gmail personnels, de configurer SPF et DKIM ainsi qu'un enregistrement DMARC. Yahoo pose les mêmes règles. Microsoft a suivi pour Outlook.com, Hotmail et Live à partir du 5 mai 2025, pour les domaines qui envoient plus de 5 000 emails par jour. La FAQ de Google indique qu'à partir de novembre 2025 Gmail renforce l'application de ces règles.

Une prospection bien menée reste loin de ces volumes. Mais rien ne justifie de s'en tenir au minimum : les trois enregistrements se configurent en une heure.

SPF : qui a le droit d'envoyer

SPF, défini par la RFC 7208, est un enregistrement TXT publié sur le domaine. Il liste les serveurs autorisés à envoyer des emails pour ce domaine. Pour un domaine qui envoie uniquement via Google Workspace :

votremarque-conseil.fr.  TXT  "v=spf1 include:_spf.google.com ~all"

Quelques règles à connaître :

• un seul enregistrement SPF par domaine : en publier deux produit une erreur ;
• dix recherches DNS au maximum : chaque include, a, mx ou redirect en consomme, et la RFC fixe la limite à dix ; au-delà, SPF échoue ;
• la fin de l'enregistrement : ~all (échec doux) marque comme suspects les serveurs non listés, -all (échec strict) demande de les rejeter. Avec DMARC en place, ~all est un choix courant.

SPF vérifie le domaine de l'enveloppe technique, pas celui que voit le lecteur dans le champ « De ». C'est DMARC qui fera le lien.

DKIM : une signature sur chaque message

DKIM, défini par la RFC 6376, ajoute à chaque message une signature cryptographique. La clé publique est publiée dans le DNS sous un « sélecteur ». Votre fournisseur de messagerie génère la paire de clés et vous donne l'enregistrement à publier, du type :

google._domainkey.votremarque-conseil.fr.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Google exige une clé d'au moins 1024 bits et recommande 2048 bits. Après publication, il faut en général activer la signature dans la console du fournisseur : oublier cette étape est l'erreur la plus fréquente. Un message signé reste vérifiable même s'il est transféré, ce qui rend DKIM plus robuste que SPF.

DMARC : la politique et l'alignement

DMARC s'appuie sur SPF et DKIM et ajoute deux choses. D'abord l'alignement : pour passer DMARC, le message doit être authentifié par SPF ou DKIM avec un domaine qui correspond au domaine visible dans le champ « De ». Ensuite une politique : ce que le destinataire doit faire d'un message qui échoue. L'enregistrement se publie sur le sous-domaine _dmarc :

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

• p=none : observer sans bloquer. C'est le minimum accepté par Google et Yahoo, et le bon point de départ ;
• p=quarantine : envoyer en spam les messages qui échouent ;
• p=reject : les refuser ;
• rua : l'adresse qui reçoit les rapports agrégés, à lire pour repérer un envoi légitime mal configuré.

La norme DMARC (RFC 7489) fait l’objet d’une révision à l’IETF, appelée « DMARCbis ». Les enregistrements v=DMARC1 existants restent valables : vérifiez simplement votre configuration quand la nouvelle version sera publiée.

Le reste de la configuration

• MX : le domaine d'envoi doit pouvoir recevoir les réponses. Sans MX, les réponses se perdent et le domaine paraît suspect.
• DNS inverse et TLS : exigés par Google pour tous les expéditeurs. Les grands fournisseurs de messagerie s'en chargent ; vérifiez-le si vous utilisez votre propre serveur.
• Site web : une redirection du domaine d'envoi vers votre site principal rassure les destinataires curieux comme les filtres.
• Désinscription : les gros expéditeurs doivent proposer la désinscription en un clic, via les en-têtes List-Unsubscribe et List-Unsubscribe-Post décrits par la RFC 8058, et un lien visible dans le message.

Vérifier que tout passe

Envoyez un message vers une boîte Gmail de test, ouvrez-le, puis choisissez « Afficher l'original ». Gmail y indique le résultat de SPF, DKIM et DMARC : les trois doivent afficher PASS. Répétez le test vers une boîte Outlook.com. Ensuite, déclarez le domaine dans Google Postmaster Tools pour suivre le taux de spam signalé par les utilisateurs, que Google demande de maintenir sous 0,3 % et recommande de garder sous 0,1 %.

Les erreurs les plus fréquentes

1. Deux enregistrements SPF sur le même domaine, après l'ajout d'un nouvel outil.
2. Plus de dix recherches DNS dans SPF, à force d'empiler les include.
3. Une clé DKIM publiée, mais la signature jamais activée chez le fournisseur.
4. Un outil d'envoi qui signe avec son propre domaine : DKIM passe, mais pas l'alignement DMARC.
5. Une politique p=reject posée trop tôt, qui bloque un envoi légitime oublié.
6. Un domaine d'envoi sans MX, qui ne reçoit pas les réponses.

Une fois l'authentification en place, une boîte neuve n'est pas encore prête à prospecter : elle n'a pas d'historique. C'est l'objet de la chauffe.

Sources

• Google, Consignes relatives aux expéditeurs d'e-mails et FAQ
• Yahoo, Sender best practices
• Microsoft, nouvelles exigences d'Outlook pour les gros expéditeurs
• IETF, RFC 7208 (SPF), RFC 6376 (DKIM), RFC 8058 (désinscription en un clic)

Articles liés