E-postalarım Gelmiyor: MX Kaydı Kontrol Rehberi

Siteniz sorunsuz açılıyor, panelinize giriyorsunuz, her şey yolunda görünüyor. Ama "e-postalarım gelmiyor" diyorsunuz: müşteriler mail attıklarını söylüyor, siz hiçbir şey görmüyorsunuz. Belki de tam tersi — siz gönderebiliyorsunuz ama gelen kutunuz sessiz. Bu tabloda sorun neredeyse hiçbir zaman "mail sunucusu bozuk" değildir. Site açılıyor mail gelmiyor şikâyetinin arkasında, on vakanın dokuzunda ya MX kaydı ya da mail sunucusunun kendi yönlendirme ayarı vardır. Çünkü site ve e-posta aynı alan adını paylaşsa bile tamamen farklı iki DNS kaydına bakar: site A kaydına, e-posta MX kaydına. Birini değiştirip diğerini unutmak, yıllardır gördüğüm en yaygın hatadır.

Bu yazıda kurumsal mail çalışmıyor durumunu tahminle değil, ölçerek çözeceğiz. Önce gelen ve giden posta sorununu birbirinden ayıracağız — bu ayrımı yapmadan atılan her adım boşa gider. Sonra MX kaydının dünyaya gerçekte ne döndürdüğünü dig ve nslookup ile göreceğiz; DNS panelinde doğru görünen bir kaydın neden dışarıdan farklı okunduğunu anlayacağız. Ardından Türkçe kaynakların hiç değinmediği asıl tuzağa geleceğiz: MX kaydınız kusursuz olsa bile sunucunun kendi "local mail exchanger" ayarı postayı kendine alıp orada gömebilir. Eski ve yeni MX'in aynı anda tanımlı kalması, SPF hatasının gelen postayı değil gideni etkilemesi ve catch-all ile spam filtresinin nasıl karıştırıldığı da yazının içinde. Sonunda elinizde, kimin hatalı olduğunu 10 dakikada söyleyen bir teşhis akışı olacak.

Önce Şunu Ayırın: Gelen Posta mı, Giden Posta mı Sorunlu#

Teşhise başlamadan önce cevaplamanız gereken tek soru şudur: posta size ulaşmıyor mu, yoksa siz gönderdiğinizde karşı tarafa ulaşmıyor mu? Bu iki durum tamamen farklı kayıtlara bakar ve birbirine karıştırıldığında saatler kaybedilir.

Sağdaki sütunun ilk satırı bu yazının konusu. Eğer sizin sorununuz ikinci satırsa, yani gönderdikleriniz geri dönüyorsa, MX kaydını kurcalamak hiçbir işe yaramaz — o durumda gmaile mail gitmiyor yazısındaki gönderen tarafı kontrollerine geçin. Bu yazı boyunca "gelen posta" sorununu çözüyoruz.

Hızlı bir ayrım testi: kendinize dışarıdan bir adresle (kişisel Gmail hesabınız, telefonunuzun operatör maili, bir arkadaşınızın adresi) mail atın. Ulaşmıyorsa gelen posta sorunudur ve MX'ten başlarsınız. Ulaşıyor ama sadece belirli bir kurumdan gelenler ulaşmıyorsa, sorun MX'te değil filtrededir.

MX Kaydının Gerçekte Ne Döndüğünü Görün#

MX kaydını DNS panelinde görmek yeterli değildir; dünyanın ne gördüğünü sorgulamanız gerekir. Panelde doğru duran bir kayıt, bölge yayınlanmadıysa, yanlış nameserver'a bakılıyorsa veya TTL nedeniyle eski değer önbellekteyse dışarıya farklı görünür.

Linux veya macOS terminalinde:

dig MX ornekfirma.com.tr +short
dig MX ornekfirma.com.tr @8.8.8.8 +short

Windows'ta:

nslookup -type=mx ornekfirma.com.tr
nslookup -type=mx ornekfirma.com.tr 8.8.8.8

Sağlıklı bir cevap şuna benzer:

10 mail.ornekfirma.com.tr.
20 mail2.ornekfirma.com.tr.

