Hosting Değiştirdikten Sonra E-Postalar Neden Çalışmaz?

Hosting değiştirdikten sonra e-postanın durmasının en sık nedenleri şunlardır: isim sunucusu değişince MX, mail, SPF ve DKIM kayıtları yeni DNS bölgesine taşınmamıştır, MX'in gösterdiği yeni sunucuda posta kutuları henüz açılmamıştır ya da yeni panel alan adının postasını hâlâ kendi diskinde tutmaya çalışıyordur. İlk iş, postanın nerede duracağına karar vermektir: eski sağlayıcıda, yeni hostingte ya da Microsoft 365, Google Workspace gibi ayrı bir serviste. Ardından MX kaydını, mail adının IP'sini, kutuları, SPF ile DKIM'i ve paneldeki yerel teslim ayarını sırayla kontrol edin.

Önce karar: posta nerede duracak?

Tipik tablo şöyle gelişir. Site yeni sunucuya kurulur, isim sunucuları değiştirilir, ana sayfa sorunsuz açılır ve herkes işin bittiğini düşünür. Ertesi gün muhasebeden biri dünden beri tek posta gelmediğini söyler. Site ile e-posta aynı alan adını kullanır ama ayrı yollardan akar, DNS'te hangi kaydın neyi göstereceği de postanın nerede yaşayacağına bağlıdır. Bu karar netleşmeden yapılan her düzeltme bir sorunu kapatıp başka birini açar.

Üç seçenek var. Aşağıdaki tablo her birinde MX'in neyi göstermesi ve yeni sunucudaki panel ayarının ne olması gerektiğini özetliyor.

Bizce küçük ekipler için en az bakım isteyen düzen, postayı sitenin bulunduğu paneldeki kutularda tutmaktır. Kullanıcı sayısı arttıkça ya da ortak takvim gibi ihtiyaçlar doğdukça ayrı servis anlam kazanır. Postayı siteyle aynı panelde yönetmek isterseniz Plesk panelli kurumsal hosting paketlerinde alan adınıza bağlı e-posta hesapları açılır. Hesap sayısı sınırsızdır, toplam disk alanı ise seçtiğiniz pakete bağlıdır.

Belirtiden nedene: hızlı eşleştirme

Elinizde yalnız bir belirti varsa hangi kontrolden başlayacağınızı bu tablo gösterir. Komutların ayrıntısı bir sonraki bölümlerde.

İsim sunucusu değişince hangi kayıtlar kaybolur?

Şunu baştan söyleyelim: isim sunucusunu değiştirdiğinizde kayıtlar tek tek taşınmaz, bölgenin tamamı el değiştirir. Eski sağlayıcıdaki bölgede ne varsa orada kalır. Yeni panel ise alan adını eklediğiniz anda kendi varsayılan bölgesini üretir: kök A kaydı, www, mail ve kendisini gösteren bir MX. Web sitesi için bu yeterlidir. Posta için çoğu zaman değildir.

Kaybolanlar genellikle bir zamanlar elle eklenmiş kayıtlardır. Microsoft 365 ya da Google Workspace'e giden MX değerleri, servisin alan adı doğrulaması için istediği TXT, Outlook'un otomatik kurulumda baktığı autodiscover kaydı, harici servisin DKIM kayıtları ve SPF'e sonradan eklenmiş include değerleri ilk akla gelenler. Bülten aracının ya da e-fatura yazılımının istediği doğrulama kayıtları da var, bunlar yıllarca unutulur ve geçiş günü birden eksik çıkar.

Geçişi henüz yapmadıysanız eski bölgenin tam dökümünü alın. Yaptıysanız ve elinizde döküm yoksa umut tükenmiş değil. Eski sağlayıcı bölgeyi silmediyse eski isim sunucusuna doğrudan sorarak kayıtları hâlâ görebilirsiniz:

dig @<eski-isim-sunucusu> ornek.com.tr MX +short
dig @<eski-isim-sunucusu> ornek.com.tr TXT +short
dig @<eski-isim-sunucusu> autodiscover.ornek.com.tr +short

<eski-isim-sunucusu> yerine alan adının eskiden kullandığı NS adını yazın. Yanıt boş geliyorsa bölge silinmiş ya da o sunucu artık bu alan adı için yanıt vermiyordur, o durumda eski sağlayıcının DNS ekranı veya destek ekibi tek kaynaktır. İsim sunucusu yerine yalnız A kaydını değiştirerek geçtiyseniz posta kayıtlarınız yerinde durur ve sorun başka bir yerdedir. İki yöntemin farkını alan adını hostinge bağlarken NS ile A kaydı arasındaki seçimde ayrıntılı anlattık.

