Tout le courrier externe à Office 365 échoue SPF, marqué comme indésirable par EOP dans un déploiement hybride

En bref: les e-mails légitimes atterrissent dans les dossiers indésirables car EOP (Exchange Online Protection) tamponne les e-mails comme indésirables (SCL5) et échec SPF. Cela se produit avec tous les domaines externes (par exemple gmail.com/hp.com/microsoft.com) vers le domaine du client (contoso.com).

Informations de fond:

Nous sommes au début de la migration des boîtes aux lettres vers Office 365 (Exchange Online). Il s'agit d'une configuration de déploiement hybride / coexistence riche, où:

• Sur site = Exchange 2003 (hérité) et 2010 (installé pour le déploiement hybride)
• Hors site = Office 365 (Exchange Online)
• EOP est configuré pour la vérification SPF.
• Les enregistrements MX pointent sur le site car nous n'avons pas terminé la migration de toutes les boîtes aux lettres du site vers Exchange Online.

Le problème est que lorsque des utilisateurs externes envoient des e-mails à une boîte aux lettres Office 365 dans l'organisation (flux de messagerie: externe -> passerelle de messagerie -> serveurs de messagerie locaux -> EOP -> Office 365), EOP effectue une recherche SPF et hard / soft messages défaillants avec l'adresse IP externe de la passerelle de messagerie à partir de laquelle il a reçu le courrier.

(Les boîtes aux lettres locales ne présentent pas ce problème; seules les boîtes aux lettres migrées vers Office 365 le font.)

Une illustration:

Exemple 1: de Microsoft à O365

Authentication-Results: spf=fail (sender IP is 23.1.4.9) 
smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate
23.1.4.9 as permitted sender) receiver=protection.outlook.com; client-ip=23.1.4.9; 
helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5

Exemple 2: de HP à O365

Authentication-Results: spf=none (sender IP is 23.1.4.9) 
smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none 
(message not signed) header.d=none; Received-SPF: None 
(protection.outlook.com: hp.com does not designate permitted sender hosts) 
X-MS-Exchange-Organization-SCL: 5

Exemple 3: de Gmail à O365

Authentication-Results: spf=softfail (sender IP is 23.1.4.9) 
smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com; 
dkim=fail (signature did not verify) header.d=gmail.com; 
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning 
gmail.com discourages use of 23.1.4.9 as permitted sender)  
X-MS-Exchange-Organization-SCL: 5

Pour les en-têtes de message avec X-Forefront-Antispam-Report, reportez-vous à http://pastebin.com/sgjQETzM

Remarque: 23.1.4.9 est l'adresse IP publique du connecteur de serveur hybride Exchange 2010 local vers Exchange Online.

Comment empêcher les e-mails externes d'être marqués comme indésirables par EOP pendant la phase de coexistence d'un déploiement hybride?

[Mise à jour du 12 décembre 2015]

Ce problème a été résolu par le support d'Office 365 (l'équipe escaladée / backend) car cela n'a rien à voir avec nos paramètres.

On nous a suggéré ce qui suit:

