Tanggal Email Salah Setelah Migrasi Zoho ke Microsoft 365

Apa yang Terjadi di Kotak Surat Anda

Migrasi domain Anda dari Zoho Mail ke Microsoft 365 baru saja selesai. Infrastruktur Exchange Online sudah berjalan, kotak surat sudah diprovisikan, catatan MX sudah diperbarui. Lalu, Senin pagi, seorang pengguna membuka Outlook dan melihat semua email dari 2021 menampilkan tanggal hari ini. Pengguna lain menemukan pesan-pesan dari tahun lalu muncul di paling atas kotak masuk, seolah baru saja tiba. Tiket-tiket mulai berdatangan.

Ini bukan bug Outlook. Bukan juga masalah khusus Zoho. Ini adalah perilaku yang sudah diketahui, tapi kurang terdokumentasi, dari setiap migrasi IMAP ke Exchange Online. Memahami dengan tepat mengapa hal ini terjadi adalah langkah pertama untuk memperbaikinya dengan benar.

Akar Masalah Teknis: INTERNALDATE dan Header Received

Email yang tersimpan di server IMAP terdiri dari dua hal yang berbeda: isi pesan mentah (header RFC 2822, badan pesan, lampiran) dan metadata penyimpanan yang dikelola server IMAP, termasuk INTERNALDATE. Metadata inilah yang digunakan klien email untuk menampilkan dan mengurutkan pesan.

Header Date: yang ada di dalam pesan mentah (RFC 2822) merepresentasikan tanggal pesan dibuat atau dikirim oleh pengirim. INTERNALDATE, sebaliknya, adalah tanggal server IMAP menerima atau menyimpan pesan tersebut. Pada server yang sehat, kedua nilai ini biasanya berdekatan. Setelah migrasi, ceritanya berbeda.

Bagaimana Migrasi IMAP Merusak Tanggal

Ketika alat migrasi (Zoho Migration Wizard, imapsync, BitTitan, atau alat lainnya) memindahkan pesan dari Zoho Mail ke Exchange Online, prosesnya melalui protokol IMAP. Alat tersebut terhubung ke Zoho, mengambil pesan, lalu menyisipkannya ke Exchange Online via perintah IMAP APPEND. Di sinilah masalah mulai muncul.

Exchange Online, saat menerima setiap pesan, membuat header Received: baru yang ditempatkan di bagian paling atas pesan. Header ini mencatat tanggal dan waktu persis penyisipan, yaitu tanggal migrasi berlangsung. Beberapa alat migrasi mencoba mempertahankan INTERNALDATE asli dengan mengirimkannya sebagai parameter ke perintah APPEND. Yang lain tidak melakukannya, atau melakukannya dengan tidak tepat, sehingga Exchange Online secara otomatis menetapkan tanggal penerimaan sebagai INTERNALDATE.

Hasilnya: baik email yang dikirim tahun 2019 maupun 2022, INTERNALDATE-nya kini menunjuk ke minggu migrasi. Outlook membaca nilai ini sebagai prioritas utama. Urutan tampilan pun kacau.

Perilaku Khusus Zoho Migration Wizard

Zoho menyediakan alat migrasinya sendiri untuk meninggalkan platformnya: Zoho Migration Wizard. Alat ini praktis untuk migrasi sederhana, tapi ada perilaku yang sudah tercatat di forum-forum administrator: alat ini tidak selalu meneruskan INTERNALDATE asli dengan benar saat menyisipkan pesan ke server tujuan.

Lebih tepatnya, masalah ini terutama muncul pada migrasi ke server yang secara konsisten menambahkan header Received: pada setiap pesan masuk, dan itulah tepatnya perilaku Exchange Online. Bahkan jika Zoho Migration Wizard meneruskan tanggal asli melalui parameter APPEND, header Received: yang dibuat oleh Exchange Online tetap berada di posisi pertama dalam rantai header, dan Outlook menggunakannya untuk menentukan "kapan email tiba".

