cPanel’den Google Workspace / Microsoft 365’e E‑Posta Taşıma Rehberi (IMAP Sync ile Kesintisiz Geçiş)

cPanel üzerinde yıllardır çalışan bir e‑posta altyapısını Google Workspace veya Microsoft 365’e taşımak, kağıt üzerinde basit görünebilir; ancak iş kesintisiz geçişe ve veri kaybı yaşamamaya gelince, küçük hatalar bile büyük sorunlara dönüşebilir. DCHost ekibi olarak hem kendi altyapımız içinde hem de müşterilerimizin projelerinde sık sık cPanel → bulut e‑posta geçişleri yapıyoruz ve pratikte en çok işe yarayan yaklaşımın, iyi planlanmış bir IMAP senkronizasyon (IMAP sync) stratejisi olduğunu görüyoruz.

Bu rehberde; cPanel’den Google Workspace / Microsoft 365’e geçerken nelere dikkat etmeniz gerektiğini, IMAP sync ile posta kutularını nasıl taşıyacağınızı, DNS tarafında MX / SPF / DKIM / DMARC ayarlarını nasıl kurgulamanız gerektiğini ve geçişi neredeyse sıfır kesinti ile nasıl tamamlayabileceğinizi adım adım anlatacağız. Amacımız, hem teknik ekibi hem de teknik detaya uzak işletme sahiplerini rahatlatacak kadar net ve uygulanabilir bir yol haritası sunmak.

Eğer henüz hangi modeli seçeceğinize karar vermediyseniz, yani e‑postalarınızın tamamen hosting üzerinde mi, yoksa Google Workspace / Microsoft 365 gibi servislerde mi kalması gerektiğini tartışıyorsanız, önce mutlaka kendi hosting e‑postanız mı Google Workspace / Microsoft 365 mi sorusunu teknik ve mali açıdan ele aldığımız yazımıza göz atmanızı öneririz. Bu makale ise, kararını vermiş ve artık cPanel’den bulut e‑posta servislerine temiz, kontrollü ve geri dönüşü mümkün bir geçiş yapmak isteyenler için.

Neden Google Workspace / Microsoft 365’e Geçiliyor?

cPanel üzerinde çalışan klasik e‑posta sistemi, özellikle web sitenizle aynı hosting hesabında olduğu için küçük ve orta ölçekli projelerde hâlâ oldukça pratik. Buna rağmen birçok işletme, belirli bir olgunluk seviyesine geldiğinde e‑postasını Google Workspace veya Microsoft 365 gibi hizmetlere taşımayı tercih ediyor. Bunun başlıca sebeplerini netleştirirsek, geçiş motivasyonunuz ve öncelikleriniz de daha berrak hale gelir.

Öne çıkan motivasyonlar genellikle şunlar:

• Daha güçlü web arayüzü ve entegrasyonlar: Takvim, görev yönetimi, çevrim içi ofis uygulamaları, Drive/OneDrive entegrasyonları gibi ek özellikler.
• Mobil ve masaüstü istemcilerde sorunsuz deneyim: Otomatik yapılandırma, kurumsal cihaz yönetimi, güvenlik politikaları.
• Daha iyi spam filtresi ve güvenlik katmanları: Gelişmiş anti‑spam, anti‑phishing, 2FA, oturum yönetimi, şüpheli oturum uyarıları.
• BT ekibinin yükünün azalması: Disk, CPU, RAM, MTA yönetimi gibi konuları azaltarak e‑posta tarafını kısmen servis sağlayıcıya devretmek.
• Uzun vadeli arşiv ve uyum gereksinimleri: Yasal saklama, e‑discovery, journaling, arşiv posta kutuları gibi ihtiyaçlar.

Bu avantajları alırken en büyük kaygı ise şu oluyor: “Mevcut cPanel mail’lerim kaybolmadan, çalışanlarım hiçbir şey hissetmeden bu geçişi nasıl yaparım?” İşte burada IMAP sync ve doğru DNS planlaması, DCHost tarafında da her projede uyguladığımız kilit iki araç haline geliyor.

Taşıma Öncesi Planlama ve Envanter Çalışması

Başarılı bir geçişin %70’i, aslında geçişten önce yaptığınız hazırlığa bağlı. DCHost tarafında bir cPanel → Google Workspace / Microsoft 365 projesine başlarken ilk yaptığımız iş, detaylı bir envanter çıkarıp geçiş senaryosunu netleştirmek oluyor.

