Ce que font réellement SPF, DKIM et DMARC
Voyez les trois comme une chaîne à trois maillons. SPF autorise les serveurs qui peuvent envoyer pour votre domaine. DKIM ajoute une signature cryptographique pour qu'un destinataire sache que le message n'a pas été modifié en route. DMARC relie les deux au domaine que le lecteur voit réellement dans la ligne From: et publie une politique sur la conduite à tenir quand le contrôle échoue. En clair : SPF vérifie l'enveloppe, DKIM vérifie le contenu, et DMARC vérifie que l'un des deux correspond au nom que votre destinataire lit.
SPF : quels serveurs peuvent envoyer pour votre domaine
Un enregistrement SPF est un unique enregistrement DNS TXT qui commence par v=spf1 et liste les hôtes et les include autorisés à envoyer pour le domaine, en se terminant par un mécanisme all. Deux règles piègent la plupart des gens. D'abord, un domaine ne peut publier qu'un seul enregistrement v=spf1 ; un second fait renvoyer permerror à l'évaluation et l'authentification échoue de fait (RFC 7208, section 4.5). Ensuite, SPF ne peut effectuer que dix mécanismes déclenchant une requête DNS au maximum — include, a, mx, ptr, exists et le modificateur redirect — pendant l'évaluation ; au-delà de dix, le résultat est de nouveau permerror (section 4.6.4). Le qualificateur final porte la politique : ~all est un softfail (accepter mais marquer), -all est un hardfail (rejeter les expéditeurs non listés), et +all ferait tout passer, ce qui explique qu'on ne le publie jamais. Une limite de structure à connaître : SPF authentifie le domaine caché du Return-Path, pas le From: visible, et il casse au transfert, car l'IP du serveur qui transfère n'est pas dans votre enregistrement — c'est précisément pourquoi DMARC ne repose pas sur SPF seul.
DKIM : une signature que rien ne peut modifier en douce
DKIM signe chaque message sortant avec une clé privée détenue par votre système d'envoi et publie la clé publique correspondante dans le DNS. La signature couvre des en-têtes choisis et le corps, si bien que toute altération en transit invalide la signature. Les destinataires trouvent la clé grâce à un sélecteur : un en-tête DKIM-Signature porte s= (le sélecteur) et d= (votre domaine), et le vérificateur interroge sélecteur._domainkey.votredomaine pour la clé publique (RFC 6376, section 3.6.2.1). Les sélecteurs permettent aussi de faire tourner plusieurs clés à la fois, ce qui rend la rotation propre — publiez un nouveau sélecteur, basculez la signature dessus, puis retirez l'ancien (une valeur de clé vide signale sa révocation). Sur la longueur de clé, la RFC 6376 exige des clés RSA d'au moins 1024 bits pour un usage durable et les vérificateurs doivent gérer des clés jusqu'à 2048 bits ; 2048 bits est le choix moderne raisonnable, et faire tourner les clés périodiquement limite les dégâts si l'une fuite un jour.
DMARC : la politique qui relie le tout
DMARC est l'enregistrement qui donne un sens à SPF et DKIM pour le domaine que lit votre destinataire. Son idée centrale est l'alignement. Un message ne passe DMARC que lorsque SPF ou DKIM produit un pass et que ce pass repose sur un identifiant aligné avec le domaine From: visible (RFC 7489, section 4.2). C'est pourquoi un message peut passer le SPF brut et échouer à DMARC : si votre ESP envoie avec son propre domaine de Return-Path, SPF passe pour l'ESP, mais ce domaine n'est pas aligné avec votre From:, donc le volet SPF de DMARC échoue. L'alignement existe en deux modes — relâché, qui accepte un domaine organisationnel commun (mail.votreco.com s'aligne avec votreco.com), et strict, qui exige une correspondance exacte. Comme un seul mécanisme aligné suffit, l'alignement DKIM porte souvent le courrier que SPF ne peut pas, comme les messages transférés. L'enregistrement lui-même s'écrit v=DMARC1; p=none; rua=mailto:rapports@votreco.com ; la balise p fixe la politique (none, quarantine ou reject), rua indique où sont envoyés les rapports agrégés, et sp fixe une politique distincte pour les sous-domaines — qui prend la valeur de votre p si vous l'omettez.
Pourquoi c'est devenu obligatoire en 2024
L'authentification était autrefois une hygiène facultative. En février 2024, elle est devenue une barrière. Gmail et Yahoo imposent désormais aux gros expéditeurs — Google compte quiconque envoie plus de 5 000 messages par jour vers Gmail — de s'authentifier avec SPF et DKIM et de publier un enregistrement DMARC, qui peut démarrer à p=none. Le courrier marketing et les envois sur abonnement doivent aussi porter la désinscription en un clic : l'en-tête List-Unsubscribe (RFC 2369) et List-Unsubscribe-Post: List-Unsubscribe=One-Click, le mécanisme en un clic de la RFC 8058, pour que le client du destinataire puisse se désinscrire d'un seul POST HTTPS. Vous pouvez lire l'ensemble des règles Gmail et Yahoo dans le guide de délivrabilité. Deux points à noter : l'application s'est durcie depuis 2024, alors construisez selon la règle même sous 5 000 par jour, et garder un taux de plaintes bas figure au même rang que l'authentification, pas comme une option.
Les erreurs courantes qui cassent l'authentification en silence
- Publier +all sur votre enregistrement SPF, ce qui autorise l'internet entier à envoyer en votre nom — l'inverse du but.
- Publier plus d'un enregistrement v=spf1 sur le même domaine, ce qui renvoie permerror et annule SPF.
- Dépasser la limite de dix requêtes DNS à mesure que vous ajoutez des include de prestataires, ce qui renvoie aussi permerror.
- Une clé DKIM trop courte ou jamais renouvelée, si bien qu'une clé fuitée ou cassée par force brute continue de signer indéfiniment.
- Passer directement à p=reject sans lire le moindre rapport agrégé, ce qui bloque du courrier légitime que vous aviez oublié d'envoyer.
- Oublier sp= pour les sous-domaines, laissant une politique laxiste exposer marketing.votreco.com à l'usurpation.
- Un expéditeur tiers — un ESP, un outil de facturation, un service d'assistance — que vous n'avez jamais amené à l'alignement SPF et DKIM, si bien que son courrier échoue à DMARC.
La place de l'authentification dans votre stack
L'authentification est le socle sur lequel tout le reste repose. Si vous hébergez vous-même, vous détenez le DNS et les clés de signature en propre, la forme la plus forte de contrôle sur votre identité d'expéditeur. Une plateforme d'engagement client devrait afficher l'état d'authentification et d'alignement de chaque domaine d'envoi plutôt que le cacher, pour voir d'un coup d'œil quelles sources passent. Acheminez l'e-mail transactionnel et marketing sur des flux séparés et, idéalement, des sous-domaines distincts, pour qu'un pic de plaintes marketing ne menace jamais la distribution des réinitialisations de mot de passe. Et ordonnez le travail correctement : l'authentification et l'alignement viennent d'abord, avant le préchauffage du domaine — préchauffer un domaine non authentifié ne fait qu'apprendre aux fournisseurs à se méfier de vous plus vite.