SPF, DKIM, DMARC : pourquoi la délivrabilité email est difficile

L'email a un défaut de naissance : le protocole SMTP, conçu à une époque de confiance mutuelle, ne prévoit aucune authentification de l'expéditeur. N'importe quelle machine peut écrire ce qu'elle veut dans le champ From:. Toute la mécanique moderne de délivrabilité — SPF, DKIM, DMARC — est un empilement de rustines pour recoller, après coup, une identité vérifiable sur un protocole qui n'en avait pas. C'est cette origine « par correctifs successifs » qui explique pourquoi le sujet est aussi contre-intuitif : les trois mécanismes ne se recouvrent pas proprement, chacun répond à une question différente, et c'est leur articulation — pas chacun pris isolément — qui fait ou défait la remise d'un message.

Trois questions différentes, pas trois versions de la même

La première source de confusion, c'est de croire que SPF, DKIM et DMARC font « la même chose en mieux ». Non : ils répondent à trois questions distinctes.

SPF (Sender Policy Framework) autorise des machines à émettre pour un domaine. Le propriétaire d'un domaine publie, dans le DNS, la liste des serveurs habilités à envoyer en son nom. À la réception, le serveur destinataire regarde d'où vient concrètement la connexion et vérifie que cette source figure bien dans la liste. Point crucial : SPF ne contrôle pas l'adresse que l'humain voit (From:), mais l'expéditeur de l'enveloppe SMTP (le MAIL FROM, aussi appelé Return-Path). Enveloppe et en-tête visible peuvent diverger — et cet écart est précisément ce qui rendra l'alignement nécessaire plus loin.

DKIM (DomainKeys Identified Mail) signe cryptographiquement le message. Le serveur émetteur appose une signature numérique sur un jeu d'en-têtes et le corps ; le destinataire récupère la clé publique dans le DNS du domaine signataire et vérifie que le message n'a pas été altéré et provient bien d'une entité détenant la clé privée. DKIM ne dit rien sur qui a le droit d'envoyer ; il atteste que ce message précis est authentique et intact. C'est une garantie d'intégrité et d'origine, pas d'autorisation.

DMARC (Domain-based Message Authentication, Reporting and Conformance) est la politique qui relie le tout au domaine visible. DMARC ne réinvente aucune vérification : il s'appuie sur les résultats de SPF et de DKIM, et ajoute la question qui manquait — est-ce que l'identité authentifiée correspond bien au domaine que l'utilisateur voit dans le From: ? Il indique aussi au récepteur quoi faire en cas d'échec, et où envoyer les rapports.

Le résumé mental utile : SPF parle de l'enveloppe, DKIM parle de la signature, DMARC parle de la politique et de la cohérence. Aucun ne suffit seul.

L'alignement : le concept que tout le monde rate

Voici le piège le plus fréquent, et le plus coûteux à diagnostiquer. Un message peut passer SPF et passer DKIM, et pourtant échouer DMARC. Ça paraît absurde tant qu'on n'a pas compris l'alignement.

DMARC n'accepte pas un « SPF réussi » ou un « DKIM réussi » dans l'absolu. Il exige que le domaine validé soit aligné avec le domaine du From: visible.

• Alignement SPF (aspf) : le domaine du MAIL FROM (enveloppe) doit correspondre au domaine du From:.
• Alignement DKIM (adkim) : le domaine (d=) de la signature DKIM doit correspondre au domaine du From:.

DMARC est satisfait dès qu'au moins un des deux est à la fois valide et aligné. C'est la subtilité : SPF peut réussir techniquement mais sur un domaine d'enveloppe différent (typique d'un routeur transactionnel tiers qui met son propre Return-Path) — alors SPF « passe » mais n'est pas aligné, donc ne compte pas pour DMARC. Si DKIM n'aligne pas non plus, DMARC échoue malgré deux voyants au vert pris séparément.

Chaque alignement a un mode strict ou relâché (relaxed). En relâché, un sous-domaine suffit à s'aligner avec le domaine organisationnel ; en strict, l'égalité exacte est requise. Le relâché est le défaut sensé dans la quasi-totalité des cas — le strict casse silencieusement dès qu'un service légitime émet depuis un sous-domaine.

C'est là que se voit la maîtrise : non pas « ai-je activé SPF et DKIM », mais « mes identités authentifiées s'alignent-elles avec ce que le destinataire lit ? ».