1. Tüm posta kutularının ve rolleri listesi

Önce cPanel’deki tüm e‑posta hesaplarını, alias’ları ve forward’ları listeleyin:

• Kişisel hesaplar: [email protected]
• Departman hesapları: info@, sales@, destek@
• Alias / forward adresler: info@ → ahmet@, destek@ → destek.ekip@ gibi
• Mailing list / dağıtım listeleri: cPanel’de varsa bunları da not edin.

Yeni tarafta (Google Workspace / Microsoft 365) bu rollerin hangisinin birebir posta kutusu, hangisinin dağıtım listesi, hangisinin paylaşılan posta kutusu olacağına önceden karar verin. Böylece IMAP sync tarafında neyi, nereye taşıyacağınız netleşir.

2. Boyut analizi ve kota planı

cPanel’de her posta kutusunun boyutunu ve toplam disk tüketimini kontrol edin. Özellikle 20–30 GB üzeri posta kutuları için geçiş stratejisini ayrı düşünmek gerekir. Büyük posta kutuları için:

• Klasör bazında önceliklendirme (ör. Yalnızca son 2 yıl + kritik klasörler)
• Arşiv klasörleri oluşturarak eski mailleri ayrı bir posta kutusuna taşımak
• Geçiş öncesi temizlik (spam, gönderilmiş ögeler, büyük ekler)

cPanel tarafında büyük posta kutularını nasıl küçültebileceğinizi merak ediyorsanız, dev mail kutularını küçültme ve kota yönetimi için hazırladığımız rehbere göz atabilirsiniz.

3. Şifreler, kimlik doğrulama ve güvenlik

IMAP sync yaparken genellikle her posta kutusunun kullanıcı adı ve şifresine ihtiyacınız olur. Bazı araçlar OAuth ile çalışsa da çoğu senaryoda kullanıcı şifrelerini bilmek veya geçici şifreler tanımlamak zorundasınız. Bu yüzden:

• Var olan şifrelerin güvenle saklandığı bir parola kasası kullanın.
• Gerekirse geçici geçiş şifreleri oluşturup geçiş sonra şifreleri yenileyin.
• Kullanıcıları sürece dahil ederek şifre değişimi planını önceden duyurun.

4. Kesintisiz geçiş stratejisi

Özellikle kurumsal projelerde, “Geçiş sırasında hiçbir e‑posta kaybolmasın, kullanıcılar aynı anda switch edilsin.” beklentisi olur. Bunun için ideal yaklaşım:

1. Ön senkronizasyon (bulk IMAP sync) → Eski postaların büyük kısmını önceden taşımak
2. DNS cutover’dan hemen önce delta / incremental sync → Son farkları taşımak
3. MX değişikliğinden sonra kısa bir süre daha ters yönlü kontrol → Kaçan mail var mı diye bakmak

Bu mantığın daha genel halini, MX geçişlerine özel olarak anlattığımız e‑posta altyapısını taşırken kesinti yaşamamak için hazırladığımız kontrol listesinde de bulabilirsiniz.

cPanel Tarafında Hazırlık: Hesaplar, Kotalar ve Yedekler

Geçişe başlamadan önce cPanel tarafını sağlama almak, veri bütünlüğü açısından kritik. DCHost altyapısındaki cPanel sunucularında bu adımları rutin olarak uygularız.

1. Tam yedek ve gerektiğinde geri dönüş planı

Her şeyden önce, cPanel hesabının (veya en azından tüm e‑posta verisinin) bir tam yedeğini alın:

• cPanel > Yedekleme veya Tam Yedek alma bölümü üzerinden full backup
• veya yalnızca mail dizinlerini (mail/, etc/aliases vb.) rsync ile güvenli bir depolamaya kopyalamak

Bu sayede IMAP sync sırasında ya da DNS cutover’dan sonra ortaya çıkabilecek beklenmedik bir sorun durumunda elinizde geriye dönük, tutarlı bir kopya olur.

2. IMAP erişimini ve bağlantı sınırlarını kontrol edin

IMAP sync aracı, cPanel sunucusuna yoğun şekilde bağlanacağı için:

• IMAP (993 TLS) servisinin stabil çalıştığından emin olun.
• Bağlantı sınırlarını (concurrency limit, rate limit vb.) hosting sağlayıcınız veya sunucu yöneticinizle netleştirin.
• Gerekirse geçici olarak limitler biraz yükseltilsin; aksi hâlde sync süreci çok uzayabilir.

