Semua Email Eksternal ke Office 365 Gagal SPF, Ditandai sebagai Sampah oleh EOP dalam Penggunaan Hibrid

Singkatnya: email yang sah masuk ke folder Sampah sebagai EOP (Exchange Online Protection) menandai pesan email sebagai sampah (SCL5) dan gagal-SPF. Ini terjadi dengan semua domain eksternal (mis. Gmail.com/hp.com/microsoft.com) ke domain klien (contoso.com).

Info latar belakang:

Kami berada di awal migrasi kotak surat ke Office 365 (Exchange Online). Ini adalah konfigurasi Hybrid Deployment / Rich-Coexistence, di mana:

• On-Premises = Exchange 2003 (Legacy) & 2010 (Diinstal untuk Penggunaan Hibrid)
• Off-Premises = Office 365 (Exchange Online)
• EOP dikonfigurasi untuk pemeriksaan SPF.
• Catatan MX menunjuk di tempat karena kami belum menyelesaikan migrasi semua kotak surat dari di tempat ke Exchange Online.

Masalahnya adalah ketika pengguna eksternal mengirim email ke kotak surat Office 365 di organisasi (aliran surat: Eksternal -> Mail Gateway -> server surat lokal -> EOP -> Office 365), EOP melakukan pencarian SPF dan hard / soft gagal pesan dengan alamat IP menghadap eksternal Mail Gateway dari mana ia menerima surat.

(Kotak surat lokal tidak menunjukkan masalah ini; hanya kotak surat yang dimigrasi ke Office 365.)

Sebuah ilustrasi:

Contoh 1: dari Microsoft ke 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

Contoh 2: dari HP ke 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

Contoh 3: dari Gmail ke 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

Untuk tajuk pesan dengan X-Forefront-Antispam-Report, lihat http://pastebin.com/sgjQETzM

Catatan: 23.1.4.9 adalah alamat IP publik dari konektor server Exchange 2010 hibrid lokal ke Exchange Online.

Bagaimana kita menghentikan email eksternal agar tidak ditandai sebagai sampah oleh EOP selama tahap koeksistensi dari Penyebaran Hibrid?

[Pembaruan 2015-12-12]

Masalah ini diperbaiki oleh dukungan Office 365 (eskalasi / tim backend) karena tidak ada hubungannya dengan pengaturan kami.

Kami menyarankan yang berikut:

1. Daftar putih IP publik di Daftar Perbolehkan EOP (Mencoba. Tidak membantu.)
2. Tambahkan catatan SPF untuk domain kami: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY termasuk: spf.protection.outlook.com -semua" (Jangan menganggap saran ini valid sebagai EOP seharusnya tidak memeriksa gmail.com terhadap alamat IP SMTP kami karena tidak ditentukan dalam catatan SPF gmail.com. Tampaknya tidak seperti cara kerja SPF.)
3. Pastikan TLS diaktifkan (Lihat di bawah)

Bagian kuncinya adalah poin ketiga. "Jika TLS tidak diaktifkan, email masuk dari Exchange lokal tidak akan ditandai sebagai email internal / trust, dan EOP akan memeriksa semua catatan," kata dukungan.

Dukungan menentukan masalah TLS dari header email kami dengan baris di bawah ini:

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

Ini menunjukkan TLS tidak diaktifkan ketika EOP menerima email. EOP tidak memperlakukan email yang masuk sebagai email kepercayaan. Yang benar harus seperti:

• X-MS-Exchange-Organization-Autha: Internal

Namun, ini bukan disebabkan oleh pengaturan kami; orang yang membantu membantu kami memastikan pengaturan kami benar dengan memverifikasi log SMTP verbose dari server Exchange 2010 Hybrid kami.

Pada sekitar waktu yang sama, tim backend mereka memperbaiki masalah tanpa memberi tahu kami apa yang menyebabkannya (sayangnya).

Setelah mereka memperbaikinya, kami menemukan bahwa header pesan memiliki beberapa perubahan signifikan seperti di bawah ini.

Untuk email yang berasal dari internal dari Exchange 2003 ke Office 365:

• X-MS-Exchange-Organization-Autha: Internal (Itu "Anonim")

• SCL = -1 (Itu SCL = 5)

• Diterima-SPF: SoftFail (Itu sama)

Dan untuk email eksternal (mis. Gmail.com) ke Office 365:

• X-MS-Exchange-Organization-AuthAs: Anonymous (Itu sama)

• SCL = 1 (Itu SCL = 5)

• Diterima-SPF: SoftFail (Itu sama)