Baştaki sayı önceliktir ve küçük olan önce denenir. Yani 10 öncelikli sunucu ayakta olduğu sürece 20 hiç kullanılmaz. Çıktıda hiçbir şey yoksa MX kaydı yok demektir; bu durumda gönderen sunucular RFC gereği alan adının A kaydına posta bırakmayı deneyebilir — ki sitenizin çalıştığı web sunucusunda mail servisi yoksa posta orada ölür ve gönderen "550 relay not permitted" benzeri bir hata alır.

Üç kontrolü mutlaka birlikte yapın:

1. Yetkili sunucudan sorgulayın. Önbelleği atlayıp doğrudan alan adının nameserver'ına sorun; kaydın gerçekten yayınlanıp yayınlanmadığını yalnızca bu gösterir.

dig NS ornekfirma.com.tr +short
dig MX ornekfirma.com.tr @ns1.saglayicinizin-ns.com +short

2. MX hedefinin A kaydı var mı bakın. MX bir hostname'e işaret eder; o hostname'in IP'si yoksa posta teslim edilemez. Bu, taşınmalarda çok sık kaçırılır.

dig A mail.ornekfirma.com.tr +short

3. MX hedefi CNAME olmamalı. mail.ornekfirma.com.tr bir CNAME ise standartlara aykırıdır ve bazı gönderen sunucular teslimi reddeder. MX hedefi doğrudan A (veya AAAA) kaydı olmalıdır.

Sorgu araçlarının ayrıntısı için dig ve nslookup ile DNS sorgulama ve kaydın teorik yapısı için MX kaydı nedir yazılarına bakabilirsiniz. Değişiklik yeni yapıldıysa, önce dünyanın ne gördüğünü DNS propagasyon kontrol araçları ile birden çok noktadan doğrulayın; tek bir bilgisayarın önbelleği sizi kolayca yanıltır.

En Sık Görülen Neden: Sunucudaki Yönlendirme Ayarı MX'i Eziyor#

MX kaydınız dışarıdan doğru görünüyorsa ve posta yine gelmiyorsa, sorun neredeyse kesinlikle sunucunun kendi mail yönlendirme ayarındadır. Bu, Türkçe rehberlerin hiç anlatmadığı ama pratikte en çok vakit kaybettiren durumdur.

Mantık şudur: cPanel/WHM tabanlı bir sunucu, üzerinde barındırdığı alan adı için gelen postayı kendisine ait sayabilir. Bu durumda o sunucudaki bir PHP scripti veya webmail'den gönderilen mesaj, MX kaydına hiç bakmadan doğrudan yerel posta kutusuna teslim edilir. Alan adının MX'i başka bir sağlayıcıya (kurumsal mail sistemine) bakıyorsa, sonuç şudur: dışarıdan gelen postalar doğru yere ulaşır, ama sitenizin kendi gönderdiği bildirimler ve o sunucudan atılan mailler görünmez bir yerel kutuya düşer. İnsanlar bunu "bazı mailler geliyor bazıları gelmiyor" diye tarif eder.

cPanel'de kontrol edilecek yer: E-posta → E-posta Yönlendirme (Email Routing). Üç seçenek vardır:

• Otomatik Algıla (Automatically Detect Configuration): sunucu MX kaydına bakıp karar verir. Çoğu durumda doğru seçimdir.
• Yerel Posta Değiştirici (Local Mail Exchanger): "bu alan adının postası bende" der ve MX kaydını görmezden gelir.
• Uzak Posta Değiştirici (Remote Mail Exchanger): "bu alan adının postası bende değil, MX'e uy" der.

Alan adınızın postası başka bir sistemdeyse bu ayar Uzak olmalıdır. Sunucuda barındırılıyorsa Yerel olmalıdır. WHM erişiminiz varsa aynı bilgi iki dosyada tutulur:

grep ornekfirma.com.tr /etc/localdomains
grep ornekfirma.com.tr /etc/remotedomains

Alan adı yanlış dosyadaysa yönlendirme ayarını panelden değiştirmek dosyaları da düzeltir. Elle düzenlemek yerine paneli kullanın; iki dosyanın tutarsız kalması daha karışık sorunlara yol açar.

Aynı mantık Plesk'te "Mail Service" ve "Mail Settings" altında, DirectAdmin'de ise alan adının MX yönetimi ekranındaki "Use this server to handle my emails" kutucuğunda karşınıza çıkar. İsimler değişir, tuzak aynıdır.

