Trois sigles reviennent dès qu’on parle de délivrabilité, et la plupart des expéditeurs les traitent comme une formalité déléguée au prestataire technique. C’est une erreur d’appréciation : ces enregistrements décident si vos messages atteignent la boîte de réception ou le dossier indésirables. Ils se configurent une fois, en une heure, et leur absence coûte des années de résultats médiocres inexpliqués.
Trois enregistrements, trois questions différentes
Chacun répond à une question distincte, et c’est en les confondant qu’on s’y perd. SPF demande : ce serveur a-t-il le droit d’envoyer au nom de ce domaine ? DKIM demande : le message a-t-il été altéré depuis son envoi ? DMARC demande : que faire quand les deux premiers échouent, et qui prévenir ? Les trois se déclarent dans la zone DNS du domaine, là où sont déjà décrits le site et la messagerie. Julien Jimenez range ces réglages dans la catégorie des travaux qu’on ne fait qu’une fois mais qu’on ne peut pas ne pas faire, et l’ordre compte : SPF et DKIM d’abord, DMARC ensuite, jamais l’inverse.
SPF : qui a le droit d’envoyer en votre nom
L’enregistrement SPF liste les serveurs autorisés à envoyer des messages portant votre nom de domaine. Le serveur qui reçoit consulte cette liste et compare. Deux pièges reviennent constamment. Le premier : oublier un expéditeur légitime l’outil de campagnes, le formulaire du site, la facturation, l’outil de support dont les messages seront alors traités comme suspects. Le second : accumuler les autorisations au fil des années. SPF impose une limite de dix consultations DNS ; au-delà, l’enregistrement devient invalide et cesse de vous protéger, silencieusement. Un seul enregistrement SPF par domaine, jamais deux.
DKIM : la signature qui prouve l’intégrité
DKIM ajoute à chaque message une signature cryptographique, vérifiable grâce à une clé publique publiée dans votre DNS. Si le contenu a été modifié en route, la vérification échoue. Contrairement à SPF, DKIM survit aux transferts de messages, ce qui en fait l’authentification la plus fiable des deux. La configuration consiste à copier les valeurs fournies par votre outil d’envoi. Point de vigilance : chaque outil possède sa propre clé, avec un préfixe distinct, et il faut donc déclarer autant d’enregistrements que de services expéditeurs.
DMARC : la règle qui décide du sort des échecs
DMARC s’appuie sur les deux précédents et ajoute deux choses : une consigne ne rien faire, isoler, ou rejeter et un canal de rapports qui vous indique qui envoie des messages en votre nom, y compris les usurpateurs. Il exige aussi que le domaine visible par le destinataire corresponde à celui qui est authentifié, condition que beaucoup de configurations approximatives ne remplissent pas. Deux précisions utiles. Les rapports arrivent au format XML, illisibles tels quels : un service d’analyse, souvent gratuit en dessous d’un certain volume, les transforme en tableau exploitable. Et une politique déclarée sur le domaine principal s’applique par défaut à ses sous-domaines, ce qui surprend le jour où un outil interne cesse brutalement d’envoyer.
Passer de la surveillance à l’application
La quasi-totalité des domaines s’arrête à la consigne « ne rien faire ». C’est une étape d’observation, pas une protection : elle n’empêche strictement rien. Le trajet complet demande quelques semaines publier la consigne neutre, lire les rapports pendant trois à quatre semaines, régulariser les expéditeurs légitimes oubliés, puis durcir progressivement. Depuis 2024, les principaux fournisseurs de messagerie grand public exigent une authentification en règle des expéditeurs de volume, et le seuil de tolérance n’a fait que baisser depuis. Un domaine dont l’authentification tient réellement n’améliore pas vos contenus, mais il supprime la seule cause de mauvais résultats sur laquelle vous n’auriez jamais eu de visibilité.
