Mail Sunucusu Sorun Giderme Akış Şeması

"Mailler gitmiyor" cümlesi, bir sistem yöneticisinin alabileceği en az bilgi taşıyan bildirimlerden biridir. Bu tek cümlenin arkasında DNS hatası da olabilir, dolu bir kutu da, kara listeye girmiş bir IP de. Mail sunucusu sorun giderme işini uzatan şey teknik zorluk değil, sırasız arama: insanlar genellikle en son duydukları şeyden başlar, SPF kaydını kurcalar, servisi yeniden başlatır ve bu arada sorunun gerçek izlerini siler.

Bu rehberde her mail sorununa uygulanabilen sıralı bir teşhis akışı kuracağım. Belirtiyi doğru tanımlamakla başlayıp DNS, ağ bağlantısı, kimlik doğrulama, kuyruk, log ve kutuya teslim katmanlarını tek tek eleyeceğiz. Her katman için çalıştıracağın komutları, çıktının nasıl okunacağını ve o katmanda sorun yoksa bir sonrakine nasıl geçeceğini yazdım. Sonunda SMTP yanıt kodları sözlüğü ve teşhisi baltalayan klasik hatalar var.

Adım 0: Belirtiyi Daraltmadan Hiçbir Şey Yapma#

Teşhisin en değerli adımı, ilk beş dakikada sorulacak dört sorudur. Bu sorular olası sebeplerin çoğunu daha ilk turda eler:

1. Yön: Sorun giden mesajlarda mı, gelen mesajlarda mı, yoksa ikisinde de mi?
2. Kapsam: Tek kullanıcıyı mı, tek alan adını mı, yoksa herkesi mi etkiliyor?
3. Hedef: Yalnızca belirli bir sağlayıcıya mı (Gmail, Outlook) yoksa her yere mi?
4. Davranış: Mesaj hata mı dönüyor, gecikiyor mu, yoksa sessizce kayboluyor mu?

Bu tabloyla başlamak, "SPF kaydımı mı bozdum acaba" turuna girmeden önce sorunu doğru koridora sokar. Belirti "gelen mail yok" ise DNS'ten, "giden mail yok" ise kuyruktan başla.

Katman 1: DNS Kayıtlarını Doğrula#

Gelen posta sorunlarının önemli bölümü DNS'te biter. Kontrolü tek bir komut dizisiyle yap ve dönen değerleri beklediğinle karşılaştır:

# Posta hangi sunucuya teslim edilecek?
dig +short MX firmaniz.com
# Beklenen: 10 mail.firmaniz.com.

# O isim bir IP'ye çözülüyor mu?
dig +short A mail.firmaniz.com
# Beklenen: 185.12.34.56

# Ters DNS (PTR) kaydı var mı ve isimle eşleşiyor mu?
dig -x 185.12.34.56 +short
# Beklenen: mail.firmaniz.com.

# Kimlik doğrulama kayıtları
dig +short TXT firmaniz.com | grep spf1
dig +short TXT varsayilan._domainkey.firmaniz.com
dig +short TXT _dmarc.firmaniz.com

Dört klasik DNS hatası: MX kaydının hiç olmaması, MX kaydının bir IP adresine işaret etmesi (MX bir isme işaret etmelidir), PTR kaydının eksik ya da uyumsuz olması ve alan adında birden fazla SPF TXT kaydı bulunması. Sonuncusu özellikle sinsidir; iki SPF kaydı olan bir alan adında SPF kontrolü tamamen geçersiz sayılır.

MX tarafındaki tipik senaryoları e-postalarım gelmiyor: MX sorunu yazısında ayrıntılı ele aldım. DNS katmanında sorun görmüyorsan bir sonraki katmana geç; burada zaman kaybetme.

Katman 2: Bağlantı ve TLS#

DNS doğruysa sıradaki soru şu: ilgili portlar gerçekten açık ve TLS düzgün çalışıyor mu? Önce hangi portun ne işe yaradığını netleştirelim, çünkü yanlış porta bakmak çok yaygın:

Kullanıcı istemcileri asla 25. porta bağlanmamalıdır; o port sunucular arası teslimat içindir ve birçok internet sağlayıcısı ev bağlantılarında bunu engeller. Bir kullanıcı "gönderemiyorum" diyorsa ilk kontrol edilecek şey portun 587 ya da 465 olduğudur.

# Dışarıdan 25. port erişilebilir mi (gelen posta için kritik)
openssl s_client -starttls smtp -connect mail.firmaniz.com:25 -crlf

