- Le courriel ne prouve pas l'expéditeur : SPF, DKIM et DMARC, publiés dans votre DNS, apportent cette preuve aux messageries.
- Depuis février 2024, Gmail et Yahoo exigent SPF ou DKIM de tous les expéditeurs, et les trois des gros expéditeurs.
- Commencez par un DMARC en observation avec des rapports, lisez-les, puis durcissez la politique : jamais l'inverse.
Un courriel ne prouve pas qui l'envoie
Le courriel a été conçu à une époque où les réseaux se faisaient confiance. Rien, dans son fonctionnement d'origine, n'empêche quiconque d'écrire « De : » suivi de votre adresse : c'est aussi simple que d'inscrire une fausse adresse d'expéditeur au dos d'une enveloppe. Faute de preuve, Gmail, Outlook ou Yahoo jugent donc chaque message sur des indices : qui l'envoie vraiment, depuis quel serveur, avec quelle réputation. Quand les indices manquent, la prudence l'emporte, et votre devis rejoint les indésirables.
Le symptôme est toujours le même, et il est trompeur. Un client vous dit n'avoir jamais reçu votre facture ; une relance part, elle aussi, dans le vide. Rien ne vous signale l'échec : le message est bien parti, votre logiciel l'affiche dans les éléments envoyés, et aucun avis de non-remise ne revient. C'est ce silence qui coûte le plus cher, parce qu'on cherche longtemps ailleurs avant de regarder le nom de domaine.
Trois enregistrements, publiés dans le DNS de votre nom de domaine, répondent à ce problème : SPF, DKIM et DMARC. Le DNS est l'annuaire public d'internet, celui qui indique à quel serveur correspondent votre site et votre messagerie ; on y ajoute ici des lignes de texte que toute messagerie peut consulter. Ces enregistrements ne garantissent pas qu'un message arrive en boîte de réception, mais leur absence suffit, de plus en plus souvent, à l'en empêcher. Ils ne coûtent rien, se posent une fois, et demandent surtout de savoir qui envoie en votre nom.
Trois mécanismes, trois questions
Chacun des trois répond à une question différente, et l'un ne remplace pas l'autre. SPF demande : ce serveur avait-il le droit d'envoyer pour ce domaine ? DKIM : ce message a-t-il été signé par ce domaine, et n'a-t-il pas été modifié en route ? DMARC : ce que vérifient SPF et DKIM correspond-il à l'adresse que voit le lecteur, et que faire sinon ? Trois portes successives, en somme, chacune apposant son sceau sur l'enveloppe.
SPF : la liste des serveurs autorisés
SPF (Sender Policy Framework, défini par la RFC 7208) est une ligne de texte qui commence par v=spf1 et énumère les serveurs autorisés à envoyer pour votre domaine : votre messagerie, votre outil de lettre d'information, votre logiciel de facturation s'il envoie lui-même. Elle se termine par une consigne pour tout le reste : ~all, l'échec léger, qui demande de traiter avec méfiance un serveur absent de la liste, ou -all, l'échec franc, qui demande de le refuser. La messagerie qui reçoit le message regarde de quelle machine il arrive et vérifie qu'elle figure sur la liste. Un détail compte : SPF contrôle l'adresse de retour technique, celle où reviennent les messages non distribués, et non l'adresse affichée dans « De : ».
DKIM : une signature sur chaque message
DKIM (DomainKeys Identified Mail, RFC 6376) fonctionne comme un sceau. Votre serveur d'envoi signe chaque message avec une clé privée, qu'il garde secrète ; la clé publique correspondante est publiée dans votre DNS, sous un nom appelé sélecteur (par exemple default._domainkey suivi de votre domaine). La messagerie qui reçoit le message vérifie la signature avec cette clé publique. Si elle concorde, deux choses sont prouvées : le message vient d'un serveur qui détient la clé de votre domaine, et son contenu n'a pas été modifié en route. Une clé de 2048 bits est aujourd'hui la recommandation courante.
DMARC : la règle du jeu, et le compte rendu
DMARC (RFC 7489) relie les deux précédents à ce que voit le lecteur. Il exige que l'un au moins des deux contrôles réussisse et soit « aligné », c'est-à-dire porte sur le même domaine que l'adresse affichée dans « De : ». Il dit ensuite aux messageries quoi faire en cas d'échec : p=none (ne rien changer, observer), p=quarantine (ranger dans les indésirables) ou p=reject (refuser le message). Il permet enfin, par l'adresse rua=, de recevoir des rapports agrégés : des comptes rendus réguliers, envoyés par les messageries, qui disent quels serveurs ont envoyé en votre nom et avec quel résultat. C'est la seule façon fiable de découvrir les envois que vous aviez oubliés.
Ce que Gmail, Yahoo et Outlook exigent désormais
Pendant longtemps, ces enregistrements relevaient de la bonne pratique. Depuis février 2024, Gmail et Yahoo en ont fait une condition : un expéditeur qui ne s'authentifie pas voit ses messages filtrés, ralentis ou refusés. Les règles visent d'abord les envois en nombre, mais elles fixent aussi un plancher pour tout le monde.
- Pour tous les expéditeurs : SPF ou DKIM en place sur le domaine d'envoi. C'est le minimum, et une entreprise qui envoie ses devis depuis son propre domaine est concernée.
- Pour ceux qui envoient plus de 5 000 messages par jour vers Gmail : SPF, DKIM et DMARC ensemble, avec un domaine aligné sur l'adresse affichée.
- Pour les messages commerciaux de ces gros expéditeurs : un désabonnement en un clic, en plus d'un lien de désinscription bien visible dans le message.
- Un taux de plaintes bas : Google recommande de rester sous 0,1 % de messages signalés comme spam, et de ne jamais atteindre 0,3 %.
Microsoft a annoncé en 2025 des exigences comparables pour les expéditeurs à fort volume vers ses messageries grand public, dont Outlook.com. Une petite entreprise n'atteint pas ces volumes, mais elle n'y échappe pas pour autant : ses messages sont jugés avec les mêmes outils, et un domaine qui ne prouve rien part avec un handicap, même pour un seul devis. Mieux vaut donc poser les trois enregistrements une fois pour toutes que se demander chaque année si le seuil vous concerne.
La mise en place, pas à pas
La partie technique tient en quelques lignes ; la partie difficile est l'inventaire, car ce ne sont presque jamais les seuls outils auxquels on pense qui envoient en votre nom. Voici l'ordre que nous suivons, qui évite de bloquer un envoi légitime en voulant protéger les autres. Comptez quelques semaines entre le premier et le dernier pas : c'est le temps de lire les rapports, pas celui de taper les lignes.
- Faire l'inventaire
Listez tout ce qui envoie avec votre nom de domaine : messagerie, lettre d'information, logiciel de facturation, formulaire du site, prise de rendez-vous, boutique en ligne. Chacun devra figurer dans SPF ou signer avec DKIM.
- Publier un seul SPF
Rassemblez tous ces services dans un unique enregistrement
v=spf1, en reprenant les mentionsinclude:que chacun indique dans sa documentation. Terminez par~alltant que l'inventaire n'est pas confirmé. - Activer DKIM partout
Dans chaque service, cherchez la page d'authentification du domaine : elle vous donne la clé publique et le sélecteur à publier. Faites-le pour la messagerie comme pour la lettre d'information, sinon une partie seulement de vos messages sera signée.
- Publier DMARC en observation
Ajoutez sous
_dmarcsuivi de votre domaine une ligne commev=DMARC1; p=none; rua=mailto:suivie d'une adresse que vous lirez vraiment. Rien ne change encore pour vos messages, mais les rapports commencent à arriver. - Lire les rapports
Pendant quelques semaines, repérez les serveurs qui envoient en votre nom et échouent : c'est souvent un outil oublié lors de l'inventaire. Corrigez, jusqu'à ce que seuls des envois que vous ne reconnaissez pas échouent encore.
- Durcir la politique
Passez à
p=quarantine, observez encore, puis àp=rejectsi tout est en ordre. À ce stade, un fraudeur qui usurpe votre adresse voit ses messages écartés.
Les rapports agrégés arrivent sous forme de fichiers techniques, en général quotidiens, peu lisibles à l'œil nu ; des services spécialisés les mettent en forme et signalent les échecs. L'essentiel est d'avoir une adresse qui les reçoit et quelqu'un qui les regarde. Un rapport que personne ne lit ne protège de rien.
Les pièges qui défont tout
Ces enregistrements sont courts, et c'est ce qui les rend fragiles : une erreur d'un caractère suffit à les rendre inopérants, sans le moindre message d'alerte. Voici les erreurs que nous rencontrons le plus souvent en reprenant un domaine. Toutes se vérifient en quelques minutes, à condition de savoir les chercher.
- Deux enregistrements SPF. Un domaine n'en admet qu'un ; quand un nouvel outil en ajoute un second au lieu de compléter le premier, le contrôle échoue, quel que soit le serveur.
- Plus de dix recherches dans le SPF. Chaque
include:déclenche des recherches DNS, et la norme en fixe le plafond à dix : au-delà, le SPF échoue entièrement, pour tous vos envois. - Un DMARC sans adresse de rapports.
p=nonesansrua=ne protège rien et ne renseigne rien. Nous l'avons vécu sur notre propre domaine : l'enregistrement était présent, conforme, et parfaitement inutile. - Un site qui ne peut pas envoyer. Certains hébergeurs bloquent, par mesure anti-spam, les connexions d'un site vers les ports de messagerie. Le message d'erreur dit à quelle étape l'envoi a échoué : un délai dépassé désigne le réseau, un refus d'authentification désigne les identifiants.
Vérifier, de bout en bout
Le contrôle le plus simple est gratuit et se fait depuis votre propre boîte. Envoyez un message à une adresse Gmail que vous possédez, ouvrez-le, puis choisissez « Afficher l'original » dans le menu du message. Gmail indique en tête de page le résultat de SPF, de DKIM et de DMARC : chacun doit porter la mention PASS. Refaites l'essai pour chaque outil d'envoi, car chacun suit son propre chemin.
Mais un PASS ne dit pas tout. Chez nous, un message partait, arrivait et passait les contrôles, alors qu'un en-tête manquant abîmait le lien qu'il contenait : le destinataire cliquait sur un lien qui ne menait nulle part. Un courriel qui arrive ne prouve pas qu'il arrive correctement.
Pour les volumes importants, Google Postmaster Tools donne une vue d'ensemble : réputation du domaine, taux de plaintes, résultats d'authentification sur les messages reçus par Gmail. L'outil demande de prouver que vous possédez le domaine, et ne montre des données qu'au-delà d'un certain volume d'envois. Une petite entreprise s'en passe sans dommage ; celle qui envoie une lettre d'information à une large liste gagne à l'ouvrir chaque mois.
Au-delà de l'authentification
SPF, DKIM et DMARC prouvent qui vous êtes ; ils ne disent rien de ce que vous envoyez. Une messagerie juge aussi le comportement : les plaintes, les adresses qui n'existent plus, l'intérêt que les destinataires portent à vos messages. Un domaine parfaitement authentifié peut donc encore finir en indésirables s'il écrit à des gens qui ne l'attendent pas.
- Envoyer depuis votre propre domaine, jamais depuis une adresse de messagerie gratuite : c'est votre domaine qui porte les enregistrements, donc votre réputation.
- Garder un nom d'expéditeur stable, le même d'un envoi à l'autre, pour que vos clients le reconnaissent au premier coup d'œil. Il fait partie de votre identité au même titre que votre logo, comme nous l'expliquons dans notre article sur le système d'identité.
- Mettre un lien de désinscription visible dans chaque message commercial. Un lecteur qui ne trouve pas comment partir clique sur « Signaler comme spam », et c'est votre réputation qui paie.
- Ne jamais acheter de fichier d'adresses. Ces listes mêlent adresses mortes, pièges à spam et personnes qui n'ont rien demandé : quelques envois peuvent suffire à abîmer la réputation d'un domaine.
- Nettoyer les adresses qui rebondissent. Une adresse qui renvoie une erreur permanente doit sortir de la liste : écrire sans fin à des adresses mortes est un signal que les messageries surveillent.
Ce travail ne se voit pas, et c'est pour cela qu'il est négligé. Il fait partie de ce que nous posons pour chaque maison dans notre discipline email, avant la première campagne et avant le premier devis ; le formulaire de votre site est concerné au même titre, car un site bien construit envoie ses messages depuis votre domaine, signés. Un message soigné qui n'arrive pas ne vaut rien ; un message authentifié commence enfin à travailler pour vous.
Avant d'être lu, un message doit être cru.
Ce que vous pouvez faire cette semaine
Cochez au fil de l'eau : rien n'est enregistré, c'est un pense-bête.
Fondateur et directeur de Digital Air Media, maison de création digitale ouverte à Paris en 2017. Il écrit ici ce que la maison applique à ses propres pages avant de le proposer à d'autres.