E-Posta Altyapısını Taşırken Kesinti Yaşamamak

E-posta altyapısını taşımak, bir şirket için sadece teknik bir operasyon değil, iş sürekliliğini doğrudan etkileyen kritik bir adımdır. Satış ekibiniz müşteri tekliflerini, hukuk ekibiniz sözleşmeleri, operasyon ekibiniz günlük iş akışını e-posta üzerinden yürütüyor. Dolayısıyla Google Workspace, Microsoft 365 veya cPanel tabanlı bir e-posta altyapısından diğerine geçerken yaşanacak birkaç saatlik kesinti bile hem itibar hem de gelir kaybı anlamına gelebilir. Bu yazıda, DCHost ekibinde sık sık planladığımız ve yönettiğimiz e-posta geçiş operasyonlarından edindiğimiz tecrübeleri paylaşarak; Google Workspace, Microsoft 365 ve cPanel arasında neredeyse sıfır kesintiyle e-posta taşımanın pratik bir yol haritasını anlatacağız.

Odak noktamız şu olacak: DNS tarafında MX ve SPF/DKIM/DMARC kayıtlarını doğru sırada değiştirmek, kutulardaki (mailbox) verileri önceden senkronize etmek, geçişten sonra eski altyapıyı bir süre daha aktif tutmak ve kullanıcı tarafındaki deneyimi minimum seviyede etkilemek. Yazıyı, hem küçük ölçekli işletmelerin hem de çoklu domain ve yüzlerce hesap yöneten IT ekiplerinin sahada gerçekten uygulayabileceği net adımlar şeklinde yapılandırdık.

E-Posta Altyapısını Taşımak Neden Riskli?

Önce riskleri netleştirelim ki, geçiş planını buna göre sağlam kurabilelim. E-posta altyapısı taşıma sürecinde genellikle şu üç başlık başınızı ağrıtır:

• Kesinti ve kayıp e-postalar: MX kayıtları tam oturmadan yapılan geçişlerde, bazı e-postalar eski sisteme, bazıları yeni sisteme, bazıları ise hiç ulaşmaz.
• İtibar ve teslim edilebilirlik: SPF, DKIM, DMARC ve rDNS yanlış kurgulanırsa, yeni altyapınızdan gönderilen e-postalar spam klasörüne düşmeye başlar.
• Kullanıcı deneyimi: Outlook, mobil istemciler, şifreler ve klasör yapıları düzgün taşınmazsa, ofiste herkesin aynı anda size soru sorduğu stresli bir güne dönüşür.

Bunların tamamı teknik olarak çözülebilir problemler. Konu, doğru sırayı ve doğru zamanlamayı tutturmak. DNS tarafındaki kritiklerin bir özetini isterseniz, daha önce yazdığımız DNS kayıtları A’dan Z’ye rehberine de mutlaka göz atın.

Temel Kavramlar: MX, TTL, SPF/DKIM/DMARC ve IMAP Senkronizasyonu

Geçiş senaryolarına girmeden önce, üzerinde konuşacağımız temel yapı taşlarını netleştirelim.

MX kayıtları ve TTL

MX (Mail Exchanger) kayıtları, bir alan adı için e-postaların hangi sunucuya teslim edileceğini belirler. Örneğin example.com alan adınız varsa, MX kayıtları “bu domain’e gelen e-postaları şu servise gönder” talimatıdır.

• MX değişikliği = Yol tabelasını değiştirmek. Yanlış zamanda yaparsanız, e-postalar iki farklı yere dağılır.
• TTL (Time To Live), DNS kaydının önbellekte ne kadar süre tutulacağını belirler. Geçişten önce TTL’i düşürmezseniz, bazı kullanıcılar eski MX’e uzun süre gitmeye devam eder.

DNS yayılımını hızlandırmak için TTL stratejisini nasıl kullanacağınızı detaylıca anlattığımız Zero-downtime taşıma için TTL stratejileri yazısına da göz atabilirsiniz.

SPF, DKIM ve DMARC

E-posta kimlik doğrulama tarafının üç temel kaydı vardır:

• SPF: Hangi sunucuların bu domain adına e-posta göndermeye yetkili olduğunu söyler.
• DKIM: Gönderilen e-postayı, domain’in özel anahtarıyla imzalayarak alıcı tarafa “bu e-posta gerçekten bu domain’den” sinyali verir.
• DMARC: SPF/DKIM kontrolü başarısız olursa, alıcı sunucunun ne yapması gerektiğini (reddet, karantinaya al, raporla) tanımlar.

