SFR - Office 365 - SPF

[#1]

Bonjour,

Nous sommes une société avec nom de domaine et nous utilisons outlook office 365.

Je précise que nous sommes une société sécurisée.

Depuis lundi, tous les mails que nous adressons à nos clients qui utilisent : noos, numericable, clubinternet, neuf, sfr, ne reçoivent pas nos messages et nous recevons le message d'erreur ci-dessous.

Je ne pense pas que nous soyons les seuls en france...Au vu du message d'erreur, seul le destinataire (sfr) peut remédier au problème.

Nous n’avons pas pu remettre votre message adressé à ………..@noos.fr.

noos.fr n’a pas pu confirmer que votre message a été envoyé à partir d’un emplacement approuvé.

Office 365 Action requise   Destinataire Erreur de validation SPF

Résolution L’administrateur de courrier de votre organisation devra diagnostiquer et corriger les paramètres de courrier de votre domaine. Veuillez transférer ce message à l’administrateur de votre courrier.

Plus d’informations pour les administrateurs de courrier

Code d’état : 550 5.7.23 Cette erreur se produit lorsque la validation SPF (Sender Policy Framework) du domaine du destinataire échoué. Si vous êtes l’administrateur du courrier du destinataire, vérifiez auprès de votre bureau d’enregistrement de domaines que les enregistrements SPF associés à votre domaine sont configurés correctement. Office 365 ne prend en charge qu’un seul enregistrement SPF (c’est-à-dire, un enregistrement TXT qui définit SPF) pour votre domaine. Incluez le nom de domaine suivant : spf.protection.outlook.com. Si vous disposez d’une configuration hybride (c’est-à-dire, si certaines de vos boîtes aux lettres se trouvent dans le cloud et d’autres en local) ou si vous êtes client d’une offre Exchange Online Protection autonome, ajoutez l’adresse IP sortante de vos serveurs locaux à l’enregistrement TXT. Pour obtenir des informations et des instructions sur la configuration des enregistrements SPF, consultez les articles Personnaliser un enregistrement SPF pour valider le courrier sortant envoyé à partir de votre domaine et Enregistrements DNS externes pour Office 365.

Détails de l’erreur

Erreur signalée : 550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 SPF permanent error: Notification d’état de remise générée par : MRXP264MB0854.FRAP264.PROD.OUTLOOK.COM Serveur distant : msfrf2627.sfr.fr

[FR-28220]

Bonjour,

j'ai le même soucis (à priori depuis notre passage à office 365).

Notre prestataire nous dit que tout est bon et que cela vient de SFR, SFR me dit que cela de nous...

[SGDA]

Bonjour @RogerDu 

Effectivement la solution se trouve dans les rouages de la suite que seul un administrateur peut atteindre. Donc il faut le contacter en lui donnant ce fil de discussion pour qu'il effectue la correction.

[RogerDu]

Bonjour,

Ce n'est pas très clair et facile à corriger pour un néophyte.

De plus le lien : https://portal.office.com/adminportal/home ne peut pas etre utilisé par un particulier.

"Se connecter

Vous ne pouvez pas vous connecter ici avec un compte personnel. Utilisez votre compte professionnel ou scolaire à la place.

Je ne comprend pas pourquoi sans avoir modifié quoi que ce soit, c'est à l'utilisateur de faire des corrections.

Cordialement

Roger

[SGDA]

Bonsoir @VincentD59 

Merci pour ces précisions, et effectivement il faut agir au niveau de l'expédition, tout en sachant que comme l'indique @jlch1 dans un post ci-dessus, SFR applique une stricte interprétation qui génère un rejet en cas de présent de include superflu et non actif.

Comme je l'ai indiqué, une fois votre include configuré, il existe des outils pour le tester tels que

https://mxtoolbox.com/spf.aspx

https://toolbox.googleapps.com/apps/checkmx/

Bon courage

[VincentD59]

Bonjour,

La solution se trouve sur le lien suivant :https://docs.microsoft.com/fr-fr/microsoft-365/security/office-365-security/set-up-spf-in-office-365....

Cependant, je vous donne quelques explications car ce n'est pas forcément très clair.

Quand vous envoyez un mail à des adresses avec neuf.fr, ou sfr.fr, ... vous recevez une notification signalant que le mail n'a pas été distribué.

Le code erreur est 5.7.23.

Dans les explications données dans la notification, vous pouvez lire : 

"Cette erreur se produit lorsque la validation SPF (Sender Policy Framework) du domaine du destinataire échoué."

Cela laisse à penser que le problème provient du destinataire et pas de l'émetteur donc de vos serveurs. Mais c'est une erreur d'interprétation.

En allant sur le lien ci-dessus, vous pouvez lire ceci :

"si votre domaine personnalisé ne dispose pas d’un enregistrement TXT SPF, certains serveurs de réception peuvent totalement rejeter le message. En effet, le serveur de réception ne peut pas valider le fait que le message provient d’un serveur de messagerie autorisé"

En clair, pour éviter de véhiculer des mails usurpés ou hammeçonnés, certains serveurs DNS vérifient l'origine du DNS d'émission.

Vous devez donc paramétrer votre DNS sur Office 365, pour donner une authentification par un enregistrement TXT SPF.

Pour cela, il faut que votre administrateur aille sur le centre d'administration d'Office 365 : https://portal.office.com/adminportal/home

Puis sur configurer et domaine

Sélectionnez le domaine en question

Cliquez sur Gérer DNS

Configurer mes services en ligne

Des propositions de TXT SPF sont réalisées, vous pouvez les valider.

enregistrez et quitter

Normalement, cela fonctionne à nouveau : faîtes le test en envoyant un mail qui n'était pas reçu.

J'espère que cela résolvera votre problème.

[jlch1]

@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?!

[SGDA]

Bonjour,

Merci de ton post. Ta conclusion rejoint la mienne à savoir que l'application stricte du protocole SPF a révélé les lacunes des configurations des expéditeurs....mais aussi qu'une communication de la part de SFR aurait été très utilie.

Il existe actuellement des problèmes entre SFR et yahoo.fr (ou .com) . On peut suspecter là aussi un relèvement de standard de filtrage (arroseur arrosé ?)

et en ajoutant DMARC ?  (mais cela necessite que SPF soit accepté)

idem pour DKIM qui prouve que les entêtes non pas été modifiées ...mais elles seront ensuite traitées suivant SPF

[jlch1]

Bonjour,

Visiblement, la vérification SPF est devenue moins permissive. C'est dommage qu'il n'y ait pas eu de communication de la part de SFR, parce que ça a mis beaucoup de monde "dans le noir".

Simplement, lorsque des "include" sont renseignés dans SPF, ils doivent être encore valides. Parfois on laisse des valeurs historiques de peur d'une régression (ex: prestataire pour mailing). Désormais, SFR teste chaque valeur, et si elle ne contient pas d'élément, refus.

Pour info, même une stratégie DKIM ne prévaut pas.

Jean-Luc Ch.
Lan Explore

[SGDA]

Essayez de suivre les conseils de google

https://support.google.com/a/answer/33786?hl=fr

et commencer par tester votre nom de domaine avec

https://toolbox.googleapps.com/apps/checkmx/

[alexopti69]

Nous sommes dans le même cas.

Nos adresses mails sont gérées via Google Admin avec le nom de domaine de notre entreprise. 

Et depuis 4 semaines, nous ne pouvons plus adresser de mails aux boites SFR de nos clients.

Quelqu'un aurait-il la réponse sur la configuration à effectuer dans Google Admin pour que les boîtes SFR, Neuf... acceptent les mails de certains noms de domaine.