Site Bir Sunucuda, Mail Başka Sunucuda: DNS Nasıl Ayarlanır?

Ekranda MX kaydını yeni mail sağlayıcınızın verdiği değerle güncellediniz, kaydettiniz, dig ile kontrol ettiniz ve doğru cevabı aldınız. Dışarıdan gönderilen postalar da düzgün geliyor. Fakat sitenizin iletişim formundan gelen bildirimler hiçbir yere ulaşmıyor. Aynı sunucuda barınan başka bir hesaptan [email protected] adresine yazıldığında da posta buharlaşıyor — ne yeni kutuya düşüyor, ne de gönderene hata dönüyor.

Bu tablo, "site bir sunucuda, mail başka sunucuda" kurulumunun klasik tuzağıdır ve nedeni DNS'te değildir. Alan adının A kaydı hâlâ eski web sunucusunu gösterdiği sürece o sunucudaki mail servisi, alan adını "benim yerel alan adım" olarak kabul etmeye devam eder. O sunucudan çıkan bir posta MX kaydına hiç bakmaz; postayı ağa çıkarmadan kendi diskindeki kutuya bırakır. Kutu boştur, kimse okumaz, iz sadece log dosyasında kalır.

Bu rehberde ayrık kurulumun gerçekten nasıl yapıldığını anlatacağım: hangi kaydın hangi sunucuyu göstereceği, cPanel/Plesk/DirectAdmin tarafında kapatılması gereken "bu alan adının postasını ben taşıyorum" ayarının tam olarak nerede olduğu, alt alan adlarının nereye bakması gerektiği ve geçişi kesintisiz tamamlamak için hangi sırayla ilerleneceği. Sonunda hem gelen hem giden yönü tek tek doğrulayacak komutlarınız olacak.

Bu Kurulumda Aslında Ne Ayrışıyor#

Tek bir alan adı, birden fazla bağımsız hizmeti aynı anda adresleyebilir. Bunu mümkün kılan şey, DNS'in her hizmet için ayrı kayıt tipi kullanmasıdır. Web trafiği A/AAAA kaydına bakar, e-posta teslimatı MX kaydına bakar ve bu ikisi birbirinden tamamen bağımsızdır.

Bu ayrımın en yaygın üç gerekçesi var. Birincisi, sitenizi hızlı bir sunucuya taşırken kurumsal posta kutularını Google Workspace veya Microsoft 365 tarafında bırakmak istemeniz. İkincisi, tam tersi: siteyi bir platformda (paylaşımlı hosting, statik barındırma, hazır uygulama servisi) tutarken postayı kendi mail sunucunuzda yönetmek. Üçüncüsü ise geçiş dönemi: siteyi bugün taşıdınız, posta kutularının aktarımını hafta sonuna bıraktınız. Üç senaryoda da yapılması gereken teknik iş aynıdır.

Kayıt tiplerinin genel mantığına aşina değilseniz A kaydının ne işe yaradığı ve MX kaydının önceliği nasıl kullandığı konularına ayrı yazılarımızdan bakabilirsiniz; buradan itibaren ikisinin çakıştığı noktaya odaklanacağım.

MX'i Değiştirdim Ama Mailler Hâlâ Eski Sunucuya Düşüyor#

Bu, konunun tamamını özetleyen sorudur. Cevabı anlamak için bir postanın iki farklı yoldan gelebileceğini görmek gerekir.

Dışarıdan gelen posta. Gmail üzerinden [email protected] adresine yazıldığında Gmail sunucusu alan adının MX kaydını sorgular, dönen sunucuya bağlanır ve postayı teslim eder. Bu yolda A kaydının hiçbir etkisi yoktur. MX'i değiştirdiyseniz ve propagasyon tamamlandıysa dışarıdan gelen posta doğru yere gider. Zaten bu yüzden ilk testleriniz "çalışıyor" der.

