E-postaları Yeni Hosting'e Kaybetmeden Taşıma

Siteyi taşımak geri alınabilir bir iştir: yanlış giderse eski sunucudaki dosyalar hâlâ oradadır, DNS'i geri çevirirsiniz, bir şey kaybolmaz. Mail taşımak öyle değildir. Geçiş sırasında yanlış anda MX kaydını çevirdiyseniz, o iki saat içinde gelen siparişler, teklifler ve sözleşmeler hiçbir yerde değildir — ne eski sunucuda, ne yenisinde. Hosting değişikliğinde mail kaybı yaşayan firmaların neredeyse tamamında sebep imapsync komutunun yanlış yazılması değil, adımların yanlış sırayla yapılmasıdır.

Bu yazıda mailleri yeni sunucuya aktarma işini doğru sırayla anlatıyorum: önce TTL'i düşürmek, sonra yeni sunucuda kutuları açmak, sonra ilk kopyalama, ancak ondan sonra MX kaydını çevirmek, ardından ikinci ve son bir senkronizasyon. Bu sıranın her adımının bir sebebi var ve hiçbiri atlanabilir değil. Ayrıca cPanel'de mail taşımayı sessizce bozan "Email Routing" tuzağını, POP3 kullanan istemcilerin nasıl mail yuttuğunu ve geçiş sonrası yapılacak kontrolleri de ele alacağım.

Mail Taşımada Kayıp Nereden Kaynaklanır#

Mail kaybının tek bir kaynağı vardır: bir mesajın, siz o kutuyu kopyaladıktan sonra ama MX kaydı yeni sunucuyu göstermeye başlamadan önce eski sunucuya düşmesi. Bu pencerede gelen her mesaj eski sunucunun kutusunda kalır; siz de kopyalamayı tamamladığınızı sandığınız için o kutuya bir daha bakmazsınız.

İkinci kaynak, tam tersi bir zamanlama hatasıdır: MX kaydını yeni sunucu kutuları oluşturulmadan çevirmek. Bu durumda yeni sunucu mesajı kabul eder ama "böyle bir kullanıcı yok" diyerek kalıcı hata (550) döndürür. Gönderene "adres bulunamadı" bounce'u gider; mesaj kuyruğa bile girmez, tamamen kaybolur.

Üçüncü kaynak DNS'in kendisidir. MX kaydını değiştirseniz bile dünya genelindeki çözümleyiciler eski kaydı TTL süresi boyunca önbellekte tutmaya devam eder. TTL'iniz 14400 saniye ise, kaydı değiştirdikten sonra dört saat boyunca bazı gönderenler hâlâ eski sunucunuza mail atar. Bu sürenin varlığını kabul etmek yerine yok saymak, kayıpların en yaygın sebebidir. DNS önbelleğinin nasıl çalıştığını TTL nedir yazısında ayrıntılı bulabilirsiniz.

Dördüncü kaynak istemci tarafıdır: POP3 ile "sunucudan sil" ayarı kullanan bir Outlook, siz kopyalamadan önce mesajları çekip sunucudan silmiş olabilir. O mesajlar sunucuda değil, tek bir bilgisayarın PST dosyasındadır.

Taşımadan Önce Toplanacak Bilgiler#

Geçişe başlamadan önce şu listenin tamamının elinizde olması gerekir. Eksik bir madde, geçişin ortasında sizi durdurur ve durma anı kaybın başladığı andır.

• Eski sunucudaki tüm mail hesaplarının listesi ve şifreleri. Şifreyi bilmiyorsanız eski panelden sıfırlayın; imapsync şifresiz çalışmaz.
• Her kutunun boyutu ve klasör yapısı (cPanel → Email Accounts ekranı kullanımı gösterir).
• Eski ve yeni sunucunun IMAP hostname'i, portu ve TLS ayarı. Hangi portun ne olduğu konusunda tereddüt varsa mail portları hangisi kullanılır yazısına bakın.
• Alan adının DNS'inin hangi panelden yönetildiği. Nameserver'lar hosting'de mi, alan adı sağlayıcısında mı, yoksa bir CDN'de mi? Yanlış panelde kayıt değiştirmek en sık yaşanan zaman kaybıdır; dig +short NS ornekfirma.com çıktısı doğru paneli tek satırda söyler.
• Kimin POP3, kimin IMAP kullandığı bilgisi. Aradaki farkı ve neden önemli olduğunu IMAP ve POP3 farkı yazısında ele aldım.
• Mevcut MX, SPF, DKIM ve autodiscover kayıtlarının bir çıktısı:

dig +short MX ornekfirma.com
dig +short TXT ornekfirma.com
dig +short TXT default._domainkey.ornekfirma.com
dig +short CNAME autodiscover.ornekfirma.com

Bu çıktıyı bir dosyaya kaydedin. Geçiş sonrası bir şey çalışmadığında karşılaştıracağınız referans budur.

Doğru Sıra: Yedi Adımlık Geçiş Planı#

Sıra şudur ve değiştirilemez:

Bu tablonun tek satırlık özeti şudur: önce kutu, sonra kopya, sonra MX, sonra ikinci kopya. Türkçe kaynakların çoğu 3. ve 4. adımı yer değiştirir ya da 6. adımı hiç yazmaz; kayıp tam olarak orada oluşur.

TTL'i Düşürmek: En Çok Atlanan Adım#

TTL'i düşürmek, geçişin kaybı en aza indiren tek hazırlığıdır ve geçişten en az 24 saat önce yapılmalıdır. Mantığı basit: bir DNS kaydının TTL değeri, dünyadaki çözümleyicilerin o kaydı ne kadar süre önbellekte tutacağını söyler. TTL 14400 (4 saat) iken MX'i değiştirirseniz, değişikliği yaptığınız andan itibaren dört saat boyunca bazı gönderen sunucular hâlâ eski MX'i kullanır.

Ama önemli bir ayrıntı var: TTL'i düşürmenin kendisi de eski TTL kadar süre alır. Yani 14400'lük bir kaydı 300'e çektiğinizde, tüm dünyanın 300'ü görmesi yine 4 saat sürer. Bu yüzden TTL düşürme işlemi geçiş gününde değil, en az bir gün önce yapılır.

Kaydın son hâli şuna benzemelidir:

; Geçişten 24-48 saat önce
ornekfirma.com.         300  IN  MX  10 mail.yenisunucu.com.
mail.ornekfirma.com.    300  IN  A       203.0.113.25
autodiscover.ornekfirma.com. 300 IN CNAME mail.yenisunucu.com.

cPanel kullanıyorsanız: Domains → Zone Editor → Manage ekranında ilgili kaydın yanındaki Edit'e basıp TTL alanına 300 yazın. Cloudflare gibi bir katman varsa TTL "Auto" olarak görünebilir; MX kayıtları proxy'lenemediği için orada da gerçek TTL uygulanır, gerekiyorsa manuel olarak 300 seçin.

Geçerli TTL'i ölçmek için otoriter sunucuyu değil, bir genel çözümleyiciyi sorgulayın — çünkü sizi ilgilendiren, dünyanın gördüğü kalan süredir:

# Kalan önbellek süresini gösterir; art arda çalıştırınca sayı azalır
dig @8.8.8.8 MX ornekfirma.com | grep -A1 "ANSWER SECTION"

# Otoriter sunucudaki gerçek TTL değeri
dig @ns1.eskisaglayici.com MX ornekfirma.com +noall +answer

Geçiş tamamlandıktan ve her şey stabil olduktan sonra TTL'i eski değerine (3600 ya da 14400) geri çıkarmayı unutmayın; kalıcı 300 TTL gereksiz DNS sorgusu üretir.

imapsync ile Kopyalama#

imapsync, iki IMAP sunucusu arasında mesajları klasör yapısını koruyarak kopyalayan bir araçtır. Çalışma mantığı kritik: her mesajı Message-ID, Date ve boyut gibi başlıklardan tanır, hedefte zaten varsa tekrar kopyalamaz. Bu yüzden aynı komutu ikinci kez çalıştırmak güvenlidir — 6. adımdaki delta senkronizasyonu tam olarak buna dayanır.

Önce kuru çalıştırma yapın; hiçbir şey kopyalanmaz, sadece ne olacağını raporlar:

imapsync --dry \
  --host1 mail.eskisunucu.com --user1 [email protected] --password1 'ESKI_SIFRE' \
  --host2 mail.yenisunucu.com --user2 [email protected] --password2 'YENI_SIFRE' \
  --ssl1 --port1 993 --ssl2 --port2 993 \
  --automap --logdir /root/imapsync-log

Çıktının sonundaki özet satırlarında Messages found in host1 ile Messages found in host2 sayılarını karşılaştırın. Kuru çalıştırma temizse --dry parametresini kaldırıp gerçeğini çalıştırın:

imapsync \
  --host1 mail.eskisunucu.com --user1 [email protected] --password1 'ESKI_SIFRE' \
  --host2 mail.yenisunucu.com --user2 [email protected] --password2 'YENI_SIFRE' \
  --ssl1 --port1 993 --ssl2 --port2 993 \
  --automap --skipsize --useheader Message-ID --useheader Date \
  --exclude '^Junk$|^Spam$|^Trash$' \
  --logdir /root/imapsync-log

Parametrelerin ne işe yaradığı:

• --automap: Gelen Kutusu/INBOX, Sent/Gönderilmiş gibi özel klasörleri otomatik eşler. İki taraf farklı panel kullanıyorsa şarttır.
• --skipsize: Bazı sunucular mesaj boyutunu farklı raporlar; bu parametre boyuta bakmadan Message-ID üzerinden karşılaştırır ve gereksiz kopyalamayı önler.
• --exclude: Spam ve çöp klasörlerini taşımayın. Hem süreyi kısaltır hem de yeni sunucunun itibarını gereksiz yere riske atmaz.
• --logdir: Her hesap için ayrı log dosyası yazar. Bir kutuda sorun çıktığında bakacağınız yer burasıdır.

Onlarca hesabı tek tek yazmak yerine bir CSV dosyasından döngüyle geçin:

# hesaplar.csv:  kullanici;eski_sifre;yeni_sifre
while IFS=';' read -r user eski yeni; do
  echo "=== $user ==="
  imapsync \
    --host1 mail.eskisunucu.com --user1 "$user" --password1 "$eski" \
    --host2 mail.yenisunucu.com --user2 "$user" --password2 "$yeni" \
    --ssl1 --port1 993 --ssl2 --port2 993 \
    --automap --skipsize --logdir /root/imapsync-log
done < hesaplar.csv

Büyük kutularda (10 GB üzeri) ilk kopyalama saatler sürebilir; işlemi screen -S mailtasima ya da tmux new -s mailtasima içinde başlatın, aksi hâlde SSH bağlantınız koptuğunda kopyalama da kesilir ve yarım kalan kutuyu nereden devam ettireceğinizi bilemezsiniz.

MX Kaydını Çevirme ve cPanel'in Sessiz Tuzağı#

MX kaydını, kutular oluşturulup ilk kopyalama bittikten sonra çevirin. Yeni MX kaydı şöyle görünür:

ornekfirma.com.   300  IN  MX  10 mail.yenisunucu.com.
mail.ornekfirma.com. 300 IN A      203.0.113.25

Değişikliğin yayıldığını farklı çözümleyicilerden doğrulayın:

dig @8.8.8.8 +short MX ornekfirma.com
dig @1.1.1.1 +short MX ornekfirma.com
dig @9.9.9.9 +short MX ornekfirma.com

Şimdi asıl tuzak. Eski sunucu cPanel ise, MX kaydını değiştirmeniz mailin oraya düşmesini durdurmaz. cPanel/Exim, alan adı sunucuda "yerel" (local) olarak tanımlıysa MX kaydına bakmadan mesajı kendi kutusuna teslim eder. Yani eski sunucudaki bir siteden gönderilen ya da o sunucudaki başka bir hesaptan gelen mailler, MX'i çevirdikten sonra bile yeni sunucuya değil, eski kutuya düşer. Kullanıcı "bazı mailler geliyor bazıları gelmiyor" der ve kimse sebebini bulamaz.

Çözüm, eski sunucuda mail yönlendirmesini uzak olarak işaretlemektir:

1. Eski cPanel → Email → Email Routing
2. Alan adını seçin
3. Remote Mail Exchanger işaretleyin ve kaydedin

Kök erişiminiz varsa doğrudan Exim'in dosyalarından da doğrulayabilirsiniz:

# Alan adı bu dosyada ise mail YEREL teslim edilir - çıkarılmalı
grep -n 'ornekfirma.com' /etc/localdomains

# Uzak teslim için bu dosyada olmalı
grep -n 'ornekfirma.com' /etc/remotedomains

Aynı adımı yeni sunucuda tersine kontrol edin: orada alan adının /etc/localdomains içinde ve panelde "Local Mail Exchanger" olarak işaretli olması gerekir. cPanel hesabının tümünü taşıyorsanız cPanel hesap taşıma yazısındaki adımlar bu ayarları da kapsar.

İkinci Senkronizasyon: Kaybı Sıfırlayan Adım#

MX değişiminden 24–48 saat sonra imapsync komutunu aynı parametrelerle bir kez daha çalıştırın. Bu, yazının en önemli adımıdır ve kaynakların çoğunda hiç yer almaz.

Sebep şu: MX'i çevirdiğiniz andan itibaren bir süre boyunca bazı gönderen sunucular hâlâ eski MX'i kullanır (TTL'i 300'e düşürdüyseniz bu süre kısadır ama sıfır değildir). O mesajlar eski sunucudaki kutuya düşmüştür. İkinci senkronizasyon tam olarak o mesajları alır. imapsync mükerrer kopyalamadığı için ilk kopyalamada aktarılanlar tekrar taşınmaz; sadece aradaki fark gelir.

# 1. kopyalamayla birebir aynı komut - imapsync farkı kendisi bulur
imapsync \
  --host1 mail.eskisunucu.com --user1 [email protected] --password1 'ESKI_SIFRE' \
  --host2 mail.yenisunucu.com --user2 [email protected] --password2 'YENI_SIFRE' \
  --ssl1 --port1 993 --ssl2 --port2 993 \
  --automap --skipsize --logdir /root/imapsync-log

Log çıktısında Messages transferred satırında küçük bir sayı (birkaç ila birkaç yüz) görmeniz normaldir; sıfır görmeniz de iyidir. Bu sayı binlerle ifade ediliyorsa MX kaydınız aslında yayılmamış demektir — geri dönüp DNS'i kontrol edin.

Bir hafta sonra üçüncü bir senkronizasyon daha yapmak, geç kalmış birkaç mesajı yakalamak için ucuz bir sigortadır. Eski hosting hesabını en az 30 gün kapatmayın.

Geçiş Sonrası Kontrol Listesi#

Geçiş bittikten sonra sırayla şunları doğrulayın:

1. Gerçek bir dış hesaptan test maili atın (Gmail gibi) ve yeni sunucuda geldiğini görün.
2. Yeni sunucudan dışarı mail gönderin ve karşı tarafta gelen kutusuna düştüğünü kontrol edin — spam'e düşüyorsa SPF/DKIM kayıtları yeni sunucuya göre güncellenmemiş demektir.
3. SPF kaydını güncelleyin. Eski sunucunun IP'si ya da include'u kayıtta kalırsa bir sorun çıkmaz ama gereksizdir; asıl risk yeni sunucunun SPF'e eklenmemiş olmasıdır.
4. DKIM'i yeni sunucuda üretin ve DNS'e ekleyin. Eski anahtar yeni sunucuda geçerli değildir; kaydı güncellemezseniz imzalar doğrulanamaz ve mailleriniz spam'e düşer.
5. Webmail girişini test edin. Kullanıcıların şifresi çalışıyor mu, klasör yapısı yerinde mi?
6. Kutu boyutlarını karşılaştırın. Eski ve yeni sunucudaki toplam mesaj sayısı kabaca aynı olmalı (Spam/Trash hariç tuttuysanız fark normaldir).
7. Otomatik yanıtlayıcı, filtre ve yönlendirme kurallarını yeniden kurun. imapsync bunları taşımaz; sadece mesajları taşır. Bu, en sık unutulan maddedir.
8. autodiscover/autoconfig kayıtlarını güncelleyin, aksi hâlde Outlook eski sunucuyu göstermeye devam eder.

Filtre ve yönlendirme kurallarının taşınmadığını geçişten sonra fark etmek, "müşteriye giden kopyalar birden kesildi" şikâyetiyle sonuçlanır. Geçiş öncesinde eski panelden ekran görüntüsü alın.