1. Mettre en liste blanche l'adresse IP publique dans la liste d'autorisation EOP (essayé. Cela n'a pas aidé.)
2. Ajouter un enregistrement SPF pour notre domaine: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY inclure: spf.protection.outlook.com -all" (Ne pensez pas que cette suggestion est valide car EOP ne doit pas comparer gmail.com à notre adresse IP SMTP car elle n'est pas spécifiée dans les enregistrements SPF de gmail.com. Cela ne semble pas ainsi fonctionner SPF.)
3. Assurez-vous que TLS est activé (voir ci-dessous)

La partie clé est le troisième point. "Si le TLS n'est pas activé, les e-mails entrants provenant d'Exchange local ne seront pas marqués en tant qu'e-mails internes / de confiance, et EOP vérifiera tous les enregistrements", a déclaré le support.

Le support a déterminé un problème TLS à partir de nos en-têtes de messagerie par la ligne ci-dessous:

• X-MS-Exchange-Organization-AuthAs: anonyme

Cela indique que TLS n'était pas activé lorsque EOP a reçu un e-mail. EOP n'a pas traité l'e-mail entrant comme un e-mail de confiance. La bonne devrait être comme:

• X-MS-Exchange-Organization-AuthAs: interne

Cependant, cela n'a pas été causé par nos paramètres; le support nous a aidés à nous assurer que nos paramètres étaient corrects en vérifiant les journaux SMTP détaillés de notre serveur hybride Exchange 2010.

À peu près au même moment, leur équipe de backend a résolu le problème sans nous dire ce qui l'avait causé (malheureusement).

Après l'avoir corrigé, nous avons constaté que les en-têtes de message présentaient des modifications importantes comme ci-dessous.

Pour le courrier d'origine interne d'Exchange 2003 vers Office 365:

• X-MS-Exchange-Organization-AuthAs: interne (c'était "Anonymous")

• SCL = -1 (C'était SCL = 5)

• Received-SPF: SoftFail (C'était la même chose)

Et pour les courriers externes (par exemple gmail.com) vers Office 365:

• X-MS-Exchange-Organization-AuthAs: anonyme (c'était la même chose)

• SCL = 1 (C'était SCL = 5)

• Received-SPF: SoftFail (C'était la même chose)

Bien que la vérification SPF échoue toujours pour gmail.com (externe) à Office 365, la personne de support a déclaré que tout allait bien et que tous les e-mails iraient dans la boîte de réception au lieu du dossier indésirable.

En guise de remarque, lors du dépannage, l'équipe du backend a trouvé un problème de configuration apparemment mineur - nous avions l'IP de notre connecteur entrant (c'est-à-dire l'IP publique du serveur hybride Exchange 2010) définie dans notre liste d'autorisation IP (suggérée par un autre support Office 365 personne comme étape de dépannage). Ils nous informent que nous ne devrions pas avoir besoin de le faire et qu'en fait, cela peut entraîner des problèmes de routage. Ils ont déclaré que lors de la première passe, le courrier électronique n'était pas marqué comme spam, il y avait donc également un problème possible ici. Nous avons ensuite supprimé l'IP de la liste d'adresses IP autorisées. (Cependant, le problème de spam existait avant le réglage de la liste verte IP. Nous ne pensions pas que la liste verte était la cause.)

En conclusion, "cela devrait être un mécanisme EOP", a expliqué la personne de soutien. Par conséquent, le tout devrait être causé par leur mécanisme.

Pour toute personne intéressée, le fil de dépannage avec l'une de leurs personnes de support peut être consulté ici: https://community.office365.com/en-us/f/156/t/403396

Êtes-vous sûr que le flux de messagerie va directement de votre serveur hybride vers O365?

Lorsque vous avez exécuté l'assistant hybride, il devrait avoir créé des connecteurs localement et dans O365, qui traiteront le flux de messagerie entre les forêts en tant que courrier interne. Cela signifie qu'il contournera les vérifications EOP / Spam et que vous ne devriez jamais voir ces messages SPF.

Si votre périphérique Edge modifie les en-têtes, cela peut être à l'origine de votre problème - entre votre serveur et O365, rien ne devrait modifier les en-têtes de message. Assurez-vous que vous n'avez pas de connecteur existant qui peut remplacer ceux créés par l'assistant hybride. Vous pouvez toujours supprimer les connecteurs existants qui ont été créés et réexécuter l'assistant pour les recréer.

Vérifiez vos règles de transport dans Exchange et assurez-vous qu'elles ne modifient pas le message avant de passer à O365, si elles les désactivent et testez à nouveau pour vous assurer que ce n'est pas votre problème.

Dernière (ou peut-être première) vérification que votre fédération est correctement configurée. Si ce n'est pas le cas, cela pourrait expliquer pourquoi votre courrier n'est pas traité correctement. C'est là que la réexécution de l'assistant hybride peut également vous aider.

Pas un expert ici, ça fait très longtemps que je n'ai pas joué avec Exchange mais je vais essayer de répondre au mieux de mes capacités.

Permet de discuter de la conception pendant une seconde, pourquoi ne routez-vous pas tout le trafic vers EOP d'abord, puis vers vos serveurs Exchange locaux? vous perdez une bonne fonctionnalité là-bas, il serait certainement plus facile pour vous de contrôler le spam à partir d'un seul emplacement (supposez que vous êtes local Exchange a un filtre anti-spam aussi).

Passons maintenant au problème du spam:

1. Flux de messagerie et connecteurs : J'ai le sentiment que les connecteurs ne sont pas correctement configurés, si tous vos e-mails entrants semblent provenir de la même adresse IP 23.1.4.9 au lieu de l'adresse IP du serveur de messagerie de l'expéditeur, il est certain que les vérifications SPF échoueraient , puisque son objectif est de vérifier l'adresse IP de l'expéditeur et le nom de domaine de cette adresse IP de l'expéditeur. Je passerais certainement un peu de temps à revoir la configuration des connecteurs, voici un bon lien pour cela: https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection(v=exchg.150 ) .aspx
2. Filtres anti-spam EOP et filtres de connexion : si la configuration IP des connecteurs est effectuée correctement, il est peut-être temps de regarder vos filtres anti-spam / connexion sous EOP, je créerais des filtres pour contourner la vérification des e-mails entrants à partir de l'IP 23.1.4.9, mais cela ferait que tous les e-mails entrants contourneraient les listes de vérification du filtre anti-spam, cela vous amène au problème mentionné au point précédent, vérifiez vos connecteurs et, de préférence, acheminez d'abord les e-mails entrants vers EOP.