Authentification email : guide actionnable SPF, DKIM et DMARC
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 inbox s’érode, et votre marque reste expose à l’usurpation.
Pourquoi l’authentification conditionne inbox et protection de marque
Quand Gmail, Outlook / Microsoft 365, Yahoo, Orange, Free ou un filtre d’entreprise évaluent un message, ils ne « croient » pas l’adresse From affichée. Ils croisent des preuves techniques : qui est autorisé envoyer (SPF), si le contenu a été signé et non modifié (DKIM), et si 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 changement 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’auth se lit rarement seule : elle aggrave plaintes, réputation et, in fine, le dossier spam. Pour un diagnostic plus large, voir notre pilier [Emails en spam](https://www.ikusita.com/emails-en-spam).
Changer d’IP ou de domaine n’est pas la rponse à une auth cassée. Ce geste reste exceptionnel. Dans la majorité des cas, il faSut 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 brl 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 mcanismes 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 stratgie 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, lautre, ou les deux, via l’alignement.
DMARC : observer, puis enforcer
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.
### Parcours recommandé : observe puis enforce
1. Inventaire + SPF/DKIM sains sur tous les flux légitimes.
2. `p=none` (observation) avec `rua=` (rapports agrégés) vers une boîte ou un outil que vous lisez réellement.
3. Analyse des rapports : sources légitimes manquantes, usurpations, échecs d’alignement, partenaires fantômes.
4. 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.
5. 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 coupe des flux métier (factures, tickets, newsletters d’une filiale). Rester indéfiniment en `none` protège peu contre le phishing. Le bon rythme dépend de votre cartographie d’metteurs, pas d’un slogan « reject immédiat ».
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*), Proposed Standard, qui obsolète RFC 7489 et RFC 9091. Le dernier brouillon, `draft-ietf-dmarc-dmarcbis-41` (avril 2025), nest 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’implmentation. Le reporting, autrefois dans RFC 7489, est scindé : RFC 9990 (rapports agrgé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 en septembre 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é.
| Tag | Statut IANA / RFC 9989 | Rôle | Conduite |
| --- | --- | --- | --- |
| `v` | active | Version, valeur unique `DMARC1` | Obligatoire, en premier |
| `p` | active | Politique du domaine | Conservé |
| `sp` | active | Politique des sous-domaines existants | Conservé si besoin |
| `np` | active (nouveau) | Politique des sous-domaines inexistants | Optionnel, utile anti-spoofing |
| `psd` | active (nouveau, RFC 9091 absorbée) | Frontière PSD / organisation | Surtout PSO ; défaut `u` |
| `t` | active (nouveau) | Mode test (binaire) | Remplace l’esprit de `pct`, pas le pourcentage |
| `adkim` / `aspf` | active | Alignement DKIM / SPF (r/s) | Défaut relaxed |
| `rua` | active (format dans RFC 9990) | Rapports agrégés | Conservé |
| `ruf` | active (format dans RFC 9991) | Rapports d’échec | Conservé, rarement honoré |
| `fo` | active | Options des rapports d’échec | Conservé, ignoré sans `ruf` |
| `pct` | historic (RFC 7489) | chantillonnage | Ne plus publier ; ignor si présent |
| `rf` | historic (RFC 7489) | Format des rapports dchec | Ne plus publier ; ignoré |
| `ri` | historic (RFC 7489) | Intervalle des rapports agrégés | Ne plus publier ; ignoré |
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.
## Alignement : le critre 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é. Rsultat : DMARC choue malgré des auth « vertes » 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](https://www.ikusita.com/migration) pose précisément ce protocole.
### 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 rel, 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](https://www.ikusita.com/suivi) délivrabilité, au même titre que Postmaster Tools ou les Feedback Loops : l’auth nest pas un projet « one shot DNS », c’est un contrôle continu.
BIMI (optionnel) : le logo aprs 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 enforce et une réputation saine. Nous ne le recommandons qu’une fois le socle d’authentification et d’alignement stabilisé.
DKIM2 : brouillon IETF, impact surtout côté opérateurss
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 incomplte).
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.
### Conduite pour nos clients
Nous suivons le WG IETF, mais nous ne basculons pas une architecture de production sur un Internet-Draft. La meilleure prparation reste un socle SPF / DKIM / DMARC solide, des flux cartographiés, et des rapports lus. Quand les opérateurs publieront un support réel, l’effort côté expditeur sera surtout de signer selon leurs exigences et de vérifier la coexistence, pas de rinventer la délivrabilité from scratch.
Sources à surveiller : Datatracker IETF, famille `draft-ietf-dkim-dkim2-*` (spec, BCP, DNS, motivation).
## 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. → [https://www.ikusita.com/audit](https://www.ikusita.com/audit)
- Formations : monter en autonomie vos équipes marketing, IT et conformité sur l’auth et la lecture des rapports. → [https://www.ikusita.com/formations](https://www.ikusita.com/formations)
- Gestion de crise : usurpation active, rejet massif lié à une auth cassée post-migration, ou médiation opérateurs / écosystème (Alliance Digitale, Signal Spam, EMDay selon le dossier). → [https://www.ikusita.com/gestion-de-crise](https://www.ikusita.com/gestion-de-crise)
- Emails en spam (diagnostic élargi) : [https://www.ikusita.com/emails-en-spam](https://www.ikusita.com/emails-en-spam)
- Suivi : garder l’auth et la réputation sous contrôle dans la durée. → [https://www.ikusita.com/suivi](https://www.ikusita.com/suivi)