Outlook, Telefonlar ve POP3 Tuzağı#

Kullanıcı istemcilerini güncellemek geçişin son ama en görünür adımıdır. IMAP kullanan hesaplarda yapılacak iş, hesabın sunucu adreslerini yeni değerlerle değiştirmektir; mesajlar zaten sunucudadır.

POP3 kullananlarda durum farklıdır ve dikkat ister. POP3, mesajları sunucudan indirip (çoğu varsayılan ayarda) siler. Bu üç sonucu doğurur:

• Kullanıcının geçmiş mailleri sunucuda değil, o bilgisayarın veri dosyasındadır. imapsync onları göremez, taşıyamaz.
• Geçiş sırasında istemci hâlâ eski sunucuya bağlanıyorsa, siz kopyalarken o mesajları çekip silebilir.
• Yeni hesabı kurduğunuzda kullanıcı eski maillerini "kaybolmuş" sanır.

Doğru yaklaşım: geçişten önce POP3 kullanan istemcileri IMAP'e çevirin ve yerel klasörlerdeki eski mesajları sürükle-bırak ile IMAP kutusuna yükleyin, sonra taşımayı yapın. Bu mümkün değilse en azından geçiş boyunca istemciyi kapalı tutun ve "sunucuda kopya bırak" seçeneğini açın.

Telefon tarafında en pratik yol, eski hesabı silip yeniden eklemektir; ayarları düzenlemeye çalışmak genelde kısmi kalır. Yeni hesap eklerken sunucu adreslerini elle girin, otomatik algılamaya güvenmeyin — autodiscover kaydınız henüz yayılmamış olabilir.

Sıkça Sorulan Sorular#

Mail taşırken hiç kayıp yaşamamak mümkün mü#

Mümkündür, koşulu doğru sırayı uygulamaktır: TTL'i önceden düşürün, yeni sunucuda kutuları MX'i çevirmeden önce oluşturun, ilk kopyalamayı yapın, MX'i çevirin, 24–48 saat sonra ikinci bir senkronizasyon çalıştırın. imapsync mükerrer mesaj kopyalamadığı için ikinci senkronizasyon sadece aradaki farkı alır ve geçiş penceresinde eski sunucuya düşmüş mesajları kurtarır. Eski hesabı en az 30 gün açık tutmak da geç gelen mesajlar için ek güvence sağlar.

MX kaydını ne zaman değiştirmeliyim#

MX kaydını, yeni sunucuda tüm mail kutularını oluşturduktan ve ilk kopyalamayı tamamladıktan sonra değiştirin. Kutular oluşturulmadan MX'i çevirirseniz yeni sunucu "kullanıcı yok" diyerek kalıcı hata döner ve mesaj kaybolur; kopyalama yapılmadan çevirirseniz kullanıcılar geçiş anında boş kutuyla karşılaşır. Değişikliği iş yoğunluğunun en düşük olduğu saatte, tercihen hafta sonu akşamı yapın ve öncesinde TTL'i 300 saniyeye indirmiş olun.

TTL'i ne kadar önce düşürmeliyim#

Mevcut TTL süresi kadar önce, pratikte en az 24 saat önce. Çünkü TTL değişikliğinin kendisi de eski TTL kadar sürede yayılır: 14400'lük bir kaydı 300'e çektiğinizde tüm çözümleyicilerin yeni değeri görmesi yine dört saat alır. Geçiş gününde TTL düşürmek hiçbir işe yaramaz, sadece yaptığınızı sanırsınız. Geçiş bittikten ve her şey oturduktan sonra TTL'i eski değerine geri çıkarın.

imapsync komutunu iki kez çalıştırmak mailleri kopyalar mı#

Kopyalamaz; imapsync her mesajı Message-ID ve tarih gibi başlıklardan tanır, hedefte zaten varsa atlar. Bu yüzden aynı komutu istediğiniz kadar çalıştırabilirsiniz ve zaten geçişin doğru yöntemi de budur. İkinci çalıştırma sadece ilk kopyalamadan sonra eski sunucuya düşmüş yeni mesajları taşır. Mükerrer mesaj görüyorsanız sebep genelde --skipsize kullanılmaması ve iki sunucunun mesaj boyutunu farklı raporlamasıdır.

