SPF, DKIM, DMARC : qui fait quoi, et pourquoi il en faut trois

La question revient à chaque première réunion : « on a déjà un SPF, ça ne suffit pas ? ». Non — et la raison n'est pas que SPF serait mal fait. C'est que les trois mécanismes répondent à trois questions différentes, dont une seule intéresse vraiment le destinataire de vos mails.

Ce que chacun vérifie

Le point important est dans la troisième ligne. DMARC ne valide rien. Il exploite les résultats de SPF et de DKIM, et il ajoute la seule vérification qui compte du point de vue de l'utilisateur : le nom de domaine affiché dans le champ De : est-il bien celui qui a été authentifié ?

Pourquoi SPF seul laisse la porte ouverte

Un message électronique porte deux adresses d'expéditeur, et c'est là que tout se joue.

L'enveloppe (MAIL FROM) sert au transport. C'est elle que SPF vérifie. Elle n'apparaît jamais dans le client de messagerie.

L'en-tête (From:) est celle que votre correspondant voit. C'est elle que l'attaquant veut usurper, et SPF ne la regarde pas.

Rien n'empêche donc un message d'obtenir un SPF parfaitement valide sur un domaine d'attaquant, tout en affichant comptabilite@votre-entreprise.fr dans le champ visible. Le destinataire voit une authentification réussie et votre nom. C'est exactement ce que DMARC vient corriger, en exigeant l'alignement des deux domaines.

Pourquoi DKIM est le plus solide des trois

DKIM signe cryptographiquement une partie du message avec une clé privée, la clé publique étant publiée dans votre DNS. Le destinataire vérifie la signature.

Trois propriétés en font le mécanisme le plus robuste en pratique :

• Il survit aux redirections. Un message transféré garde sa signature ; SPF, lui, échoue mécaniquement, puisque le serveur qui relaie n'est pas dans votre enregistrement.
• Il ne consomme aucune résolution DNS au sens de la limite SPF, ce qui compte quand vous avez quinze prestataires.
• Il ne dépend pas des adresses IP du prestataire, qui changent sans que personne ne vous prévienne.

Sa faiblesse est ailleurs : une signature ne dit rien de la légitimité de l'expéditeur. N'importe qui peut signer ses propres messages. C'est encore DMARC qui tranche, en exigeant que le domaine de la signature s'aligne sur le domaine affiché.

Ce que DMARC ajoute vraiment

Trois choses, dans l'ordre d'importance :

1. L'alignement. La vérification décrite plus haut, et la seule qui protège le lecteur.
2. Une instruction. none, quarantine ou reject : ce que le destinataire doit faire en cas d'échec. Sans elle, chaque opérateur décide dans son coin.
3. Des rapports. Chaque jour, les grands opérateurs vous envoient un résumé de ce qu'ils ont vu passer en votre nom. C'est la seule source d'information exhaustive dont vous disposerez sur vos propres flux.

Ce troisième point est sous-estimé. Les rapports agrégés DMARC révèlent régulièrement des expéditeurs légitimes dont plus personne ne connaissait l'existence — un vieux serveur d'impression, un script de supervision, une plateforme abandonnée par une équipe partie depuis.

Et BIMI, MTA-STS, tout le reste ?

Ils viennent après, jamais avant.

BIMI affiche votre logo dans la boîte de réception ; il exige p=quarantine ou p=reject au préalable. C'est une récompense, pas une protection.

MTA-STS et DANE protègent le transport contre l'interception, pas contre l'usurpation d'identité. Sujet réel, problème différent.

ARC préserve les résultats d'authentification à travers les relais légitimes ; utile quand vous dépendez de listes de diffusion, mais uniquement une fois DMARC en place.

Par où commencer, concrètement

1. Publier un DMARC en p=none avec une adresse de rapport, sur tous vos domaines — y compris ceux qui n'envoient jamais rien.
2. Lire les rapports pendant quatre à six semaines pour constituer l'inventaire réel de vos expéditeurs.
3. Activer DKIM chez chaque prestataire légitime, avec votre domaine.
4. Ne toucher à SPF qu'à la fin, et le garder court.
5. Basculer par paliers vers p=reject.