E-posta Sağlayıcısını Değiştirirken Mail Kaybetmeden MX Geçişi

Yeni sağlayıcının panelinde kutular hazır, size verdikleri MX değerleri elinizde ve DNS panelinde "Kaydet" düğmesinin üzerinde bekliyorsunuz. Aklınızdaki soru teknik bir soru değil, ticari bir soru: bu düğmeye bastığım anda birisi teklif isterse o mesaj nereye düşecek? Eski kutuya mı, yenisine mi, yoksa hiçbir yere mi?

Cevap, düğmeye basmadan önce hangi hazırlıkları yaptığınıza bağlı olarak üçünden herhangi biri olabilir. MX kaydı değiştiğinde dünya bunu aynı anda öğrenmez; bazı gönderen sunucular eski kaydı önbelleğinde tutmaya devam eder ve postayı eski sisteme teslim eder. Eski sistemde kutu hâlâ duruyorsa mesaj orada birikir — kayıp değildir ama siz bakmadığınız için kaybolmuş gibidir. Eski sistemde kutu kapatılmışsa mesaj kalıcı hata alır ve gönderene "böyle bir adres yok" bildirimi gider; bu gerçekten kayıptır ve geri dönüşü yoktur.

Bu yazı, geçişi bir kesim planı gibi kuruyor: T-72'den T+72'ye kadar hangi saatte ne yapılacağı, o adımın neden o sırada olduğu ve nasıl doğrulanacağı. Kutu içeriğini kopyalamanın kendisi ayrı bir konu — imapsync ayrıntıları için e-postaları yeni sunucuya taşıma yazısına bakın. Burada odak teslimat tarafında: DNS, çift MX dönemi, kimlik doğrulama kayıtlarının geçiş penceresindeki hâli, istemci ayarları ve geri dönüş.

Geçiş Anında Gelen Mailler Nereye Düşer?#

Bir gönderen sunucu size posta yollarken önce alan adınızın MX kaydını sorar. Bu sorgunun cevabı kendi çözümleyicisinin önbelleğinden gelir. Siz MX'i değiştirdiğinizde o önbellekteki kayıt, kendi TTL süresi dolana kadar geçerliliğini korur. Dolayısıyla kesim anından sonra postalar iki hedefe birden akmaya devam eder ve bu akış, eski TTL değeri kadar sürer.

Bu pencerede bir mesajın başına gelebilecek dört şey vardır:

Planın tamamı bu tablodaki üçüncü ve dördüncü satırları imkânsız hâle getirmek üzerine kuruludur. Kural şudur: geçiş penceresinde hiçbir taraf hiçbir geçerli adrese kalıcı hata döndürmemelidir. Kalıcı hata (5xx) mesajı öldürür; geçici hata (4xx) yalnızca geciktirir, çoğu gönderen birkaç gün boyunca yeniden dener.

T-72: MX ve İlgili Kayıtların TTL'ini Düşürün#

TTL düşürmek geriye dönük çalışmaz. Şu anda MX kaydınızın TTL'i 14400 ise, bugün onu 300'e çekseniz bile dört saat boyunca bazı çözümleyiciler eski değeri 14400 saniyelik ömürle tutmaya devam eder. Yani düşük TTL'in gerçekten yürürlüğe girmesi için eski TTL kadar beklemek gerekir. Bu yüzden ilk adım kesimden en az üç gün önce atılır; 86400 (bir gün) TTL kullanan sağlayıcılarda 72 saat rahat bir paydır.

Sadece MX satırının TTL'ini düşürmek yetmez. Geçişte değişecek her kaydın TTL'i inmelidir:

; T-72'de düşürülecek kayıtlar
ornek.com.                  300  IN  MX     10 mx1.eskisaglayici.com.
ornek.com.                  300  IN  TXT    "v=spf1 include:eskisaglayici.com ~all"
mail.ornek.com.             300  IN  A      203.0.113.25
autodiscover.ornek.com.     300  IN  CNAME  autodiscover.eskisaglayici.com.
webmail.ornek.com.          300  IN  A      203.0.113.25