Yeni altyapıya geçerken SPF, DKIM ve DMARC’ı doğru güncellemezseniz, özellikle Google Workspace ve Microsoft 365 gibi servisler üzerinde teslim edilebilirlik sıkıntıları yaşarsınız. Bu alanı adım adım kurmak için hazırladığımız SPF, DKIM, DMARC ile e-posta teslim edilebilirliğini artırma rehberini mutlaka okunacaklar listenize ekleyin.

IMAP senkronizasyonu ve veri taşıma

Çoğu kurumsal geçişte asıl kritik nokta, eski posta kutularındaki verileri yeni ortama önceden senkronize edebilmektir. Bunun için:

• IMAP üzerinden eski ve yeni sunucuya bağlanıp klasörleri bire bir kopyalayan araçlar,
• Google Workspace / Microsoft 365’in kendi sağladığı Migration araçları,
• cPanel tarafında tam hesap yedeği (full backup) ve restore mekanizmaları

kullanılır. cPanel’den cPanel’e ve cPanel’den farklı sunuculara e-posta taşımayı teknik seviyede anlattığımız cPanel e-posta hesaplarını yeni sunucuya taşımak yazısı da, bu yazının doğal bir tamamlayıcısıdır.

Genel Sıfır Kesinti Stratejisi: Çatı Plan

Google Workspace, Microsoft 365 ve cPanel arasında tüm geçiş senaryolarında uygulayabileceğiniz ortak bir çatı strateji var. Önce bu şablonu anlatalım, sonra her senaryo için özelleştirelim.

1. Envanter çıkarın: Kaç domain, kaç kullanıcı, kaç alias, hangi cihazlar (Outlook, mobil, webmail) kullanılıyor? Dağıtık ekipler, departman bazlı özel kurallar var mı?
2. DNS erişimini netleştirin: Domain’in DNS’ini kim yönetiyor? Panel girişleri kimde? Değişiklikleri kim uygulayacak?
3. TTL’i önceden düşürün: Geçişten en az 24-48 saat önce ilgili MX ve TXT (SPF, doğrulama kayıtları) için TTL’i 300 saniye (veya 600) seviyesine indirin.
4. Yeni ortamı paralel kurun: Google Workspace / Microsoft 365 / cPanel üzerinde domain’i ekleyin, posta kutularını oluşturun, parolaları belirleyin.
5. İlk senkronizasyonu yapın: IMAP Migration veya yerleşik taşıma araçlarıyla mevcut veriyi yeni ortama çekin. Kullanıcılar bu sırada eski sistemde çalışmaya devam edebilir.
6. Test kullanıcılarıyla pilot geçiş: Önce 2-3 test hesabını tamamen taşıyın, MX’leri onlar için değiştirin (mümkünse alt domain veya ayrı domainle).
7. MX cutover (ana geçiş): Her şey yolundaysa, ana domain’in MX kayıtlarını yeni altyapıya yönlendirin.
8. Artık senkronizasyonu: MX değişiminden sonra bir süre daha delta (sadece son değişiklikler) senkronizasyonu yaparak kayıp riskini azaltın.
9. Eski altyapıyı bir süre açık tutun: En az 3-7 gün, mümkünse 2 hafta. Böylece gecikmeli DNS yayılımından gelen son e-postaları da yakalarsınız.
10. Kullanıcı tarafı temizlik: Outlook profilleri, mobil hesaplar, imzalar, paylaşımlı kutular vb. son rötuşları yapın.

Alan adı / DNS tarafında e-posta kesintisi yaşama risklerini ayrıca anlattığımız alan adı taşırken e-posta kesintisini önlemek yazısını da bu aşamada okumanız faydalı olur.

Senaryo 1: cPanel’den Google Workspace’e Geçiş

Birçok müşterimizin en sık yaptığı geçişlerden biri: Klasik cPanel e-posta altyapısından Google Workspace’e taşınmak. Burada amaç genellikle spam filtreleme kalitesini, mobil entegrasyonları ve işbirliği araçlarını (Drive, Docs vb.) daha yoğun kullanmak.

1. Planlama ve hazırlık

