@SGDAoui en effet nous sommes bien d'accord.
Comme tu l'indiques SPF n'est pas non plus un truc hyper sécurisant, bien qu'il protège du gros des attaques non ciblées.
De ce point de vue, ne pas gérer un include qui n'existe plus en sortant une erreur "550 5.7.1 SPF permanent error: " me semble une punition sèvère.
Cela signifie que le jour où un presta de mailing change le FQDN de son include, cela provoque un effet domino. Si le chef marketing vous demande d'ajouter l'include pour tester que sa plate-forme de mailing fonctionne, pas de faute de frappe... avant ça n'avait de conséquences que vis à vis de la plate-forme de maling - ça devient une autre paire de manches. Cela signifie également qu'on devient dépendant de chacun des hébergeur de ces fameux include. Est-ce bien conforme? Je ne sais pas, mais ça m'étonnerait.
Le cas qui m'a concerné était une migration vers une messagerie Cloud. La société maintenait son propre include, l'avait gardé "au cas où", bien que vide. Depuis maintenant pas mal d'années, quand on reprend des SPFs, on voit une ribambelle d'include, pas forcément évidents à "nettoyer".
Pour DMARC, j'avoue ne pas avoir testé, et je n'ai rien sous la main pour le faire rapidement (remettre un include bidon, vérifier que ça dysfonctionne, et mettre en place DMARC). En effet ça ne coûte pas grand chose de le mettre en place, surtout lorsque nos deux comparses (SPF & DKIM) ont déjà été activés.
Conclusion: si vous avez des mails chez SFR, vous avez du recevoir nettement moins de pubs, newsletters & co depuis quelques semaines
Je viens de jeter un oeil au cas SFR/Yahoo... et ça me semble bien compliqué! pour le coup on n'a pas trop de maîtrise de ce qu'il se passe entre les serveurs SMTP SFR & Yahoo. Je tenterais de sortir en TLS à tout hasard.
Ils ne seraient pas un peu saturés de boulot SFR?!
