Bonjour,
J'ai parcouru plusieurs fils concernant des mails non distribués vers des domaines sfr.fr, laposte.net pour cause de "550 5.7.24 SPF permanent error".
J'ai ce même problème, mais ne trouve pas de solution (ou ne la comprend pas…)
Ce que je comprends est que les domaines rejettent les emails car l'enregistrement SPF renvoie sur des PTR qui ne semblent pas acceptés par les destinataires sfr.fr, laposte.net.
N'étant pas un pro du DNS ou de la config d'email, je compte sur votre soutien pour m'éclairer 
@Fritz2cat et @janus57 >> J'ai lu vos nombreuses réponses à ce sujet sur des fils plus anciens, mais désolé de reposer à nouveau cette question …
Source : https://www.dmarcanalyzer.com/spf/checker/
PTR mechanism used
We recommend not to use PTR as this is a deprecated mechanism and several senders may (completely) ignore the SPF record when this method is used.
Source du mail rejeté (exemple laposte.net)
This is the mail system at host mo5.mail-out.ovh.net.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
: host smtpz4.laposte.net[160.92.124.66] said: 550
5.7.24 SPF permanent error: (in reply to end of DATA command)
Reporting-MTA: dns; mo5.mail-out.ovh.net
X-Postfix-Queue-ID: 58F322D3210
X-Postfix-Sender: rfc822; xxxx@MYDOMAIN.fr
Arrival-Date: Fri, 1 Oct 2021 17:01:02 +0200 (CEST)
Final-Recipient: rfc822; xxx@laposte.net
Original-Recipient: rfc822;xxx@laposte.net
Action: failed
Status: 5.7.24
Remote-MTA: dns; smtpz4.laposte.net
Diagnostic-Code: smtp; 550 5.7.24 SPF permanent error:
MYDOMAIN.fr
ça ne va pas aider.
Je peux vous dire que vous avez dû faire une erreur dans votre SPF, un point c'est tout.
Hello Fritz2cat,
Merci pour ta réponse
J'ai modifié le domaine dans le log, je peux te le mp stp ?
Bonjour,
si vous ne voulez pas donner le domaine il y a une solution alternative : https://digwebinterface.com/
mettre votre domaine type "TXT" et cocher "Authoritative" puis montrer ce qui en resort (là par contre il ne faut absolument rien masquer).
Cordialement, janus57
J'ai modifié le domaine dans le log, je peux te le mp stp ?
Bien reçu le domaine en MP.
Je ne vois aucune violation de protocole dans ton SPF.
( "v=spf1 include:mx.ovh.com ~all" )
Bonjour Fritz2cat,
Merci pour ta réponse.
Ce que je ne comprends pas c'est pourquoi le mail envoyé est rejeté, et je pensais que c'était dû au renvoi de mx.ovh.com vers les PTR:
source : https://www.dmarcanalyzer.com/spf/checker :
DNS record 1 lookups + 2 additional lookups
v=spf1 include:mx.ovh.com ~all
Include
mx.ovh.com
Warning : You shouldn't use PTR lookups as they are deprecated
DNS record 2 lookups
v=spf1 ptr:1out.ovh.netout.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all
Où sont paramétrés ces 2 lookups en PTR ?? Est ce dans le mx.ovh.net, ou ai je loupé une config dans mon DNS ?
Est ce que ces PTR lookups sont à la base du rejet de mail vers laposte.net ?
Est ce que ces PTR lookups sont à la base du rejet de mail vers laposte.net ?
Si SFR et Laposte se mettent à rejeter les SPF contenant des PTR, alors là OVH a un gros gros souci à se faire.
Il y a effectivement deux PTR dans le SPF "mx.ovh.com" que vous appelez via l'include.
Le consortium SPF n'a jamais encouragé l'utilisation de PTR car cette méthode pourrait théoriquement être abusée. Mais de là à être dépréciée et rejetée par 2 sites majeurs français...
Bonjour,
Pour information je viens de tester depuis un MX Plan vers laposte.net et pas de refus lié au SPF.
Cordialement, janus57
Pour information je viens de tester depuis un MX Plan
à mon avis le domaine que @BernardC24 m'a communiqué en MP n'est pas celui de l'expéditeur du mail.
Le domaine de l’expéditeur est bien celui envoyé en mdp.
La seule adresse qui diffère est le "reply to" qui renvoie vers une autre adresse d'un autre domaine.
Je vous mp les sources complètes (sans adresse destinataire) pour les rejets sfr et laposte.
Le domaine de l’expéditeur est bien celui envoyé en mdp.
Je confirme.
Le Reply-to n'est jamais analysé dans les spécifications SPF.
SFR et Laposte utilisent exactement les mêmes logiciels, les plaintes concernant l'un se retrouvent toujours à l'identique chez l'autre (ou bien Laposte est hébergé chez SFR, qui sait ?)
OVH a envoyé le message depuis mo173.1out.ovh.netout.ovh.net qui est bien validé par votre SPF.
De deux choses l'une
ou bien l'analyseur d'enregistrements TXT chez SFR et laposte bloquent devant cet enregistrement dans votre zone DNS
TXT "8CA2FA0959D48E1A4ABE13115737FBED0F7B0180"
S'il ne sert à rien, supprimez-le.
S'il sert à quelque chose, supprimez le temporairement, refaites un essai de mail dans un peu plus d'une heure.
Merci pour cette première approche. J'ai passé le TTL à 3600 pour être sur que ce soit le spf qui réponde en 1er. J'attends la propagation pour voir si cela corrige le pb.
"De deux choses l'une" >> l'une est l'enregistrement TXT >> ok
Quelle pourrait être l'autre chose ?
Les entrées TXT de la zone DNS ont été renseignées historiquement, comment peut on savoir à quoi elles se rapportent ?
Les entrées TXT de la zone DNS ont été renseignées historiquement, comment peut on savoir à quoi elles se rapportent ?
TXT "8CA2FA0959D48E1A4ABE13115737FBED0F7B0180"
Ce format m'est inconnu. La plupart du temps chaque service qui demande de mettre une entrée TXT ou CNAME met un indicateur sous la forme indicateur=valeur, ou bien dans le sous-domaine comme ovhcontrol.example.com
Voyez les TXT de Google par exemple:
;; ANSWER SECTION:
google.com. 3208 IN TXT "google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"
google.com. 3208 IN TXT "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com. 3208 IN TXT "globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
google.com. 3208 IN TXT "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
google.com. 3208 IN TXT "google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"
google.com. 3208 IN TXT "apple-domain-verification=30afIBcvSuDV2PLX"
google.com. 3208 IN TXT "docusign=1b0a6754-49b1-4db5-8540-d2c12664b289"
google.com. 3208 IN TXT "MS=E4A68B9AB2BB9670BCE15412F62916164C0B20BB"
google.com. 3208 IN TXT "v=spf1 include:_spf.google.com ~all"
Quelle pourrait être l'autre chose ?
C'est la supposition qu'ils n'accepteraient plus le PTR, mais en fait non, la moitié de la France est chez OVH et 1/4 est chez SFR ou Laposte...
Ca ferait beaucoup plis de plaignants.
Oui, effectivement c'est plus propre ! Les joies de reprendre une config sans savoir ce que ça représente …
Je les ai viré de ma zone DNS, j'attends de voir si je retrouve du rejet de mails sur les domaines lapsoste et sfr … Je vous tiens au courant, et merci pour infos
We recommend not to use PTR as this is a deprecated mechanism and several senders may (completely) ignore the SPF record when this method is used.
Du coup, si les domaines ignorent le SPF, ils pourraient passer le message en spam plus facilement, non ?
SPF quand il est déclaré dans votre domaine, n'a d'impact que pour les mails que vous envoyez.
La décision de SFR, Laposte et autres de classer un mail entrant comme ham ou comme spam dépend d'eux uniquement, j'ignore comment ils peuvent réagir face à un SPF qui contient un PTR.