Merci pour ton retour ! On est d'accord sur l'essentiel : SPF est indispensable, et ton explication (-all, autorisation des IP émettrices) me semble exacte.
Une précision, parce que ma phrase ne dit pas que « SPF est cosmétique » : elle porte sur l'include:spf.mailjet.com qu'on te demande d'ajouter au SPF de ton domaine (celui du From:). Le point est là : le SPF récupéré et évalué est celui du domaine du return-path (l'enveloppe), pas celui du From:. Or, pour un ESP qui gère les bounces (ex: Mailjet), le return-path est le domaine de l'ESP (ex: bnc3.mailjet.com), ou un return-path personnalisé bnc3.mondomaine.fr qui pointe (CNAME) vers le SPF de Mailjet. Le SPF du domaine du From n'est donc jamais consulté pour ces envois : d'où le côté cosmétique de cet include-là (le support Mailjet me l'a confirmé par écrit).
À l'inverse, quand c'est l'hébergeur de boîtes qui émet depuis @mondomaine.fr (messagerie « normale »), le return-path est bien @mondomaine.fr : là son SPF est consulté, et les includes correspondants (Proton, Google, OVH...) sont indispensables. C'est donc uniquement l'include Mailjet qui est inutile, parce que Mailjet n'utilise jamais le domaine du From comme return-path.
Bref, on est bien d'accord sur SPF ; la phrase visait ce cas précis.
Sur le -all : Comme le transfert casse SPF (l'enveloppe est conservée, mais l'IP du relais change), un receveur ne peut pas en faire un rejet absolu sans jeter du courrier légitime. C'est justement pour ça que SPF est aujourd'hui consommé via DMARC, en tandem avec DKIM (qui, lui, survit au transfert) : si SPF casse mais que DKIM est aligné, DMARC passe. SPF devient donc un signal parmi d'autres plutôt qu'un verrou. En revanche, sur le fait que ce soit « de moins en moins respecté » qu'avant ou que des messages disparaissent, je n'ai pas d'observation de première main, je te fais confiance là-dessus.
[^] # Re: SPF
Posté par Yanal-Yves . En réponse au journal Antispoofing e-mail (SPF, DKIM, DMARC, BIMI) : la synthèse que j'aurais aimé trouver. Évalué à 2 (+7/-5).
Merci pour ton retour ! On est d'accord sur l'essentiel : SPF est indispensable, et ton explication (-all, autorisation des IP émettrices) me semble exacte.
Une précision, parce que ma phrase ne dit pas que « SPF est cosmétique » : elle porte sur l'include:spf.mailjet.com qu'on te demande d'ajouter au SPF de ton domaine (celui du From:). Le point est là : le SPF récupéré et évalué est celui du domaine du return-path (l'enveloppe), pas celui du From:. Or, pour un ESP qui gère les bounces (ex: Mailjet), le return-path est le domaine de l'ESP (ex: bnc3.mailjet.com), ou un return-path personnalisé bnc3.mondomaine.fr qui pointe (CNAME) vers le SPF de Mailjet. Le SPF du domaine du From n'est donc jamais consulté pour ces envois : d'où le côté cosmétique de cet include-là (le support Mailjet me l'a confirmé par écrit).
À l'inverse, quand c'est l'hébergeur de boîtes qui émet depuis @mondomaine.fr (messagerie « normale »), le return-path est bien @mondomaine.fr : là son SPF est consulté, et les includes correspondants (Proton, Google, OVH...) sont indispensables. C'est donc uniquement l'include Mailjet qui est inutile, parce que Mailjet n'utilise jamais le domaine du From comme return-path.
Bref, on est bien d'accord sur SPF ; la phrase visait ce cas précis.
Sur le -all : Comme le transfert casse SPF (l'enveloppe est conservée, mais l'IP du relais change), un receveur ne peut pas en faire un rejet absolu sans jeter du courrier légitime. C'est justement pour ça que SPF est aujourd'hui consommé via DMARC, en tandem avec DKIM (qui, lui, survit au transfert) : si SPF casse mais que DKIM est aligné, DMARC passe. SPF devient donc un signal parmi d'autres plutôt qu'un verrou. En revanche, sur le fait que ce soit « de moins en moins respecté » qu'avant ou que des messages disparaissent, je n'ai pas d'observation de première main, je te fais confiance là-dessus.
Yanal-Yves