# Kullanıcı gönderim portu
openssl s_client -starttls smtp -connect mail.firmaniz.com:587 -crlf

# IMAP doğrudan TLS
openssl s_client -connect mail.firmaniz.com:993 -crlf

# Sertifikanın hangi isimler için geçerli olduğunu gör
openssl s_client -connect mail.firmaniz.com:993 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Bağlantı hiç kurulmuyorsa güvenlik duvarına ve servisin gerçekten dinlediğine bak. Sertifika uyarısı alıyorsan sertifikanın subjectAltName listesinde istemcinin bağlandığı ismin bulunduğunu doğrula; en sık görülen hata, sertifikanın yalnızca ana alan adını kapsayıp mail. alt alan adını kapsamamasıdır. Port ve TLS uyumunu tek ekranda görmek için SMTP test aracımızı da kullanabilirsin.

# Servis gerçekten dinliyor mu
ss -lntp | grep -E ':(25|587|465|993|143)\b'

Katman 3: Kimlik Doğrulama ve Yetkilendirme#

Bağlantı kuruluyor ama kullanıcı gönderemiyorsa sorun kimlik doğrulamadadır. Burada iki ayrı mekanizma var ve karıştırılmaları yaygın: Dovecot kullanıcının parolasını doğrular, Postfix ise doğrulanmış kullanıcıya aktarım (relay) izni verir.

# Dovecot kullanıcıyı ve parolasını kabul ediyor mu
doveadm auth test [email protected]

# Kullanıcı veritabanında görünüyor mu
doveadm user [email protected]

# Postfix'in SASL yapılandırmasını gör
postconf -n | grep -E 'sasl|relay'

doveadm auth test başarılıysa ama gönderim yine reddediliyorsa, Postfix'in smtpd_sasl_auth_enable ayarına ve smtpd_recipient_restrictions sırasına bak. permit_sasl_authenticated satırının reject_unauth_destination satırından önce gelmesi gerekir; sıra tersse doğrulanmış kullanıcı bile dışarıya gönderemez.

Relay access denied hatası da tam olarak bu katmanın belirtisidir ve iki farklı anlama gelir: giden mesajda kullanıcı doğrulanmamış demektir, gelen mesajda ise alıcı alan adı sunucunun kabul ettiği alan adları arasında değil demektir.

Katman 4: Kuyruk Gerçeği Söyler#

Kimlik doğrulama sorunu yoksa mesaj kuyruğa girmiştir ve kuyruk sana tam olarak ne olduğunu söyler. Bu katman, teşhisin en bilgi verici yeridir.

# Kuyruktaki mesaj sayısı
postqueue -p | tail -1

# Ertelenen mesajların hedef ve yaş dağılımı
qshape deferred | head -15

# Belirli bir mesajın içeriği ve son hata satırı
postcat -q A1B2C3D4E5

# Kuyruğu hedefe göre özetle
postqueue -j | grep -o '"recipients".*' | head

qshape deferred çıktısında tek bir hedefin altında birikme görüyorsan sorun o sağlayıcıya özeldir — hız sınırı, itibar ya da o taraftaki geçici arıza. Birikme her hedefe yayılmışsa sorun sende: DNS çözümlemesi, giden bağlantı ya da disk.

Kuyruk boşsa ve mesaj hiç görünmüyorsa, mesaj kuyruğa hiç girmemiştir; bu durumda geri Katman 3'e dönersin. Kuyrukta duruyor ve status=deferred yazıyorsa, satırın sonundaki parantez içi metin sana alıcı sunucunun ne dediğini kelimesi kelimesine söyler.

Katman 5: Logları Kuyruk Kimliğiyle Okumak#

Mail logları satır satır okunmaz; kuyruk kimliği üzerinden okunur. Postfix bir mesajı kabul ettiğinde ona bir kimlik atar ve o mesajla ilgili her satır bu kimliği taşır. Teşhis, kimliği bulup tüm satırları bir araya getirmekle başlar.

# Gönderen adresinden kuyruk kimliğini bul
grep 'from=<[email protected]>' /var/log/mail.log | tail -5

# Kimliği bulduktan sonra o mesajın tüm hikâyesini oku
grep 'A1B2C3D4E5' /var/log/mail.log

# Canlı izleme (test mesajı gönderirken açık tut)
tail -f /var/log/mail.log | grep -i '[email protected]'

