Authentification des emails :
SPF, DKIM et DMARC n’auront plus de secrets pour vous

L’authentification email est l’ensemble des protocoles (SPF, DKIM, DMARC, et BIMI en option) qui prouvent aux opérateurs de messagerie qu’un message prétendant venir de votre domaine est bien autorisé, non altéré, et aligné sur votre identité d’expéditeur. Sans elle, la confiance des opérateurs s’érode, et votre marque risque d’être victime d’usurpation.

Pourquoi l’authentification conditionne la réception et la protection de marque?

Quand Gmail, Outlook / Microsoft 365, Yahoo, Orange, Free, … ou un filtre antispam évaluent un message, ils ne « croient » pas l’adresse d’expéditeur affichée (From). Ils croisent des preuves techniques :

Qui est autorisé envoyer (SPF)?
Est-ce que le contenu a été signé et non modifié (DKIM)?
Est-ce que le domaine visible est aligné avec ces preuves (DMARC)?

Sans authentification cohérente, deux risques se cumulent :

1. Délivrabilité :
messages en spam, soft rejects, ou rejets durs,
surtout après migration de routeur, ajout d’un CRM ou modifications DNS.

2. Protection de marque :
un tiers peut usurper votre domaine pour du phishing. DMARC en politique stricte réduit cette surface ;
SPF et DKIM seuls ne suffisent pas à la fermer.