Komut satırından beş dakikalık kontrol

Panel ekranları size ne yazdığınızı gösterir, internetin ne gördüğünü göstermez. Kontrolü bu yüzden dig ile yapın. Linux ve macOS'ta hazır gelir. Windows'ta aynı sorguları nslookup -type=mx ornek.com.tr biçiminde çalıştırabilirsiniz.

dig ornek.com.tr NS +short
dig ornek.com.tr MX +short
dig mail.ornek.com.tr A +short
dig ornek.com.tr TXT +short
dig default._domainkey.ornek.com.tr TXT +short
dig -x 203.0.113.10 +short

Sırayla okuyalım. İlk satır yetkili isim sunucularını verir. Beklediğiniz sağlayıcı çıkmıyorsa kayıtları yanlış panelde düzenliyorsunuz demektir. İkinci satır örneğin 10 mail.ornek.com.tr. döndürür, burada önemli olan öncelik sayısı değil, adın hangi makineye çıktığıdır. Üçüncü satır o adın IP adresini verir ve postanın gerçekte nereye gittiğini bu IP söyler. Microsoft 365 ya da Google Workspace kullanıyorsanız MX servisin verdiği adı göstermelidir, mail adının IP'si o durumda yalnız istemci ayarlarını ilgilendirir.

Dördüncü satırda v=spf1 ile başlayan tek bir kayıt görmelisiniz. Beşinci satır DKIM açık anahtarını getirir. cPanel ve Plesk seçici adı olarak çoğunlukla default kullanır, harici servislerde seçici farklıdır ve servisin yönetim ekranında yazar. Son satır, gönderim yapan sunucu IP'sinin ters kaydını (PTR) gösterir. Örnekteki 203.0.113.10 yerine kendi gönderim sunucunuzun IP'sini yazın.

Değişikliği yeni yaptıysanız bir de önbellek sorusu var. Şu sorgu, yanıtın yanında çözümleyicide kalan süreyi de yazar:

dig +noall +answer ornek.com.tr MX
ornek.com.tr.   2817   IN   MX   10 mail.ornek.com.tr.

Buradaki 2817, kullandığınız çözümleyicinin bu cevabı yaklaşık 47 dakika daha önbellekte tutacağını söyler. Yetkili sunucuya doğrudan sorduğunuzda (dig @<yeni-isim-sunucusu> ornek.com.tr MX) doğru değeri, genel çözümleyicide eskisini görüyorsanız beklemekten başka yapacak bir şey yoktur. Önbelleğin nasıl işlediğini DNS kayıt türleri ve TTL rehberinde açıkladık. Kayıtları cPanel'de düzeltecekseniz Zone Editor'de MX ve TXT kaydı düzenleme adımları işinizi görür.

Kutular, parolalar ve istemci ayarları

MX yeni sunucuyu gösteriyor ama gönderenlere 550 5.1.1 ile başlayan bir hata dönüyorsa alıcı sunucu "böyle bir kutu yok" diyordur. RFC 3463'teki durum kodlarında X.1.1, adreste belirtilen posta kutusunun bulunmadığını anlatır, baştaki 5 de kalıcı hata demektir. Hosting taşırken en sık atlanan adım budur: site taşınır, e-posta hesapları yeni panelde açılmaz. cPanel'den cPanel'e tam hesap yedeğiyle geçtiyseniz kutular genellikle parolalarıyla birlikte gelir. Elle taşıdıysanız her hesabı yeniden açmanız ve yeni parolaları kullanıcılara iletmeniz gerekir.

İstemci tarafında iki ayrı tuzak var. İlki sunucu adı. Outlook'a mail.ornek.com.tr yazılıysa istemci DNS'i izler: kayıt yeni sunucuyu gösterdiği anda oraya bağlanır, hesap orada yoksa ya da parola farklıysa durmadan parola sorar. Eski sağlayıcının kendi sunucu adı yazılıysa tersi olur. İstemci DNS değişikliğinden hiç etkilenmez, eski sunucuya bağlanmayı sürdürür ve eski hesap kapandığı gün birden çalışmaz hâle gelir. Hangisinin yazılı olduğunu görmeden "Outlook bozuldu" teşhisi koymayın.

İkinci tuzak sertifika adı. İstemcinin bağlandığı ad sunucunun sunduğu sertifikada yer almıyorsa Outlook da telefonlar da uyarı verir. Bazı yapılandırmalarda mail adı için sertifika kendiliğinden üretilir, bazılarında sunucunun ana makine adını kullanmanız beklenir. Tahmin etmek yerine panelin gösterdiği değeri kullanın: cPanel'de Email Accounts ekranındaki Connect Devices bağlantısı gelen ve giden sunucu adlarını yazar. Outlook ve telefonda hesabı elle IMAP olarak kurma adımlarını ayrıca anlattık.