Aynı sunucudan gönderilen posta. Web sunucunuz üzerindeki bir PHP betiği, WordPress bildirimi, cron çıktısı veya aynı makinede barınan başka bir hesap [email protected] adresine yazdığında iş değişir. Mail sunucusu yazılımı (cPanel'de Exim, çoğu Linux kurulumunda Postfix) önce şunu sorar: bu alan adı benim mi? Eğer alan adı yerel alan adları listesindeyse cevap "evet" olur, sunucu DNS'e hiç çıkmaz ve postayı kendi diskindeki kutuya yazar. MX kaydı orada okunmaz bile.

Sonuç, tam olarak baştaki tablodur: dış dünya doğru sunucuya konuşur, sunucunun kendisi ise alan adını hâlâ kendi malı sanar. Postalar kaybolmaz aslında; eski sunucuda, kimsenin bakmadığı bir posta dizininde birikir.

Bu davranışı doğrulamak için eski web sunucunuzda şu komutları çalıştırın:

# cPanel/Exim: alan adı yerel listede mi, uzak listede mi?
grep -x "sirketiniz.com" /etc/localdomains
grep -x "sirketiniz.com" /etc/remotedomains

# Bir adresin nereye yönleneceğini doğrudan Exim'e sordurun
exim -bt [email protected]

exim -bt çıktısında router = localuser benzeri bir satır görüyorsanız posta yerel kutuya gidiyordur. router = dnslookup ve karşısında dış sunucunun adı görünüyorsa yönlendirme doğrudur.

Postfix kullanan bir sunucuda karşılığı şudur:

# Alan adı hangi listelerde geçiyor?
postconf -n | grep -E "mydestination|virtual_mailbox_domains|relay_domains"

# Kuyruğa düşen postanın nereye gittiğini görün
postqueue -p

cPanel'de Local ve Remote Mail Exchanger Ayarı Nerede#

cPanel bu kararı "Email Routing" adı altında dört seçenekle sunar ve doğru seçeneği işaretlemek, ayrık kurulumun kilit adımıdır.

1. cPanel'e giriş yapın, Email bölümünde Email Routing (Türkçe arayüzde E-posta Yönlendirme) sayfasını açın.
2. Üstteki listeden alan adını seçin.
3. Dört seçenekten Remote Mail Exchanger'ı işaretleyin.
4. Change düğmesine basın.

"Automatically Detect Configuration" pratikte sorun çıkarır, çünkü otomatik tespit her zaman anlık MX kaydına bakmaz; bazı kurulumlarda kararı hesap açılışında verip saklar. Ayrık yapıda tercihi elle sabitleyin.

Bu değişikliğin sunucu tarafındaki karşılığı, alan adının /etc/localdomains dosyasından çıkarılıp /etc/remotedomains dosyasına yazılmasıdır. Değişiklikten sonra yukarıdaki grep komutlarını tekrar çalıştırıp sonucun yer değiştirdiğini görün. Reseller veya sunucu yöneticisiyseniz aynı ayara WHM tarafında Home » Email » Edit MX Entry ekranından, birden çok hesap için ulaşabilirsiniz.

Plesk, DirectAdmin ve panelsiz sunucularda karşılığı#

Plesk: Websites & Domains altında alan adını açın, Mail sekmesine geçin ve Mail Settings ekranındaki Activate mail service on domain kutucuğunun işaretini kaldırın. Bu kutu işaretli kaldığı sürece Plesk alan adını yerel posta alan adı olarak tanır ve sunucu içi gönderimler dışarı çıkmaz.

DirectAdmin: E-Mail Manager bölümündeki MX Records sayfasında MX değerini düzenleyin ve aynı sayfadaki Use this server to handle my emails seçeneğinin işaretini kaldırın. DirectAdmin bu iki ayarı bilinçli olarak yan yana koymuştur; MX'i değiştirip kutucuğu unutmak en sık yapılan hatadır.

Panelsiz Postfix: Alan adı mydestination, virtual_mailbox_domains veya relay_domains içinde geçmemelidir. Hiçbirinde yoksa Postfix alan adını dış alan adı sayar ve normal MX araması yapar.

# İlgili satırları düzenledikten sonra
postfix check
systemctl reload postfix

A Kaydı Web'i, MX Kaydı Mail'i Gösterecek Şekilde Zone Yazmak#

Ayrık kurulumun DNS tarafı aslında sade. Aşağıda tipik bir zone parçası var: web sunucusu 203.0.113.10, mail ise tamamen başka bir sağlayıcıda.

; Web tarafı - hosting sunucusunu gösterir
sirketiniz.com.               3600  IN  A      203.0.113.10
www.sirketiniz.com.           3600  IN  CNAME  sirketiniz.com.

; Mail tarafı - bambaşka bir sağlayıcı
sirketiniz.com.               3600  IN  MX     10 mx1.postaservisi.com.
sirketiniz.com.               3600  IN  MX     20 mx2.postaservisi.com.

; Gönderim yetkisi: hem sağlayıcı hem web sunucusu tek kayıtta
sirketiniz.com.               3600  IN  TXT    "v=spf1 include:_spf.postaservisi.com ip4:203.0.113.10 -all"

; Webmail ve istemci ayarları mail sağlayıcısına gider
mail.sirketiniz.com.          3600  IN  CNAME  webmail.postaservisi.com.
autodiscover.sirketiniz.com.  3600  IN  CNAME  autodiscover.postaservisi.com.

Dikkat edilecek üç nokta var.

Birincisi, MX kaydının sağ tarafı IP adresi olamaz. MX kaydı bir sunucu adı bekler; oraya 203.0.113.20 yazarsanız çoğu gönderici sunucu kaydı geçersiz sayar ve postayı geri çevirir. Doğru yol, önce mail sunucusu için bir A kaydı oluşturup MX'i o ada yöneltmektir.

İkincisi, MX hedefi CNAME olmamalıdır. mail.sirketiniz.com adını CNAME olarak tanımlayıp MX'i ona yöneltmek standartlara aykırıdır ve bazı gönderici sunucular bu zinciri takip etmez. Mail sağlayıcınızın verdiği MX adını doğrudan kullanın; kendi alt alan adınızı MX hedefi yapacaksanız onu A kaydı olarak tanımlayın.

Üçüncüsü, mail.sirketiniz.com alt alan adı çoğu kurulumda hâlâ eski sunucuyu gösterir. Hosting panelleri bu kaydı otomatik oluşturur ve siz MX'i değiştirdiğinizde onu güncellemez. Kullanıcılarınız Outlook'ta sunucu adı olarak mail.sirketiniz.com yazmaya devam ederse eski sunucuya bağlanmayı denerler ve kimlik doğrulama hatası ya da sertifika uyarısı alırlar. Bu kaydı ya yeni sağlayıcıya yöneltin ya da tamamen kaldırıp istemcilere sağlayıcının kendi adresini verin.

Zone dosyasının satır yapısını daha ayrıntılı görmek isterseniz DNS zone dosyası anatomisi yazısı işinizi görür.

Site Formlarından Giden Mailler Neden Spam'e Düşüyor#

Ayrık kurulumun ikinci yarısı, çoğu zaman ihmal edilen gönderim tarafıdır. İletişim formu, sipariş onayı, şifre sıfırlama gibi postaları web sunucunuz üretir ve sirketiniz.com adına gönderir. Alıcı tarafında ise şu kontrol çalışır: bu alan adı adına gönderim yapan IP, SPF kaydında yetkili mi?

MX'i yeni sağlayıcıya taşıyıp SPF kaydını olduğu gibi bırakırsanız iki farklı hata çıkar. SPF'te sadece mail sağlayıcısı varsa web sunucunuzun gönderdikleri yetkisiz sayılır. SPF'te sadece eski sunucu varsa bu kez sağlayıcı üzerinden çıkan postalar reddedilir. İkisini de kapsayan tek bir kayıt yazmanız gerekir; yukarıdaki örnekte include: ile ip4: ifadelerinin yan yana durmasının sebebi budur.

Alan adı başına yalnızca bir tane SPF TXT kaydı bulunabilir. İki ayrı v=spf1 satırı eklerseniz kayıt geçersiz olur ve doğrulama tamamen düşer. Ayrıca SPF'in include zincirinde 10 DNS sorgusu sınırı vardır; art arda birkaç servis eklerken bu sınırı aşmak sandığınızdan kolaydır.

En temiz çözüm, site kaynaklı postaları da mail sağlayıcınızın SMTP sunucusundan göndermektir. WordPress'te bir SMTP eklentisiyle, kendi uygulamanızda ise doğrudan SMTP ayarıyla bu yapılır. Böylece hem SPF tek bir kaynağı gösterir hem de DKIM imzası tutarlı olur. Konunun tamamı için SPF, DKIM ve DMARC kurulumu yazısına bakın.

# SPF kaydını okuyun - birden fazla v=spf1 satırı olmamalı
dig TXT sirketiniz.com +short | grep spf1

# DKIM seçici kaydını kontrol edin
dig TXT secici._domainkey.sirketiniz.com +short

Geçişi Kesintisiz Yapmak: Doğru Sıralama ve TTL Planı#

Adımların sırası, kesinti süresini belirler. Aşağıdaki akış posta kaybını en aza indirir.

1. Bir gün önce TTL'i düşürün. MX ve ilgili A kayıtlarının TTL değerini 3600'den 300'e çekin. Böylece asıl değişiklik anında dünya kaydı beş dakikada öğrenir. TTL mantığı için propagasyon süresi yazısına bakabilirsiniz.
2. Yeni sunucuda kutuları önceden açın. Aynı adresler yeni tarafta hazır olmalı; MX değiştikten sonra gelen posta yerini bulamazsa gönderene geri döner.
3. Mevcut postaları kopyalayın. IMAP senkronizasyonu ile ilk aktarımı önceden yapın. Yöntemler için e-postaları yeni sunucuya taşıma yazısı yeterli detayı veriyor.
4. MX kaydını değiştirin. Eski MX kayıtlarını silin; iki sağlayıcının MX'ini aynı anda bırakmak postaların rastgele bölünmesine yol açar.
5. Aynı dakikada mail routing ayarını çevirin. cPanel'de Remote Mail Exchanger, Plesk'te mail servisi kapalı, DirectAdmin'de kutucuk işaretsiz. Bu adım atlanırsa yazının başındaki tablo ortaya çıkar.
6. SPF ve DKIM kayıtlarını güncelleyin.
7. 24-48 saat sonra eski sunucudaki kutuları son bir kez senkronize edin, ardından TTL'i tekrar 3600'e çıkarın.

Eski sunucudaki posta kutularını hemen silmeyin. Propagasyon bitene kadar bazı göndericiler eski MX'i kullanmaya devam eder; kutu silinirse o postalar geri döner ve kaybolur.

Doğrulama: Gelen ve Giden Yönü Ayrı Ayrı Test Edin#

Testleri iki yönde de yapmadan geçişi tamamlanmış saymayın.

# 1) MX kaydının dünyaya ne döndüğünü görün
dig MX sirketiniz.com +short

# 2) Yetkili sunucuya doğrudan sorun (önbelleği atlayın)
dig @ns1.saglayiciniz.com MX sirketiniz.com +short

# 3) MX hedefinin IP'sini çözün
dig A mx1.postaservisi.com +short

# 4) Hedef sunucunun 25. portta gerçekten cevap verdiğini görün
openssl s_client -starttls smtp -crlf -connect mx1.postaservisi.com:25

Sorgulama araçlarının ayrıntısı için dig ve nslookup kullanımı yazısına bakabilirsiniz.

En kritik test ise web sunucusundan gönderim testidir, çünkü baştaki sorunu yalnızca bu ortaya çıkarır:

# Web sunucusunda çalıştırın - posta gerçekten dışarı çıkıyor mu?
echo "gecis testi" | mail -s "Routing testi" [email protected]

# Ardından log'da yönlendirmeyi okuyun (cPanel/Exim)
tail -n 50 /var/log/exim_mainlog | grep sirketiniz.com

# Postfix kullanan sunucularda
tail -n 50 /var/log/mail.log | grep sirketiniz.com

Log satırında teslimatın yerel bir kutuya yapıldığını gösteren bir ifade görüyorsanız posta hâlâ sunucu içinde kalıyordur; routing ayarı uygulanmamıştır. Satırda dış MX sunucusunun adı ve 250 OK cevabı geçiyorsa kurulum doğrudur.

Belirti, Sebep ve Çözüm Tablosu#

Sıkça Sorulan Sorular#

MX kaydını değiştirdim, neden hâlâ eski sunucuya mail düşüyor?#

Büyük ihtimalle eski sunucu alan adını kendi yerel alan adı olarak tanımaya devam ediyor. Bu durumda o sunucudan gönderilen postalar MX kaydına hiç bakmadan sunucu içindeki kutuya bırakılır. cPanel'de Email Routing ayarını Remote Mail Exchanger yapmanız, Plesk'te mail servisini kapatmanız veya DirectAdmin'de ilgili kutucuğun işaretini kaldırmanız gerekir. Ayar değişene kadar dışarıdan gelen postalar doğru gitse bile içeriden gidenler kaybolmaya devam eder.

A kaydı ile MX kaydı aynı sunucuyu göstermek zorunda mı?#

Hayır. Bu iki kayıt birbirinden tamamen bağımsızdır. A kaydı web trafiğinin hangi sunucuya gideceğini, MX kaydı ise e-postanın hangi sunucuya teslim edileceğini belirler. Aynı alan adı için A kaydı bir hosting sunucusunu, MX kaydı ise bambaşka bir mail sağlayıcısını gösterebilir. Bunlar aynı anda ve sorunsuz çalışır; ayrık kurulumun temeli zaten bu bağımsızlıktır.

Mail sunucusunun IP adresini doğrudan MX kaydına yazabilir miyim?#

Yazmamalısınız. MX kaydı bir sunucu adı bekler, IP adresi değil. IP yazıldığında birçok gönderici sunucu kaydı geçersiz sayar ve postayı teslim etmeden geri çevirir. Doğru yöntem, mail sunucusu için önce bir A kaydı oluşturmak, ardından MX kaydını o ada yöneltmektir. Aynı şekilde MX hedefinin CNAME olması da standartlara aykırıdır ve teslimat sorunlarına yol açar.

Site taşındıktan sonra e-postaları eski sunucuda ne kadar tutmalıyım?#

En az bir hafta tutmanızı öneririm. Propagasyon tamamlansa bile bazı gönderici sunucular önbellekteki eski MX kaydını daha uzun süre kullanabilir. Kutular silinirse bu postalar geri döner ve kaybolur. Bir hafta sonunda eski sunucuya son bir kez bakıp yeni gelen posta olup olmadığını kontrol edin, varsa senkronize edin, ancak ondan sonra hesapları kapatın.

İletişim formu maillerini de mail sağlayıcısı üzerinden göndermeli miyim?#

Evet, mümkünse öyle yapın. Site kaynaklı postalar web sunucusunun IP'sinden çıktığında bu IP'yi ayrıca SPF kaydında yetkilendirmeniz, itibarını takip etmeniz ve DKIM imzasını ayrıca çözmeniz gerekir. Uygulamayı sağlayıcınızın SMTP sunucusundan gönderim yapacak şekilde ayarlarsanız tüm postalar aynı yetkili kaynaktan çıkar, kimlik doğrulama tutarlı olur ve spam klasörüne düşme ihtimali belirgin şekilde azalır.

Aynı alan adı için hem eski hem yeni MX kaydını bir süre birlikte tutabilir miyim?#

Tutmamanız daha doğru. İki MX kaydı birlikte durduğunda gönderici sunucular önceliğe göre birine bağlanır ve postalar iki sunucu arasında rastgele bölünür; kullanıcı postasının hangisinde olduğunu bilemez. Öncelik değerini yükseltmek de sorunu çözmez, çünkü asıl sunucu meşgulse ikincil MX devreye girer. Geçiş anında eski kayıtları silip tek bir hedef bırakın.