Microsoft 365 geçişinden önce domain, DNS ve posta kutuları nasıl planlanır?

Microsoft 365'e geçmeden önce ilk cevaplanması gereken soru kaç posta kutusu taşınacağı değil, mevcut posta sisteminin gerçekte nasıl kullanıldığıdır. E-posta dışında takvimler, kişiler, arşivler, ortak adresler, paylaşılan posta kutuları ve bazı uygulamaların gönderdiği otomatik iletiler de aynı yapıya bağlı olabilir.

Aktif çalışanları listelemek bu yüzden tek başına yeterli olmaz. Eski çalışan hesapları, yönlendirmeler, alias adresleri, dağıtım listeleri, tarayıcı ve yazıcı gönderimleri, web sitesi formları veya muhasebe gibi iş uygulamaları da kontrol edilmelidir. Bunlardan biri unutulursa kullanıcıların posta kutuları çalışırken başka bir iş akışı sessizce bozulabilir.

Geçiş yöntemi de bu envantere göre seçilir. Bazı yöntemler yalnızca posta içeriğini taşırken takvim, kişi, görev, izin veya arşiv tarafında farklı hazırlık isteyebilir. Önce neyin taşınacağını bilmek, daha sonra seçilen yöntemin gerçekten o ihtiyacı karşılayıp karşılamadığını kontrol etmeyi kolaylaştırır.

Microsoft 365'te kurumsal alan adını kullanabilmek için domain sahipliğinin doğrulanması gerekir. Bu genellikle DNS'e eklenen bir doğrulama kaydıyla yapılır. Geçiş gününde DNS panelinin kimde olduğunu araştırmaya başlamak istemeyiz. Registrar hesabı, DNS yönetimi ve gerekli yönetici erişimleri önceden belli olmalıdır.

Domain kaydı, DNS hizmeti ve web sitesi aynı firmadan satın alınmış olabilir ama teknik olarak aynı şey değildir. Posta için bir DNS kaydını değiştirmek web sitesini taşımayı gerektirmez. Benzer şekilde name server değiştirmek de sıradan bir posta geçişinin otomatik adımı değildir.

Buradaki önemli nokta mevcut DNS bölgesini görmeden toplu değişiklik yapmamaktır. Web sitesi, üçüncü taraf doğrulama kayıtları, SPF içindeki göndericiler veya başka servisler aynı domain altında çalışıyor olabilir. Microsoft 365 için gereken kaydı eklerken ilgisiz kayıtların korunması gerekir.

Kullanıcılar ve gerekli posta kutuları MX kaydı Microsoft 365'e çevrilmeden önce hazır olmalıdır. Bunun nedeni basit. MX değiştiği andan itibaren yeni gelen postaların hedefi Microsoft 365 olur. Yeni tarafta karşılığı bulunmayan bir adres varsa o ileti doğru yere ulaşmayabilir.

Microsoft'un yönetici belgeleri de kullanıcıların ve posta kutularının MX değişikliğinden önce oluşturulmasını özellikle öneriyor. Burada sık karıştırılan başka bir nokta daha var. MX kaydını değiştirmek eski e-postaları Microsoft 365'e taşımaz. Eski içerik, kullanılan geçiş yöntemine göre ayrıca aktarılır veya eski sistemde tutulur.

Birincil adresler, alias'lar, paylaşılan posta kutuları ve gruplar ayrı ayrı kontrol edilmelidir. Yönetici hesaplarını da günlük kullanıcı hesabıyla aynı mantıkta ele almamak gerekir. Lisans tarafında ise herkese otomatik olarak aynı paketi vermek yerine kullanılan uygulamalar, depolama ihtiyacı, cihaz yönetimi ve gerekli güvenlik özellikleri dikkate alınmalıdır.

Değişiklikten önce mevcut DNS kayıtlarının bir kopyasını almak iyi bir başlangıçtır. Ardından kullanılacak değerler internetten bulunan genel bir örnekten değil, doğrudan ilgili Microsoft 365 tenant'ının yönetim ekranından alınmalıdır. Böylece başka bir tenant'a veya eski bir yapılandırmaya ait kaydın kullanılma ihtimali ortadan kalkar.

MX kaydı yeni gelen postanın hedefini belirler. SPF, hangi sistemlerin domain adına posta göndermeye yetkili olduğunu belirtmeye yardımcı olur. DKIM gönderilen iletilerin imzalanmasıyla, DMARC ise SPF ve DKIM sonuçlarının domain politikasıyla nasıl ele alınacağıyla ilgilidir. İsimleri aynı ekranda görülse de bunlar aynı işi yapan kayıtlar değildir.

Özellikle SPF tarafında mevcut göndericileri bilmek önemlidir. Web sitesi, muhasebe uygulaması, yazıcı, CRM veya başka bir hizmet domain adına e-posta gönderiyorsa yeni yapı hazırlanırken bunlar unutulmamalıdır. Aynı domain için gelişigüzel birden fazla SPF kaydı eklemek de doğru çözüm değildir.

DNS değişiklikleri her noktada aynı saniyede görünmeyebilir. Önbellekler nedeniyle bir süre eski ve yeni yanıtların görüldüğü durumlar olabilir. Bu nedenle değişikliği yaptıktan sonra yalnızca panelde kaydın doğru görünmesine bakmak yerine gerçek posta akışı da test edilmelidir.

Kullanılan geçiş yöntemi uygunsa küçük bir pilot grup seçmek birçok varsayımı gerçek kullanıcıyla sınamaya yardımcı olur. Pilot grupta yalnızca Outlook'un açılması değil, web erişimi, mobil cihazlar, takvim paylaşımı, ortak posta kutuları ve dışarıyla posta alışverişi gibi günlük kullanım biçimleri de kontrol edilmelidir.

Web sitesi veya iş uygulamalarının e-posta gönderimi de ayrıca test edilmelidir. Bir çalışanın posta kutusu sorunsuz çalışırken web formunun bildirim gönderememesi mümkündür. Bu iki farklı akışın aynı test sonucuymuş gibi kabul edilmemesi gerekir.

Geri dönüş planı da yalnızca eski MX değerini bir yere not etmek değildir. Hangi durumda geri dönüleceği, geçiş sırasında eski ve yeni sistemde oluşmuş iletilerin nasıl ele alınacağı ve kullanıcılara ne söyleneceği önceden düşünülmelidir. Değişikliği geri almak teknik olarak mümkün olsa bile o arada oluşan veriyi görmezden gelemeyiz.