Meskipun pemeriksaan SPF masih gagal-gagal untuk gmail.com (eksternal) ke Office 365, orang yang mendukung mengatakan OK, dan semua email akan masuk ke Kotak Masuk alih-alih folder Sampah.

Sebagai catatan tambahan, selama pemecahan masalah, tim backend menemukan satu masalah konfigurasi yang tampaknya kecil - kami memiliki IP dari Konektor Masuk kami (yaitu IP publik dari Exchange 2010 server Hybrid) yang ditentukan dalam Daftar Perbolehkan IP kami (disarankan oleh dukungan Office 365 lain orang sebagai langkah pemecahan masalah). Mereka memberi tahu kami bahwa kami tidak perlu melakukan ini dan pada kenyataannya hal itu dapat menyebabkan masalah perutean. Mereka berkomentar bahwa pada pass awal, email tidak ditandai sebagai spam sehingga ada juga kemungkinan masalah di sini. Kami kemudian menghapus IP dari Daftar Perbolehkan IP. (Namun, masalah spam ada sebelum pengaturan IP Daftar Daftar dibuat. Kami tidak mengira Daftar Perbolehkan adalah penyebabnya.)

Kesimpulannya, "itu harus mekanisme EOP," kata orang yang mendukung. Karena itu, semuanya harus disebabkan oleh mekanisme mereka.

Bagi siapa pun yang tertarik, utas pemecahan masalah dengan salah satu personel pendukung mereka dapat dilihat di sini: https://community.office365.com/en-us/f/156/t/403396

Apakah Anda yakin aliran email akan langsung dari server Hybrid Anda ke O365?

Saat Anda menjalankan wizard hibrid, ia seharusnya membuat konektor secara lokal dan O365, yang akan menginjak aliran email di antara hutan sebagai email internal. Ini berarti ia akan melewati pemeriksaan EOP / Spam dan Anda seharusnya tidak pernah melihat pesan SPF tersebut.

Jika perangkat tepi Anda memodifikasi header, ini mungkin menyebabkan masalah Anda - antara server Anda dan O365 tidak ada yang mengubah header pesan. Pastikan Anda tidak memiliki konektor yang ada yang mungkin menggantikan konektor yang dibuat oleh wizard Hibrid. Anda selalu dapat menghapus konektor yang ada yang dibuat dan menjalankan kembali wizard untuk membuatnya kembali.

Periksa aturan transportasi Anda di Exchange dan pastikan mereka tidak mengubah pesan sebelum pergi ke O365, jika mereka menonaktifkannya dan menguji lagi untuk memastikan itu bukan masalah Anda.

Terakhir (atau mungkin yang pertama) periksa apakah federasi Anda dikonfigurasi dengan benar. Jika bukan itu sebabnya email Anda tidak diperlakukan dengan benar. Di sinilah menjalankan kembali wizard Hybrid dapat membantu Anda juga.

Bukan ahli di sini, sudah lama sekali sejak saya bermain dengan Exchange, tetapi saya akan mencoba menjawab dengan kemampuan terbaik saya.

Mari kita diskusikan desainnya sebentar, mengapa Anda tidak merutekan semua lalu lintas ke EOP terlebih dahulu dan kemudian ke server Exchange di tempat Anda? Anda kehilangan fungsionalitas yang baik di sana, itu pasti akan membuat segalanya lebih mudah bagi Anda untuk mengontrol spam dari satu lokasi (asumsikan bahwa Exchange lokal Anda juga memiliki filter anti spam).

Sekarang mari kita beralih ke masalah spam:

1. Alur dan Konektor Surat : Saya merasa bahwa konektor tidak diatur dengan benar, jika semua email masuk Anda tampaknya berasal dari alamat IP 23.1.4.9 yang sama dan bukan alamat IP server surat pengirim, untuk memastikan pemeriksaan SPF akan gagal , karena tujuannya adalah untuk memeriksa IP pengirim dan nama domain IP pengirim tersebut. Saya pasti akan meluangkan waktu untuk meninjau kembali cara pemasangan konektor, berikut ini tautan yang bagus untuk itu: https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection(v=exchg.150 ) .aspx
2. Filter Spam EOP dan Filter Koneksi : jika pengaturan IP konektor dilakukan dengan benar, mungkin ini saatnya Anda melihat filter spam / koneksi di bawah EOP, saya akan membuat filter untuk mem-bypass memeriksa email yang masuk dari IP 23.1.4.9, tetapi itu akan membuat semua email masuk memintas daftar periksa filter spam, ini membawa Anda ke masalah yang disebutkan di poin sebelumnya, periksa konektor Anda dan lebih baik, rutekan email masuk ke EOP terlebih dahulu.