MX kaydı kendi sunucunuzun bir hostname'ini gösteriyorsa o hostname'in A kaydının TTL'i de aynı ölçüde önemlidir; MX doğru sunucuyu gösterip A kaydı eski IP'de kalırsa posta yine eski makineye gider. TTL seçimi ve önbellek mantığı için TTL nedir yazısına bakabilirsiniz.

Değişikliğin gerçekten yürürlükte olduğunu 72 saat boyunca ara ara ölçün:

# Dönen TTL değeri 300'e doğru inip inmediğini gösterir
dig +noall +answer MX ornek.com @8.8.8.8
dig +noall +answer MX ornek.com @1.1.1.1

T-48: Hedef Tarafta Kutular, Takma Adlar ve Yönlendirmeler Hazır Olsun#

Kesim anında yeni sağlayıcı, alan adınıza gelebilecek her geçerli adresi tanıyor olmalıdır. Tanımadığı bir adrese posta geldiğinde 550 no such user döner ve o mesaj gerçekten kaybolur. Bu yüzden T-48'de yapılacak iş sadece "kutuları açmak" değildir; eski sistemdeki adres envanterinin tamamını çıkarmaktır.

IMAP kopyalama araçları yalnızca kutu içeriğini taşır. Aşağıdakilerin hiçbiri kopyalanmaz, elle yeniden kurulur:

1. Takma adlar (alias) ve yönlendirmeler. cPanel kullanıyorsanız listeyi sunucudan doğrudan alabilirsiniz: /etc/valiases/ornek.com dosyası tüm forwarder tanımlarını içerir.
2. Dağıtım listeleri. info@, destek@ gibi birden fazla kişiye dağıtılan adresler.
3. Sunucu tarafı filtreler ve otomatik yanıtlar. Tatil mesajları ve klasöre taşıma kuralları.
4. Catch-all (varsayılan adres) ayarı. Eski sistemde açıksa, kapalı bir yeni sistemde daha önce sessizce çalışan adresler bir anda hata döndürmeye başlar. Riskleri için catch-all e-posta adresi yazısına bakın.
5. Uygulama hesapları. Sitenizin iletişim formu, muhasebe yazılımı, e-ticaret bildirimleri hangi kullanıcı adıyla SMTP'ye bağlanıyorsa o hesap da yeni tarafta olmalıdır.

Geçiş penceresi boyunca yeni tarafta geçici bir catch-all açmak, envanterde atlanan bir adresi kalıcı kayıptan geçici birikime çevirir. Pencere kapandıktan sonra kapatırsınız.

T-24: IMAP ile İlk (Ön) Kopya#

Kesimden bir gün önce mevcut kutuların tam kopyası yeni sunucuya alınır. Bu kopyanın amacı işi bitirmek değil, kesimden sonra yapılacak ikinci kopyayı kısa tutmaktır. On yıllık bir kutuyu kesim anında kopyalamaya kalkarsanız aktarım saatler sürer ve o saatler boyunca kullanıcılar iki sistem arasında bölünmüş bir gelen kutusuyla çalışır.

İlk kopyadan sonra kullanıcılar eski sistemi kullanmaya devam eder; henüz hiçbir şey değişmemiştir. Kesimden sonra alınacak ikinci kopya yalnızca aradaki farkı (delta) taşır ve dakikalar sürer. Komut ayrıntıları ve klasör eşleme sorunları için taşıma rehberini kullanın.

Bu adımda not almanız gereken tek şey, ilk kopyanın bittiği tam saattir. İkinci kopyada bu saat sizin başlangıç noktanızdır.

T-0: MX Kaydını Çevirme Anı#

Kesim anında yapılacak iş tek bir kayıt değişikliği değildir; birkaç kaydın birlikte değişmesi gerekir. Sıra önemlidir: önce yeni MX yayınlanır, sonra eski MX kaldırılır.