Pourquoi un simple transfert casse tout (et la réponse SRS)

Le cas d'école qui humilie les configurations naïves : le forward. Un utilisateur met en place une redirection automatique de sa boîte vers une autre. Le serveur intermédiaire reçoit le message, puis le réémet vers la destination finale — depuis sa propre IP, qui n'a évidemment jamais été déclarée dans le SPF du domaine d'origine. Résultat : SPF échoue à l'arrivée. Le message était parfaitement légitime, mais la mécanique du transfert l'a fait sortir du périmètre autorisé.

DKIM résiste mieux au transfert (la signature survit tant que le relais ne modifie ni les en-têtes signés ni le corps — ce qui n'est pas garanti : une bannière ajoutée, un réencodage, et la signature saute). Mais SPF, lui, est structurellement cassé par le simple fait de changer d'expéditeur d'enveloppe.

La réponse historique est SRS (Sender Rewriting Scheme) : le serveur qui transfère réécrit le Return-Path pour y mettre son propre domaine, de sorte que SPF soit vérifié contre lui (qui, lui, s'autorise). SRS règle le problème SPF du transfert — au prix d'une complexité supplémentaire et, surtout, en désalignant ce Return-Path du From: d'origine. D'où la conséquence pratique : dans un monde qui transfère beaucoup, on ne peut pas s'appuyer sur SPF pour porter DMARC, il faut miser sur DKIM (qui survit au transfert) comme pilier d'alignement. Comprendre ça évite des heures de faux diagnostics.

Quarantaine, Indésirables, et le vocabulaire trompeur

Autre nid à confusion : le vocabulaire des sanctions. DMARC propose trois politiques — none, quarantine, reject — mais leur traduction concrète chez le récepteur n'est pas standardisée et prête à malentendu.

• none : « observe, ne sanctionne pas ». Le message est traité normalement ; DMARC se contente de rapporter. C'est un mode d'écoute, pas de protection.
• quarantine : « traite comme suspect ». En pratique, le plus souvent, le message atterrit dans le dossier Indésirables/Spam — mais « quarantaine » au sens DMARC et « dossier Indésirables » ne sont pas synonymes : le premier est une instruction de politique, le second une décision d'implémentation du récepteur, qui peut aussi choisir un marquage, une mise en attente, ou autre. Deux fournisseurs peuvent interpréter quarantine différemment.
• reject : « refuse à la porte ». Le message est rejeté au niveau SMTP ; l'expéditeur reçoit un non-remise. Rien n'arrive, pas même dans les Indésirables.

La confusion « quarantine = ça arrive quand même dans les spams, donc c'est inoffensif » est dangereuse : pour un domaine transactionnel (factures, réinitialisations de mot de passe), atterrir en Indésirables est déjà un échec métier majeur. La politique n'est pas un curseur de gravité anecdotique : c'est un choix qui a des conséquences business directes.

Le durcissement progressif : none → quarantine → reject

La discipline centrale de DMARC, celle qui distingue un praticien d'un copieur-colleur de tutoriels, c'est de ne jamais sauter d'étape.

Passer directement en reject sur un domaine dont on ne connaît pas encore tous les flux légitimes revient à bloquer son propre courrier. Or presque personne n'a une cartographie exhaustive de ses émetteurs : il y a l'outil de facturation, la plateforme marketing, le CRM, le serveur applicatif, le service RH, les alertes de supervision, l'ancien script oublié sur une machine oubliée… Chacun doit émettre de façon alignée (SPF aligné ou DKIM aligné) avant que reject ne devienne sûr.

D'où le chemin en trois temps :

1. p=none + rapports (rua) actifs. On ne sanctionne rien, on écoute. Les rapports agrégés révèlent, jour après jour, tous les émetteurs qui utilisent le domaine — les légitimes qu'on avait oubliés, et les usurpateurs. On corrige les légitimes (on aligne, on ajoute les enregistrements DKIM manquants) jusqu'à ce que le trafic authentifié soit propre.
2. p=quarantine, souvent avec un pct (pourcentage) partiel pour monter graduellement. On commence à sanctionner les échecs, mais de façon récupérable (Indésirables), en surveillant qu'aucun flux légitime ne tombe.
3. p=reject seulement quand les rapports montrent que 100 % du trafic légitime aligne. Là, et seulement là, on peut refuser tout le reste sans se tirer une balle dans le pied.

Sauter de 1 à 3 « parce que c'est plus sécurisé », c'est confondre la posture (reject est la posture la plus forte) et le chemin (on n'y arrive qu'après avoir tout inventorié). La sécurité ici n'est pas un interrupteur, c'est une migration surveillée.

Les rapports (rua) : le seul moyen de voir dans le noir

Sans rapports, on pilote à l'aveugle. La balise rua de DMARC demande aux récepteurs d'envoyer des rapports agrégés (typiquement quotidiens) : pour chaque source d'envoi, combien de messages, depuis quelles IP, avec quels résultats SPF/DKIM et quel alignement. C'est l'instrument qui rend le durcissement possible — sans lui, on ne saurait ni qui émet légitimement, ni qui usurpe, ni quand reject devient sûr.

Ces rapports arrivent en XML brut, peu lisibles à l'œil ; en pratique on les agrège avec un outillage (interne ou service dédié) pour en tirer une vue « qui envoie quoi, aligné ou pas ». La compétence se voit dans la lecture de ces signaux : distinguer un flux légitime mal configuré (à réparer) d'une usurpation (à ignorer côté légitimité, mais qui confirme qu'il faut serrer la politique).

Il existe aussi les rapports d'échec (ruf, forensiques), plus détaillés mais porteurs de données personnelles et donc peu émis par les récepteurs pour des raisons de confidentialité — on s'appuie donc surtout sur rua.

Lire les signaux : là où le diagnostic se gagne

Quand un message légitime tombe malgré tout, le réflexe amateur est de tout reconfigurer au hasard. Le réflexe de praticien est de lire les en-têtes d'un message rejeté ou quarantiné. Les récepteurs y déposent leur verdict : un résultat d'authentification qui indique séparément l'état de dkim=, de spf=/dmarc=, et parfois un verdict composite propre au fournisseur (compauth= chez certains). Ces champs disent exactement lequel des trois mécanismes a échoué, et surtout si c'est l'alignement plutôt que la vérification qui a lâché.

Un exemple de péripétie classique — le genre de saga qui arrive à tout le monde : tout semble en ordre, DKIM est « configuré », et pourtant les messages partent en quarantaine. Le diagnostic par les en-têtes révèle un dkim=fail. La cause, elle, est sournoise : la clé DKIM publiée dans le DNS ne correspond plus à la clé privée réellement utilisée sur le serveur d'envoi (rotation faite d'un côté, pas de l'autre ; ou copie incomplète lors d'une migration). La signature est donc bien apposée, mais invérifiable — DKIM échoue, l'alignement DKIM tombe, et si SPF n'aligne pas non plus, DMARC bascule en quarantaine. Le fix est trivial une fois la cause vue (resynchroniser clé DNS et clé on-disk) ; tout le travail était dans la lecture du signal, pas dans la correction.

C'est la morale de tout le sujet : la délivrabilité ne se « configure » pas une fois pour toutes. C'est une boucle — publier, observer les rapports et les en-têtes, corriger, durcir d'un cran, réobserver. Le protocole est simple à décrire et retors à faire tenir en production, parce que la vérité n'est jamais dans la config qu'on croit avoir posée, mais dans les signaux que renvoient les récepteurs.

Pourquoi c'est intrinsèquement difficile — le mot de la fin

Trois raisons de fond, au-delà des détails :

1. C'est un système distribué sans autorité centrale. Émetteur, DNS, relais, récepteur : chacun a ses règles, et personne n'a de vue d'ensemble. On agit d'un seul côté (le sien) et on ne découvre le verdict qu'après coup, via des rapports différés.
2. Les mécanismes interagissent de façon non triviale. SPF, DKIM et DMARC ne s'additionnent pas : l'alignement, le transfert, le désalignement induit par SRS créent des cas où « tout est vert » et pourtant « ça échoue ». La difficulté est dans les couplages, pas dans les briques.
3. L'inventaire des émetteurs légitimes est presque toujours incomplet. Le durcissement progressif existe précisément parce qu'on ne connaît jamais d'avance tous ceux qui envoient en son nom. La discipline consiste à découvrir avant de sanctionner.

Maîtriser la délivrabilité, ce n'est donc pas connaître trois acronymes. C'est tenir une boucle de configuration, d'observation et de durcissement, en sachant lire les signaux que le reste du monde renvoie — et en résistant à la tentation de tout serrer d'un coup.