Admin yang menggunakan alat IMAP generik seperti imapsync untuk migrasi keluar dari Zoho menghadapi masalah yang persis sama, kadang lebih parah, karena konfigurasi bawaan imapsync tidak dioptimalkan untuk Exchange Online. (Omong-omong, jika Anda pernah membaca log imapsync baris demi baris pada pukul 2 pagi untuk mencari satu kesalahan sinkronisasi, Anda tahu betul ini alat yang kuat tapi tidak terlalu ramah untuk kasus-kasus tepi.)

Mengapa Outlook Menampilkan Tanggal yang Salah

Outlook tidak hanya menggunakan header Date: untuk menampilkan tanggal email. Dalam sebagian besar tampilan, INTERNALDATE yang disediakan server IMAP/Exchange-lah yang digunakan, terutama untuk pengurutan kotak masuk. Header Date: asli memang ada di dalam pesan, utuh, tapi diabaikan demi INTERNALDATE.

Itulah mengapa opsi "Urutkan berdasarkan Tanggal Pengiriman" di Outlook tidak benar-benar menyelesaikan masalah. Memang menampilkan tanggal yang berbeda, tapi perilaku pengurutan tetap tidak stabil tergantung versi Outlook dan mode tampilan (percakapan dikelompokkan atau tidak). Pengurutan berdasarkan tanggal pengiriman bukan solusi. Itu hanya plester yang akan lepas begitu klien diperbarui.

Seberapa Luas Masalah Ini Sebenarnya

Pada migrasi Zoho ke Microsoft 365 berukuran menengah, mudah sekali ada 50.000 hingga 500.000 pesan yang terdampak, tergantung usia kotak surat dan ukuran organisasi. Setiap email yang dipindahkan selama jendela migrasi membawa tanggal yang rusak, sehingga masalah ini langsung terlihat oleh pengguna begitu pertama kali membuka Outlook.

Folder Terkirim sering menjadi yang paling bermasalah. Seorang sales yang mencari penawaran yang dikirim Maret 2022 harus menyisir ratusan email yang semuanya menampilkan tanggal migrasi. Dampak operasionalnya nyata, bukan sekadar tampilan.

Dan berbeda dari yang mungkin Anda bayangkan, masalah ini tidak hilang seiring waktu. INTERNALDATE ditetapkan pada saat penyisipan. Nilainya tidak memperbaiki dirinya sendiri. Tanpa tindakan aktif, email-email tersebut akan mempertahankan tanggal yang rusak selamanya.

Mengapa Memperbaiki Sendiri Lebih Berisiko dari yang Terlihat

Godaannya dapat dipahami: karena header Date: asli masih ada di dalam pesan, tinggal... perbaiki metadatanya. Secara teori masuk akal. Dalam praktiknya, pada kotak produksi dengan 80.000 email, ini adalah operasi yang bisa berjalan sangat buruk.

Berikut beberapa kasus tepi yang kemungkinan besar tidak akan ditangani dengan baik oleh skrip buatan sendiri:

• Email bertanda tangan S/MIME, di mana tanda tangan mencakup seluruh header. Mengubah apa pun pada struktur pesan akan membatalkan tanda tangan kriptografis.
• Pesan terenkripsi PGP, di mana isinya bersifat buram dan setiap manipulasi pada amplop MIME dapat merusak pesan.
• Header non-ASCII yang dienkode dengan RFC 2047 (nama pengirim dengan karakter khusus), yang rusak jika skrip tidak menangani encoding dengan benar.
• Lampiran yang dienkode base64 dengan baris yang tidak diakhiri dengan benar, batas MIME yang tidak standar, atau struktur multipart bertingkat.
• Email tanpa header Date: yang valid (ini ada, terutama dalam ekspor Zoho yang lama), di mana skrip harus memutuskan apa yang harus dilakukan.

