cPanel E‑Posta Hesaplarını Yeni Sunucuya Taşımak: IMAP Senkronizasyonu ve DNS Cutover

cPanel e‑posta taşıma sürecine genel bakış

Bir alan adı veya hosting paketi taşırken en çok tedirgin eden konulardan biri e‑posta hesaplarıdır. Web sitesinin birkaç dakika erişilememesi çoğu iş için tolere edilebilirken, e‑postanın kesilmesi veya bazı iletilerin kaybolması direkt olarak iş süreçlerini, satışları ve müşteri ilişkilerini etkiler. Bu nedenle cPanel e‑posta hesaplarını yeni bir sunucuya taşırken hedefiniz net olmalı: Sıfıra yakın kesinti, sıfır veri kaybı ve minimum kullanıcı müdahalesi.

Bu yazıda DCHost ekibi olarak sahada defalarca uyguladığımız, pratikte kendini kanıtlamış bir taşıma yaklaşımını parçalara ayırarak anlatacağız. Odakta üç temel bileşen var: Eski ve yeni sunucu arasında IMAP senkronizasyonu, DNS tarafında kontrollü bir MX cutover planı ve tüm süreci destekleyen TTL stratejisi. Yani önce posta kutularını arka planda kopyalıyor, ardından DNS’i dikkatlice çeviriyor ve son olarak da kalan farkları yakalayarak taşıma işlemini tamamlıyoruz.

Eğer alan adınızı da taşıyorsanız veya DNS yönetimini değiştiriyorsanız, mutlaka daha önce anlattığımız alan adı taşırken e‑posta kesintisini önleme rehberini de bu yazıyla birlikte düşünmenizi öneririz. Şimdi, adım adım ilerleyelim ve süreci teknik ama anlaşılır bir dille netleştirelim.

Taşıma öncesi hazırlık: Envanter, erişim ve DNS durumu

Başarılı bir cPanel e‑posta taşımasının sırrı, işe komut satırından veya DNS panelinden değil, doğru envanter çıkarma adımıyla başlamakta. Önce neye sahip olduğunuzu tam olarak görmelisiniz.

1. E‑posta envanterini çıkarın

Eski cPanel hesabınızda şu bilgileri mutlaka listeleyin:

• Tüm e‑posta adresleri (info@, destek@, kişisel adresler vb.)
• Her hesabın kota bilgisi (örneğin 2 GB, sınırsız vb.)
• Hangi hesapların aktif kullanıldığı, hangilerinin artık gereksiz olduğu
• Otomatik yönlendirme (forwarder) tanımlı adresler
• Otomatik cevaplayıcı (autoresponder) kullanılan adresler

Bu listeyi bir tablo halinde çıkarmak, yeni sunucuda hesapları birebir aynı şekilde oluştururken ciddi zaman kazandırır ve hata riskini azaltır.

2. Eski ve yeni sunucuya erişimi doğrulayın

IMAP senkronizasyonu yapabilmek için hem eski hem de yeni cPanel sunucusunda aşağıdaki bilgilere ihtiyacınız olacak:

• Hostname veya IP adresi (örneğin mail.ornekalanadi.com ya da doğrudan IP)
• IMAP portu (genelde 993 SSL veya 143 TLS)
• Her e‑posta hesabının tam adresi ve şifresi
• Güvenli bağlantı türü (SSL/TLS) ve doğrulanmış sertifika

Özellikle kurumsal yapılarda kullanıcı şifrelerini doğrudan almak mümkün olmayabilir. Böyle bir durumda, geçici olarak yönetici tarafından belirlenen şifreleri kullanmak veya kullanıcıların kendi arabirimlerinden şifre güncellemesi yapmasını sağlamak gerekir. Bu planı baştan netleştirmek, taşıma esnasındaki sürprizleri azaltacaktır.

3. DNS ve MX kayıtlarını analiz edin

Taşıma sürecinde DNS tarafında neyi, ne zaman değiştireceğiniz çok kritik. Öncelikle mevcut DNS durumunuzu netleştirin:

• Alan adınızın nameserver kayıtları nerede yönetiliyor? (Domain paneli, DCHost DNS, başka bir DNS sağlayıcısı vb.)
• MX kayıtlarınız hangi hostname veya IP adresini işaret ediyor?
• Mail ile ilişkili alt alan adları var mı? (mail.ornekalanadi.com, webmail.ornekalanadi.com vb.)
• Mevcut SPF, DKIM ve DMARC kayıtlarınız nasıl tanımlanmış?