Nous croisons systématiquement marketing (qui envoie? pour quelles finalités?), technique (enregistrements, clés, alignement, rapports) et juridique (identité d’expéditeur, responsabilité en cas d’usurpation, lien avec le consentement et les plaintes). Une faille d’authentification se lit rarement seule : elle aggrave plaintes, réputation et, in fine, alimente le dossier spam. Pour un diagnostic plus large, voir notre tutoriel “Emails en spam?” (https://www.ikusita.com/emails-en-spam).

Changer d’IP ou de domaine n’est pas la réponse à une authentification cassée. Ce geste reste exceptionnel. Dans la majorité des cas, il faut corriger SPF / DKIM / DMARC et rétablir la confiance sur l’identité existante, pas fuir un historique en créant un nouvel actif « propre » qui sera ébranlé aussi vite si les causes ne sont pas traitées.

SPF : autoriser les émetteurs légitimes

SPF (Sender Policy Framework) publie, dans un enregistrement DNS TXT du domaine (ou sous-domaine) d’enveloppe, la liste des serveurs autorisés à émettre pour ce domaine. Au moment de la réception, le serveur distant compare l’IP d’émission à cette politique.

Ce qu’il faut faire concrètement

- Inventorier tous les émetteurs légitimes : routeur / ESP marketing, transactionnel, CRM, support, facturation, outils RH, hébergeur de boîtes, partenaires qui envoient « en votre nom ».

- Publier un seul enregistrement SPF par domaine (ou sous-domaine) concerné. Plusieurs TXT SPF concurrents cassent la validation.

- Utiliser les mécanismes adaptés (`include:`, `a`, `mx`, `ip4` / `ip6`) fournis par chaque fournisseur, puis terminer par une politique claire (`~all` en phase de durcissement prudent, `-all` quand l’inventaire est fiable).

- Vérifier après chaque ajout : propagation DNS, résultat `pass` / `softfail` / `fail` sur des messages réels, pas seulement un simulateur.

Limite critique : les lookups DNS

SPF impose une limite de 10 mécanismes DNS (lookups). Au-delà, le résultat peut devenir `permerror` : l’auth « casse » même si la liste dIP était juste. Multi-ESP, chaînes d’`include:` trop longues, et anciens partenaires oublis sont les causes les plus fréquentes. Consolidez, retirez les includes morts, et privilégiez des sous-domaines d’envoi ddiés plutôt qu’un SPF racine monstrueux.

DKIM : signer pour prouver l’intégrité

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique dans les en-têtes. Le destinataire récupre la clé publique via DNS (`selector._domainkey.domaine`) et vérifie que certains en-têtes et le corps n’ont pas été altrs en transit.

Ce qu’il faut faire concrètement

- Activer DKIM sur chaque flux d’envoi (marketing et transactionnel).
Un canal non signé crée des trous dans DMARC.

- Préférer des clés 2048 bits quand le fournisseur le permet.

- Choisir des sélecteurs stables, documenter qui les gère,
et prévoir la rotation (nouvelle clé publiée avant retrait de lancienne).

- Signer avec un domaine (ou sous-domaine) que vous contrôlez,
cohérent avec votre stratégie d’alignement DMARC.

- Contrôler les échecs DKIM après rewrite de liens, scan antivirus passerelle,
ou modification MIME par un intermédiaire.

DKIM ne dit pas « cette IP est autorisée ». Il dit « ce message, tel quel, est signé par le détenteur de cette clé ». C’est pourquoi SPF et DKIM se complètent, et pourquoi DMARC s’appuie sur l’un, l’autre, ou les deux, via l’alignement.

DMARC : observer, puis décider

DMARC (Domain-based Message Authentication, Reporting and Conformance) lie SPF et/ou DKIM au domaine de l’en-tête From (domaine organisationnel). Il publie une politique (`p=`) et demande des rapports pour voir ce qui passe, échoue, ou usurpe.

Ce qu’il faut faire concrètement

- Inventaire + SPF/DKIM sains sur tous les flux légitimes.

- `p=none` (observation) avec `rua=` (rapports agrégés) vers une boîte
ou un outil que vous lisez réellement.

- Analyse des rapports : sources légitimes manquantes,
usurpations, échecs d’alignement, partenaires fantômes.

- Durcissement progressif : `p=quarantine` (éventuellement `t=y` en mode test RFC 9989, à la place de l’ancien `pct=`), puis `p=reject` quand le bruit légitime est sous contrôle.

- Politiques de sous-domaines (`sp=`) cohérentes : un sous-domaine oublié en `none` alors que la racine est en `reject` laisse une porte ouverte.

Passer trop vite en `reject` sans lire les rapports peut couper des flux métier (factures, tickets, newsletters d’une filiale). Rester indéfiniment en `none` ne vous protègera pas contre le phishing.

DMARCbis (RFC 9989) :
statut, tags et conduite opérationnelle

En mai 2026, l’IETF a publié RFC 9989 (Domain-Based Message Authentication, Reporting, and Conformance), qui obsolète RFC 7489 et RFC 9091. Le dernier brouillon, `draft-ietf-dmarc-dmarcbis-41` (avril 2025), n’est plus un “Internet-Draft” : il est devenu RFC. Ce n’est pas une “Internet Standard” (échelon IETF supérieur). “Proposed Standard” signifie consensus de groupe, revue publique, et spécification jugée assez stable pour l’implémentation. Le reporting, autrefois dans RFC 7489, est scindé : RFC 9990 (rapports agrégés) et RFC 9991 (rapports d’échec par message). Les enregistrements restent en `v=DMARC1`.

Découverte du domaine organisationnel

RFC 7489 s’appuyait sur une Public Suffix List, sans PSL obligatoire. RFC 9989 définit un DNS Tree Walk : le récepteur interroge `_dmarc` sur le domaine From, puis remonte les labels (plafond de huit requêtes). Le tag `psd` (défaut `u`) sert aux opérateurs de suffixe public (`psd=y`) ou à déclarer une frontière organisationnelle (`psd=n`). Un titulaire de domaine de marque n’a en gnéral pas à publier `psd`. RFC 9091 (PSD DMARC) est absorbe dans RFC 9989.

Tags et sémantique (par rapport à RFC 7489)

Tags actifs nouveaux : `np` (politique pour sous-domaines inexistants, NXDOMAIN, syntaxe identique à `p` ; si absent, on retombe sur `sp` puis `p`), `psd`, `t` (mode test, défaut `n`). Avec `t=y`, le récepteur conforme abaisse d’un cran la politique appliquée (`reject` traité comme `quarantine`, `quarantine` comme `none`) sans changer la gnration des rapports. `pct`, `rf` et `ri` sont historic au registre IANA (mise à jour 22 mai 2026) : un récepteur RFC 9989 ignore ces tags. `rua`, `ruf` et `fo` restent dans l’enregistrement de politique ; seuls les formats et procédures de reporting sont dans RFC 9990 / 9991. L’alignement relaxed / strict (`adkim`, `aspf`, défaut relaxed) est inchangé, mais le domaine organisationnel vient du Tree Walk, plus de la PSL.

RFC 9989 durcit le message sur `p=reject` : un récepteur ne doit pas rejeter uniquement sur cette politique ; sans autre analyse, il doit traiter l’échec comme `quarantine`. Les domaines d’utilisateurs génraux (listes de diffusion) ne devraient pas publier `p=reject`. Un `p=reject` ne doit pas reposer uniquement sur SPF : DKIM aligné est requis.

Ce que nous pouvons faire maintenant

Nous continuons observe puis enforce, `rua`, `p` / `sp`, et l’inventaire des flux. Nous pouvons ajouter `np` pour fermer les sous-domaines fantômes. Nous ne publions plus `pct`, `rf` ni `ri`. `t=y` n’est pas un pourcentage : c’est un test binaire, utile seulement si le récepteur implémente RFC 9989. Le Tree Walk est côt récepteur ; le déploiement réel chez les opérateurs reste inégal à l’automne 2026. Nous n’attendons pas une RFC « finale » supplémentaire pour une politique saine, mais nous ne faisons pas dépendre la délivrabilité de `t` ni de `np` tant que le support n’est pas vérifié.

Sources (autoritaires) :
RFC 9989, Herr & Levine, Proposed Standard, mai 2026, Datatracker mis à jour le 20 mai 2026, https://datatracker.ietf.org/doc/rfc9989/ et https://www.rfc-editor.org/rfc/rfc9989 ; RFC 9990, Brotman, mai 2026, https://datatracker.ietf.org/doc/rfc9990/ ; RFC 9991, Jones & Vesely, mai 2026, https://datatracker.ietf.org/doc/rfc9991/ ; historique `draft-ietf-dmarc-dmarcbis-41` devenu RFC 9989 le 19 mai 2026, https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/history/ ; registre IANA DMARC Tags, dernière mise à jour 22 mai 2026, https://www.iana.org/assignments/dmarc-parameters/dmarc-parameters.xhtml ; errata RFC 9989, https://www.rfc-editor.org/errata/rfc9989.

L’alignement :
le critère que beaucoup oublient

Un SPF ou un DKIM « pass » ne suffit pas à DMARC. Il faut l’alignement avec le domaine From :

- Alignement SPF :
le domaine d’enveloppe (Return-Path / Mail From) s’aligne (strict ou relaxed) sur le From.

- Alignement DKIM :
le domaine de la signature (`d=`) s’aligne sur le From.

En pratique, beaucoup d’ESP signent correctement mais sur un domaine ESP, ou utilisent un Return-Path non aligné. Résultat : DMARC échoue malgré des authentification “validées” au niveau message. La remédiation classique : sous-domaine d’envoi sous votre marque, DKIM sur ce domaine, et SPF du sous-domaine qui autorise l’ESP.

Sans alignement, vous n’avez ni la meilleure délivrabilité possible, ni la protection de marque que DMARC est censé offrir.

Pièges fréquents
(et comment les éviter)

Migration de routeur / ESP

Changer d’outil sans republier SPF, sans activer DKIM sur le nouveau sélecteur, et sans recalibrer DMARC est l’incident d’auth le plus courant. Anticipez la double publication le temps du basculement, validez sur des seeds, puis retirez les includes de l’ancien ESP. Notre accompagnement migration de routeur pose précisément ce protocole.e.

Multi-ESP et multi-outils

Marketing sur un ESP, transactionnel sur un autre, CRM qui envoie encore, agence qui « teste » depuis sa plateforme : chaque oubli DNS = échec intermittent, difficile à reproduire. Cartographiez les flux avant de toucher à `p=`.

Trop de lookups SPF

Au-delà de 10 lookups, SPF devient imprévisible. Aplatissez la politique, segmentez par sous-domaine, supprimez les includes inutiles.

DMARC publié mais rapports ignorés

Sans lecture des `rua` (et `ruf` si pertinent et supporté), vous pilotez à l’aveugle. Les rapports révèlent usurpation, shadow IT email, et partenaires non déclarés.

Politique cosmétique

`p=none` sans plan de durcissement, ou `reject` sans alignement réel, donne une illusion de conformité. Les opérateurs et les attaquants ne s’y trompent pas longtemps…

Rapports DMARC : en faire un outil de pilotage

Les rapports agrégés (XML, souvent quotidiens) décrivent, par source IP / organisme, les résultats SPF, DKIM et l’alignement. Exploitez-les pour :

- confirmer que vos ESP légitimes passent en aligné ;

- détecter du spoofing sur votre marque ;

- prioriser les correctifs avant `quarantine` / `reject` ;

- alimenter une revue périodique (mensuelle au minimum en phase de durcissement).

Nous recommandons d’intégrer cette lecture au suivi délivrabilité (https://www.ikusita.com/suivi), au même titre que Postmaster Tools ou les boucles de rétroaction : l’authentification n’est pas un projet « one shot », c’est un contrôle continu.

BIMI : le logo après la confiance

BIMI (Brand Indicators for Message Identification) peut afficher votre logo dans certains clients de messagerie lorsque DMARC est suffisamment strict (souvent `quarantine` ou `reject` selon les exigences du moment) et que votre identité visuelle (et, selon les cas, un certificat de marque type VMC) est prête.

BIMI ne répare pas une mauvaise délivrabilité. C’est une couche de confiance visuelle qui vient après SPF, DKIM, DMARC et une réputation saine. Nous ne le recommandons qu’une fois le socle d’authentification et d’alignement stabilisé ainsi qu’une hygiène de base de données maîtrisée.

DKIM2 : brouillon IETF,
un impact surtout côté opérateurs

DKIM2 (DomainKeys Identified Mail v2) est un travail en cours au sein du groupe IETF DKIM. Ce n’est pas une RFC publiée ni un protocole déployé chez les grands oprateurs en septembre 2026. Les documents (`draft-ietf-dkim-dkim2-spec`, bonnes pratiques, DNS) voluent encore. Nous le mentionnons pour anticiper, pas pour reconfigurer immédiatement vos envois.

L’intention technique est de corriger des limites de DKIM1 et de l’cosystème actuel (rejeu de messages, modifications par intermédiaires, chaînes de transfert, DSN / bounces authentifiés). Là o DKIM1 atteste surtout qu’un domaine a signé un contenu à un moment donné, DKIM2 vise une chaîne de signatures par hop : chaque système qui traite le message peut signer, documenter ses modifications, et lier davantage le parcours (y compris des éléments liés à la source et à la destination). L’objectif côt rception est de mieux distinguer un message légitimement relayé d’un message rejoué hors contexte, et d’attribuer une réputation aux intermédiaires qui ont modifié le flux.

Pourquoi l’impact sera surtout pour les opérateurs de messagerie

Pour un annonceur ou une équipe marketing, le levier immédiat reste SPF, DKIM1, DMARC (RFC 9989) et l’alignement. DKIM2 ne change pas demain matin votre checklist DNS.

En revanche, les opérateurs de messagerie (Gmail, Microsoft, Yahoo, FAI, filtres d’entreprise, MTA / passerelles) devront, s’ils adoptent le protocole :

- valider des chaînes de signatures multi-hops, pas une seule signature d’auteur ;

- décider comment traiter l’absence de DKIM2 pendant une longue coexistence avec DKIM1, SPF, DMARC et éventuellement ARC ;

- intégrer ces signaux dans réputation, anti-spam, abuse, logs et diagnostics support ;

- grer les politiques locales (quels intermédiaires reconnaître, quelles modifications accepter, quel poids donner à une chaîne incomplète).

Les drafts de bonnes pratiques insistent sur le fait de ne pas traiter, en période de transition, la simple absence de DKIM2 comme un motif de rejet à elle seule. Les signataires et récepteurs continueront longtemps à croiser DKIM1 et DKIM2.

Quand faire appel à un audit, une formation ou une gestion de crise?

- Audit :
inventaire des flux, état SPF/DKIM/DMARC/BIMI,
alignement, lookups, écarts multi-ESP, plan de durcissement.
→ Audit

- Formations :
monter en autonomie vos équipes marketing,
IT et conformité sur l’authentification et la lecture des rapports.
→Formations

- Gestion de crise :
usurpation active, rejet massif lié à une authentification cassée post-migration,
ou médiation opérateurs / écosystème
→Gestion de cris

- Emails en spam (diagnostic élargi) :
Emails en spam

- Suivi :
garder l’authentification et la réputation sous contrôle dans la durée.
→Suivi