Skrip yang berjalan baik pada 50 email pengujian tidak akan berjalan baik pada kotak produksi Zoho yang diekspor dengan bertahun-tahun histori. Dan bagaimana cara memverifikasi, pesan per pesan, bahwa setiap koreksi utuh dan lampiran tidak terpotong? Proses verifikasi setidaknya sama rumitnya dengan koreksi itu sendiri.

Ada juga soal kuota. API Exchange Online melalui Microsoft Graph menerapkan batas laju yang ketat (error 429 Too Many Requests yang sudah tidak asing lagi). Batch yang tidak dibatasi kecepatannya pada 100.000 pesan bisa memicu pemblokiran sementara atau error diam-diam yang sulit didiagnosis setelahnya. Tanpa mekanisme pemulihan dari kegagalan, Anda harus mulai dari awal lagi.

Cara Redate.io Memperbaiki Tanggal Setelah Migrasi Zoho

Redate.io terhubung ke tenant Microsoft 365 Anda melalui izin Azure AD standar, tanpa akses admin global. Pemindaian awal gratis: Redate.io mengidentifikasi kotak surat yang terdampak dan memperkirakan volume email dengan tanggal yang salah, dengan membandingkan INTERNALDATE terhadap nilai-nilai yang ada di rantai header pesan.

Koreksi menggunakan mesin proprietary yang menganalisis rantai header lengkap setiap pesan, mengidentifikasi tanda tangan spesifik alat migrasi Zoho (baik Zoho Migration Wizard maupun imapsync yang dikonfigurasi untuk migrasi keluar dari Zoho), dan merekonstruksi metadata tanggal melalui pipeline validasi multi-tahap. Setiap email yang dikoreksi diverifikasi satu per satu: integritas konten, pelestarian lampiran, kepatuhan RFC. File asli disimpan dalam folder cadangan yang dapat diakses selama 30 hari.

Tidak ada migrasi ulang. Tidak ada downtime. Pengguna tetap bisa menggunakan Outlook sementara koreksi berjalan di latar belakang.

Harga berupa pembayaran satu kali berdasarkan volume, tanpa langganan. Detail tersedia langsung di situs web.

Skenario Terkait yang Perlu Diketahui

Jika Anda mengelola beberapa migrasi sekaligus, atau jika Anda adalah MSP yang mengadministrasi klien yang meninggalkan Zoho, perlu diketahui bahwa masalah yang sama terjadi pada migrasi dari platform lain ke Exchange Online. Mekanismenya identik: header Received: yang dibuat oleh Exchange menimpa INTERNALDATE dari sumber mana pun.

Untuk migrasi dari Google Workspace, dari Exchange on-premises, atau melalui alat seperti BitTitan MigrationWiz atau CloudM, artikel-artikel khusus di blog Redate.io menjelaskan perilaku spesifik setiap alat. Lihat artikel Tanggal Email Rusak Setelah Migrasi ke Exchange Online untuk gambaran umum semua skenario yang berakhir di tenant ini.

Jika migrasi Anda melibatkan kotak surat bersama atau resource Exchange (ruang rapat, peralatan), masalahnya sama, dan alat koreksi yang sama berlaku. Panduan perbaikan tanggal migrasi Exchange IMAP di Outlook di situs Redate.io menjelaskan langkah-langkah koneksi ke tenant Anda.

Untuk tim yang menggunakan imapsync khusus untuk keluar dari Zoho, halaman imapsync Tidak Menyimpan Tanggal? mendokumentasikan opsi konfigurasi imapsync dan mengapa opsi-opsi itu tidak cukup untuk menghindari masalah di Exchange Online.

Tanggal migrasi Zoho Anda masih muncul di Outlook? Pindai kotak surat Anda secara gratis di Redate.io untuk mengukur seberapa luas masalahnya sebelum memutuskan tindakan apa yang perlu diambil.