Mail Sunucusu Neden Mail Gönderemiyor: İlk Kontrol Adımları
Sabah 9’da ofise geliyorsunuz, mail kutunuz dolu ama gönderdiğiniz mailler karşı tarafa ulaşmamış. Ya da daha kötüsü, bir müşteri arıyor ve “sizden mail gelmiyor” diyor. Mail sunucusu sorunları, sistem yöneticilerinin en çok karşılaştığı ve en çok sinir bozucu olan problemlerin başında geliyor. Neyse ki çoğu durumda sorunun kaynağını bulmak için sistematik bir yaklaşım yeterli oluyor. Bu yazıda, mail sunucunuzun neden mail gönderemediğini adım adım nasıl tespit edeceğinizi anlatacağım.
Önce Log Dosyalarına Bakın
Her şeyden önce şunu söyleyelim: mail sunucusu sorunlarında log dosyaları en iyi arkadaşınızdır. Postfix kullanıyorsanız loglar genellikle /var/log/mail.log veya /var/log/maillog dosyasında tutuluyor. Exim kullanıyorsanız /var/log/exim4/mainlog dosyasına bakmanız gerekiyor.
# Son 100 satır mail loguna bakmak için
tail -n 100 /var/log/mail.log
# Gerçek zamanlı log takibi
tail -f /var/log/mail.log
# Belirli bir hata mesajını aramak için
grep "status=bounced" /var/log/mail.log | tail -20
# Belirli bir domain için giden mailleri filtrelemek
grep "to=<.*@hedef-domain.com>" /var/log/mail.log | tail -20Log dosyalarında arayacağınız anahtar kelimeler şunlar:
- status=bounced: Mail tamamen reddedilmiş
- status=deferred: Mail geçici olarak ertelenmiş, tekrar denenecek
- Connection refused: Hedef sunucuya bağlantı kurulamıyor
- Connection timed out: Bağlantı zaman aşımına uğruyor
- Relay access denied: Relay izni yok
Bir gerçek dünya senaryosu: Geçen ay bir müşterinin sunucusunda tüm mailler “deferred” durumunda bekliyordu. Log’a baktığımda şu mesajı gördüm: connect to gmail.com[64.233.184.26]:25: Connection timed out. Bu doğrudan 25. portun ISP tarafından engellendiğine işaret ediyordu. Ama acele etmeyelim, diğer kontrolleri de yapalım.
SMTP Bağlantısını Test Edin
Log’dan bir ipucu aldıktan sonra bağlantı sorununu doğrulamamız gerekiyor. Bunun için telnet veya nc (netcat) kullanabilirsiniz.
# 25. porta telnet ile bağlantı testi
telnet smtp.hedef-domain.com 25
# Netcat ile port testi (daha hızlı)
nc -zv smtp.hedef-domain.com 25
# Eğer 25 kapalıysa 587 (submission) portu deneyin
nc -zv smtp.hedef-domain.com 587
# 465 (SMTPS) portu için
nc -zv smtp.hedef-domain.com 465
# Timeout belirleyerek test (10 saniye)
nc -zv -w 10 smtp.hedef-domain.com 25Eğer nc -zv smtp.hedef-domain.com 25 komutu Connection refused veriyorsa sorun karşı sunucu tarafında. Ama Connection timed out veriyorsa, ya sizin güvenlik duvarınız ya da ISP’niz 25. portu engelliyor demektir.
Kendi sunucunuzun 25. portunu dinleyip dinlemediğini kontrol etmek için:
# Dinlenen portları kontrol et
ss -tlnp | grep :25
netstat -tlnp | grep :25
# Postfix'in çalışıp çalışmadığını kontrol et
systemctl status postfix
# Postfix kuyruğunu kontrol et
mailq
postqueue -pmailq komutunun çıktısına dikkat edin. Eğer kuyrukta binlerce mail birikmiş ve hepsi “Connection timed out” hatası alıyorsa, bu büyük ihtimalle port engeli sorunudur.
DNS Kayıtlarını Kontrol Edin
Mail gönderiminin önündeki en yaygın engellerden biri hatalı DNS yapılandırmasıdır. Karşı sunucular sizin MX, A ve PTR kayıtlarınızı kontrol ediyor. Bunlardan biri yanlışsa mail gitmez.
# MX kayıtlarını kontrol et
dig MX kendi-domain.com
# A kaydını kontrol et
dig A mail.kendi-domain.com
# PTR (Reverse DNS) kaydını kontrol et
# IP adresinizi yazın
dig -x 203.0.113.10
# Dışarıdan DNS sorgusu yapmak için Google DNS kullanın
dig MX kendi-domain.com @8.8.8.8
# SOA kaydını kontrol et (DNS propagasyon sorunları için)
dig SOA kendi-domain.comPTR kaydı özellikle kritik. Çoğu büyük mail sağlayıcısı (Gmail, Outlook, Yahoo) PTR kaydı olmayan ya da hostname ile eşleşmeyen IP adreslerinden gelen mailleri reddediyor veya spam olarak işaretliyor.
Şöyle bir senaryo yaşadım: Yeni bir VPS aldık, mail sunucusunu kurduk, her şey doğru görünüyordu ama Gmail mailleri reddediyordu. PTR kaydını kontrol ettiğimizde VPS sağlayıcısının varsayılan PTR kaydının static.203.0.113.10.example-vps.com gibi jenerik bir şey olduğunu gördük. Bunu mail.musteri-domain.com olarak güncelleyip VPS sağlayıcısının kontrol panelinden PTR kaydı tanımladıktan sonra problem çözüldü.
SPF, DKIM ve DMARC Kontrolü
Günümüzde SPF, DKIM ve DMARC olmadan ciddi bir mail sunucusu çalıştıramazsınız. Bu kayıtlar olmadan veya yanlış yapılandırıldığında, mailleriniz karşı tarafta spam klasörüne düşüyor ya da direkt reddediliyor.
# SPF kaydını kontrol et
dig TXT kendi-domain.com | grep spf
# DKIM kaydını kontrol et (selector adını doğru yazın, örn: default, mail, google)
dig TXT default._domainkey.kendi-domain.com
# DMARC kaydını kontrol et
dig TXT _dmarc.kendi-domain.com
# Dışarıdan test için nslookup kullanımı
nslookup -type=TXT kendi-domain.comSPF kaydının düzgün göründüğünü ama yine de sorun yaşadığınızı varsayalım. Bu durumda Postfix’in gerçekten o IP adresinden mi gönderdiğini kontrol edin:
# Sunucunun dışarıya çıkan IP adresini kontrol et
curl ifconfig.me
curl ipinfo.io/ip
# Birden fazla IP varsa Postfix'in hangisini kullandığını kontrol et
postconf inet_interfaces
postconf mynetworksDKIM imzalamanın çalışıp çalışmadığını test etmek için kendinize test maili gönderin ve mail başlıklarını inceleyin. Gmail’de “Orijinali Göster” seçeneğiyle tam header’ları görebilirsiniz. dkim=pass yazıyorsa DKIM çalışıyor demektir.
Güvenlik Duvarı ve Port Kontrolü
Sunucu içinden dışarıya bağlantı kurulabiliyor mu? Bunu test etmek için:
# Kendi sunucunuzdan dışarıya 25. port bağlantısı testi
telnet smtp.gmail.com 25
# UFW kullanıyorsanız kural listesini kontrol et
ufw status verbose
# iptables kurallarını kontrol et
iptables -L -n -v | grep 25
# Giden trafik kurallarına özellikle bak
iptables -L OUTPUT -n -v
# firewalld kullanıyorsanız
firewall-cmd --list-allBazı cloud sağlayıcıları (AWS, GCP, Azure, DigitalOcean) varsayılan olarak 25. portu kapalı tutuyor. Bu durumda ya sağlayıcıya başvurup portu açtırmanız ya da 587 portunu kullanacak şekilde yapılandırmanız gerekiyor.
AWS’de çok yaşanan bir senaryo: EC2 instance’ınızda her şey doğru kurulu ama dışarıya mail gitmiyor. Sorun Security Group’ta değil, AWS’nin 25. portu varsayılan olarak engellemesinde. AWS Support’a ticket açıp “email sending” talebinde bulunmanız gerekiyor. Bu süreç bazen 24-48 saat sürebiliyor.
Postfix Konfigürasyonunu Doğrulayın
Bağlantı ve DNS sorunları yoksa Postfix konfigürasyonuna bakmak gerekiyor.
# Postfix konfigürasyonunu test et (syntax hatalarını gösterir)
postfix check
# Tüm konfigürasyonu listele
postconf -n
# Önemli parametreleri tek tek kontrol et
postconf myhostname
postconf mydomain
postconf myorigin
postconf relayhost
postconf smtp_tls_security_level
# Postfix'i yeniden yükle (servis restart etmeden)
postfix reload
# Postfix servisini yeniden başlat
systemctl restart postfixpostconf -n komutu yalnızca varsayılandan farklı olan ayarları gösteriyor, bu yüzden sorun giderme için idealdir. Özellikle şu parametrelere dikkat edin:
- myhostname: Tam nitelikli domain adı (FQDN) olmalı, PTR kaydınızla eşleşmeli
- mydomain: Alan adınız
- myorigin: Gönderici adresindeki domain
- relayhost: Eğer başka bir SMTP sunucusu üzerinden gönderiyorsanız burası dolu olmalı
- smtp_tls_security_level: TLS ayarı,
mayveyaencryptolmalı
Gerçek bir hata: Bir sunucuda myhostname = localhost.localdomain olarak kalmış. Gmail ve Outlook bu hostname’den gelen bağlantıları direkt reddediyordu. main.cf dosyasında myhostname = mail.gercek-domain.com olarak düzeltip postfix reload yaptıktan sonra sorun çözüldü.
Test Maili Gönderin ve İzleyin
Konfigürasyon düzeltmeleri yaptıktan sonra test maili göndererek logları gerçek zamanlı izlemek gerekiyor.
# Komut satırından test maili gönder
echo "Test maili - $(date)" | mail -s "Test" [email protected]
# Sendmail komutuyla test
sendmail -v [email protected] << EOF
Subject: Test Maili
From: [email protected]
Bu bir test mailidir.
EOF
# Postfix'in kendi kuyruğuna test
postfix sendmail -v [email protected] <<EOF
Subject: Test
Test
EOF
# Aynı anda log'u izle
tail -f /var/log/mail.logMail gönderdikten sonra log’da şu satırı aramak istiyorsunuz:
postfix/smtp[12345]: ABC123: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[64.233.184.26]:25, delay=1.2, delays=0.1/0/0.5/0.6, dsn=2.0.0, status=sent (250 2.0.0 OK)status=sent ve dsn=2.0.0 görüyorsanız mail başarıyla gönderilmiş demektir.
Kuyruktaki Mailleri Yönetin
Mail sunucusunda sorun varken biriken kuyruktaki mailleri yönetmek de önemli.
# Kuyruk durumunu göster
mailq
postqueue -p
# Kuyruktaki tüm mailleri hemen göndermeyi dene
postqueue -f
# Belirli bir mail ID'sini kuyruğa tekrar al
postsuper -r MAIL_ID
# Tüm kuyruğu tekrar dene
postsuper -r ALL
# Belirli bir maili kuyruktan sil
postsuper -d MAIL_ID
# Tüm kuyruğu temizle (dikkatli kullanın!)
postsuper -d ALL
# Hata alan mailleri listele
mailq | grep "^[A-F0-9]" | awk '{print $1}' | while read id; do postcat -q $id | grep "^To:"; doneKuyruğu incelerken hangi adreslerin sorun çıkardığına bakın. Eğer belirli bir domain’e giden mailler hep hata alıyorsa, o domain’in mail sunucusunda bir sorun olabilir veya sizin IP’niz o domain tarafından engellenmiş olabilir.
IP Kara Liste Kontrolü
Gönderen IP adresiniz bir kara listeye (blacklist/RBL) girmiş olabilir. Bu çok yaygın bir durum, özellikle yeni sunucularda veya daha önce başka biri tarafından kullanılmış IP adreslerinde.
# MXToolbox gibi araçlar için curl kullanımı
# IP'nizi değiştirin: 203.0.113.10
host 10.113.0.203.zen.spamhaus.org
# Spamhaus kontrolü
host 10.113.0.203.bl.spamcop.net
# Barracuda kontrolü
host 10.113.0.203.b.barracudacentral.orgIP’niz kara listedeyse aldığınız yanıt genellikle 127.0.0.x formatında bir IP olacak. NXDOMAIN yanıtı alıyorsanız listede değilsiniz demektir.
Kara liste kontrolü için pratik yol: [mxtoolbox.com/blacklists.aspx](https://mxtoolbox.com/blacklists.aspx) adresine IP’nizi girin, 100’den fazla kara listeyi aynı anda kontrol eder. Listede bulunuyorsanız, ilgili kara liste sağlayıcısının sitesinden “delisting” talebinde bulunabilirsiniz. Spamhaus için bu süreç genellikle 24-48 saat sürüyor.
TLS ve Sertifika Sorunları
Günümüzde TLS şifrelemesi neredeyse zorunlu. TLS sorunları da mail gönderimine engel olabilir.
# SMTP TLS bağlantısını test et
openssl s_client -connect smtp.hedef-domain.com:587 -starttls smtp
# SSL/TLS doğrudan bağlantı testi
openssl s_client -connect smtp.hedef-domain.com:465
# Sertifika geçerliliğini kontrol et
openssl s_client -connect mail.kendi-domain.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -dates
# Postfix TLS log seviyesini geçici olarak artır
postconf -e "smtp_tls_loglevel=2"
postfix reload
tail -f /var/log/mail.log
# Test sonrası eski haline döndür
postconf -e "smtp_tls_loglevel=0"
postfix reloadSertifika süresi dolmuş veya hostname eşleşmiyorsa smtp_tls_security_level = verify veya secure kullanıyorsanız bağlantı reddedilecektir. Bu durumda ya sertifikayı yenileyin ya da güvenlik seviyesini may olarak düşürün (ama bu güvenlik açısından ideal değil).
Let’s Encrypt sertifikası kullanıyorsanız ve otomatik yenileme çalışıyorsa sorun olmaz, ama bazen certbot hook’ları düzgün çalışmaz ve Postfix eski sertifikayla çalışmaya devam eder:
# Certbot ile sertifika yenileme
certbot renew --dry-run
# Yenileme sonrası Postfix'i yeniden başlat
systemctl restart postfix
# Certbot deploy hook kontrolü
ls /etc/letsencrypt/renewal-hooks/deploy/Hızlı Tanı Özeti
Bir sorunla karşılaştığınızda şu sırayı takip edin:
- Log dosyalarına bakın:
/var/log/mail.logveya/var/log/maillogilk durağınız olsun - Hata mesajını not alın: “Connection refused”, “timed out”, “relay denied” gibi mesajlar sonraki adımı belirliyor
- Port erişimini test edin:
nc -zv hedef:25ile bağlantı kontrolü yapın - DNS kayıtlarını doğrulayın: PTR, MX, SPF, DKIM, DMARC kayıtlarının doğruluğunu kontrol edin
- IP kara liste sorgulaması yapın: MXToolbox ile hızlı kontrol
- Güvenlik duvarı kurallarını gözden geçirin: Hem gelen hem giden 25, 587, 465 portları
- Postfix konfigürasyonunu doğrulayın:
postfix checkvepostconf -nile syntax ve ayar kontrolü - TLS sertifikalarını kontrol edin: Süre dolmamış ve hostname eşleşiyor mu
- Test maili gönderin: Gerçek zamanlı log izleyerek sonucu gözlemleyin
Sonuç
Mail sunucusu sorunları ilk bakışta karmaşık görünse de sistematik bir yaklaşımla genellikle birkaç dakika içinde kaynağa ulaşabiliyorsunuz. Sorunların büyük çoğunluğu log’larda açıkça görünüyor: ya bir port engellenmiş, ya DNS kaydı eksik ya da IP kara listeye girmiş. Paniklemeden önce tail -f /var/log/mail.log açın, test maili gönderin ve mesajı okuyun. Mail sunucuları size genellikle ne olduğunu söylüyor, dinlemek gerekiyor.
Bir de şunu ekleyeyim: Bu kontrolleri sorun çıktığında değil, düzenli olarak yapın. Ayda bir kez IP kara liste kontrolü, sertifika süre takibi ve test maili göndermek, büyük sorunları küçükken yakalamak için yeterli. Prometheus ve Alertmanager kullanıyorsanız blacklist monitoring için hazır exporterlar da mevcut, ama bu başka bir yazının konusu.