• Hangi domain’ler Google Workspace’e taşınacak?
• Kaç aktif kullanıcı, kaç alias var?
• Mailing list, forwarder, catch-all kullanılıyor mu?
• Toplam posta kutusu boyutları nedir? (Quota raporlarını cPanel’den alabilirsiniz.)

Bu envanter, lisans sayısını, geçiş süresini ve bant genişliği ihtiyacını netleştirir.

2. Google Workspace üzerinde domain ve kullanıcıları oluşturma

• Google Workspace yönetim konsolunda domain’i ekleyin.
• İlgili TXT doğrulama kaydını DNS’e ekleyin ama MX kayıtlarını henüz değiştirmeyin.
• Kullanıcı hesaplarını (mailbox’ları) elle veya CSV/import ile oluşturun.
• Geçici parolalar oluşturup, şifre değişimini ilk girişte zorunlu kılabilirsiniz.

3. IMAP Migration ile veri senkronizasyonu

Google Workspace’in yerleşik Migration aracını kullanarak cPanel’deki eski posta kutularını yeni hesaplara IMAP üzerinden çekebilirsiniz. Adımlar özetle:

1. cPanel sunucunuzda IMAP portlarının (993/143) dışarı açık ve erişilebilir olduğunu doğrulayın.
2. Migration kaynağı olarak IMAP sunucunuzu (örn. mail.sirketiniz.com) tanımlayın.
3. Kullanıcı eşleştirmelerini (eski adres → yeni adres) girin.
4. İlk tam senkronizasyonu başlatın ve bitmesini bekleyin.

Burada kritik nokta, kullanıcıların hala eski cPanel kutusunu kullanmaya devam ettiği bir dönemde ilk kopyalamayı yapmanızdır. Böylece büyük veri kütlesini önceden çekip, MX değişiminden sonra sadece son farkları (delta) kopyalarsınız.

4. MX cutover: MX kayıtlarını Google Workspace’e yönlendirme

İlk senkronizasyon tamamlandıktan ve test hesaplarıyla deneme yaptıktan sonra ana geçişe hazırsınız.

1. DNS panelinizde domain’in MX kayıtlarını Google Workspace’in önerdiği değerlere güncelleyin.
2. Önceden TTL’i 300-600 sn’e düşürdüyseniz, çoğu istemci birkaç dakika içinde yeni MX’leri görecektir.
3. Google Workspace Migration aracıyla bir ikinci senkronizasyon (delta sync) çalıştırın. Bu, MX değişiminden önce ve hemen sonra gelen e-postaları da yeni kutulara çeker.
4. cPanel tarafında webmail’e girerek yeni e-posta akışının oraya gelmediğinden emin olun. Gelen varsa manuel veya ikinci bir IMAP sync ile aktarın.

5. SPF, DKIM ve DMARC güncellemeleri

MX değişimiyle aynı zaman diliminde kimlik doğrulama kayıtlarını da güncellemelisiniz:

• SPF kaydınıza Google Workspace’in önerdiği include: ifadesini ekleyin veya kayıt boşsa sıfırdan oluşturun.
• Google Workspace üzerinde DKIM anahtarını üretin ve DNS’e TXT kaydı olarak ekleyin.
• DMARC kaydınızı önce p=none (sadece raporla) modunda başlatıp, akışı gözlemledikten sonra quarantine veya reject moduna çekebilirsiniz.

Bu aşamadan sonra, e-posta kimlik doğrulamanızın sağlıklı çalıştığını, daha önce bahsettiğimiz e-posta itibarını izleme ve kurtarma rehberindeki araçlarla da test edebilirsiniz.

6. Eski cPanel altyapısını ne zaman kapatmalı?

Bizim sahadaki önerimiz şu: cPanel’deki e-posta hesaplarını ve hizmeti en az 7-14 gün daha açık tutun.

• Bu sürede webmail’e arada bir girip yeni e-posta düşüp düşmediğini kontrol edin.
• Hiç e-posta gelmediğinden emin olduktan sonra, son bir tam IMAP sync çekebilir ve cPanel tarafındaki kutuları dondurabilirsiniz.

Senaryo 2: cPanel’den Microsoft 365’e Geçiş

Bu senaryonun mantığı, Google Workspace geçişine çok benzer; fark, kullandığınız migration araçları ve bazı DNS kayıt detaylarıdır.