İkinci Sık Neden: Eski ve Yeni MX Aynı Anda Tanımlı#

Hosting veya mail sağlayıcısı değiştiren firmaların yarısı bu hataya düşer: yeni MX kayıtları eklenir ama eski kayıtlar silinmez. Sonuç, tesadüfe bağlı bir posta dağılımıdır.

Böyle bir bölgede dig MX çıktısı şuna benzer:

10 mail.eski-saglayici.com.
10 mx1.yeni-sistem.com.
20 mx2.yeni-sistem.com.

Buradaki felaket, ilk iki kaydın aynı önceliğe sahip olmasıdır. Standart, eşit öncelikli sunucular arasında rastgele dağıtım öngörür. Yani gelen postanın yaklaşık yarısı hâlâ eski sunucuya teslim edilir. Eski sunucu ayakta ve alan adını hâlâ "yerel" biliyorsa postayı sessizce kabul eder ve kimsenin bakmadığı bir kutuya koyar. Gönderen tarafta hiçbir hata görünmez — mesaj "iletildi" der. Kullanıcı da haklı olarak "mailler kayboluyor" der.

Doğru davranış şudur:

1. Yeni MX kayıtlarını ekleyin.
2. Eski MX kayıtlarını tamamen silin (öncelik numarasını büyütüp bırakmak yetmez; eski sunucu yedek olarak postayı yine kabul eder).
3. Eski sunucudaki alan adının yönlendirmesini "Uzak" yapın veya alan adını o sunucudan kaldırın.
4. Eski sunucudaki posta kutularını, geçiş bitmeden silmeyin — geçiş süresince oraya düşmüş mesajlar olabilir.

Bir başka sessiz katil, bölgede kalmış eski bir wildcard veya alt alan adı MX kaydıdır. dig MX mail.ornekfirma.com.tr ve dig MX *.ornekfirma.com.tr sorgularını da yapın; özellikle eski yapılandırmalardan kalma autodiscover ve mail alt alan adları beklenmedik yerlere işaret edebiliyor.

SPF Hatası Gelen Postayı Engellemez#

SPF kaydı, gelen postanızı engellemez; sizin gönderdiğiniz postanın karşı tarafta kabul edilmesini etkiler. Bu ayrım netleşmediği için sayısız kişi, gelen kutusu boş dururken saatlerce SPF kaydını düzeltmeye çalışıyor.

SPF, bir alan adı adına posta göndermeye hangi IP'lerin yetkili olduğunu ilan eder. Yani alıcı sunucu, size gelen bir mesajın gönderen alan adının SPF'ine bakar — sizin SPF'inize değil. Sizin SPF kaydınız yanlışsa etkilenen şey şudur: müşterileriniz sizin mailinizi spam'de bulur veya reddedilir.

Tabloda gördüğünüz gibi, gelen posta sorununda yalnızca ilk iki satır işinize yarar. Yine de bu kayıtları ihmal etmeyin: taşıma sırasında MX'i taşıyıp SPF'i unutmak, birkaç gün sonra "gönderdiğim mailler gitmiyor" diye ikinci bir kriz üretir. Kayıtların ne yaptığını ve nasıl yazıldığını SPF, DKIM ve DMARC rehberinde bulabilirsiniz. Aynı şekilde, gönderen sunucunun IP'sinin ters DNS kaydı hostname ile eşleşmiyorsa PTR tarafına da bakmanız gerekir; bu, kurumsal alıcıların çok sık uyguladığı bir kontroldür.

Postanın Sunucuya Ulaşıp Ulaşmadığını Log'dan Doğrulayın#

DNS doğru, yönlendirme doğru ama posta hâlâ görünmüyorsa artık tahmin etmeyi bırakıp sunucu log'una bakma zamanıdır. Log, "posta hiç gelmedi" ile "posta geldi ama bir yere gömüldü" arasındaki farkı kesin olarak söyleyen tek kaynaktır.

Exim kullanan cPanel sunucularda:

grep "[email protected]" /var/log/exim_mainlog | tail -50

Postfix kullanan sunucularda:

grep -i "[email protected]" /var/log/mail.log | tail -50

Çıktıda arayacağınız üç durum var:

• Hiçbir satır yok. Posta bu sunucuya hiç ulaşmamış demektir. Sorun DNS/MX veya yönlendirme tarafındadır; sunucuyu kurcalamayı bırakın.
• => [email protected] satırı var. Posta teslim edilmiş. O hâlde mesaj bir klasördedir: spam klasörü, bir filtre kuralının taşıdığı klasör veya farklı bir posta kutusu. IMAP yerine POP3 kullanıyorsanız başka bir cihaz mesajı indirip sunucudan silmiş de olabilir.
• ** ... Mailbox quota exceeded veya rejected satırı var. Sebep açıkça yazıyordur.

Kök erişiminiz yoksa aynı bilgiyi cPanel'in E-posta → Posta Kaydı Teslimi (Track Delivery) ekranından alabilirsiniz. Alıcı adresi yazıp aratın; her mesajın kabul mi edildiği, reddedildiği mi yoksa hiç görünmediği mi listelenir. Bu ekran, teknik ekibi olmayan bir firmanın tek başına yapabileceği en değerli teşhis adımıdır.

Sunucunun 25. portu dışarıdan gerçekten kabul edip etmediğini de sınayabilirsiniz:

telnet mail.ornekfirma.com.tr 25

220 mail.ornekfirma.com.tr ESMTP benzeri bir karşılama satırı görüyorsanız sunucu posta kabul ediyor demektir. Bağlantı hiç kurulmuyorsa güvenlik duvarı veya yanlış IP söz konusudur ve bu, sunucu IP adresi bulunamadı hatası ile aynı kökten gelen bir problem olabilir.

Catch-All, Spam Filtresi ve Kota: Kayıp Postanın Diğer Üç Sebebi#

MX doğru, log'da mesaj görünüyor ama kullanıcı hâlâ "gelmiyor" diyorsa geriye üç klasik sebep kalır.

1. Catch-all (varsayılan adres) yanlış ayarlanmış. Catch-all, alan adınıza gelen ama tanımlı bir kutuya denk gelmeyen mesajların nereye gideceğini belirler. cPanel'de E-posta → Varsayılan Adres altındadır ve üç seçeneği vardır: adrese ilet, sistemden gelen postayı at (:fail:), veya sessizce sil (:blackhole:). Yıllardır gördüğüm klasik felaket, spam'den bunalan birinin bunu :blackhole: yapmasıdır: muhasebe@ kutusu silindiğinde veya adı yanlış yazıldığında gelen tüm mesajlar sessizce, hiçbir uyarı vermeden yok edilir. Gönderen hiçbir hata görmez. Catch-all'ı ya gerçek bir kutuya iletin ya da :fail: yapın — en azından gönderen "böyle bir adres yok" uyarısı alır ve sorunu size söyler.

2. Spam filtresi mesajı ayrı klasöre taşıyor. cPanel'in Apache SpamAssassin bileşeni, eşiği aşan mesajları ya konu satırına ***SPAM*** ekleyerek geçirir ya da doğrudan spam klasörüne koyar. Webmail'den bakan kullanıcı bu klasörü görür, ama Outlook'ta yalnızca Gelen Kutusu'na abone olunmuşsa o klasör hiç görünmez. Kullanıcı için mesaj "gelmemiştir". Önce webmail'den kontrol ettirin.

3. Posta kutusu kotası dolmuş. Kota dolduğunda sunucu yeni mesajları reddeder ve gönderene "mailbox is full" bounce'ı döner. Kullanıcı bunu genelde fark etmez çünkü bounce gönderene gider. cPanel'de E-posta Hesapları listesinde her kutunun kullanım yüzdesi görünür; kırmızıya yaklaşan bir kutu varsa önce kotayı yükseltip sonra eski arşivi indirin. Kota artırımı disk alanınız elverdiği sürece anında etkilidir, bekleme gerektirmez.

Bir dördüncü ihtimali de not edelim: kullanıcının kendi kurduğu bir filtre kuralı. cPanel'de hem hesap düzeyinde hem kullanıcı düzeyinde filtre tanımlanabilir ve yıllar önce kurulmuş "şu kelimeyi içerenleri sil" kuralları kimsenin aklına gelmez. E-posta → E-posta Filtreleri altında listeyi mutlaka gözden geçirin.

