E-posta taşıma, web sitesi taşımaktan daha risklidir çünkü kaybedilen şey geri gelmez. Site birkaç dakika kapalı kalırsa ziyaretçi tekrar dener; e-posta akışı kesilirse o iletiler ya geri döner ya kaybolur — ve bir daha gönderilmezler.
Bu rehber, e-posta altyapısı taşımasını kesintisiz yürütmenin adımlarını anlatıyor.
Önce Şunu Ayırt Edin: Gelen mi, Giden mi?
E-posta taşımada en yaygın karışıklık budur ve netleştirmeden başlamak, gereksiz kesinti üretir.
| Akış | Neyle yönetilir | Taşıma riski |
|---|---|---|
| Gelen e-posta | MX kayıtları | Yüksek — kesinti veri kaybı demek |
| Giden e-posta | Gönderen sistemin yapılandırması | Düşük — geri alınabilir |
Yalnızca gönderim altyapınızı değiştiriyorsanız (örneğin bir smarthost hizmetine geçiyorsanız) MX kayıtlarına hiç dokunmazsınız ve gelen akışınız hiç etkilenmez. Bu, taşımanın en düşük riskli hâlidir.
Posta kutularınızı da taşıyorsanız iş büyür: kutu içerikleri aktarılmalı, MX kayıtları değiştirilmeli ve geçiş anında iletilerin kaybolmaması sağlanmalıdır.
Senaryo 1: Yalnızca Gönderimi Taşımak
En yaygın ve en kolay senaryo. Adımlar:
- Envanter çıkarın. Alan adınız adına gönderim yapan tüm sistemleri listeleyin: posta sunucusu, web uygulaması, CRM, muhasebe yazılımı, cihazlar.
- Yeni sağlayıcıyı SPF kaydına ekleyin. Eskisini henüz çıkarmayın — geçiş sırasında iki yol da geçerli olmalı.
- DKIM anahtarını ekleyin. DKIM birden fazla anahtarı destekler; eski ve yeni birlikte var olabilir.
- Tek bir sistemi geçirin. En az kritik olanla başlayın, test edin.
- Kalan sistemleri sırayla geçirin. Her birinden sonra test e-postası gönderip başlıklardaki doğrulama sonuçlarını kontrol edin.
- Eski yolu kapatın. Tüm sistemler geçtikten sonra eski gönderim yolunu devre dışı bırakın.
- SPF kaydını sadeleştirin. Artık kullanılmayan kaynağı çıkarın — sorgu limitini boşuna doldurmayın.
Bu senaryoda kesinti riski yoktur çünkü her adım geri alınabilir ve gelen akış hiç etkilenmez. Gönderimi yönetilen bir SMTP relay hizmetine taşıyorsanız, IP itibarı ve ısıtma süreci sağlayıcı tarafında yürüdüğü için geçiş sonrası teslimat oranlarınız da genellikle iyileşir.
Senaryo 2: Posta Kutularını Taşımak
Burada risk gerçektir ve planlama gerektirir.
1. Hedef Ortamı Hazırlayın
Yeni sağlayıcıda tüm hesapları, yönlendirmeleri, dağıtım listelerini ve otomatik yanıtları oluşturun. Eski sistemdeki yapılandırmanın tam envanterini çıkarın — özellikle yönlendirmeler ve dağıtım listeleri sıkça atlanır ve eksikliği geç fark edilir.
2. İlk Senkronizasyonu Yapın
Kutu içeriklerini eski sistemden yenisine kopyalayın. Bu, veri hacmine göre saatler veya günler sürebilir. Geçişten günler önce başlatın — bu aşamada eski sistem çalışmaya devam eder, kullanıcılar etkilenmez.
3. TTL'i Düşürün
MX kayıtlarının yaşam süresini geçişten en az 24-48 saat önce düşük bir değere çekin. Bu adım geçiş anında yapılamaz — eski yüksek değer hâlâ dünyanın önbelleklerindedir.
4. Geçiş: MX Kaydını Değiştirin
Trafiğin en düşük olduğu saati seçin. MX kaydını yeni sistemi gösterecek şekilde güncelleyin.
5. Çift Teslimat Penceresi
Bu, kesintisizliğin anahtarıdır. DNS yayılımı tamamlanana kadar bazı gönderenler eski sisteme, bazıları yenisine ileti gönderecektir.
Bu pencerede eski sistemi kapatmayın. Eski sisteme gelen iletileri yeni sisteme yönlendirecek bir kural tanımlayın. Böylece hangi yoldan gelirse gelsin her ileti yeni kutuya ulaşır.
Eski sistemi en az bir hafta bu şekilde açık tutun.
6. Son Senkronizasyon
Geçişten sonra, eski sisteme geçiş anında düşmüş olabilecek iletileri yakalamak için bir kez daha senkronizasyon yapın.
7. Kapatın ve Temizleyin
Bir hafta boyunca eski sisteme ileti gelmediğini doğruladıktan sonra kapatın. SPF ve diğer DNS kayıtlarından eski sağlayıcıyı çıkarın.
En Sık Atlanan Beş Kalem
- Yönlendirmeler ve takma adlar. Kutu taşınır ama yönlendirme kuralları taşınmaz. Sonuç: bazı adreslere gelen iletiler kaybolur.
- Dağıtım listeleri. Grup adresleri ayrı yapılandırma gerektirir.
- Otomatik yanıtlar ve filtreler. Kullanıcıların kendi kurdukları kurallar genellikle taşınmaz.
- Takvim ve kişiler. Kutu senkronizasyonu bunları kapsamayabilir.
- Uygulama entegrasyonları. Web uygulamanız, CRM'iniz ve cihazlarınız eski sunucu bilgileriyle yapılandırılmıştır. Bunları güncellemeyi unutmak, taşıma sonrası "e-posta gönderilemiyor" hatalarının en yaygın nedenidir.
Geçiş Sonrası Kontrol Listesi
- Farklı sağlayıcılardan test e-postası gönderip gelen kutusuna ulaştığını doğrulayın.
- Yeni sistemden gönderip başlıklardaki SPF, DKIM ve DMARC sonuçlarının "pass" olduğunu kontrol edin.
- Tüm yönlendirmeleri ve dağıtım listelerini test edin.
- Web sitesi iletişim formundan bir test gönderin.
- Mobil cihazlardaki hesap ayarlarının güncellendiğini doğrulayın.
- DMARC raporlarını birkaç gün izleyip beklenmedik bir gönderim kaynağı olup olmadığına bakın.
Sonuç
E-posta taşımada risk, iki akışı ayırt etmekle başlar: yalnızca gönderimi taşımak düşük riskli ve geri alınabilir bir iştir; posta kutularını taşımak ise planlama gerektirir. Kesintisizliğin anahtarı iki adımdadır — TTL'i önceden düşürmek ve geçişten sonra eski sistemi bir hafta yönlendirmeli olarak açık tutmak. Bu iki adım uygulandığında hiçbir ileti kaybolmaz. En sık atlanan kalem ise uygulama entegrasyonlarıdır: kutular taşınır, ama web sitenizin ve iş yazılımlarınızın ayarları eski sunucuyu göstermeye devam eder.
Sıkça Sorulan Sorular (SSS)
Taşıma sırasında e-posta kaybolur mu?
Doğru yapılırsa hayır. Kritik adım, MX değişikliğinden sonra eski sistemi kapatmayıp gelen iletileri yeni sisteme yönlendirmektir. Bu pencere olmadan, DNS yayılımı sırasında eski sisteme düşen iletiler kaybolabilir.
Sadece gönderim altyapımı değiştiriyorum, MX'e dokunmalı mıyım?
Hayır. MX kayıtları gelen e-postayı yönetir ve gönderim değişikliğiyle ilgisi yoktur. MX'e dokunmak, gelen e-posta akışınızı gereksiz yere riske atar.
Geçiş sırasında SPF kaydını nasıl yönetmeliyim?
Geçiş boyunca hem eski hem yeni sağlayıcıyı tek bir SPF kaydında listeleyin. İki ayrı SPF kaydı oluşturmayın — bu geçersiz bir yapılandırmadır. Geçiş tamamlandıktan sonra eskisini kayıttan çıkarın.
Taşıma ne kadar sürer?
Yalnızca gönderim taşınıyorsa birkaç saat. Posta kutuları da taşınıyorsa ilk senkronizasyon veri hacmine göre günler alabilir — ama bu süre boyunca eski sistem çalıştığı için kullanıcılar etkilenmez. Fiili geçiş anı ise dakikalarla sınırlıdır.
