Temel fikir

Kurumsal e-posta taşıma işi, MX kaydını değiştirmekten önce başlar. Adresleri, arşivleri, uygulama göndericilerini ve kullanıcı erişimini aynı geçiş planında ele alın.

Önce posta envanteri çıkarın

Kullanıcı posta kutularının yanında info, destek ve muhasebe gibi ortak adresleri listeleyin. Takma adres, yönlendirme ve dağıtım grubu aynı şey değildir; mevcut görevlerini yazın. Her kutunun boyutunu, arşiv kapsamını ve kimin eriştiğini kaydedin. Eski çalışan adreslerinin nasıl ele alınacağını işletmenin yetkili kişisiyle belirleyin.

Web sitesi formları, fatura yazılımı, sunucu uyarıları ve tarayıcı cihazlar da e-posta gönderebilir. Sadece çalışanların bilgisayarlarını taşımak bu göndericileri geride bırakır. Her uygulamanın gönderici adresini ve bağlantı ayarının nerede tutulduğunu not edin. Parolaları envanter dosyasına düz metin olarak eklemeyin; erişim bilgilerinin yetkili kişiye güvenli biçimde devredileceği yöntemi ayrıca tanımlayın.

Yeni hizmeti günlük çalışma biçimiyle değerlendirin

Depolama kotası kadar ortak kutu kullanımı, mobil erişim, takvim ihtiyacı ve hesap kurtarma süreci önemlidir. Bir ekip aynı adresi birkaç kişi kullanıyorsa ortak parola yerine hizmetin sunduğu uygun yetkilendirme modelini sorun. Ayrılan çalışanın erişimini kaldırırken ekip yazışmalarına ulaşmanın nasıl sürdürüleceğini önceden düşünün.

TekPosta kurumsal mail servisi, bize ait projeler arasındadır. Kapsamını incelerken bu envanter üzerinden kutu, aktarım ve destek gereksinimlerinizi iletebilirsiniz. Bağlantı bağımsız bir teslimat veya güvenlik testi değildir. Özellikle geçmiş arşiv aktarımı, gönderim sınırları ve veri dışa aktarımı gibi konuları teklif üzerinde netleştirin.

DNS kayıtlarının görevlerini birbirine karıştırmayın

MX kayıtları alan adına gelen postanın hangi sunuculara yönleneceğini belirtir. SPF yetkili gönderim kaynaklarını tanımlar; DKIM iletiyi alan adıyla ilişkilendiren imzalama mekanizmasıdır. DMARC ise kimlik doğrulama ve alan adı hizalaması sonuçlarına bağlı politika ile raporlamayı düzenler. Bu kayıtların görevlerini DNS rehberindeki temel kayıt türleriyle birlikte inceleyin.

Değerleri başka bir alan adından kopyalamayın; yeni sağlayıcının alan adınıza yönelik kurulum yönergesini kullanın. Eski ve yeni sistem geçici olarak gönderim yapacaksa mevcut yetkili göndericileri hesaba katın. Birden çok ayrı SPF kaydı eklemek yerine doğru tek politika üzerinde çalışın. Sıkı bir DMARC politikasına geçmeden önce meşru göndericilerin doğrulamasını ve raporları değerlendirin.

Pilot taşıma ile kapsamı doğrulayın

Önce az sayıda yetkili kullanıcıyla pilot uygulayın. Yeni kutuları hazırlayın, gerekli doğrulamaları tamamlayın ve örnek arşivi aktarın. IMAP üzerinden ileti kopyalanması takvim, kişi listesi ve yerel arşiv dosyalarının da taşındığı anlamına gelmez. Kullanılan aktarım yönteminin kapsamadığı öğeleri ayrıca planlayın.

Pilotta klasörler, Türkçe karakterler, tarih sırası, büyük ekler ve arama davranışı kontrol edilsin. İleti sayısı ve boyut farkı varsa sebebini inceleyin; yalnızca “işlem tamamlandı” mesajını kabul etmeyin. Kullanıcıların telefon ve masaüstü uygulamalarında giriş yapabildiğini sınayın. Bu aşamada öğrenilen sorunlar, tüm ekibin aynı anda işinin aksamasını önlemeye yardımcı olur.

Geçiş penceresini ve geri dönüşü yazın

DNS değişikliğinin ne zaman yapılacağını, sorumluyu ve beklenen izleme süresini belirleyin. TTL ayarını değişiklikten yeterli süre önce değerlendirin; yeni TTL, önceden önbelleğe alınmış kayıtları anında temizlemez. Eski hizmeti hemen kapatmayın. Önbellekler ve devam eden aktarım nedeniyle her iki taraftaki gelen postayı bir süre kontrol etmek gerekebilir.

Geri dönüş yalnızca eski MX değerini yazmak değildir. Yeni sistemde birikmiş iletilerin ne olacağını ve hangi kutunun geçerli kayıt kabul edileceğini de planlayın. Sorun halinde karar verecek kişiyle durdurma ölçütü belli olsun. Site taşıma rehberindeki değişiklik envanteri yaklaşımı burada da işe yarar; web hizmetiyle mail taşımasını gereksiz yere aynı pencereye sıkıştırmayın.

Teslim kabulünü gerçek posta akışlarıyla yapın

Kurum içi, kurum dışı gelen ve kurum dışı giden iletileri ayrı test edin. Yanıt, ek dosya, ortak kutu ve web formu bildirimlerini kapsayın. Alınan iletilerin başlıklarında kimlik doğrulama sonuçlarını inceleyin. Başarılı SPF veya DKIM tek başına her iletinin gelen kutusuna düşeceği garantisi değildir; içerik, gönderim davranışı ve alıcı sistem de sonucu etkiler.

Geçiş tamamlanınca uygulama ayarlarını, erişim sahiplerini ve yeni hizmetin destek yolunu belgeleyin. Eski sistem kapatılmadan önce arşiv ve geri yükleme gereksinimini son kez kontrol edin. Kullanıcılara kısa bir kurulum notu ve sorun bildirme yolu verin. Düzenli bir devir, ileride çalışan değiştiğinde veya yeni cihaz eklendiğinde aynı bilgilerin yeniden aranmasını önler.

Kaynaklar ve ek okuma

Platform belgeleri giriş gerektirebilir; arayüz ve özellikler sürüme göre değişebilir. Örnekler, ayrıca belirtilmedikçe temsili senaryolardır.

Bir düzeltme öneriniz mi var? Sayfa bağlantısıyla bildirin. · Kaynak ve yayın yaklaşımı