Gönderim sırasında sunucu 535 koduyla kimlik doğrulamayı reddediyorsa kullanıcı adının tam e-posta adresi olup olmadığına, parolanın yeni sunucuda belirlenen parola olup olmadığına ve porta bakın. Bu üçü tamamsa SMTP 535 kimlik doğrulama hatasının diğer nedenlerini sırayla elemek gerekir.

Otomatik kurulum ayrı bir konudur. Outlook, yalnız e-posta adresiyle hesap kurarken autodiscover.ornek.com.tr gibi adlara bakar. Microsoft 365 kullanıyorsanız Microsoft 365 için gereken DNS kayıtları listesine göre bu ad autodiscover.outlook.com adresine giden bir CNAME olmalıdır. Yeni panel kendi autodiscover kaydını oluşturduysa Outlook yeni profil kurarken yanlış sunucuyu bulur.

Giden postalar reddediliyor ya da spama düşüyor

Alma tarafı düzeldikten sonra gönderme tarafına geçin. Karşı sunucular postanızı artık başka bir IP adresinden görüyor ve ilk baktıkları şey o IP'nin size ait gönderici listesinde olup olmadığı. SPF kaydı eski sunucunun IP'sini sabit yazıyorsa yeni sunucu listede yoktur. Kaydın nasıl yazılacağını SPF, DKIM ve DMARC kurulum rehberi anlatıyor. Yeni servis eklerken kaydı şişirmemek gerekir, çünkü SPF'teki 10 DNS sorgusu sınırı aşıldığında doğrulama tümden bozulur.

DKIM'de durum daha sinsidir. Yeni sunucu kendi anahtar çiftini üretir ve giden postaları bu anahtarla imzalar. DNS'te hâlâ eski sunucunun açık anahtarı duruyorsa imza doğrulanmaz. DNS yeni paneldeyse kayıt çoğunlukla kendiliğinden oluşur. DNS başka yerdeyse panel oraya yazamaz. cPanel'in Email Deliverability ekranı önerilen DKIM kaydını gösterir ama Repair düğmesi yalnız sunucu alan adının yetkili isim sunucusuysa çalışır. Plesk'te Mail Settings sayfasındaki "How to configure external DNS" ipucu, harici DNS'e eklemeniz gereken iki kaydı verir.

PTR kaydı alan adınızın DNS'inde değil, IP adresinin sahibinde tanımlanır. Paylaşımlı hostingte bu sağlayıcının işidir. Kendi VPS ya da VDS'inizden posta gönderiyorsanız ters kaydı sunucu sağlayıcınızdan istemeniz gerekir, cPanel belgesi de IP'nin sahibi olmayan birinin bu kaydı değiştiremeyeceğini açıkça yazar. Konu küçük görünür ama değildir: Google'ın gönderici yönergeleri, gönderim yapan IP'nin ters kaydının bir ana makine adına çözülmesini ve o adın da aynı IP'ye geri dönmesini şart koşar.

Site formları ve sipariş postaları dışarı çıkmıyor

Bu belirti kafa karıştırır. Dışarıdan gelen postalar Microsoft 365'teki kutulara sorunsuz düşüyor, ama sitedeki iletişim formundan info@ornek.com.tr adresine giden bildirimler hiç gelmiyor. Nedeni basit. Web sunucusundaki posta yazılımı alan adını kendine ait sanıyorsa iletiyi internete göndermez, kendi diskindeki kutuya bırakır. Kimsenin bakmadığı, belki hiç açılmamış bir kutuya.

cPanel'de bu davranışı Email bölümündeki Email Routing ekranı belirler. Belgedeki tanımlara göre Local Mail Exchanger seçiliyken sunucu alan adının postasını her zaman kabul eder ve yerel kutuya teslim eder. Remote Mail Exchanger seçiliyken postayı kabul etmez, en düşük numaralı MX'e gönderir. Önerilen varsayılan olan Automatically Detect Configuration ise kararı sunucudaki bölge dosyasında yazan MX girişine göre verir, internette yayımlanan gerçek MX'e bakmaz. DNS'iniz başka yerdeyse ve yeni sunucudaki bölge hâlâ kendini gösteren bir MX taşıyorsa ayar yanlış tarafa düşer. Posta dışarıdaysa Remote Mail Exchanger'ı elle seçin. cPanel, siz bir kez seçtikten sonra bu ayarı kendiliğinden değiştirmez, posta düzenini ileride yeniden değiştirirseniz bu ekranı da güncelleyin.