Adım Adım Teşhis Akışı#

Aşağıdaki sırayı bozmadan uygularsanız sorunu ortalama 10 dakikada kesin olarak yerine oturtursunuz. Her adım, bir sonrakini gereksiz kılabilir.

1. Yönü belirleyin. Dışarıdan kendinize mail atın. Gelmiyorsa devam edin; geliyorsa sorun gelen postada değil, gönderendedir.
2. MX'i dışarıdan sorgulayın. dig MX alanadi +short. Boşsa kayıt yok, ekleyin ve 5–6. adımlara geçin.
3. MX hedefinin A kaydını doğrulayın. dig A mail.alanadi +short. IP dönmüyorsa teslim imkânsızdır.
4. Eski MX kaydı kalmış mı bakın. Birden çok sağlayıcının hostname'i görünüyorsa fazlalıkları silin.
5. Sunucudaki yönlendirmeyi kontrol edin. cPanel → E-posta Yönlendirme. Posta başka sistemdeyse "Uzak", buradaysa "Yerel" olmalı.
6. 25. portu sınayın. telnet mail.alanadi 25 karşılama satırı vermeli.
7. Log'a bakın. exim_mainlog veya Track Delivery. Mesaj görünüyorsa DNS temizdir, sorun teslim sonrasındadır.
8. Kutuyu, kotayı, spam klasörünü, filtreleri ve catch-all'ı kontrol edin.
9. Değişiklik yaptıysanız bekleyin. MX kaydının TTL'i kadar süre eski değer önbellekte kalabilir. TTL nedir yazısı bu bekleme süresini nasıl kısaltacağınızı anlatıyor.

Bu akışta 7. adıma ulaştıysanız ve mesaj log'da görünüyorsa, DNS tarafını tekrar kurcalamanın hiçbir anlamı yoktur — bunu vurguluyorum çünkü insanlar en çok burada geri dönüp MX'i tekrar tekrar değiştirerek çalışan yapıyı bozuyor.

Sıkça Sorulan Sorular#

MX kaydı değişikliği ne kadar sürede aktif olur#

MX değişikliği, eski kaydın TTL süresi kadar bekledikten sonra dünya genelinde geçerli olur; tipik TTL değerleri 300 saniye ile 24 saat arasındadır. Değişiklik yetkili nameserver'da anında görünür, ancak ara DNS çözümleyicileri eski değeri TTL süresi dolana kadar önbellekte tutar. Bu yüzden planlı bir geçişten en az 24 saat önce TTL'i 300 saniyeye düşürmek profesyonel yaklaşımdır. Geçiş tamamlandıktan sonra TTL'i tekrar normal seviyeye çıkarabilirsiniz.

Site açılıyor ama mail gelmiyorsa hosting mi bozuk#

Hayır, bu tablo neredeyse her zaman hostingin sağlıklı olduğunu gösterir. Site A kaydına, e-posta ise MX kaydına bakar; ikisi bağımsız çalışır ve biri düzgünken diğeri bozuk olabilir. Sitenin açılması, web sunucusunun ve DNS'in temel olarak çalıştığını kanıtlar. Sorunu MX kaydında, sunucunun mail yönlendirme ayarında veya posta kutusu tarafında aramanız gerekir.

MX kaydı olmayan bir alan adına mail gönderilebilir mi#

Teknik olarak gönderilebilir ancak güvenilmez. MX kaydı yoksa gönderen sunucular standarda göre alan adının A kaydına posta teslim etmeyi dener. Sitenizin çalıştığı sunucuda posta servisi yapılandırılmamışsa bu deneme başarısız olur ve gönderene bir hata döner. Bazı modern sağlayıcılar ise MX'i olmayan alan adlarına hiç teslim denemez. E-posta kullanacaksanız MX kaydı tanımlamak zorunludur.

Birden fazla MX kaydı olması sorun yaratır mı#

Farklı öncelik numaralarıyla tanımlanmış birden fazla MX kaydı sorun değil, tam tersine yedeklilik sağlar. Sorun, iki farklı sağlayıcının sunucularının aynı anda ve özellikle aynı öncelikle tanımlı kalmasıdır; bu durumda posta rastgele bölünür ve yarısı yanlış kutuya düşer. Aynı sistemin birden çok sunucusu için 10, 20, 30 gibi kademeli öncelikler kullanın. Eski sağlayıcıya ait kayıtları geçiş sonrası mutlaka silin.

