Bonjour à tous, J'ai eu un retour par le support de 1and1.fr. La raison de l'échec est "la présence d'un CNAME dans l'enregistrement MX du DNS du domaine destinataire. Celle-ci est interdite par la RFC2181".
Le fil [1] aborde la question mais j'ai du mal à anticiper s'il existe des cas de figure, où la présence d'un CNAME dans l'enregistrement MX du DNS est nécessaire. J'ai signalé la raison du blocage au prestataire destinataire. J'espère qu'il donnera une suite favorable à ma requête. Les paris sont ouverts ... [1] http://serverfault.com/questions/643672/why-does-rfc-2181-disallow-mx-record-with-a-cname-exchange Le 24 août 2016 à 22:04, BERTRAND Joël <joel.bertr...@systella.fr> a écrit : > Christophe a écrit : > >> Hello, >> > > 'soir, > > Le 24/08/2016 à 15:50, Olivier a écrit : >> >>> Bonjour, >>> >>> J'ai un correspondant particulier avec qui je n'arrive pas à échanger >>> d'email: >>> - il n'arrive pas à recevoir les miens et réciproquement. >>> >>> En utilisant mon compte personnel de courriel (Gmail, en >>> l'occurrence), j'arrive à échanger. >>> >>> Mon prestataire de courriel est 1and1. >>> Le sien est une SSII française qui a une clientèle de PME. >>> >>> Avant de solliciter 1and1, j'aimerai cerner d'avantage ce qui se passe >>> même si mes connaissances en matière de courriel sont celles d'un >>> simple utilisateur. >>> >>> Quelqu'un pourrait-il me guider quelque peu ? >>> >>> Slts >>> >> >> Pour compléter les autres réponses des colistiers : >> Les logs du serveur qui envoie le mail est une base certaine et qui >> permet de voir réellement ce qu'il se passe (si toutefois on peut y >> avoir accès). >> La vérification du dossier spam également. >> >> D'expérience et dans le cadre d'une activité professionnelle, il est >> véritablement préférable d'avoir son propre serveur mail, hébergé ou >> non, mais sur lequel on a la main, et sur lequel il est possible de >> consulter les logs. >> C'est très nettement plus rapide/facile pour voir ce qui cloche dans ce >> genre de situations. >> >> Pour diagnostiquer le soucis et étant donné les circonstances : c'est >> des deux côtés qu'il faut agir, ne serait-ce que pour savoir s'ils ont >> vu passer le mail en provenance de <user16...@chezmoi.glop> vers >> <user46322@chezleclient.machin> (et inversement) : chez 1and1 *et* le >> prestataire du domaine destinataire (d'expérience, c'est souvent le >> domaine destinataire qui bloque) ; De fait, il faudrait également >> demander (via le correspondant) au support de la SSII concernée pour >> voir s'ils ont également une trace du mail envoyé . >> >> D'expérience (une fois de plus) , l'envoi et la réception de mails est >> devenu un sujet complexe, notamment par les vérifications qui sont >> effectuées à l'arrivée d'un mail sur un serveur. >> Typiquement, l'activation d'une "greylist" mal paramétrée n'est pas >> forcément innocente dans le problème rencontré. >> >> @+ >> Christophe. >> > > Voir aussi du côté des champs SPF. Un correspondant de la liste a > eu une surprise avec un relais de smarthost qui a décidé de relayer son > domaine en IPv6 alors que la déclaration n'était pas faite dans le TXT du > domaine et qu'il l'avait verrouillé avec un '-all'. > > Par ailleurs, de plus en plus de domaines refusent les mails en > provenance de domaines sans enregistrement SPF. > > Cordialement, > > JKB > >