Plesk'te karşılığı, Websites & Domains altında alan adının Mail sekmesindeki Mail Settings sayfasıdır. "Mail service on this domain" ayarında Linux sunucularda Enabled ve Disabled for incoming mail seçenekleri bulunur. Posta ayrı serviste duruyorsa Disabled for incoming mail seçin: sunucu alan adı için gelen postayı kabul etmez, siteniz ise gönderim yapmaya devam eder. Aynı listede Not configured seçeneği de var ve Plesk belgesine göre bu seçenek alan adının posta kutularını içindeki iletilerle birlikte kalıcı olarak siler. Kutularda veri varsa ona dokunmayın.

Ayarı düzelttikten sonra formu yeniden doldurun. Bildirim hâlâ gelmiyorsa sorun yönlendirmede değil, gönderimin kendisindedir. WooCommerce kullanıyorsanız sıradaki adım sipariş e-postasının tetiklenip tetiklenmediğini ve gönderim günlüğünü kontrol etmektir.

Geçiş günlerinde eski sunucuya düşen postalar

Diyelim ki MX kaydını pazartesi sabahı değiştirdiniz ve eski kaydın TTL değeri 14400 saniye, yani dört saat. Bu sürede bazı gönderen sunucular önbellekteki eski cevaba güvenip postayı eski sunucuya teslim eder. İleti kaybolmaz ama yanlış kutuya düşer, kimse de oraya bakmaz. Pratikte iki kural yeter. Eski hesabı en az eski TTL süresi boyunca, tercihen birkaç gün daha posta kabul eder hâlde bırakın. Kesişim bittikten sonra eski kutularda kalanları IMAP ile yeni sunucuya eşitleyerek toplayın.

Eski hesabı erken kapatmak bu süreçteki en pahalı hatadır. Kapatılmış bir hesap postayı bekletmez, reddeder. Gönderen bir hata raporu alır ve çoğu zaman aynı iletiyi bir daha göndermez.

Düzeldiğini nasıl anlarsınız?

Tek bir başarılı deneme yetmez, çünkü posta iki yönlü ve birkaç ayrı yoldan akar. Şu sırayı izleyin:

1. Alan adınızın dışındaki bir hesaptan (örneğin kişisel bir Gmail hesabından) ad@ornek.com.tr adresine posta gönderin ve yeni kutuya düştüğünü görün.
2. Bu postayı yanıtlayın. Alıcı tarafta iletinin kaynağını açın (Gmail'de "Orijinali göster"). Received satırlarında yeni gönderim sunucunuzun adını ya da IP'sini, Authentication-Results satırında spf=pass ve dkim=pass değerlerini arayın.
3. Sitedeki iletişim formunu doldurun ve bildirimin gerçekten okunan kutuya ulaştığını görün.
4. Telefonda Wi-Fi'ı kapatıp mobil veriyle posta alıp gönderin. Farklı ağ, farklı çözümleyici demektir.
5. Eski TTL süresi dolduktan sonra eski kutuya yeni posta düşmediğini kontrol edin.

İkinci adımda dkim=fail görüyorsanız DNS'teki anahtar yeni sunucununkiyle eşleşmiyordur. spf=fail ya da spf=softfail görüyorsanız SPF kaydı yeni IP'yi kapsamıyordur. İkisi de geçiyor ama ileti hâlâ istenmeyen klasöründeyse sorun artık DNS'te değil, içerikte ya da IP itibarındadır.

Destek ekibine yazmadan önce

Sorun sürüyorsa Netx müşteri panelinden destek talebi açabilirsiniz. "Postalar gelmiyor" cümlesi tek başına teşhise yetmez. Talebe şunları eklerseniz ilk yanıt doğrudan çözüme gider:

• Alan adı ve postanın nerede durması gerektiği (yeni hosting, eski sağlayıcı ya da ayrı servis)
• Yukarıdaki dig komutlarının çıktısı
• Geri dönen hata iletisinin tam metni, özellikle 550 5.1.1 gibi kod içeren satır
• Örnek bir iletinin gönderen ve alıcı adresi, gönderim tarihi ve saati (saat dilimiyle)
• Ulaşan bir iletinin tam başlık bilgisi
• Hangi değişikliğin ne zaman yapıldığı: isim sunucusu, MX, panel ayarı

Parolaları talep metnine yazmayın. Başlık bilgisini paylaşmadan önce içinde saklamak istediğiniz bir adres olup olmadığına da bir göz atın.