Gelen mail spam klasörüne düşüyorsa MX kaydı mı hatalı#

Hayır, spam klasörüne düşme MX ile ilgili değildir. MX kaydı yalnızca postanın hangi sunucuya teslim edileceğini belirler; teslim sonrasında mesajın hangi klasöre konacağına spam filtresi karar verir. Filtre kararını mesajın içeriğine, gönderenin SPF/DKIM durumuna ve IP itibarına göre verir. Sürekli spam'e düşen bir gönderen varsa o gönderenin adresini beyaz listeye alın veya filtre eşiğini yükseltin.

Catch-all adresini kapatmak mailleri kaybettirir mi#

Catch-all'ı kapatmak mail kaybettirmez, aksine kaybı görünür hâle getirir. Kapalıyken tanımsız bir adrese gelen mesaj reddedilir ve gönderen "böyle bir adres yok" uyarısı alır; böylece yazım hatasını düzeltip tekrar gönderir. Catch-all'ı "sessizce sil" olarak ayarlamak ise en tehlikeli seçenektir, çünkü mesaj hiçbir iz bırakmadan yok olur ve gönderen bunu asla öğrenemez. Gerçekten ihtiyacınız varsa catch-all'ı izlenen bir kutuya iletin.

Nameserver değiştirdikten sonra mailler neden durdu#

Nameserver değiştiğinde alan adının DNS bölgesi tamamen yeni sağlayıcının sunucularından okunmaya başlar ve eski bölgedeki kayıtlar geçersiz olur. Yeni bölgede MX ve TXT kayıtları birebir oluşturulmadıysa e-posta anında durur, çünkü artık dünya MX kaydı olmayan bir alan adı görür. Bu yüzden nameserver değişikliğinden önce tüm kayıtların yeni bölgede hazır olması gerekir. Bu geçişi kesintisiz yapmanın yöntemi ayrı bir konudur ve planlı yapılmalıdır.

Mail sunucusunun 25. portu kapalıysa ne olur#

25. port kapalıysa dışarıdan hiçbir sunucu size posta teslim edemez ve gönderenler zaman aşımı hatası alır. Bu port, sunucular arası posta teslimi içindir ve kullanıcı gönderimi için kullanılan 587 veya 465'ten farklıdır. Güvenlik duvarında 25 numaralı portun gelen yönde açık olduğunu doğrulayın. Kullanıcıların posta gönderememesi ise ayrı bir konudur ve 587/465 portlarına bakılır.

Kapanış#

E-postalarım gelmiyor şikâyeti karmaşık görünse de aslında dar bir sorun kümesidir: MX kaydının kendisi, MX hedefinin A kaydı, sunucunun kendi yönlendirme ayarı, eski kayıtların temizlenmemiş olması ve teslim sonrası kutu/kota/filtre tarafı. Bu beş yeri sırayla ve ölçerek kontrol ettiğinizde tahmine yer kalmaz. Kritik ayrımı bir kez daha vurgulayayım: MX gelen postayı, SPF/DKIM/PTR ise giden postayı ilgilendirir. Bu iki kümeyi karıştırmadığınız sürece teşhis hızlıdır. Ve log'da mesajı gördüğünüz an DNS tarafını kapatın; ondan sonrası posta kutusu meselesidir.

Kurumsal e-posta altyapısını kendiniz yönetmek istemiyorsanız ya da mail kutularınız hosting hesabınızla aynı yerde durduğu için sürekli kota ve itibar sorunu yaşıyorsanız, e-postayı ayrı bir yapıya taşımak en kalıcı çözümdür. Kurumsal e-posta çözümleri sayfası MX ve SPF ayarları hazır gelen bir yapı sunar; yüksek hacimli bildirim ve bülten gönderimi yapıyorsanız SMTP sunucu tarafı, IP itibarını sizin kontrol ettiğiniz bir kurulum verir. Alan adı ve DNS yönetimini tek yerden toplamak isterseniz alan adı hizmetleri, sitenizle e-postanızı birlikte barındırmak isterseniz hosting paketleri sayfasındaki seçenekleri inceleyebilirsiniz.