Depuis 2024, les grands fournisseurs de messagerie exigent des expéditeurs en masse une authentification SPF et DKIM ainsi qu'une politique DMARC publiée. Même pour un petit expéditeur, un enregistrement défaillant est le chemin le plus court vers le dossier spam. Les trois mécanismes répondent à trois questions différentes.

SPF : ce serveur a-t-il le droit d'envoyer pour le domaine ?

SPF est un enregistrement DNS TXT sur votre domaine expéditeur qui liste les serveurs autorisés à envoyer en son nom. Le serveur destinataire regarde l'expéditeur d'enveloppe (le Return-Path, pas le From visible) et vérifie si l'IP qui se connecte figure dans cette liste. Causes d'échec typiques : un nouveau service d'envoi ajouté sans mise à jour de l'enregistrement, un enregistrement dépassant la limite de dix requêtes DNS, ou une redirection qui a changé l'IP de connexion.

DKIM : le message a-t-il été modifié depuis sa signature ?

DKIM ajoute une signature cryptographique à certains en-têtes et au corps. La clé publique est publiée dans le DNS sous un sélecteur. Si la signature est vérifiée, le destinataire sait que le message a été signé par le domaine indiqué et n'a pas été modifié. Les échecs viennent généralement d'une clé absente ou remplacée, d'un pied de page de liste de diffusion ajouté après signature, ou d'un outil qui signe avec son propre domaine plutôt que le vôtre.

DMARC : que doit faire le destinataire, et cela correspond-il au From ?

DMARC relie les deux. Il vérifie qu'au moins l'un de SPF ou DKIM a réussi et que le domaine ayant réussi est aligné avec le domaine de l'en-tête From visible. Puis il indique au destinataire quoi faire en cas d'échec : p=none (surveiller), p=quarantine (spam) ou p=reject. DMARC vous envoie aussi des rapports agrégés montrant qui envoie au nom de votre domaine.

L'alignement est le point où s'arrêtent la plupart des discussions « mais SPF passe ». Si votre outil d'emailing envoie avec son propre Return-Path et signe avec son propre domaine DKIM, SPF et DKIM passent pour le domaine de l'outil, et DMARC échoue quand même pour le vôtre.

Lire les verdicts dans un test

À l'arrivée d'un message, le serveur destinataire consigne ses conclusions dans un en-tête Authentication-Results, par exemple :

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass (p=REJECT) header.from=example.com

Mailproof extrait ces verdicts pour chaque boîte de test afin que vous voyiez d'un coup d'œil si chaque fournisseur a accepté votre authentification. Un softfail, temperror ou none mérite attention même si le message a atteint la boîte de réception : la réputation porte un message aujourd'hui et le laisse tomber demain.

Liste de contrôle

  • Un seul enregistrement SPF par domaine, moins de dix requêtes DNS, terminé par -all ou ~all.
  • Des clés DKIM d'au moins 2048 bits, renouvelées lors des changements de personnel ou de prestataires.
  • Un enregistrement DMARC sur le domaine organisationnel, en commençant par p=none avec rapports, puis quarantine et reject une fois les rapports propres.
  • Des domaines Return-Path et DKIM personnalisés configurés dans chaque outil tiers pour que tout s'aligne avec votre domaine From.