3. Kullanıcılar için klasör düzeni ve temizlik

IMAP sync, klasör yapısını aynen taşıdığı için geçiş öncesinde basit bir temizlik yapmanız faydalı olur:

• Gereksiz klasörleri kapatmak veya bir araya toplamak
• Trash / Junk klasörlerindeki çok eski posta ve ekleri temizlemek
• Gereksiz taslak / gönderilmiş klasörlerini birleştirmek

Bu hem hedef tarafta daha düzenli bir posta kutusu sağlar hem de senkronizasyon süresini kısaltır.

IMAP Sync Mantığı: Eski Sunucudan Bulut Servise Veri Taşımak

IMAP senkronizasyonu, temelde iki IMAP sunucusu arasındaki klasör ve mesaj içeriklerinin kopyalanmasıdır. cPanel tarafı “kaynak”, Google Workspace / Microsoft 365 tarafı ise “hedef” IMAP sunucusu olur. Araç, ilgili hesap için önce klasör listesini çekip, sonra her klasördeki mesajları tek tek kopyalar ve UID’leri eşleştirir.

Tek yönlü, güvenli kopyalama

IMAP sync işlemi genellikle tek yönlüdür: cPanel → Google Workspace / Microsoft 365. Yani yanlış bir komut vermediğiniz sürece hedef taraftan kaynak tarafa veri silmez veya yazmaz. Bu da geçişin görece güvenli olmasını sağlar.

Kullandığınız araca göre yapılandırma değişse de temel parametreler şunlardır:

• Kaynak IMAP sunucusu: host, port, SSL/TLS, kullanıcı adı, şifre
• Hedef IMAP sunucusu: host, port, SSL/TLS, kullanıcı adı, şifre
• Hangi klasörlerin taşınacağı ve hariç tutulacağı
• Eşzamanlı bağlantı sayısı (performans ve limitler için önemli)

Örnek IMAP sync komutu (genel mantık)

Aşağıdaki örnek, sık kullanılan bir IMAP sync aracının mantığını anlatmak için temsili bir komuttur. Kullandığınız araca göre parametreler değişebilir:

imapsync 
  --host1 mail.eski-sunucu.com --user1 [email protected] --password1 "ESKI_SIFRE" 
  --host2 imap.yeni-sunucu.com --user2 [email protected] --password2 "YENI_SIFRE" 
  --ssl1 --ssl2 
  --automap --skipjunk 
  --nofoldersizes --useheader 'Message-ID' --skipsize

Buradaki amaç, kaynaktaki posta kutusunu hedefe kopyalarken gereksiz klasörleri (örneğin bazı spam klasörleri) atlamak ve IMAP sunucuları arasındaki klasör isim farklarını (Sent, Gönderilmiş öğeler gibi) otomatik eşleştirmektir.

Performans, limitler ve hız planlaması

Özellikle on binlerce mesaj içeren posta kutularında IMAP sync, saatler sürebilir. Bu yüzden:

• Küçük bir pilot kullanıcıyla süre ve hız testini mutlaka yapın.
• Eşzamanlı hesap (parallel) sayısını ve bağlantı adetini limitler dahilinde ayarlayın.
• Geçişi mümkünse mesai dışı saatlere veya hafta sonuna denk getirin.

Kaynak sunucu kapasiteniz sınırlıysa, çok fazla hesabı aynı anda senkronize etmek yerine dalga dalga (ör. 10’lu gruplar halinde) ilerlemek daha sağlıklıdır.

Adım Adım cPanel’den Google Workspace / Microsoft 365’e Taşıma Senaryosu

Şimdi teoriyi bir kenara bırakıp pratik bir geçiş senaryosunu birlikte kuralım. Bu adımlar, DCHost müşterilerinde sık kullandığımız, kendini kanıtlamış bir akış.

1. Pilot kullanıcı ile prova

• 1–2 temsilci kullanıcı seçin (tercihen teknik ekibe yakın veya süreci test etmeye istekli kişiler).
• Google Workspace / Microsoft 365 tarafında ilgili posta kutularını oluşturun.
• IMAP sync ile cPanel → yeni servis arasında ilk senkronizasyonu yapın.
• Masaüstü ve mobil istemcilerde yeni hesapları tanımlayıp, klasör yapısı ve mesaj tamlığını kontrol edin.

