On présente presque toujours SPF, DKIM et DMARC comme trois couches de sécurité que l'on empile. C'est faux, et ce contresens explique pourquoi tant de domaines correctement configurés restent usurpables.
Chacun des trois regarde un identifiant différent. SPF regarde l'expéditeur d'enveloppe, celui de la transaction SMTP. DKIM regarde le domaine qui a signé. DMARC est le seul des trois à s'intéresser au domaine du champ « De : » affiché par le client de messagerie.
Or c'est ce champ, et lui seul, que l'utilisateur lit. Un message peut donc passer SPF et DKIM sans difficulté tout en affichant à l'écran un expéditeur qui n'a rien à voir : les deux premiers protocoles n'ont jamais regardé cette ligne.
SPF : ce qu'il vérifie, et la limite qui le casse
SPF existe pour une raison simple : rien dans les protocoles historiques ne restreint ce qu'un serveur peut déclarer comme expéditeur d'enveloppe. Il publie donc la liste des serveurs autorisés à émettre pour un domaine.
Un point de forme d'abord, car il fait perdre du temps : un enregistrement SPF se publie obligatoirement dans un enregistrement DNS de type TXT, et rien d'autre.
Vient ensuite la contrainte qui casse le plus de configurations en production. SPF impose une limite dure de 10 termes provoquant une requête DNS. Au-delà, le résultat est permerror et l'authentification échoue, ce qui revient à n'avoir aucun SPF.
Encore faut-il savoir ce qui compte dans ces dix. Les termes concernés sont include, a, mx, ptr, exists, et le modificateur redirect. Chaque prestataire ajouté par un include consomme donc au moins une unité, et souvent davantage puisque son propre enregistrement en contient.
Une seconde limite, nettement moins connue, plafonne à deux les requêtes DNS sans réponse. Un include pointant vers un domaine disparu ne se contente pas d'être inutile, il consomme ce budget-là.
DKIM : une revendication, pas une preuve d'auteur
La formulation exacte compte ici, parce que l'intuition trompe. DKIM ne certifie pas l'auteur du message. Il permet au propriétaire du domaine signataire de revendiquer une responsabilité sur le message.
La nuance a des conséquences concrètes : un prestataire qui signe avec son propre domaine revendique sa propre responsabilité, pas la vôtre. La signature est valide, et pourtant elle ne dit rien de votre domaine.
Le sélecteur, souvent pris pour une simple convention de nommage, a une raison d'être précise : il existe pour permettre plusieurs clés publiques simultanées sur un même domaine signataire. C'est ce qui rend possible une rotation de clé ou plusieurs prestataires en parallèle.
Dernier point, très pratique : la signature est calculée sur le contenu du message, donc toute modification en transit fait échouer la vérification. Une passerelle qui ajoute une bannière de sécurité ou un pied de page casse la signature qu'elle est censée protéger.
DMARC : l'alignement, seul mécanisme qui protège la ligne visible
DMARC vérifie que le domaine du « De : » s'aligne avec un domaine validé par SPF ou par DKIM. C'est la définition formelle de l'alignement d'identifiants : le domaine du From doit correspondre à un domaine validé par l'un des deux, ou par les deux.
La politique se publie dans le DNS par le propriétaire du domaine, et elle se lit pendant la session SMTP. Ce n'est pas un filtrage appliqué après réception.
Ce que demandent réellement quarantine et reject
Les deux valeurs sont couramment confondues, et l'écart entre elles est plus grand qu'il n'y paraît.
p=quarantine demande au destinataire de traiter le message en échec comme suspect : dossier spam, examen renforcé. Il ne demande pas de le refuser. p=reject demande le rejet, et ce rejet doit intervenir pendant la transaction SMTP.
Entre les deux existe un réglage sous-utilisé : le tag pct permet de n'appliquer la politique qu'à une fraction du flux. C'est l'outil qui permet de durcir progressivement, plutôt que de basculer un domaine entier et de découvrir les cassures en production.
Ce que Gmail exige, et le seuil qui change tout
Depuis le 1er février 2024, tout expéditeur vers Gmail doit avoir SPF ou DKIM. Au-delà de 5 000 messages par jour, ce sont SPF et DKIM et DMARC qui deviennent exigibles.
Un détail rassurant, rarement dit : pour ce palier des 5 000, Gmail accepte une politique DMARC en p=none. L'exigence porte sur l'existence de l'enregistrement, pas sur sa sévérité.
En revanche, une condition indépendante s'ajoute et ne se règle pas dans le DNS : le taux de spam mesuré dans Postmaster Tools doit rester sous 0,3 %. Une authentification parfaite ne rattrape pas une liste de mauvaise qualité.
Dans quel ordre s'y prendre
La séquence qui évite les mauvaises surprises consiste à publier SPF, signer en DKIM, puis n'arriver à DMARC qu'en observation. Pour fixer les idées, avec des enregistrements d'illustration : v=spf1 include:_spf.google.com ~all pour SPF, puis _dmarc.exemple.fr en TXT portant v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr, avant de passer à p=quarantine.
Le rua n'est pas décoratif : c'est lui qui fait remonter les rapports, donc la seule manière de savoir qui émet en votre nom avant de commencer à bloquer.
Ce que cela demande à l'outil d'emailing
La conséquence pratique de tout ce qui précède est qu'une plateforme d'email marketing doit pouvoir signer avec votre domaine, pas seulement avec le sien, faute de quoi l'alignement DMARC ne peut pas se faire.
Notre catalogue recense 21 logiciels d'emailing publiés, et les 31 offres facturées au mois vont de 1 € à 1 290 € HT.
Deux capacités valent d'être regardées de près, et notre comparateur permet de les situer : la signature DKIM sur un domaine personnalisé avec sélecteur dédié, et la mise à disposition des rapports DMARC agrégés sans passer par un service tiers.