1. Microsoft 365 üzerinde domain ve kullanıcıları kurma

• Microsoft 365 yönetim panelinde domain’i ekleyin.
• TXT doğrulama kaydını DNS’e girin; MX kayıtlarını henüz değiştirmeyin.
• Kullanıcı hesaplarını oluşturun, lisansları atayın.

2. Migration endpoint ve batch migration

Microsoft 365 tarafında IMAP Migration için bir “migration endpoint” oluşturmanız gerekir:

1. Kaynak sunucu olarak cPanel e-posta sunucunuzun hostname’ini girin.
2. IMAP portu, güvenlik türü ve bağlantı testlerini geçin.
3. Kullanıcı eşleştirmeleri için CSV dosyası hazırlayın (eski e-posta, kullanıcı adı, parola, yeni e-posta).
4. Migration batch’leri oluşturarak hesapları gruplar halinde taşıyın (örneğin departman bazlı).

3. MX değişimi ve SPF/DKIM ayarları

İlk batch’ler başarılı olduysa, sıra ana MX değişimine gelir:

• MX kayıtlarını Microsoft 365’in verdiği adrese yönlendirin.
• SPF kaydınıza Microsoft 365’in include: ifadesini ekleyin.
• Microsoft 365 üzerinden DKIM’i aktif edin, DNS’e ilgili CNAME/TXT kayıtlarını ekleyin.
• DMARC kaydını önce none, sonra kademeli olarak reject seviyesine taşıyın.

4. Outlook ve mobil istemcilerin yeniden yapılandırılması

Microsoft 365 geçişlerinde en çok zaman alan işlerden biri, özellikle eski Outlook profillerini temizleyip yeni profilleri tanımlamaktır.

• Modern Outlook sürümleri, Autodiscover ile çoğu ayarı otomatik bulur.
• Eski profillerde OST/PST dosyalarını yedeklemeyi unutmayın.
• Mobil cihazlarda (iOS/Android) yeni hesapları Exchange/Office 365 tipi olarak ekleyin.

Bu aşamada, e-posta tarafını taşıma sürecini; genel altyapı geçişlerinizle (örneğin web sitenizin yeni sunucuya taşınması) birlikte planlıyorsanız, paylaşımlı hosting’den VPS’e kesintisiz geçiş rehberimizdeki “kademeli geçiş” yaklaşımını da uygulayabilirsiniz.

Senaryo 3: Google Workspace ↔ Microsoft 365 Arası Geçiş

Bu geçişte iki uçta da “bulut e-posta” hizmeti olduğu için, işleri biraz daha dikkatli planlamak gerekiyor. Çünkü her iki tarafta da gelişmiş güvenlik, kimlik doğrulama ve spam filtreleri aktif.

1. Geçiş modelini belirleyin: Big bang mi, kademeli mi?

• Big bang: Bir gece herkes tek seferde yeni platforma geçer. Basit yapılarda işe yarar ama risklidir.
• Kademeli geçiş: Departman departman veya domain bazlı geçiş yapılır, bir süre “hibrit” dönem yaşanır.

Bizim sahada daha çok önerdiğimiz model, kademeli ve hibrit senaryolardır. Özellikle 50+ kullanıcılı ortamlarda, aynı gün tüm ekibi taşımak yerine, en azından pilot birimlerle başlamayı tavsiye ediyoruz.

2. Veri migrasyonu: API tabanlı veya IMAP tabanlı

Google Workspace ve Microsoft 365 arasında iki ana veri aktarım yöntemi vardır:

• Platformların sunduğu yerel migration araçları ve API tabanlı çözümler,
• Eski usul IMAP tabanlı senkronizasyon.

API tabanlı yöntemler çoğu zaman daha hızlı ve güvenilir olsa da, yetkilendirme ve kapsam izinleri dikkatli kurgulanmalıdır. IMAP tabanlı taşıma, daha sade ama biraz daha uzun sürebilir.

3. Mail flow kuralları ve geçici yönlendirmeler

Hibrit geçişlerde en kritik konulardan biri, iki sistem arasındaki posta akışını doğru kurmaktır.