# systemd günlüğünden son on dakika
journalctl -u postfix --since "10 min ago" --no-pager

Tek bir mesaj için tipik bir hikâye şöyle görünür:

postfix/smtpd[1234]: A1B2C3D4E5: client=mail.ornek.com[203.0.113.10]
postfix/cleanup[1235]: A1B2C3D4E5: message-id=<[email protected]>
postfix/qmgr[1236]: A1B2C3D4E5: from=<[email protected]>, size=4210, nrcpt=1
postfix/lmtp[1237]: A1B2C3D4E5: to=<[email protected]>, relay=127.0.0.1[...],
    delay=0.42, status=sent (250 2.0.0 Saved)
postfix/qmgr[1236]: A1B2C3D4E5: removed

Son status= değeri kararı verir: sent teslim edildi, deferred ertelendi ve tekrar denenecek, bounced kalıcı olarak reddedildi. Bu üç kelimeyi gördüğün an sorunun hangi tarafta olduğunu bilirsin. Gmail'e özgü teslimat sorunlarında status= satırındaki parantez içi metni Gmail'e mail gitmiyor yazısındaki tanı adımlarıyla birlikte değerlendir.

Katman 6: Kutuya Teslim ve Kota#

Log status=sent diyorsa mesaj sunucuya teslim edilmiştir; kullanıcı hâlâ göremiyorsa sorun kutunun kendisindedir. Burada üç ihtimal var: mesaj başka bir klasöre düşmüştür, kota dolmuştur ya da bir sieve filtresi mesajı silmiştir.

# Kotayı kontrol et
doveadm quota get -u [email protected]

# Klasördeki mesaj sayısı
doveadm mailbox status -u [email protected] messages INBOX Junk

# Son bir gün içindeki mesajları tüm klasörlerde ara
doveadm search -u [email protected] mailbox-guid all since 1d

# Sieve filtre günlüğü (etkinse)
tail -20 /var/mail/vhosts/firmaniz.com/ali/.dovecot.sieve.log

Kotanın dolu olması, uzaktan bakıldığında "mail gelmiyor" gibi görünen ama tamamen yerel olan klasik bir sorundur; gönderene 452 4.2.2 döner ve mesaj bir süre kuyrukta bekledikten sonra kaybolur. Kullanıcının kendi kurduğu bir filtre de aynı etkiyi yaratabilir — özellikle "belirli bir gönderenden geleni sil" kuralları.

SMTP Yanıt Kodları Sözlüğü#

Sorun giderirken karşılaşacağın kodların çoğu birkaç aileye ayrılır. 4xx geçici, 5xx kalıcıdır ve bu ayrım yapacağın işi tamamen değiştirir.

4xx gördüğünde acele etme; mesaj kaybolmaz, kuyruk tekrar dener. 5xx gördüğünde ise kuyruk bir daha denemez, dolayısıyla müdahale etmen gerekir.

Teşhisi Baltalayan Klasik Hatalar#

Kanıtı silmek. İlk refleks olarak servisi yeniden başlatmak, kuyruğu boşaltmak ya da logları döndürmek, sorunun tek kaydını yok eder. Önce postqueue -p çıktısını ve ilgili log satırlarını bir dosyaya al, sonra müdahale et.

Kuyruk kimliği olmadan log okumak. Yoğun bir sunucuda logu düz okumak işe yaramaz; farklı mesajların satırları iç içe geçer. Her zaman önce kimliği bul, sonra o kimliğe göre filtrele.

Yanlış katmandan başlamak. "Mail gitmiyor" duyunca doğrudan SPF kaydını kurcalamak en yaygın zaman kaybıdır. Belirtiyi daraltmadan hiçbir kayda dokunma.

postqueue -f ile kuyruğu zorlamak. Hız sınırı yüzünden biriken bir kuyruğu zorlamak, karşı tarafın korumasını daha sert tetikler ve durumu kötüleştirir.

Kullanıcının söylediğine dayanmak. "Hiç mail almıyorum" diyen kullanıcının kotası dolu olabilir, mesajlar Junk klasöründe olabilir ya da istemcisi başka bir hesaba bakıyor olabilir. Sunucu tarafında doveadm ile doğrula.

Tek testle karar vermek. Tek bir sağlayıcıya gönderilen tek bir test mesajı yeterli veri değildir. En az iki farklı sağlayıcıya ve bir de kendi kontrolündeki bir adrese test et; sonuçlar farklıysa sorun hedefe özeldir.