DNS kayıtlarına genel bir bakışa ihtiyacınız varsa, detaylı terimleri sadeleştirdiğimiz DNS kayıtları A’dan Z’ye rehberini de yan sekmede açmanız faydalı olur.

Yeni cPanel sunucusunda posta kutularını hazırlamak

IMAP senkronizasyonuna geçmeden önce, yeni cPanel sunucusunda hedef posta kutularının hazır olması gerekir. Buradaki temel kural şu: Adresler, kullanıcı adları ve kotalar mümkün olduğunca birebir aynı olmalı.

1. cPanel hesabı ve alan adını tanımlayın

Yeni sunucuda DCHost üzerinden açtığınız cPanel hesabına alan adınızı ekleyin. Eğer çok sayıda domain barındırıyorsanız ve yapı karmaşıksa, aynı alan adını add-on domain mi yoksa ayrı cPanel hesabı olarak mı açmanız gerektiğini, daha önce yazdığımız cPanel’de addon domain mi, ayrı hesap mı rehberimizde ayrıntılı şekilde tartıştık. E‑posta kritik ise çoğu zaman her alan adı için ayrı cPanel hesabı tercih etmek, izolasyon ve yönetim açısından daha sağlıklıdır.

2. E‑posta hesaplarını birebir oluşturun

Envanter tablonuza bakarak yeni cPanel üzerinde:

• Eski sunucudaki tüm aktif e‑posta adreslerini aynı adla oluşturun
• Mümkünse aynı kota değerlerini kullanın (veya daha mantıklı bir limit belirleyin)
• Şifreleri kullanıcılarla mutabakata göre belirleyin (geçici veya kalıcı)
• Forwarder ve autoresponder ayarlarını da taşıyın

Özellikle kurumsal yapılarda kota planlamasını gözden geçirmek için bu taşıma iyi bir fırsattır. Bazı hesapların gereksiz büyüdüğünü, bazı hesapların da çok düşük kotada sık sık dolduğunu görebilirsiniz. DCHost tarafında kota ve disk kullanımına göre daha esnek planlar düşünüyorsanız, bunu taşıma öncesi planlamanız işinizi kolaylaştırır.

IMAP senkronizasyonu ile e‑posta kutularını taşımak

Şimdi işin kalbine, yani posta kutularının veri kaybı olmadan taşınmasına gelelim. Burada temel prensip şu: Eski sunucu ile yeni sunucu aynı anda IMAP üzerinden okunabilir olmalı ve aradaki farklar bir senkronizasyon aracı ile kademeli olarak kopyalanmalı.

Neden IMAP, POP3 değil?

POP3 protokolü tasarım gereği iletileri sunucudan çekip genellikle istemci tarafında saklamaya odaklanır. Birçok kullanıcıda ise istemci ayarı yanlış yapıldığından, kimi iletiler sunucuda tutulmaya devam eder, kimisi sadece istemcide kalır. Bu durum POP3 üzerinden sağlıklı bir taşıma yapmanızı zorlaştırır.

IMAP ise posta kutusunun tamamını sunucu üzerinde ana kaynak olarak görür. Klasör yapıları (Gelen Kutusu, Gönderilmiş, Taslaklar, özel klasörler vb.), okunma durumları, bayraklar (yıldızlı, önemli vb.) hepsi sunucu tarafında tutulur. Dolayısıyla IMAP, iki sunucu arasındaki veri bütünlüğünü korumak için çok daha uygun bir protokoldür.

IMAP senkronizasyonunun çalışma mantığı

İşin özünde IMAP senkronizasyonu, her posta hesabı için şu adımları uygular:

1. Eski sunucuya IMAP ile bağlanır, klasör listesini ve iletileri okur
2. Yeni sunucuya IMAP ile bağlanır, oradaki mevcut durumu inceler
3. Yeni sunucuda eksik olan iletileri kopyalar, var olanları tekrar kopyalamadan bırakır
4. Klasör yapılarını ve bayrakları mümkün olduğunca birebir taşır

Bu işlemi ilk başta tam bir senkronizasyon olarak çalıştırır, ardından DNS cutover öncesi ve sonrası differential (artımlı) senkronizasyonlar ile aradaki farkı güncellersiniz. Böylece taşıma sırasında gelen yeni iletiler de kaybolmaz.

IMAP senkronizasyonu için pratik ipuçları

Hangi aracı kullandığınızdan bağımsız olarak, pratikte aşağıdaki noktalara dikkat etmenizi öneririz:

• Önce küçük bir hesapla test edin: Çok büyük posta kutularına girmeden önce, 1 adet küçük hacimli e‑posta hesabı üzerinde uçtan uca test yapın.
• SSL/TLS bağlantılarını zorunlu kılın: Özellikle dışarı açık IP adreslerinden bağlanıyorsanız şifrelerin düz metin gitmemesi için IMAPS (993) veya STARTTLS (143) kullanın.
• Günlük veya log tutun: Hangi hesapta kaç iletinin taşındığını, hata alan hesapları log dosyasından takip etmek, sorun gidermeyi ciddi şekilde hızlandırır.
• Büyük posta kutuları için zaman planı yapın: 10–20 GB üstü posta kutularının ilk senkronu uzun sürebilir. Bunu gece veya düşük trafik saatlerine planlayın.

Şifre ve bağlantı sorunlarıyla baş etmek

Pratikte en sık yaşanan sorun, yanlış/eksik şifreler veya güvenlik duvarı kısıtlamalarıdır. Taşıma öncesi şu kontrol listesini uygulayın:

• Eski ve yeni sunucuda IMAP servislerinin çalıştığından emin olun
• Güvenlik duvarında 993 ve 143 portlarının erişilebilirliğini test edin
• Şüpheli durumlarda telnet veya openssl s_client ile temel bağlantı testi yapın
• Şifre politikasını netleştirin: Geçici şifre mi, kullanıcı kendi şifresini koruyor mu?

Eğer kullanıcılarınız webmail ve masaüstü istemciyi yoğun kullanıyorsa, taşıma sonrası şifreleri değiştirip, eski istemcilerdeki bağlantı ayarlarını yeni sunucu bilgilerine göre güncellemeyi de planın bir parçası olarak düşünmelisiniz.

DNS cutover: MX, A kaydı ve TTL stratejisi

Posta kutularını IMAP ile kopyaladıktan sonra sıradaki kritik adım, yeni sunucuya gerçek trafiği yönlendirmek. Bunun için DNS tarafında iki şey belirleyicidir: MX kayıtlarınız ve bu kayıtların ne kadar hızlı güncelleneceğini belirleyen TTL değerleri.

TTL kavramını doğru kullanmak

TTL, DNS kayıtlarının çözümleyicilerde ne kadar süreyle önbellekte tutulacağını belirler. MX kaydınız için TTL değeri yüksekse, değişiklik yaptığınız anda tüm dünyada hızlıca etkisini göstermez. Bu yüzden taşıma öncesi şu adımları uygulayın:

1. Mevcut MX kaydınızın TTL değerini tespit edin (örneğin 14400 saniye = 4 saat)
2. Taşıma işleminden en az 24–48 saat önce bu TTL değerini mümkünse 300–600 saniye seviyesine düşürün
3. Bu değişikliğin de yayılması için zaman tanıyın

TTL planlamasını daha geniş bir perspektifle ele aldığımız zero‑downtime taşıma için TTL stratejileri rehberinde DNS yayılımını hızlandırmak için kullanabileceğiniz pratik yöntemleri detaylandırdık. E‑posta taşımasında da aynı prensipler geçerli.

MX cutover sırası: Önce test, sonra tam geçiş

MX kaydınızı bir anda tamamen yeni sunucuya çevirmek yerine, kontrollü bir geçiş yapmak her zaman daha sağlıklıdır. Tipik bir plan şu şekilde olabilir:

1. Önce yeni cPanel sunucusunda mail.ornekalanadi.com gibi bir alt alan adı için A kaydını oluşturun ve yeni IP’ye yönlendirin.
2. Yeni sunucuda test amaçlı, ikinci bir domain veya alt domain üzerinden e‑posta alım/gönderim testleri yapın.
3. Her şey yolundaysa, asıl domaininizin MX kayıtlarını yeni mail host’unu işaret edecek şekilde güncelleyin.
4. Eski MX kaydını hemen silmeyin, düşük öncelikli bir değerle bir süre daha sistemde bırakın (isteğe bağlı, karmaşayı artırmamak şartıyla).

Bu süreçte DNS yönetimini nereden yapacağınıza karar vermediyseniz, Cloudflare DNS mi, hosting DNS’i mi sorusunu detaylandırdığımız yazıda farklı senaryoları masaya yatırmıştık. Ama hangi çözümü seçerseniz seçin, planlı bir TTL ve MX cutover olmadan sağlıklı bir geçiş beklemek zor.

SPF, DKIM ve DMARC kayıtlarını güncellemek

E‑posta teslim edilebilirliğinin bozulmaması için DNS’te sadece MX’i değil, SPF, DKIM ve DMARC kayıtlarını da yeni sunucuya göre güncellemeniz gerekiyor:

• SPF: Yeni sunucu IP’sini veya gönderen host adını SPF kaydınıza ekleyin. Eski sunucuyu bir süre daha kullanacaksanız, ikisini birden yetkili bırakın.
• DKIM: Yeni cPanel’de DKIM anahtarınızı üretin ve ilgili TXT kaydını DNS’e ekleyin. Eski anahtarla çakışmamasına dikkat edin.
• DMARC: Mevcut politikanızı (none, quarantine, reject) taşımanın hassas dönemine göre geçici olarak yumuşatabilir, raporları takip ederek hataları analiz edebilirsiniz.

Teslim edilebilirliği adım adım iyileştirme konusunda ayrıntılı teknik açıklamalara ihtiyacınız varsa, SPF, DKIM, DMARC ve rDNS ile e‑posta teslim edilebilirliğini artırma rehberimizi mutlaka inceleyin. Orada anlattığımız prensipler, cPanel taşımanızdan sonra da geçerliliğini koruyacak.

Kesintisiz geçiş için örnek zaman çizelgesi

Teoriyi netleştirdik. Şimdi bunu, gerçek hayatta uygulayabileceğiniz bir zaman çizelgesine dökelim. Aşağıdaki senaryoda, web sitesi ve e‑posta aynı domain üzerinde barınıyor ve siz DCHost üzerinde yeni bir cPanel sunucusuna geçiyorsunuz:

T‑48 saat: DNS ve hazırlık

• Alan adınızın DNS paneline erişimi kontrol edin.
• MX, SPF, DKIM ve varsa DMARC kayıtlarınızın mevcut halini yedekleyin.
• MX ve ilgili A kayıtlarının TTL değerlerini 300–600 saniye seviyesine çekin.
• Yeni cPanel sunucusunda domaini tanımlayın ve tüm e‑posta hesaplarını oluşturun.

T‑24 saat: İlk IMAP senkronizasyonu

• Eski ve yeni sunucuya IMAP bağlantısını test edin.
• Küçük bir posta kutusunda test senkronizasyonu yapın.
• Test başarılıysa, tüm aktif hesaplar için ilk tam IMAP senkronlarını başlatın.
• Büyük hesaplar için süreci izleyin, loglarda hata olup olmadığını kontrol edin.

T‑4 saat: İkinci (artımlı) senkron ve son kontroller

• Tüm hesaplar için ikinci bir IMAP senkronu çalıştırın, arada gelen yeni iletileri de kopyalayın.
• Yeni sunucudan test amaçlı bir veya birkaç hesaptan dışarıya e‑posta gönderin ve gelen kutusunu kontrol edin.
• Yeni sunucuda webmail erişimini ve SSL sertifikasını test edin.

T saati: MX cutover

• DNS panelinde MX kayıtlarınızı yeni cPanel sunucusunu işaret edecek şekilde güncelleyin.
• Gerekirse SPF kaydınıza da yeni IP veya host adını ekleyin.
• Değişiklikten sonraki ilk 15–30 dakika içinde farklı ağlardan MX lookup ve gönderim testleri yapın.

Bu noktadan sonra yeni gelen e‑postalar ağırlıklı olarak yeni sunucuya düşecektir, ancak bazı uzak DNS önbellekleri yüzünden kısa bir süre daha eski sunucuya giden iletiler olabilir.

T + 2–4 saat: Son IMAP senkronu ve temizlik

• Son bir kez IMAP senkronu çalıştırarak eski sunucuya düşmüş olabilecek iletileri de yeni sunucuya kopyalayın.
• Loglarda hata veren veya eksik kalan hesapları tek tek gözden geçirin.
• Eski sunucu üzerinde webmail girişlerini veya kullanıcı erişimini devre dışı bırakmayı planlayın.

Bu aşamada eski sunucu artık sadece bir tür yedek rolü görür. Tamamen kapatmadan önce birkaç gün daha pasif şekilde bekletmek, beklenmedik durumlara karşı sizi güvende tutar.

Tipik sorunlar ve sahadan çözümler

Yüzlerce cPanel taşımasında karşılaştığımız yaygın sorunlar ve pratik çözümlerden bazılarını paylaşalım.

1. Bazı iletiler eksik veya klasörler tam gelmedi

Genellikle nedeni, ilk senkron sonrası yapılmayan artımlı senkronlar veya belirli klasör adlarının özel karakter içermesi oluyor. Yapılması gerekenler:

• İlgili hesap için logları inceleyip hangi klasörlerde hata aldığınızı tespit edin.
• Sadece problemli klasörleri hedefleyen ek bir senkron denemesi yapın.
• Çok büyük klasörleri (örneğin 50 binden fazla ileti) parça parça taşımayı düşünün.

2. Kullanıcılar hala eski sunucuya bağlı

MX kaydını çevirmiş olsanız bile, bazı istemciler manuel olarak eski sunucunun IP’sine veya host adına tanımlı olabilir. Bu durumda:

• Kullanıcılara yeni gelen bağlantı ayarlarını net şekilde iletin (IMAP/SMTP host, port, SSL türü).
• Webmail URL’sini netleştirin ve eski webmail bağlantılarını yeni sunucuya yönlendirecek HTTP yönlendirmeleri planlayın.
• Özellikle mobil cihazlarda hesapların yeniden kurulması gerekebilir; kısa bir görsel rehber hazırlamak çok işe yarar.

3. Teslim edilebilirlik düştü, bazı iletiler spam’e gidiyor

Yeni sunucuya geçtikten sonra SPF, DKIM, rDNS ve DMARC uyumunu sağlamadan büyük hacimli posta göndermeye başlarsanız, bazı alıcı sunucular sizi şüpheli olarak işaretleyebilir. Bu nedenle:

• Önce teknik kimlik kayıtlarınızı (SPF, DKIM, rDNS) tam uyumlu hale getirin.
• DMARC raporlarını izleyerek hangi alıcıların sorun çıkardığını görün.
• IP ısınma sürecini gerçekçi tutun, özellikle toplu gönderimler için yavaş yavaş hacmi artırın.

Bu konuda daha derin bir senaryo okumak isterseniz, e‑posta itibarını kurtarma rehberimizde IP ısınma ve kara listeden çıkma süreçlerini detaylandırdık.

DCHost altyapısı ile cPanel e‑posta taşıma senaryoları

DCHost tarafında hem paylaşımlı cPanel hosting, hem de VPS ve dedicated sunucu çözümleriyle çok farklı e‑posta taşıma senaryoları görüyoruz. Birkaç tipik örneği kısaca özetleyelim:

• Küçük işletme: 5–10 e‑posta hesabı, birkaç GB toplam hacim. Genellikle tek seferde tam IMAP senkron ve hızlı DNS cutover ile 1 gün içinde tüm süreç tamamlanabiliyor.
• Ajans veya KOBİ: 20–50 hesap, onlarca GB posta. Burada genellikle taşıma 2–3 güne yayılıyor, ilk gün kopyalama, ikinci gün cutover, üçüncü gün temizlik şeklinde ilerliyoruz.
• Büyük posta hacmi olan e‑ticaret ve destek ekipleri: 100 GB üstü posta kutuları, çok sayıda klasör. Bu senaryolarda çoğu zaman DCHost üzerinde özel bir VPS veya dedicated sunucu planlayıp, IMAP senkronunu geceleri çalıştırarak kademe kademe ilerliyoruz.

Zaten DCHost blogunda da hem e‑posta hosting seçimi hem de paylaşımlı hostingden VPS’e geçiş gibi konuları detaylı ele aldık. E‑posta taşıma süreci de aslında bu kararların doğal bir uzantısı.

Sonuç ve DCHost ile bir sonraki adım

cPanel e‑posta hesaplarını yeni bir sunucuya taşımak, doğru planlama ile aslında korkulacak bir operasyon değil. Kritik olan, işi sadece MX kaydını değiştirmekten ibaret sanmamak. Sağlam bir envanter, dikkatli bir IMAP senkronizasyonu, TTL hesaplanmış bir DNS cutover ve sonrası için temel teslim edilebilirlik ayarları ile bu süreci hem teknik ekibiniz hem de son kullanıcılar için oldukça konforlu hale getirebilirsiniz.

DCHost olarak biz, hem cPanel’den cPanel’e göçlerde hem de farklı panellerden cPanel’e geçişlerde bu yaklaşımı yıllardır uyguluyoruz. İhtiyacınıza göre paylaşımlı hosting, yönetilen VPS veya dedicated sunucu tarafında size en uygun yapıyı birlikte kurgulayabilir, e‑posta hesaplarınızı minimum kesintiyle yeni altyapınıza taşıyabiliriz. Eğer elinizde karmaşık bir DNS yapısı, yüzlerce hesap veya kritik SLA gereksinimleri varsa, projeyi birlikte planlamak için bizimle iletişime geçmeniz yeterli. Böylece bir sonraki taşımanızda e‑posta tarafını artık stres kaynağı değil, kontrollü bir teknik operasyon olarak görebilirsiniz.