; Kesim: yeni sağlayıcının değerleri
ornek.com.   300  IN  MX  1   aspmx.l.google.com.
ornek.com.   300  IN  MX  5   alt1.aspmx.l.google.com.
ornek.com.   300  IN  MX  5   alt2.aspmx.l.google.com.

Buradaki sayılar önceliktir ve küçük olan önce denenir. Bu, "çift MX dönemi" hakkındaki en yaygın yanlış anlamayı da açıklar: eski ve yeni sağlayıcıyı farklı önceliklerle aynı anda tanımlarsanız postalar ikiye bölünmez. Gönderenlerin tamamı düşük numaralı sunucuyu dener; yüksek numaralı sunucu yalnızca birincisi cevap vermediğinde devreye girer. İki sağlayıcıyı aynı öncelikle tanımlarsanız gerçekten bölünme olur — ve bu istenen bir şey değildir, çünkü aynı kişinin postaları rastgele iki farklı kutuya dağılır.

Kurumsal anlamda "split delivery" denen yapı bu değildir; o, tek bir MX'in postayı aldıktan sonra kullanıcı listesine bakarak bir kısmını diğer sisteme aktarmasıdır ve sağlayıcı tarafında ayrıca yapılandırılır. Öncelik mantığının ayrıntısı için MX kaydı nedir yazısına bakabilirsiniz.

Eski sistemi yedek MX olarak bırakmak yerine önerilen yol şudur: eski sunucuda alan adını uzak (remote) alan adı olarak işaretleyip gelen postayı yeni sağlayıcıya aktarmak. cPanel/WHM tarafında bu ayar "Email Routing" altındadır; A kaydınız hâlâ eski sunucuyu gösteriyorsa varsayılan davranış postayı yerelde tutmaktır ve bu, geçişte en çok mesaj yutan ayardır. Ayrıntısı için site ve mail farklı sunucuda DNS ayarı yazısına bakın.

Değişiklikten hemen sonra ölçün:

# Yeni MX yayında mı, birden fazla resolver'dan doğrulayın
dig +short MX ornek.com @8.8.8.8
dig +short MX ornek.com @1.1.1.1

# En düşük öncelikli sunucuya gerçek bir teslimat denemesi
swaks --to [email protected] \
      --server "$(dig +short MX ornek.com | sort -n | head -1 | awk '{print $2}')"

T+0 – T+48: Eski Kutuya Düşen Mailleri İzleyin ve Delta Kopyayı Alın#

Kesimden sonraki ilk 48 saat izleme dönemidir ve bu dönemin tek amacı vardır: eski sisteme düşmeye devam eden mesajları görmek. Kayıp yaşayan firmaların çoğu bu adımı atlar — MX değişti diye eski sunucuya bir daha bakmazlar.

Eski sunucuya erişiminiz varsa teslimatları log'dan izleyebilirsiniz:

# Exim (cPanel/WHM sunucuları)
grep " <= " /var/log/exim_mainlog | grep "@ornek.com" | tail -50
exim -bp | head

# Postfix
grep "to=<.*@ornek.com>" /var/log/maillog | tail -50
postqueue -p

Erişiminiz yoksa webmail'den kutulara bakmak da yeterlidir; kesimden sonra düşen her mesaj oradadır. Trafik tamamen kesildiğinde — genellikle eski TTL süresinin iki katı içinde — ikinci ve son kopyayı alırsınız. Delta kopyada yalnızca ilk kopyadan sonra gelen mesajlar taşınır; aynı mesajın iki kez kopyalanması normalde araç tarafından engellenir.

Bu pencerede kullanıcılara söylenecek tek cümle şudur: eski webmail'i kapatmayın, yeni kutuya bakın, eski kutuya da günde bir kez göz atın.

Geçiş Penceresinde SPF, DKIM ve DMARC Her İki Sistemi Birden Kapsamalı#

