Problème
Les e-mails du client partent en spam
Ce n’est presque jamais le contenu des messages. C’est l’authentification du domaine qui échoue, et le message reçu vous dit précisément laquelle.
Ouvrez un message réellement reçu chez Gmail, affichez l’original, et lisez la ligne « Authentication-Results ». Elle porte trois verdicts : spf, dkim, dmarc. Tout le diagnostic tient dans ces trois mots, et toute réparation faite avant de les avoir lus est une réparation au hasard.
À faire tout de suite
Quatre gestes, dans cet ordre. Ne touchez à aucun enregistrement DNS avant d’avoir fait le premier.
Lisez l’en-tête d’authentification d’un message reçu
3 minDans Gmail, ouvrez le message, menu des trois points, « Afficher l’original ». Cherchez la ligne « Authentication-Results ». Un message reçu vaut mieux que n’importe quel outil de test : il vous dit ce que le destinataire a réellement constaté, depuis l’infrastructure réellement utilisée. Demandez au client de vous en transférer un en pièce jointe, pas de le recopier.
Corrigez dans cet ordre :
20 minSPF, puisDKIM, puis l’alignementSPFdéclare quels serveurs ont le droit d’envoyer pour le domaine.DKIMsigne les messages. L’alignementDMARCvérifie que le domaine affiché dans le « De » correspond au domaine qui a réussi SPF ou DKIM. C’est le troisième qui échoue le plus souvent et qu’on regarde en dernier : les deux premiers peuvent parfaitement passer pendant que l’alignement échoue.Vérifiez le DNS inversé et le TLS du serveur d’envoi
10 minGoogle exige de tous les expéditeurs que le domaine ou l’adresse IP d’envoi dispose d’enregistrements DNS direct et inversé valides — ce qu’on appelle l’enregistrement PTR — et que la transmission passe par une connexion TLS. Deux points qu’on oublie parce qu’ils ne dépendent pas de la zone du domaine mais de l’hébergeur du serveur d’envoi.
Regardez le taux de spam dans Postmaster Tools
5 minL’outil de Google affiche le taux de plaintes de votre domaine. Le seuil est clair : il doit rester sous 0,3 %. Si l’authentification est bonne et que les messages partent quand même en spam, c’est là qu’est la réponse — et la correction n’est plus technique, elle est éditoriale.
L’en-tête qui contient tout le diagnostic
Voici à quoi ressemble un cas classique : deux contrôles sur trois sont verts, et le message part quand même en indésirable. La raison est sur la troisième ligne.
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=example.com;
dkim=fail header.i=@example.net;
dmarc=fail (p=NONE) header.from=example.com
- La ligne est écrite par le serveur qui a reçu le message — ici celui de Gmail. C’est un constat, pas une prédiction : elle vaut mieux que n’importe quel simulateur.
SPFpasse : le serveur qui a envoyé le message figure bien dans l’enregistrement SPF du domaine. Ce point-là est réglé.DKIMéchoue, et le détail explique pourquoi : la signature porte sur « example.net », pas sur le domaine du message. Un prestataire signe avec son propre domaine au lieu de celui du client — cas typique d’un outil d’envoi installé sans sa configuration DNS.- Et
DMARCéchoue en conséquence : le domaine du « De » ne correspond à aucun des deux domaines authentifiés. C’est l’alignement, la panne la plus fréquente et la plus mal comprise :SPFvert etDKIMrouge suffisent à faire tomber l’ensemble.
Ce que Gmail exige, et à partir de quel volume
Les exigences ont changé le 1er février 2024 et beaucoup de configurations datent d’avant. Deux colonnes, parce que le seuil de cinq mille messages par jour change la donne.
- Authentification du domaine d’envoiTous les expéditeurs
SPFouDKIM.Plus de 5 000 messages par jourSPFetDKIM, les deux. DMARCTous les expéditeursNon exigé.Plus de 5 000 messages par jourExigé sur le domaine d’envoi. La règle d’application peut rester « none ».- Alignement
DMARCTous les expéditeursNon exigé.Plus de 5 000 messages par jourLe domaine du « De » doit correspondre au domaineSPFou au domaineDKIM. - DNS direct et inversé (PTR)Tous les expéditeursValides.Plus de 5 000 messages par jourValides.
- Transmission en TLSTous les expéditeursExigée.Plus de 5 000 messages par jourExigée.
- Taux de spam (Postmaster Tools)Tous les expéditeursSous 0,3 %.Plus de 5 000 messages par jourSous 0,3 %.
- Désabonnement en un clicTous les expéditeursNon exigé.Plus de 5 000 messages par jourExigé sur les messages marketing et les envois aux abonnés, avec un lien visible dans le corps du message.
Source : Google, « Consignes pour les expéditeurs de messages » (aide Gmail), en vigueur depuis le 1er février 2024. Google recommande par ailleurs de rester sous 0,10 % de taux de spam et d’éviter d’atteindre 0,30 %. Le format des messages doit par ailleurs respecter la RFC 5322.
Les quatre causes qui reviennent tout le temps
Avant de refaire toute la configuration, regardez si l’une de ces quatre-là vous décrit. Elles couvrent la grande majorité des cas.
Le formulaire du site qui écrit au nom du client
Votre formulaire de contact envoie depuis le serveur du site en mettant l’adresse du visiteur, ou celle du client, dans le champ « De ». Pour un serveur de réception, c’est la signature d’une usurpation. Envoyez depuis un domaine que vous contrôlez et mettez l’adresse du visiteur en « Répondre à ».
Deux enregistrements
SPFsur le même domaineUn domaine ne peut en porter qu’un seul. Deux ne s’additionnent pas : le contrôle sort en erreur permanente et le domaine se retrouve moins bien authentifié qu’avec un seul. Si vous devez autoriser deux prestataires, ils tiennent dans un seul enregistrement.
Le « ~all » qu’on croit strict
La fin d’un enregistrement
SPFdit ce qu’il faut faire des serveurs non listés. « ~all » demande un traitement souple, « -all » demande un rejet. Écrire « ~all » en pensant avoir verrouillé le domaine est l’erreur la plus courante du dossier.La messagerie changée il y a deux ans
Le client a migré, et l’enregistrement
SPFautorise toujours l’ancien fournisseur — parfois lui seul. LesMXpointent au bon endroit, les messages arrivent, mais ceux qui partent ne sont plus authentifiés. Vérifiez toujours la cohérence entre les MX et le SPF.
Pourquoi c’est arrivé
Parce que les règles se sont durcies pendant que les configurations dormaient. Depuis le 1er février 2024, Google impose à tous les expéditeurs un minimum qui n’existait pas avant : authentification du domaine, DNS inversé valide, transmission chiffrée, taux de plaintes sous 0,3 %. Une configuration qui passait très bien en 2022 peut échouer aujourd’hui sans que rien n’ait été modifié chez le client.
Et parce que l’authentification d’un domaine est faite de trois pièces que personne ne possède en entier. Le SPF est chez celui qui tient la zone DNS, la signature DKIM chez le prestataire d’envoi, l’alignement DMARC dépend des deux. Chaque intervenant fait sa part, personne ne regarde l’ensemble, et l’ensemble est précisément ce que le destinataire évalue.
Le déclencheur, lui, est presque toujours un changement banal : une migration de messagerie, un nouvel outil d’envoi de factures ou de newsletters branché en quinze minutes, un prestataire ajouté sans que sa configuration DNS suive.
Comment l’éviter la prochaine fois
Posez DMARC en mode « none » dès la livraison, avec une adresse de rapports. Vous ne bloquez rien, et vous recevez la liste de tout ce qui envoie au nom du domaine — y compris ce que le client a branché sans vous le dire. C’est le seul dispositif qui vous prévient avant les destinataires.
Traitez SPF, DKIM et DMARC comme des enregistrements DNS qu’il faut surveiller, pas comme une case cochée une fois. Ce sont trois lignes de texte qu’un prestataire, un hébergeur ou un client peut écraser en deux minutes, sans rien casser de visible : le site continue de fonctionner, les messages continuent de partir, ils arrivent simplement ailleurs.
Et vérifiez la cohérence à chaque changement de messagerie. La migration change les MX ; c’est le SPF, le DKIM et le DMARC qu’on oublie de suivre, parce qu’ils ne cassent rien le jour même.
Lisez SPF, DKIM et DMARC du domaine
L’outil lit les trois enregistrements du domaine et dit lequel manque, lequel est mal formé et ce que déclare la règle DMARC. Entrez le domaine qui envoie les messages — pas celui du site, s’ils diffèrent.
Trois lignes de texte, surveillées tous les jours.
DomainVigil relit SPF, DKIM et DMARC sur tous les domaines de vos clients, et prévient quand l’un d’eux change ou disparaît. La panne est détectée le jour où elle arrive, pas le jour où un client s’en aperçoit. Cinq domaines gratuits.
Cinq domaines gratuits, pour toujours. Sans carte bancaire.