Pilot aşamada göreceğiniz sorunlar (karışan klasör isimleri, eksik klasörler, çok eski e‑postaların gereksiz şekilde taşınması vb.) toplu geçiş öncesi düzeltmeniz için size zaman kazandırır.

2. Toplu hesap oluşturma ve ön senkronizasyon

Pilot sorunsuz ise, cPanel’deki kullanıcı listenizi Google Workspace / Microsoft 365 tarafına toplu olarak içe aktarın (CSV vb.) ve tüm posta kutularını oluşturun. Ardından:

• Her kullanıcı için IMAP sync komutlarını/işlerini hazırlayın.
• Önce ön senkronizasyon yapın: Yani DNS’i değiştirmeden, mevcut tüm posta kutularını yeni tarafa kopyalayın.
• Bu aşamada, yeni gelen e‑postalar hâlâ cPanel’e düşmeye devam edecektir, bu normal.

Ön senkronizasyon tamamlandığında, yeni tarafta tüm kullanıcılara ait “neredeyse güncel” bir kopyanız oluşmuş olur.

3. DNS cutover’a yakın ikinci (delta) senkronizasyon

Ön senkronizasyondan sonra cPanel’de yeni e‑postalar birikmeye devam ettiği için, MX kayıtlarını değiştirmeden hemen önce ikinci bir delta / incremental senkronizasyon turu yapın. Çoğu IMAP sync aracı, daha önce kopyalanmış mesajları atlayıp yalnızca yeni olanları taşımayı destekler.

Bu ikinci tur sayesinde, MX kayıtlarını yeni servise yönlendirdiğiniz anda eski tarafta “sadece birkaç dakikalık fark” kalmış olur.

4. MX, SPF ve Autodiscover / Autodiscover (Autoconfig) değişiklikleri

Artık sıra DNS tarafında. Bu aşamada:

• MX kayıtlarını, Google Workspace veya Microsoft 365’in size verdiği hedeflere güncelleyin.
• SPF kaydınızı, yeni servis sağlayıcıyı da içerecek şekilde düzenleyin (ör. include:google.com / include:spf.protection.outlook.com gibi).
• cPanel tarafında e‑posta göndermeye devam etmeyecekseniz eski SMTP IP’lerinizi SPF’ten çıkarın.
• Autodiscover / autoconfig (özellikle Outlook kurumsal ortamlarında) için önerilen CNAME / SRV kayıtlarını ekleyin.

DNS kayıtlarını yaparken TTL değerlerini doğru kullanmak, geçişi çok hızlandırır. Bu konuda detaylı bir strateji için A, MX, CNAME ve TXT kayıtları için TTL değerlerini nasıl planlamanız gerektiğini anlattığımız rehbere mutlaka bakın.

5. MX değişikliğinden sonra kısa süreli izleme ve son senkronizasyon

MX kayıtları yeni servise yayılmaya başladıktan sonra:

• cPanel mail log’larını izleyin; hâlâ eski sunucuya gelen posta var mı diye kontrol edin.
• Varsa, bir son delta IMAP sync daha çalıştırarak bu farkı da kapatın.
• Kullanıcılara masaüstü ve mobil istemcilerde yeni hesabı varsayılan hale getirmeleri için talimat gönderin.

Genellikle 24–48 saat içinde global DNS yayılımı tamamlanır ve yeni e‑posta trafiğinin neredeyse tamamı Google Workspace / Microsoft 365 tarafına düşmeye başlar.

6. Eski cPanel posta kutularının yalnızca okuma modunda tutulması

Geçişten hemen sonra eski cPanel hesaplarını silmek yerine, belli bir süre boyunca (ör. 1–3 ay) “okuma amaçlı, kilitli” şekilde bırakmak, olası atlanan maillere karşı güvenlik yastığı olur. Bu süre içerisinde:

• Kullanıcılara eski hesabı kullanmamaları, yalnızca gerektiğinde webmail’den görüntülemeleri gerektiğini net anlatın.
• İsterseniz eski posta kutularını artık yazma hakkı olmayan bir kullanıcıya devir ederek yetkileri kısıtlayın.

DNS ve Kesintisiz Geçiş: MX, TTL ve Yol Haritası

cPanel’den Google Workspace / Microsoft 365’e e‑posta taşırken, asıl veri hareketini IMAP sync sağlasa da hangi yeni postanın nereye gideceğini DNS / MX kayıtları belirler. İyi DNS planlanmamış bir geçişte tipik sorunlar şunlardır:

• Bir kısmı hâlâ eski cPanel sunucusuna düşen e‑postalar
• Yanlış MX / yanlış SPF nedeniyle spam’e düşen kritik mailler
• Uzayan DNS yayılımı yüzünden günlerce karışık bir durum

Bunları önlemek için DCHost tarafında uyguladığımız tipik yol haritası:

1. Geçişten birkaç gün önce MX, SPF ve ilgili TXT kayıtlarının TTL’ini 300 sn (veya altına) düşürmek
2. Geçiş saatinde MX’leri yeni servise çevirmek ve eski MX’leri tamamen silmek
3. SPF kaydını anında güncellemek; hem yeni servisi eklemek hem de kullanılmayan IP/hostname’leri çıkarmak
4. MX değişikliğinden sonraki ilk 24 saat boyunca log’ları izlemeye devam etmek

Güvenlik ve Teslim Edilebilirlik: SPF, DKIM, DMARC ve MTA‑STS

Yeni tarafa geçişte en fazla ihmal edilen konulardan biri de, e‑posta kimlik doğrulama kayıtlarının doğru yapılandırılması. Google Workspace / Microsoft 365, DKIM imzalama gibi birçok konuda işinizi kolaylaştırsa da alan adınızın DNS’ini siz yönettiğiniz için SPF, DKIM ve DMARC kayıtları hâlâ sizin sorumluluğunuzda.

SPF ve DKIM’i doğru kurmak

Geçiş sonrası yapmanız gerekenler:

• SPF kaydınızda yalnızca gerçekten kullandığınız e‑posta gönderim kaynaklarını tutun.
• Google Workspace / Microsoft 365 için dokümantasyonda verilen include’ları doğru ekleyin.
• Yeni serviste DKIM anahtarını oluşturup ilgili TXT kaydını DNS tarafına ekleyin.

Bu sürece daha hakim olmak için SPF, DKIM ve DMARC’ı sıfırdan kurma rehberimizi okuyarak temelleri netleştirmenizi öneririz.

DMARC politikası ve raporlarını takip etmek

DMARC, SPF ve DKIM’in birlikte tutarlı çalışıp çalışmadığını denetleyen ve alıcı sunuculara “Bu alan adına aitmiş gibi görünen mailleri nasıl muamele edelim?” bilgisini veren kritik bir mekanizma. Geçiş sonrası:

• Önce p=none ile başlayıp raporları (RUA/RUF) izleyin.
• Yanlış yapılandırılmış üçüncü parti servisleri (CRM, fatura yazılımları vb.) tespit edin.
• Adım adım p=quarantine ve p=reject seviyelerine geçin.

Bu süreci daha stratejik yönetmek için, DMARC raporlarıyla p=none’dan p=reject’e geçişi adım adım anlattığımız yazıya göz atabilirsiniz.

Ek güvenlik katmanları: MTA‑STS, TLS‑RPT, DANE

İleri seviye kurumsal ortamlarda, MTA‑STS, TLS‑RPT ve DANE/TLSA gibi DNS tabanlı güvenlik mekanizmaları da gündeme gelir. Bu protokoller:

• Sunucular arası e‑posta trafiğinin TLS ile şifrelenmesini zorunlu kılabilir.
• Yanlış veya saldırgan ara sunucuların devreye girmesini zorlaştırır.
• Hatalı TLS kurulumlarını raporlayarak iyileştirme imkanı sunar.

Bu konularla ilgileniyorsanız, MTA‑STS, TLS‑RPT ve BIMI için gelişmiş DNS ayarlarını anlattığımız rehber iyi bir başlangıç olacaktır.

Sık Yapılan Hatalar ve DCHost Ekibinin Önerdiği İyi Uygulamalar

cPanel’den Google Workspace / Microsoft 365’e geçişlerde sahada en sık gördüğümüz hatalar ve bunlara karşı önerilerimizi özetleyelim.

1. IMAP sync yerine PST/indir‑yükselt ile uğraşmak

Bireysel kullanıcı gözüyle bakınca Outlook’tan PST export alıp yeni hesaba import etmek “kolay” gibi görünür; ancak onlarca kullanıcı, yüzlerce gigabayt veri olduğunda bu yöntem kabusa döner. IMAP sync ile:

• Merkezi, tekrarlanabilir bir süreç kurarsınız.
• Geriye dönük delta senkronizasyonlarla farkları kapatabilirsiniz.
• Kullanıcılara minimum iş bırakırsınız.

2. DNS’i erken veya plansız değiştirmek

En yaygın problem: MX kayıtları değiştirilip IMAP sync’e geç başlanması. Bu durumda:

• Yeni tarafta veri eksik kalır.
• Eski ve yeni posta kutuları arasında karışıklık yaşanır.
• Kullanıcılar “Bazı maillerim kayıp.” demeye başlar.

Her zaman önce ön senkronizasyon, ardından MX değişikliği ve son olarak delta senkronizasyon sırasına sadık kalın.

3. SPF/DKIM’i ihmal etmek ve spam şikayeti almak

SPF ve DKIM doğru kurulmadığında, yeni sistemden gönderdiğiniz e‑postalar alıcı tarafında güvenilir görünmez ve spam klasörüne düşebilir. Bu da geçiş sonrası “Yeni sistem kötü, mailler gitmiyor.” algısı oluşturur. Geçiş planına SPF, DKIM ve DMARC güncellemelerini mutlaka dahil edin. İlgili alanlarda detay isterseniz, e‑postalar neden spam klasörüne düşüyor başlıklı teslim edilebilirlik kontrol listemiz size çok yardımcı olacaktır.

4. Kullanıcı iletişimini unutarak panik yaratmak

Teknik taraf mükemmel olabilir; ancak kullanıcılar sürecin ne zaman, nasıl ve kendilerini nasıl etkileyeceğini bilmezse, geçiş günü şikayet yağmuruna tutulursunuz. Bu yüzden:

• Geçişten önce net bir bilgi e‑postası gönderin.
• Yeni giriş adresleri, istemci ayarları ve şifre politikalarını açıkça yazın.
• Geçiş günü ve sonrasında destek taleplerini toplayacak net bir kanal belirleyin.

5. Eski sistemi çok erken kapatmak

IMAP sync bitti, MX’ler güncellendi diye cPanel tarafını hemen kapatmak yerine, belirli bir süre yalnızca okuma modunda tutmak; atlanmış mailleri yakalama, beklenmedik bir sorunda hızlı rollback yapma imkanı sağlar. DCHost olarak kritik projelerde mutlaka bir “geri dönüş planı” ve bu planı destekleyecek yedek / eski sistem bekleme süresi tanımlarız.

Sonuç: DCHost ile Kontrollü, Şeffaf ve Geri Dönüşü Mümkün Bir Geçiş

cPanel’den Google Workspace veya Microsoft 365’e geçiş, doğru planlandığında hem kullanıcı deneyimini hem de kurumsal güvenliği ciddi şekilde iyileştiren bir adım. Ancak bunun bir gecede, hiçbir hazırlık yapmadan sadece MX’leri değiştirerek çözülebilecek basit bir işlem olmadığını bilmek gerekiyor. IMAP sync, DNS planlaması, SPF/DKIM/DMARC ayarları ve kullanıcı iletişimi birlikte ele alındığında, geçiş süreci kontrollü, şeffaf ve gerektiğinde geri dönülebilir hale geliyor.

DCHost ekibi olarak cPanel, DNS ve e‑posta altyapısını bütünsel bir şekilde ele alıyoruz. Web siteniz hâlâ bizim sunucularımızda kalırken, e‑postanızı Google Workspace / Microsoft 365 gibi hizmetlere taşıyabilir; DNS, SSL ve e‑posta doğrulama kayıtlarını tek bir mimari içinde yönetebiliriz. Eğer henüz “kendi hosting e‑postanız mı yoksa bulut tabanlı e‑posta mı sizin için daha mantıklı?” sorusuna cevap arıyorsanız, mutlaka e‑posta hosting seçimi rehberimizi de okumanızı öneririz.

Geçişi kendiniz yapmak isterseniz, bu yazıdaki adımları bir kontrol listesi gibi kullanabilir; özellikle IMAP sync ve DNS cutover tarafında adım adım ilerleyerek riskleri minimize edebilirsiniz. Daha karmaşık, çok alan adlı veya çok lokasyonlu yapılarda ise DCHost teknik ekibinden destek olarak projeyi birlikte planlayabiliriz. Böylece hem kesinti riskini en aza indirir, hem de uzun vadede sürdürülebilir bir e‑posta ve DNS mimarisi kurmuş olursunuz.