Sıkça Sorulan Sorular#

Mail loglarını nerede bulurum#

Çoğu Debian ve Ubuntu kurulumunda /var/log/mail.log, RHEL tabanlı sistemlerde /var/log/maillog dosyasındadır. Yalnızca systemd günlüğü kullanan sistemlerde journalctl -u postfix ve journalctl -u dovecot komutlarıyla erişirsin. Log dosyasının nerede olduğundan emin değilsen postconf maillog_file çıktısına bakabilir ya da bir test mesajı gönderirken journalctl -f ile canlı izleyebilirsin.

Mesajın kuyrukta olup olmadığını nasıl kontrol ederim#

postqueue -p komutu kuyruktaki tüm mesajları kuyruk kimliği, boyut, gönderen, alıcı ve son hata mesajıyla birlikte listeler. Kuyruk büyükse qshape deferred ile hedef bazında özet almak daha okunaklıdır. Belirli bir mesajı arıyorsan postqueue -p | grep [email protected] yeterlidir; çıktı boşsa mesaj ya teslim edilmiş ya da kuyruğa hiç girmemiştir.

Mesajlar neden bazen saatlerce gecikiyor#

En yaygın sebepler greylisting, alıcı tarafın hız sınırı ve kuyruktaki yeniden deneme aralıklarıdır. Greylisting uygulayan bir sunucu ilk denemeyi kasten reddeder ve mesaj Postfix'in bir sonraki kuyruk turunda tekrar gönderilir; bu tek başına on beş dakikadan uzun bir gecikme yaratabilir. postcat -q ile mesajın son hata satırını okursan gecikmenin sebebini doğrudan görürsün.

Sunucumun kara listede olup olmadığını nasıl anlarım#

En net işaret, bounce mesajlarının içeriğidir; kara liste kaynaklı retler genellikle 550 5.7.1 koduyla birlikte listenin adını ve bir sorgulama adresini de yazar. Loglarda blocked using ya da listed by gibi ifadeler ararsan bunları hızla bulursun. Kara listeye girmenin en sık sebebi ele geçirilmiş bir hesaptan yapılan toplu gönderimdir, o yüzden delisting talebinden önce mutlaka kaynağı bul.

Bir mesajı kuyruktan nasıl silerim#

Tek bir mesaj için postsuper -d A1B2C3D4E5, tüm ertelenmiş kuyruk için postsuper -d ALL deferred komutunu kullanırsın. Silmeden önce postcat -q ile mesajın ne olduğuna baktığından emin ol; kuyruktan silinen bir mesaj geri getirilemez ve gönderen bundan haberdar olmaz. Toplu silmeyi yalnızca kaynağı belli bir spam patlamasında yap.

Test mesajını nereden göndermeliyim#

Kendi sunucundan kendi kutuna göndermek en az bilgi veren testtir, çünkü mesaj dış dünyaya hiç çıkmaz. Anlamlı bir test için en az iki farklı harici sağlayıcıya gönder ve gelen mesajın tam başlıklarını incele; Authentication-Results satırı SPF, DKIM ve DMARC sonuçlarını tek bakışta verir. Gelen yönü test etmek içinse harici bir hesaptan kendi alan adına yaz ve aynı anda tail -f ile logu izle.

Kapanış#

İyi bir teşhis, doğru komutu bilmekten çok doğru sırayı izlemekten ibarettir. Aklında kalması gereken dört alışkanlık şu: önce belirtiyi yön, kapsam, hedef ve davranış olarak daralt; katmanları sırayla ele ve bir katmanda sorun yoksa orada oyalanma; logu her zaman kuyruk kimliği üzerinden oku; ve 4xx ile 5xx ayrımını kararının merkezine koy — biri beklemeyi, diğeri müdahaleyi gerektirir. Müdahale etmeden önce kanıtı kaydetmeyi de alışkanlık hâline getir.

Bu akışı her seferinde kendin yürütmek istemiyorsan, sunucu yönetimi hizmetimiz mail katmanının izlenmesini ve arıza müdahalesini üstlenir. Kendi sunucunu kurup baştan doğru yapılandırılmış bir temelle başlamak istersen SMTP sunucu paketlerimiz Postfix, Dovecot ve rDNS kaydı tanımlı teslim edilir; posta altyapısını hiç işletmek istemiyorsan kurumsal e-posta çözümlerimiz bu sorumluluğu tamamen devralır.