Eski hosting hesabını ne zaman kapatabilirim#

En erken 30 gün sonra, tercihen ikinci ve üçüncü senkronizasyonlar temiz çıktıktan sonra kapatın. Bazı gönderen sunucular teslim edilemeyen mesajları günlerce kuyrukta tutup tekrar dener; eski sunucu kapalıysa bu mesajlar kalıcı olarak geri döner. Ayrıca kutu boyutlarını karşılaştırma, unutulmuş bir hesabı fark etme ve filtre kurallarını kontrol etme fırsatını da bu süre içinde kullanırsınız. Kapatmadan önce tüm kutuların son bir yedeğini indirin.

Filtreler ve otomatik yanıtlayıcılar da taşınır mı#

Taşınmaz; imapsync yalnızca mesajları ve klasör yapısını kopyalar. Filtre kuralları, otomatik yanıtlayıcılar, mail yönlendirmeleri, dağıtım listeleri ve otomatik iletme ayarları yeni sunucuda elle yeniden kurulmalıdır. Geçişten önce eski panelde bu ekranların ekran görüntüsünü alın; sonradan hatırlamaya çalışmak neredeyse hiç işe yaramaz. cPanel hesabının tamamını transfer yöntemiyle taşıyorsanız bu ayarlar da gelir, ama sunucu tipi değişiyorsa yine kontrol edin.

Geçişten sonra mailler spam'e düşüyor, sebebi ne#

En yaygın sebep, yeni sunucunun SPF kaydına eklenmemiş ve DKIM anahtarının güncellenmemiş olmasıdır. Eski sunucu için üretilmiş DKIM anahtarı yeni sunucuda geçerli değildir; yeni sunucuda anahtar üretip DNS'e eklemeniz gerekir. Ayrıca yeni gönderim IP'sinin PTR kaydını ve kara listede olup olmadığını da kontrol edin. Bu üçünü doğruladıktan sonra bir test maili atıp mesaj başlıklarındaki kimlik doğrulama sonuçlarına bakmak en hızlı teşhis yöntemidir.

Webmail'den kutuları indirip yükleyerek taşıyabilir miyim#

Küçük ve tek bir kutu için yapılabilir ama önerilmez. Webmail üzerinden dışa aktarma genelde klasör yapısını, okundu bilgisini ve tarih damgalarını korumaz; büyük kutularda ise tarayıcı zaman aşımına uğrar. Alternatif olarak Outlook veya Thunderbird'de iki hesabı aynı anda IMAP ile tanımlayıp klasörleri sürükle-bırak yapabilirsiniz; bu yöntem küçük hacimlerde işe yarar fakat binlerce mesajda çok yavaştır ve yarıda kesilirse nerede kaldığını bilemezsiniz. Birden fazla hesap taşıyorsanız imapsync tek doğru araçtır.

Kapanış#

E-posta taşımanın tamamı bir sıralama meselesidir. Komutun kendisi kolaydır; zor olan, MX kaydını doğru anda çevirmek ve geçiş penceresinde eski sunucuya düşen mesajları ikinci bir senkronizasyonla kurtarmaktır. TTL'i bir gün önceden düşürün, kutuları MX'ten önce açın, kopyalayın, MX'i çevirin, eski sunucuda mail yönlendirmesini uzak yapın, 24–48 saat sonra tekrar senkronize edin ve eski hesabı bir ay bekletin. Bu yedi adımı sırasıyla uygularsanız kayıp ihtimali pratikte sıfıra iner; birini atlarsanız hangi mesajı kaybettiğinizi asla öğrenemezsiniz.

Bu süreci kendiniz yürütmek istemiyorsanız Clou.TR'nin site taşıma hizmeti mail kutuları, DNS kayıtları ve geçiş zamanlaması dâhil taşımayı üstlenir. Yeni bir kutu düzenine geçiyorsanız kurumsal e-posta hizmeti SPF ve DKIM kayıtları hazır gelir; siteyle birlikte taşıyacaksanız web hosting paketleri, düzenli toplu gönderim yapıyorsanız ayrı gönderim IP'li SMTP sunucu çözümü doğru adrestir.