Bu, planın en çok atlanan ve en pahalı sonuç doğuran adımıdır. Geçiş penceresinde giden posta iki ayrı yerden çıkar: kullanıcıların bir kısmı yeni sistemden, uygulamalar ve henüz ayarı değişmemiş istemciler eski sistemden gönderir. SPF kaydınız yalnızca yeni sağlayıcıyı kapsıyorsa eski sistemden çıkan her mesaj doğrulamayı geçemez ve alıcı tarafında spam'e düşer ya da reddedilir.

Doğru yaklaşım, pencere boyunca ikisini birden kapsayan tek bir SPF kaydı yayınlamaktır:

; Geçiş penceresi boyunca — ikisi de kapsanıyor
ornek.com.  300  IN  TXT  "v=spf1 include:_spf.google.com include:spf.eskisaglayici.com ~all"

Burada dikkat edilecek sınır, SPF'nin toplam 10 DNS sorgusu limitidir. İki sağlayıcıyı birden eklemek bu limiti kolayca aşırır ve sonuç permerror olur; yani kayıt tamamen geçersiz sayılır, tek bir sağlayıcı yazmışsınız gibi bile davranmaz. Limiti nasıl ölçeceğinizi ve nasıl düşüreceğinizi SPF 10 DNS lookup limiti ve permerror yazısında bulabilirsiniz.

DKIM tarafı daha rahattır: iki sağlayıcının seçicileri (selector) farklı isimlerde olduğu için kayıtlar çakışmaz ve ikisi aynı anda yayında kalabilir. Eski sağlayıcının seçicisini kesimden hemen sonra silmeyin; yolda olan, kuyrukta bekleyen ve raporlanacak mesajlar hâlâ o imzayı taşıyor olabilir. En az iki hafta bırakın.

DMARC tarafında ise geçiş penceresinde politikayı gevşetmek gerekir. p=reject ile çalışan bir alan adında, kapsanmayan bir kaynaktan çıkan tek bir mesaj bile alıcı tarafından doğrudan reddedilir. Pencere boyunca p=none kullanıp raporları toplamak, hangi kaynakların hâlâ eski sistemden gönderdiğini görmenin en temiz yoludur:

; Geçiş penceresi
_dmarc.ornek.com.  300  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

Raporlar iki hafta boyunca yalnızca beklediğiniz iki kaynağı gösteriyorsa pencere kapanmış demektir; politikayı ancak o zaman eski sıkılığına geri alın.

Autodiscover, SRV ve Telefonların Eski Sunucuya Bağlanma Sorunu#

MX kaydı yalnızca gelen postanın hangi sunucuya teslim edileceğini belirler. Kullanıcının Outlook'u, iPhone'u ve masaüstündeki Thunderbird'ü MX kaydına hiç bakmaz; hesap kurulurken yazılan IMAP/SMTP sunucu adına bağlanır. Kesimden sonra bu cihazlar hâlâ eski sunucuya bağlanır, eski kutuyu gösterir ve kullanıcı "hiç mail gelmiyor" der.

Burada iki farklı hata mümkündür ve ikisi de sık yapılır:

• mail.ornek.com A kaydını kesim anında yeni sunucuya çevirmek. Cihazlar aynı hostname'e bağlanmaya devam eder ama artık farklı bir sistemle konuşurlar; parolalar tutmadığı için toplu kimlik doğrulama hatası başlar ve bazı sunucular tekrarlanan başarısız denemeleri IP engeliyle karşılar.
• mail.ornek.com kaydına hiç dokunmamak. Bu sefer cihazlar sessizce eski kutuya bakmaya devam eder; hata yoktur, sadece yeni mesaj gelmez.

Sağlıklı yol, kullanıcı hesaplarını yeni sağlayıcının kendi sunucu adlarıyla (imap.saglayici.com gibi) yeniden kurmak ve otomatik yapılandırma kayıtlarını kesimle birlikte güncellemektir:

; Microsoft 365 tarafı
autodiscover.ornek.com.        300 IN CNAME autodiscover.outlook.com.
_autodiscover._tcp.ornek.com.  300 IN SRV   0 0 443 autodiscover.outlook.com.

; RFC 6186 — Apple Mail ve Thunderbird'ün baktığı kayıtlar
_imaps._tcp.ornek.com.         300 IN SRV   0 1 993 imap.saglayici.com.
_submission._tcp.ornek.com.    300 IN SRV   0 1 587 smtp.saglayici.com.

Eski sağlayıcıya ait autodiscover kaydını kesimde kaldırmazsanız Outlook, kullanıcı hesabı yeniden kursa bile eski sunucuyu önerir ve iş baştan başlar.

T+72: TTL'i Geri Yükseltin ve Eski Sistemi Kapatın#

Trafik tamamen yeni tarafa oturduğunda — eski sunucunun log'unda 24 saattir yeni teslimat görünmüyorsa — kapanış adımlarını atarsınız:

1. Son bir delta kopya alın ve eski kutulardan tam yedek indirin. Kutular silindikten sonra geri dönüş yoktur.
2. MX, SPF ve ilgili kayıtların TTL'ini normal değerine (3600 veya 14400) yükseltin. Düşük TTL kalıcı olarak bırakılırsa her sorgu yetkili sunucuya gider; bu, DNS sağlayıcınıza gereksiz yük ve her teslimatta birkaç milisaniyelik ek gecikme demektir.
3. SPF kaydından eski sağlayıcının include satırını çıkarın. Bırakırsanız, o sağlayıcının altyapısındaki herhangi bir hesap sizin adınıza posta göndermeye yetkili kalır.
4. DMARC politikasını hedeflediğiniz sıkılığa (quarantine ya da reject) alın — ama önce raporlarda kapsanmayan kaynak kalmadığını doğrulayın.
5. Eski sağlayıcıdaki hizmeti iptal etmeden önce en az bir ay bekleyin. Yıllık faturalandırılan bazı adresler ve yılda bir kullanılan sistem hesapları ancak o süre içinde ortaya çıkar.

Geri Dönüş Planı: MX'i Geri Almak Yeterli mi?#

Yeni sağlayıcıda beklenmedik bir sorun çıkarsa (kimlik doğrulama sorunları, kutu limitleri, kabul edilmeyen adresler) geri dönmek mümkündür ama bedelsiz değildir. MX kaydını eski değerine çevirmek düşük TTL sayesinde dakikalar içinde etkili olur. Sorun DNS'te değil, verilerdedir: geri dönüş anına kadar yeni sisteme düşmüş mesajlar yeni kutulardadır ve şimdi ters yönde bir delta kopya gerekir.

Bu yüzden planın içinde açıkça tanımlanmış bir "dönüşü olmayan nokta" bulunmalıdır. Pratik bir eşik şudur: eski kutular silinene ve kullanıcı cihazları yeni sunucuya göre yeniden kurulana kadar geri dönüş açıktır; bu ikisinden biri yapıldıktan sonra geri dönüş yeni bir taşıma projesidir.

Geri dönüş senaryosunu masada tutmak için üç şeyi pencere boyunca bozmayın: eski kutuları silmeyin, eski sağlayıcının hizmetini iptal etmeyin ve SPF kaydından eski sistemi çıkarmayın.

Geçiş Gününü Seçmek: Neden Cuma 18:00 Değil#

Kesim saatini "mesai bitiminde yaparız, kimse etkilenmez" mantığıyla seçmek, tam olarak izlenmesi gereken 48 saatlik pencereyi kimsenin başında olmadığı bir zamana denk getirir. Cuma akşamı yapılan geçişte pencere hafta sonuna düşer: sağlayıcı destek ekipleri yavaşlar, eksik kalan bir adres pazartesi sabahına kadar fark edilmez ve pazartesi — kurumsal e-postanın en yoğun sabahı — birikmiş bir sorunla açılır.

