Exchange IMAP Aktarımı: Tarihler Neden Bozulur

Exchange'in Taşıma Hattı ve E-posta Tarihleriniz

Exchange Online'ın bir taşıma hattı var. Bir posta kutusuna giren her mesaj (internetten gelse de, klasörler arasında taşınsa da, IMAP ile içe aktarılsa da) bu hattan geçer. Ve hat, hatların yaptığını yapar: mesajı meta verilerle damgalar. Bugünün tarihiyle yeni bir Received: başlığı dahil.

Exchange IMAP aktarımlarında tarih bozulmasının temel nedeni bu. Bir hata değil. Yanlış yapılandırma değil. Microsoft'un bir posta kutusuna giren her mesajı (7 yıllık olsa bile) "yeni teslim" olarak değerlendiren kasıtlı bir mimari kararı.

Sonuç? Eski bir IMAP sunucusundan Exchange Online'a 4.000 e-posta aktarırsınız ve her biri aktarım tarihini gösterir. 2018, 2020, 2023'ten e-postalar, hepsi bugünün tarihiyle damgalanmış.

Exchange Yönetim Merkezi Taşıma Sihirbazı Nasıl Çalışır

Exchange Admin Center (EAC) IMAP aktarımları için yerleşik bir taşıma sihirbazı içerir. Çoğu Exchange yöneticisinin ilk ulaştığı grafiksel arayüz: Recipients, ardından Migration'a gidip yeni bir toplu iş oluşturursunuz, "Migrate to Exchange Online" seçip kaynak olarak IMAP'ı seçersiniz, posta kutusu eşlemeleriyle bir CSV yüklersiniz ve toplu işi başlatırsınız.

Perde arkasında EAC taşıma sihirbazı, uç nokta türü IMAP olarak ayarlanmış bir New-MigrationBatch oluşturur. Exchange kaynak IMAP sunucunuza bağlanır, her mesajı okur ve hedef Exchange Online posta kutusuna yazar.

Taşıma düzeyinde olan şu: Exchange Online mesajı IMAP kaynağından aldığında, normal e-posta teslimatını işleyen aynı taşıma hattından geçirir. Hat güncel zaman damgasıyla bir Received: başlığı ekler. Mesajın dahili teslim tarihini şimdiye ayarlar.

Received: from source-imap.oldserver.com (10.0.0.5) by
    AM6PR04MB5127.eurprd04.prod.outlook.com (2603:10a6:20b:f3::12)
    with Microsoft SMTP Server; Thu, 2 Apr 2026 08:44:19 +0000
Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest ve Aynı Sorun

Komut satırını tercih eden yöneticiler genellikle PST dosyalarını içe aktarmak için New-MailboxImportRequest'e veya sunucudan sunucuya taşımalar için IMAP uç noktalarıyla New-MigrationBatch'e yönelir. Beklenti PowerShell'in daha fazla kontrol vermesi. Ve bazı şeyler için veriyor. Tarihler için değil.

New-MailboxImportRequest'in bu davranışı geçersiz kılacak bir parametresi yok. -PreserveDates diye bir flag yok (ve inanın, yöneticiler aramış).

Doğrudan IMAP Aktarımı ve Üçüncü Taraf Araçlar

Exchange'in yerel IMAP aktarımını mı yoksa BitTitan MigrationWiz veya CloudM gibi üçüncü taraf bir aracı mı kullandığınız fark eder mi? Kısa cevap: tarih sorunu her iki şekilde de olur, ama biraz farklı nedenlerle.

Yerel Exchange IMAP aktarımında genellikle başa çıkılması gereken tek bir taşıma Received: başlığı vardır. Üçüncü taraf araç taşımasından sonra iki veya üç olabilir. Temel sorun aynı, ama başlık zinciri daha karmaşık.

Exchange Online Taşıma Kuralları Neden İşleri Kötüleştirir

Deneyimli Exchange yöneticilerini bile şaşırtan bir şey var. Exchange Online'ın taşıma kuralları (şimdi yönetim merkezinde "posta akışı kuralları" olarak adlandırılır) aktarılan mesajlar üzerinde de tetiklenebilir. Kuruluşunuzda başlık ekleyen, sorumluluk reddi notu ekleyen veya koşullara göre mesajları değiştiren kurallar varsa, bu kurallar aktarılan e-postaları da işleyebilir.

Bu, 2020'den bir e-postanın sadece bugünün tarihiyle yeni bir Received başlığı almakla kalmayıp, orijinal e-posta gönderildiğinde var olmayan bir uyumluluk kuralı tarafından sorumluluk reddi notu da eklenmesi anlamına gelebilir.

Exchange Ortamlarında Yanlış Tarihlerin Anlamı

Exchange ortamları genellikle iş ortamlarıdır. Hukuk firmaları, finans kuruluşları, sağlık organizasyonları, devlet kurumları. E-posta zaman damgalarının yasal ve düzenleyici önemi olan posta kutuları bunlar.

Exchange'de bir dava bekletmesi tarihe göre e-postaları korur. Aktarılan her e-posta orijinal tarih yerine aktarım tarihini gösteriyorsa, bekletme yanlış mesaj setini yakalar. "Ocak-Mart 2022 arasındaki tüm iletişimler" için bir eKeşif araması, bu e-postalar artık Nisan 2026 gösterdiği için hiçbir şey döndürmez.

Saklama politikaları da aynı sorunla karşılaşır. 3 yıllık saklama politikası olan bir kuruluş, 2026'dan görünen (dolayısıyla "yeni" olan) ama aslında 2019'dan olan ve korunması gereken e-postaları yanlışlıkla silebilir.

Exchange IMAP Aktarım Tarihlerini Düzeltme

Orijinal Date: başlığı Exchange taşıma hattından sağ çıkıyor. Microsoft'un hattı mesajın etrafına meta veri ekler ama içindeki orijinal RFC 2822 başlıklarını değiştirmez. Bu orijinal tarih, düzeltme için çıpa noktasıdır.

Redate.io Exchange Online posta kutusuna bağlanır (Microsoft 365 yönetici onaylı erişim ile), IMAP aktarımının neden olduğu tarih anomalileri olan mesajları tarar ve RFC uyumluluğu doğrulaması, mesaj yapısı koruması ve hedefli meta veri yeniden yapılandırması gerçekleştiren tescilli bir düzeltme motoru uygular. Motor, Received başlık zincirindeki Exchange'e özgü taşıma hattı imzalarını tanır.

Düzeltilen her mesaj tek tek doğrulanır: içerik bütünlüğü, ek sağlamaları, klasör yerleşimi ve konuşma ileti dizisi. Orijinaller 30 gün boyunca görünür bir yedek klasörde korunur.

Platforma Özel Kılavuzlar

• Outlook'ta Exchange IMAP aktarım tarihlerini düzeltme
• OWA'da Exchange IMAP aktarım tarihlerini düzeltme (Outlook on the Web)

Farklı taşıma araçlarında Microsoft 365 tarih sorunları hakkında daha geniş bir bakış için Microsoft 365 taşıması sonrası e-posta tarihlerini düzeltme rehberine bakın.

Exchange IMAP aktarımı posta kutularınızı yanlış tarihlerle mi bıraktı? Kaç e-postanın etkilendiğini ve düzeltme maliyetini görmek için ücretsiz tarama başlatın, kredi kartı gerekmez.