Posta kutularını ve gönderen sistemleri listeleyin
Kullanıcı hesapları, ortak adresler, takma adresler ve dağıtım listelerinin envanterini çıkarın. Her hesabın veri boyutunu ve erişim yöntemini belirleyin. E-postalar, kişiler, takvimler ve arşiv dosyaları farklı taşıma yöntemleri gerektirebilir; hepsinin otomatik taşınacağını varsaymayın.
Web sitesi formları, CRM, muhasebe uygulamaları ve cihazlar da şirket adına e-posta gönderebilir. Bu sistemlerin SMTP ayarları, gönderen adresleri ve izinleri geçiş kapsamına dahil edilmelidir. Şifre ve erişim bilgileri için güvenli paylaşım yöntemi belirleyin.
MX, SPF, DKIM ve DMARC kayıtlarını hazırlayın
MX kayıtları gelen postanın hangi sunucuya yönlendirileceğini tanımlar. SPF kaydı alan adı adına gönderim yapabilecek sistemleri belirtir. DKIM, gönderilen mesaja doğrulanabilir bir imza ekler. DMARC, SPF veya DKIM sonuçlarını görünen gönderen alan adıyla birlikte değerlendirir.
Yeni sağlayıcının verdiği kayıtlar mevcut DNS bölgesiyle karşılaştırılmalıdır. Alan adı için birden fazla ayrı SPF kaydı oluşturmak doğrulama hatalarına yol açabilir; yetkili göndericiler tek politika içinde düzenlenmelidir. DMARC politikası mevcut gönderim akışları incelendikten sonra belirlenir.
DNS geçişini ve veri eşitlemesini sıralayın
Yeni hesaplar açılıp test edildikten sonra ilk veri aktarımı yapılabilir. DNS önbelleklerinin etkisi ve TTL değerleri geçiş zamanlamasında dikkate alınmalıdır. Kayıt değişikliğinin her kullanıcıya aynı anda yansıyacağı kabul edilmemelidir.
MX değişiminden sonra eski sistemde kalan son mesajların nasıl eşitleneceği ve kullanıcıların yeni hesaplara ne zaman bağlanacağı belirlenir. Kontroller tamamlanmadan eski hizmetin kapatılması veri kaybına veya eksik posta akışına neden olabilir.
Kullanıcı cihazlarını ve posta akışını test edin
Masaüstü ve mobil istemcilerde hesap ayarları, gönderim ve alım testleri yapılmalıdır. Farklı dış alan adlarına gönderilen mesajların doğrulama sonuçları incelenir. Ortak adresler, yönlendirmeler ve uygulama bildirimleri ayrıca kontrol edilir.
Doğru SPF, DKIM ve DMARC yapılandırması gönderim güvenini destekler; bütün iletilerin gelen kutusuna ulaşmasını garanti etmez. İçerik, alıcı politikaları ve gönderim itibarı da etkili olabilir. Geçişten sonra hata kayıtları izlenerek kalan sorunlar giderilir.
Örnek senaryo: kullanıcı hesabı ve ortak satış adresi
Bir şirkette her çalışanın kişisel iş hesabının yanında satış, muhasebe ve destek gibi ortak adresler bulunduğunu düşünelim. Taşınacak hesap sayısı çalışan sayısına eşit olmayabilir. Bazı adresler gerçek posta kutusu, bazıları takma adres veya dağıtım listesi olabilir. Aynı görünen e-posta adresinin arkasındaki kullanım biçimi bilinmeden yeni ortamda aynı davranış sağlanamaz.
Örneğin satış adresine gelen iletiler birden fazla kişiye dağıtılıyor olabilir; cevaplar ise bir çalışanın kendi hesabından gönderiliyor olabilir. Yeni sistemde kimlerin bu adresi göreceği, kimlerin bu adla gönderim yapabileceği ve geçmiş mesajların nerede tutulacağı belirlenmelidir. Hesap listesinin yanında kullanım biçimini de sormanın neden gerekli olduğunu gösterir.
Mesaj taşımasıyla kişi ve takvim taşıması farklıdır
E-postalar kaynak ve hedef sistemin uygun erişim yöntemleri üzerinden aktarılabilir. Kişiler, takvimler, kurallar ve imzalar ise aynı aktarımın parçası olmayabilir. Bazı veriler kullanıcı cihazında yerel olarak tutulur. Sunucudaki posta kutusu taşındığında bu yerel arşivler kendiliğinden yeni platforma gitmez. Geçişten önce veri türlerini ayrı ayrı listeleyin.
Taşıma kapsamı belirlenirken hangi klasörlerin korunacağı, büyük veya bozuk iletilerde nasıl hareket edileceği ve yerel arşivlerin kullanıcıda kalıp kalmayacağı konuşulmalıdır. Kullanıcının eski mesajını bulamaması bazen aktarım hatası değil, mesajın yalnızca eski bilgisayarda tutulmuş olmasıdır. Bu ayrımı geçişten sonra değil, envanter aşamasında yapmak daha kolaydır.
Alan adınız adına yalnızca çalışanlar gönderim yapmaz
Web sitesi teklif formu, CRM bildirimi, fatura uygulaması ve tarayıcı cihazı da şirket adına ileti gönderebilir. Posta kutuları taşındıktan sonra bu sistemlerin kullandığı SMTP sunucusu veya kimlik doğrulama yöntemi değişebilir. Çalışanlar sorunsuz e-posta kullanırken teklif formunun bildirim göndermemesi, bu yardımcı sistemlerin geçiş listesinde bulunmamasından kaynaklanabilir.
Her sistemin gönderen adresi, erişim hesabı ve kullanılan bağlantı ayarı kaydedilmelidir. Yeni sağlayıcıdaki gönderim kuralları uygulamanın imkanlarıyla karşılaştırılır. SPF kaydını hazırlarken yalnızca yeni posta platformunu değil, yetkili diğer göndericileri de hesaba katın. DKIM ve DMARC kontrolleriyle birlikte dış alıcılara örnek gönderim yapın; yalnızca şirket içi iki hesap arasındaki test yeterli değildir.
DNS geçişi sırasında hangi değişiklikleri kaydetmelisiniz?
İşlemden önce mevcut MX ve doğrulama kayıtlarının kopyasını tutun. Alan adını yöneten kişiyle geçişi yapan kişinin aynı ekipte olmaması yaygındır; kaydı kimin değiştireceği ve değişikliği kimin kontrol edeceği belirlenmelidir. Alan adının yetkili DNS sunucuları ile başka bir panelde görünen kayıtları birbirine karıştırmayın. Değişiklik gerçek DNS yönetim noktasında yapılmalıdır.
TTL değerleri, eski kayıtların önbelleklerde ne kadar tutulabileceğiyle ilişkilidir. Geçiş planında bu gecikmeye yer verin ve eski sistemde kalan iletiler için son eşitlemeyi düşünün. Web sitesi aynı anda taşınıyorsa e-posta kayıtlarının yeni DNS bölgesine doğru aktarıldığı da kontrol edilir. Yalnızca web sitesinin açılması, posta yönlendirmesinin doğru olduğunu göstermez.
Teslim kontrolü: kullanıcı, uygulama ve dış alıcı
Geçişin kabulü için bir kontrol hesabıyla başlamak iyi olur. Hesaptan dışarı ileti gönderin, farklı bir alan adından yanıt alın ve gelen mesajın doğru kutuya ulaştığını doğrulayın. Mobil cihazda ve masaüstü istemcisinde aynı kontrolleri yapın. Ortak adreslerin, yetkili gönderimlerin ve dağıtım listelerinin beklendiği gibi çalıştığını ayrı test edin.
Uygulamaların ürettiği e-postalar için hata kayıtlarını inceleyin. Şifre yenileme mesajı, teklif formu ve bildirimler geçiş sonrasında denenmelidir. Son olarak eski posta kutularında yeni mesaj kalmadığından ve gereken arşivlerin teslim edildiğinden emin olun. Disket’e e-posta taşıma talebinde hesap sayısını, veri boyutunu ve kullanılan uygulamaları birlikte belirtmeniz, geçişin eksik bir hesap listesiyle başlamasını önler.
E-posta geçişinde hangi kayıt ne işe yarar?
| Kayıt veya ayar | Temel görevi | Geçişte yapılacak kontrol |
|---|---|---|
| MX | Gelen postanın sunucusunu belirtir | Yeni hedef ve öncelikler |
| SPF | Yetkili gönderim sistemlerini tanımlar | Tek politika ve bütün yetkili göndericiler |
| DKIM | Mesaj imzasının doğrulanmasını sağlar | Hedef platformun anahtar kaydı ve imzası |
| DMARC | Alan adı uyumunu ve politikasını tanımlar | Uyum sonuçları, politika ve rapor ayarları |
| SMTP | Uygulama veya istemci gönderimini sağlar | Sunucu, bağlantı ve kimlik doğrulama |
Teklif öncesi kontrol listesi
- Hesaplar, ortak adresler, kişiler ve takvimler
- Mevcut DNS ve şirket adına gönderen uygulamalar
- Yeni platform kapasitesi ve taşıma kapsamı
- İlk aktarım, MX değişimi ve son eşitleme
- Cihaz kurulumu, dış gönderim testleri ve eski sistem kapanışı
Sık sorulan sorular
Mail taşımasında bütün mesajlar aktarılabilir mi?
Kaynak sisteme erişim, veri bütünlüğü ve hedef platformun desteklediği biçimler değerlendirilir. Taşınacak veri türleri ve istisnalar geçişten önce belirlenir.
DNS değişince eski hizmet hemen kapatılmalı mı?
Geçiş testleri ve son eşitleme tamamlanmadan kapatılmamalıdır. Eski sistemin açık tutulacağı süre veri hacmi ve geçiş planına göre belirlenir.
Web sitesi çalışıyor ama form e-postaları gelmiyor; taşıma tamamlanmış sayılır mı?
Formun SMTP ve gönderim ayarları, yetkili gönderici kayıtları ve uygulama hataları ayrıca kontrol edilmelidir. Posta kutularının çalışması, web sitesi veya CRM gibi diğer göndericilerin çalıştığını kanıtlamaz. Bu sistemler geçiş kabul listesinde bulunmalıdır.
Teknik kaynaklar
Disket Teknoloji’nin sektör faaliyetleri 2014 yılında şahıs şirketi olarak başladı. Bugün hizmetlerimiz Disket Teknoloji Ltd. Şti. bünyesinde sürüyor. Şirket geçmişimiz.