• Örneğin Google Workspace’ten Microsoft 365’e geçiyorsanız, belirli kullanıcılara gelen e-postaların geçiş süresince diğer tarafa yönlendirilmesini sağlayacak kurallar tanımlanabilir.
• Bu sayede, DNS tarafındaki MX değişimi yapılmadan bile, geçici bir süre için “arka planda” yeni sisteme akan bir posta trafiği kurabilirsiniz.

Bu tür karma senaryolarda mutlaka SPF, DKIM ve DMARC etkilerini iyi okumak gerekir; çünkü yönlendirmeler SPF’yi bozabilir. Bu konuyu e-posta yönlendirmede SPF/DMARC neden kırılıyor? yazımızda detaylı anlattık.

4. Takvim, kişi ve paylaşımlı kutular

E-posta içeriği kadar önemli olan bir diğer başlık da takvimler, kişiler ve paylaşımlı posta kutularıdır.

• Paylaşımlı posta kutularının yeni sistemdeki karşılıklarını önceden oluşturun.
• Takvim paylaşım izinlerini ve toplantı odası (resource mailbox) yapılarını yeniden kurgulayın.
• Mobil cihazlarda takvim ve kişiler için kullanılan senkronizasyon yöntemlerini (Exchange, CardDAV, CalDAV vb.) gözden geçirin.

Senaryo 4: Google Workspace / Microsoft 365’ten cPanel veya Kendi Sunucunuza Dönüş

Bazen de tam tersi bir geçiş görmekteyiz: Maliyet, veri egemenliği veya özel güvenlik gereksinimleri nedeniyle Google Workspace ya da Microsoft 365’ten ayrılıp cPanel tabanlı bir çözüme veya tamamen kendi VPS/dedicated sunucusuna kurulu bir posta sunucusuna geçmek isteyen ekipler.

1. Hedef mimariyi netleştirin

Burada iki opsiyon vardır:

• cPanel tabanlı e-posta: Yönetimi kolay, küçük ve orta ölçekli işletmeler için pratik çözüm.
• VPS veya dedicated üzerinde kendi MTA’nız: Postfix + Dovecot + rspamd gibi bileşenlerle tamamen size özel bir altyapı. Bu yolu tercih ediyorsanız, detaylı kurulum ve teslim edilebilirlik ayarları için VPS’te e-posta sunucusu kurulumu rehberimizi mutlaka inceleyin.

DCHost tarafında, bu tür senaryolar için hem cPanel hosting paketleri hem de kendi e-posta sunucunuzu kurabileceğiniz VPS ve dedicated sunucu altyapıları sunuyoruz. Böylece ihtiyacınız olan seviye kadar kontrolü elinizde tutabilirsiniz.

2. Kullanıcı ve veri taşıma

Google Workspace veya Microsoft 365’ten çıkarken de IMAP tabanlı veri taşıma temel yöntemdir:

• cPanel’de veya kendi posta sunucunuzda önceden tüm kullanıcı kutularını oluşturun.
• IMAP sync aracıyla Google/Microsoft tarafındaki posta kutularını yeni kutulara bire bir kopyalayın.
• İlk tam kopyadan sonra, MX değişimine yakın dönemde bir veya iki kez delta senkronizasyonu yapın.

3. MX ve SPF’in kontrollü değişimi

Google Workspace / Microsoft 365’ten çıkarken yapmanız gerekenler:

1. Domain’in MX kayıtlarını yeni cPanel veya posta sunucunuza yönlendirin.
2. SPF kaydından Google/Microsoft ile ilgili include: ifadelerini kaldırın, yerine yeni sunucunuzu tanımlayın (IP veya hostname bazlı).
3. Yeni sunucunuzda DKIM anahtarları üretip DNS’e ekleyin. DMARC kaydını da yeni duruma göre güncelleyin.

Burada en sık yapılan hata, MX’i değiştirdikten hemen sonra Google/Microsoft tarafındaki domain yapılandırmasını tamamen silmek. Bizim önerimiz, en az 1-2 hafta bu servisleri “pasif” ama yapılandırma bozulmadan tutmak; böylece gecikmeli DNS veya istemci önbelleklerinden gelecek son e-postaları da garantilemiş olursunuz.

Kontrol Listesi: Sıfır Kesinti E-Posta Taşıma Adımları

Tüm senaryoları özetleyen, sahada gerçekten uygulayabileceğiniz bir kontrol listesini toparlayalım. Bunu kendi geçiş planınız için checklist olarak kullanabilirsiniz.