Daha sağlıklı bir seçim, gelen posta hacminin düşük olduğu ama ekibin ulaşılabilir olduğu bir zaman aralığıdır:

B2B çalışan firmalarda cumartesi sabahı, kesintisiz çalışan e-ticaret yapılarında ise salı ya da çarşamba sabahı en dengeli seçimdir. Belirleyici olan, kesimden sonraki 48 saat boyunca hem sizin hem sağlayıcının ulaşılabilir olmasıdır.

Sıkça Sorulan Sorular#

MX kaydını değiştirdiğimde gelen mailler kaybolur mu?#

Doğru hazırlıkla kaybolmaz. Kayıp yalnızca bir taraf geçerli bir adrese kalıcı hata döndürdüğünde olur; yani yeni sistemde kutu henüz açılmamışsa ya da eski sistemde kutu kesimden önce kapatılmışsa. Her iki tarafın da geçiş penceresi boyunca postayı kabul ettiğinden emin olursanız, en kötü ihtimalle mesaj eski kutuda birikir ve ikinci kopyayla alınır.

Eski ve yeni MX kaydını aynı anda bırakırsam mailler ikiye mi bölünür?#

Öncelik numaraları farklıysa bölünmez. Gönderen sunucular her zaman en küçük öncelik numarasına sahip sunucuyu dener; diğeri yalnızca birincisi ulaşılamaz olduğunda devreye girer. Bölünme ancak iki kaydı aynı öncelik numarasıyla tanımlarsanız olur ve bu istenmeyen bir durumdur, çünkü aynı kişinin postaları iki farklı kutuya rastgele dağılır.

TTL'i geçişten kaç saat önce düşürmeliyim?#

En az mevcut TTL değeri kadar önce. TTL düşürmek geriye dönük çalışmaz; eski değerle önbelleğe alınmış cevaplar kendi süreleri dolana kadar geçerli kalır. Mevcut TTL 86400 saniye ise yeni düşük değerin her yerde yürürlüğe girmesi bir gün sürer, bu yüzden 72 saatlik pay güvenlidir. Kaydın gerçek TTL'ini dig çıktısının ikinci sütunundan okuyabilirsiniz.

Geçiş sırasında SPF kaydını nasıl yazmalıyım?#

Pencere boyunca her iki sistemi de kapsayan tek bir SPF kaydı yayınlayın; bir alan adında ikiden fazla SPF kaydı bulunması kalıcı hataya yol açar. İki sağlayıcının include satırını birlikte eklerken toplam DNS sorgu sayısının onu aşmamasına dikkat edin. Geçiş tamamlandıktan sonra eski sağlayıcının satırını kaldırın, aksi halde o altyapı sizin adınıza posta göndermeye yetkili kalır.

Kullanıcıların telefonları ve Outlook'ları otomatik olarak yeni sunucuya geçer mi?#

Hayır. Bu programlar MX kaydına bakmaz; hesap kurulurken yazılan IMAP ve SMTP sunucu adına bağlanmaya devam eder. Kesimden sonra da eski sunucuyla konuşurlar ve kullanıcı yeni mesajları göremez. Hesapların yeni sağlayıcının sunucu adlarıyla yeniden kurulması gerekir; autodiscover ve SRV kayıtlarını güncellemek bu işi kolaylaştırır ama tek başına yeterli değildir.

Geçişten sonra eski hesabı ne zaman kapatabilirim?#

Eski sunucuya son teslimat geldikten sonra en az bir ay bekleyin. Bu süre içinde tam yedek alın ve kutuları silmeyin. Yılda bir kullanılan sistem hesapları, yenileme bildirimleri ve unutulmuş yönlendirmeler genelde ancak bu pencerede ortaya çıkar. Hizmeti erken iptal etmek, geri dönüş seçeneğini de tamamen ortadan kaldırır.