URL:     https://linuxfr.org/users/yanal-yves/journaux/antispoofing-e-mail-spf-dkim-dmarc-bimi-la-synthese-que-j-aurais-aime-trouver
Title:   Antispoofing e-mail (SPF, DKIM, DMARC, BIMI) : la synthèse que j'aurais aimé trouver
Authors: Yanal-Yves
Date:    2026-07-12T17:20:30+02:00
License: CC By-SA
Tags:    spoofing, claude, dmarc, spf, dkim, courriel et dns
Score:   1


Bonjour,

Ces derniers mois, j'ai dû mettre en place la protection antispoofing (SPF, DKIM, DMARC…) sur plusieurs noms de domaine, avec des configurations d'envoi variées : messagerie hébergée d'un côté, routeurs d'e-mailing (ESP) de l'autre.

Je m'attendais à quelques heures de travail. J'y ai passé des jours — non que les concepts soient inaccessibles, mais la documentation est éparpillée, souvent partielle (un mécanisme à la fois, rarement la chaîne complète ni l'alignement), et les instructions des prestataires ne collent pas toujours à la réalité technique (l'exemple du SPF réclamé par Mailjet, plus bas, l'illustre).

**À qui ça s'adresse.** J'écris pour le **propriétaire de domaine** qui veut protéger son domaine contre l'usurpation d'identité en s'appuyant sur un **hébergeur de boîtes mail** et/ou un ou plusieurs **ESP** (routeurs d'e-mailing). Ce **n'est pas** un guide d'auto-hébergement d'un serveur de mail : je ne parle pas de Postfix, OpenDKIM & co. Des ressources plus proches des RFC existent par ailleurs ; mon objectif était complémentaire — rester **simple et opérationnel**.

Plutôt que de laisser ce travail se perdre, je l'ai consigné dans une série de 9 articles, pensée comme une référence à laquelle revenir (et que d'autres peuvent réutiliser) :

1. Architecture et concepts
2. Les e-mails standards
3. FCrDNS et validation croisée
4. SPF
5. DKIM
6. DMARC
7. BIMI et analyse de ses limites
8. Parked Domain Locking
9. Synthèse et conclusion

C'est ici : <https://yanal.fargialla.com/antispoofing-e-mail/>

Un exemple du genre de piège que j'y documente : beaucoup d'ESP (Mailjet, dans mon cas) demandent d'ajouter un `include:spf.mailjet.com` au SPF du domaine, et affichent une coche rouge tant que ce n'est pas fait. Or, que le return-path soit personnalisé ou par défaut, la vérification SPF porte sur le domaine du return-path — jamais sur le SPF racine du domaine. Cet include est donc **purement cosmétique et ne sert à rien pour la délivrabilité**, ce que le support Mailjet m'a confirmé par écrit. Le détail est dans l'article DMARC : <https://yanal.fargialla.com/antispoofing-e-mail/06-dmarc-domain-based-message-authentication-reporting-and-conformance/>

**Transparence.** Les articles ont été rédigés avec l'assistance d'une IA. J'en ai défini la structure et la ligne pédagogique (ne jamais employer une notion avant de l'avoir présentée), et j'ai **relu la version française avec attention** pour que chaque phrase corresponde à ma compréhension réelle : ce site est ma « pensine », l'endroit où je reviens me remémorer ces notions après des mois sans toucher aux e-mails. La **version anglaise**, en revanche, est une traduction produite par l'IA que **je n'ai pas relue** — à lire avec cette réserve. Le tout est en accès libre, sans publicité, sous licence CC BY-SA 4.0. Techniquement, c'est un site statique Hugo.

Je suis preneur de retours et de corrections : le but est que ce soit juste et utile. Si des points vous paraissent imprécis ou discutables, dites-le, je corrigerai.