1. Envanter: Domain’ler, kullanıcılar, alias’lar, forwarding kuralları, paylaşımlı kutular, toplam veri boyutu.
2. DNS erişimi: Domain DNS paneli, yönetici hesapları, kim hangi değişikliği ne zaman yapacak?
3. TTL düşürme: Geçişten 24-48 saat önce MX ve ilgili TXT kayıtlarının TTL’ini 300-600 sn’e indirin.
4. Yeni altyapıyı hazırlama: Google Workspace / Microsoft 365 / cPanel / kendi posta sunucunuz üzerinde domain ve kullanıcı kutularını oluşturun.
5. Kimlik doğrulama kayıtlarını tasarlama: SPF, DKIM, DMARC, rDNS planını önceden kağıda dökün; hangi IP’ler hangi alanları imzalayacak?
6. İlk veri senkronizasyonu: IMAP veya yerel migration araçlarıyla mevcut kutuları yeni sisteme kopyalayın.
7. Pilot kullanıcılarla test: En az 2-3 kullanıcıyı uçtan uca taşıyıp, hem gönderme hem alma hem de spam durumlarını test edin.
8. MX cutover zamanı: Yoğun trafiğin nispeten düşük olduğu bir zaman dilimini seçin (genelde akşam saatleri veya hafta sonu).
9. MX değişimi ve anlık izleme: MX’leri yeni sisteme yönlendirdikten sonra, log’ları ve posta akışını 1-2 saat boyunca yakından izleyin.
10. Delta senkronizasyon: MX değişiminden sonra bir kez daha senkronizasyon çalıştırarak, arada kalan son e-postaları da taşıyın.
11. İstemci tarafı düzeltmeleri: Outlook profilleri, mobil hesaplar, imzalar, paylaşımlı kutu izinleri gibi kullanıcı tarafı ayarlarını finalize edin.
12. Eski altyapıyı bekletme: Eski posta sunucusunu 7-14 gün boyunca pasif ama erişilebilir tutun; gerekirse gelen son e-postaları manuel veya otomatik taşıyın.
13. Log ve blacklist kontrolü: Yeni altyapınızın IP’lerinin kara listelerde olup olmadığını ve SPF/DKIM/DMARC raporlarını düzenli kontrol edin.

Bu adımların tamamını disiplinli şekilde uygularsanız, “sıfır kesinti”ye çok yaklaşan bir geçiş gerçekleştirirsiniz. Kalan küçük sorunlar da genellikle tekil kullanıcı ayarlarına veya yerel istemci önbelleklerine dair olacaktır.

DCHost ile E-Posta Geçişini Daha Güvenli Yürütmek

E-posta altyapısı geçişi, teknik olarak detaylı ama doğru planlandığında oldukça kontrollü yürütülebilen bir süreç. DCHost olarak hem cPanel tabanlı e-posta hizmetlerinde, hem de kendi posta sunucusunu kurmak isteyen müşterilerimiz için VPS ve dedicated sunucu altyapılarında yüzlerce geçiş operasyonu gördük. Ortak ders şu: DNS, kimlik doğrulama ve veri senkronizasyonu için net bir planı olmayan hiçbir geçiş sorunsuz bitmiyor.

Eğer siz de Google Workspace, Microsoft 365 veya cPanel arasında geçiş planlıyorsanız ve kafanızda “MX’i ne zaman değiştirmeliyim, SPF’yi nasıl yeniden yazacağım, eski kutuları nasıl taşıyacağım?” gibi sorular dolaşıyorsa, bu yazıdaki kontrol listesini kendi durumunuza uyarlayarak başlayabilirsiniz. Daha karmaşık senaryolarda (çoklu domain, hibrit yapı, kendi MTA’nızı kurmak gibi) DCHost tarafındaki ekibimiz, domain yönetiminden VPS/dedicated sunucu kurulumuna, otomatik yedekleme stratejilerine kadar tüm altyapıyı birlikte tasarlayabilir.

Sonraki adım olarak; mevcut e-posta altyapınızı, DNS kayıtlarınızı ve hedef mimarinizi kısa bir doküman haline getirip bizimle paylaşmanız yeterli. Beraber, işinizin ritmini bozmadan, sakin ve öngörülebilir bir e-posta geçiş planı çıkarabiliriz.