Email Gönderilmiyor: Sunucuda Port 25 Kontrol Rehberi

Email gönderilmeme sorunu, çoğu zaman uygulama hatasından değil SMTP (Simple Mail Transfer Protocol) trafiğinin engellenmesinden kaynaklanır. En sık görülen nokta da port 25 üzerinden giden giden (outbound) bağlantılardır. Bu rehberde, sunucuda port 25’in gerçekten açık olup olmadığını; sağlayıcı kaynaklı blokları, güvenlik duvarı (firewall) kurallarını ve servis/konfigürasyon problemlerini net şekilde ayırt etmeyi öğreneceksiniz. Ayrıca pratik test adımlarıyla “sorun sunucuda mı, ağda mı?” sorusuna hızlı cevap alacaksınız.

Port 25 neden kritik? (SMTP trafiği nereye gidiyor)

Port 25, klasik SMTP trafiğinin standart çıkış portudur. Bir e-posta istemcisi veya uygulaması e-postayı sunucuya teslim ettiğinde, süreç çoğu kurulumda şu mantıkla çalışır: - Gönderici MTA (Mail Transfer Agent) alıcıya yönlendirmek için karşı tarafın SMTP sunucusuna bağlanır. - Bu yönlendirme sırasında çoğu durumda kaynak taraf (sizin sunucunuz) port 25 üzerinden dışa bağlantı kurar. - Hedef taraf yine SMTP standartlarına uygun şekilde yanıt verir.

Güncel pratikte bazı sistemler 587 (submission) veya 465 (SMTPS) ile çalışır. Ancak “email hiç gönderilmiyor” vakalarında, en hızlı teşhis için port 25 kontrolü yapılır.

Port 25 ile karışan ama farklı olan portlar

Aşağıdaki ayrım teşhis hızını artırır: - 25: Kurumsal/klasik SMTP relay veya direkt gönderim. - 587: SMTP submission (çoğunlukla STARTTLS ile doğrulama). - 465: SMTPS (TLS ile doğrudan).

Eğer uygulamanız 587/465 kullanıyor ama yine de “port 25 kapalı” diye hata veriyorsa, bu ifade bazen alt sistem (MTA) davranışına ya da hata mesajının genellemesine bağlı olabilir. Yine de doğru teşhis için port 25 testini yapmak en net adımdır.

Hızlı teşhis: Port 25 açık mı, sunucuda mı ağda mı engelli?

Port 25 ile ilgili engeller üç ana grupta toplanır: 1. Sunucu tarafı engel: firewall (UFW, iptables, security group), listen ayarı, servis çalışmıyor. 2. Ağ/sağlayıcı engeli: hosting/VPS/dedicated sağlayıcısının outbound port 25 bloklaması. 3. DNS/kimlik doğrulama değil ama teslim sorunu: SPF/DKIM/DMARC reddi; bu durum “gönderim başarılı ama teslim edilmiyor” gibi görünür. “Gönderilmiyor” hissi oluşsa bile genelde farklı hata log’ları verir.

Port 25 testiyle doğru şablona karar vermek gerekir.

1) Dışarıdan port 25 test edin (hedef bağlantı)

Önce sunucunuzun dış ağdan port 25’e bağlantı kurabildiğini test edin. Bunun için iki yön vardır: - Sunucunuzun kendisi dışarı çıkıyor mu? (outbound) - Dışarıdan sizin sununuza port 25’e erişim var mı? (inbound)

E-posta gönderimi için asıl kritik olan outbound tarafıdır.

Sunucunuzdan test etmek için (Linux): - telnet, nc (netcat) ve openssl s_client kullanılabilir. Telnet bazı sistemlerde yüklü olmayabilir.

Örnek hedef olarak bilinen bir SMTP sunucusu kullanılabilir; burada amaç doğrulama değil, “port genel olarak açılıyor mu” kontrolüdür. Aşağıdaki komutlar pratik test içindir:

• Netcat ile bağlantı denemesi:

• nc -vz hedef-smtp-sunucusu 25

• Timeout davranışını izlemek:

• Komut “succeeded” döndürüyorsa bağlantı yolu açık demektir.
• “timed out” ya da “refused” görüyorsanız farklı katmanlarda engel olabilir.

Not: Hedef olarak gerçek bir MX kaydı seçmek en doğru sonuçtur. Alıcı alan adının MX kayıtlarını bulup ilk tercihle deneme yapmak mantıklıdır.

2) Sunucu üzerinde firewall kontrolü

Outbound engel için güvenlik duvarı kuralı kontrolü yapılmalıdır. En sık senaryolar: - UFW ile gelen/giden kısıtlanmış olabilir. - iptables/nftables kural seti port 25’i drop ediyordur.

Örnek kontrol mantığı (dağıtıma göre komutlar değişebilir): - UFW aktif mi? - Port 25 çıkışı drop ediyor mu? - Log var mı (drop log)?

Net çözüm yaklaşımı şu sıradadır: 1) Önce mevcut kuralları listeleyin. 2) “25/tcp” için özellikle out kısıtı var mı kontrol edin. 3) İzin verilmesi gereken aralıklar yanlış mı (sadece belirli IP’lere izin, geri kalanı drop) bakın.

3) MTA (Postfix/Exim) servisi çalışıyor mu ve doğru portlarda dinliyor mu?

Port 25 “dinleme” (listen) ile karışır. Gönderim için dinleme şart olmayabilir; fakat bazı kurulumlarda relay davranışı etkilenir.

Sunucuda Postfix kullanıyorsanız tipik kontroller: - Servis çalışıyor mu? - Postfix hangi arayüzlerde dinliyor? - master.cf içinde SMTP servisleri etkin mi?

Sunucuda dinleme var mı diye bakmak için: - ss -ltnp | grep :25

Burada kritik okuma: - Port 25 dinleme görmüyorsanız MTA tarafında konfigürasyon sorunu vardır. - Dinleme görüyorsanız ama dışarıdan gönderim yine de başarısızsa, bu sefer outbound blok veya DNS/teslim aşaması daha olasıdır.

Sağlayıcı blokları: VPS/VDS’de port 25 outbound neden kesilir?

Türkiye’de ve dünyada birçok sağlayıcı, spam kötüye kullanımını azaltmak için outbound port 25’i kısar veya tamamen bloklar. Bu durum özellikle: - Standart VPS/VDS paketlerinde - Yeni açılan hesaplarda - Paylaşımlı IP politikalarında - “Send limit” yaklaşımında görülebilir.

Bunu anlamanın net yolu sağlayıcıdan “outbound SMTP 25 açık mı?” bilgisini istemektir. Ancak pratik doğrulama için sunucudan dış hedefe port 25 testi yapılır.

Blok varsa nasıl ayırt edilir? (karşılaştırma)

Aşağıdaki tabloda, test sonuçlarına göre olası neden ve aksiyon yer alır:

Bu ayrım özellikle “sunucu içinde her şey doğru görünüyor ama yine de e-posta gitmiyor” vakalarında zaman kazandırır.

Port 25 yerine 587/465 ile çözüm: Her zaman doğru mu?

Bazı sağlayıcılar port 25’i kısıtlayıp 587/465 üzerinden doğrulanmış submission’a izin verir. Bu yaklaşımda uygulamalar SMTP auth (kullanıcı adı/şifre) ile teslim yapar.

Net karar için şu kontrol soruları: - E-posta gönderimini hangi portla yapıyorsunuz? (25 mi, 587 mi?) - E-posta altyapınız bir MTA üzerinden mi gidiyor, yoksa uygulama doğrudan dış SMTP’ye mi bağlanıyor? - Satın aldığınız VDS/VPS üzerinde sağlayıcı “authenticated submission allowed” diyorsa 587/465 kullanımı doğru stratejidir.

Tek seferde doğru konfigürasyon mantığı

• Eğer siz kendi MTA’nızı kullanıyorsanız (Postfix relay) ve port 25 engelli ise, 587/465 üzerinden dışa giden yol her sağlayıcıda aynı değildir.
• Eğer uygulama dış bir servisle (ör. kendi kurum MTA’nız ya da bir SMTP relay servisi) doğrulanarak gönderiyorsa, uygulamanın kullandığı portu değiştirmeniz gerekir.

Bu nedenle önce hata mesajını ve uygulama ayarını netleştirin.

Güvenlik duvarı ve servis ayarlarında “en sık yapılan 6 hata”

1) Firewall’da kural var ama yanlış zincir/zone üzerinden uygulanıyor (ör. sadece inbound chain izinli). 2) MTA sadece localhost dinliyor: 127.0.0.1:25 görünüyor, dışarı çıkış etkileniyor. 3) Postfix’te relay domainleri veya mydestination yanlış ayarlı: E-postalar doğru şekilde “dışa” çıkmıyor. 4) DNS/MX yanlış olduğu için hedefe gitmeden işlem boşa düşüyor; bu bazen “gönderim yok” hissi yaratır. 5) Log rotation (log döndürme) yapılmıyor; sorun başladığında log’lar hızlıca kayboluyor ve teşhis zorlaşıyor. 6) Provider port politikası göz ardı ediliyor: Sunucu tarafını düzeltince sorun çözülmediği için zaman kaybediliyor.

Hata log’larıyla ilerleme (en net yöntem)

Net teşhis için gönderim denemesinden hemen sonra MTA log’unu inceleyin. Örneğin Postfix’te hata türleri genellikle şu şekilde ayrılır: - Bağlantı denemesi timeout: outbound engel olasılığı artar. - Authentication/authorization hataları: 587/465 veya relay yetkileri sorun olabilir. - DNS lookup hataları: yanlış/eksik MX veya resolv ayarı.

Log’tan “hangi aşamada” durduğunu görmek, port 25 kararını tek seferde netleştirir.

Net kontrol listesi: Port 25 arızasında 10 dakikada çözüm planı

Aşağıdaki listeyi birebir uyguladığınızda, sorunun yerini büyük ölçüde belirlersiniz:

1) Gönderim yaptığınız uygulama hangi SMTP portunu kullanıyor? (25/587/465) 2) Sunucudan hedef MX’e port 25 denemesi yapın: nc -vz <mx> 25 3) Timeout mı, refused mı, başarılı mı? Sonuca göre tabloyu kullanın. 4) Sunucu firewall kural setini kontrol edin: 25/tcp out engeli var mı? 5) MTA servisi çalışıyor mu? Sistem servisini doğrulayın. 6) ss -ltnp | grep :25 ile dinleme var mı bakın. 7) Postfix/Exim konfigürasyonunda relay ve domain ayarlarını doğrulayın. 8) DNS tarafında MX, A kayıt ve ters DNS (PTR) tutarlılığını kontrol edin. 9) Log’larda hata satırını bulun: bağlantı mı kimlik mi DNS mi? 10) Sağlayıcı ile görüşün: “Outbound port 25 blocked mi?” sorusunu net sorun açıklamasıyla iletin.

Sonuç: E-posta göndermiyorsanız önce port 25’i değil, “nerede kırıldığını” bulun

Aksiyon planı şu şekilde olsun: İlk 10 dakikada sunucudan MX hedefe port 25 testi yapın; sonuç timeout/refused/success ayrımını netleştirsin. Aynı anda firewall ve MTA dinleme durumunu doğrulayın. Sağlayıcı tarafı blok çıkarsa, çözüm ya port 25 outbound’un açılması (policy değişimi) ya da 587/465 üzerinden doğrulanmış submission mimarisine geçiş olmalıdır. Bu adımların sonunda, sorunu “sunucu mu, ağ mı?” olarak ayrıştırıp doğru aksiyonla ilerleyin—konfigürasyon değişikliklerini boşa döndürmeyin.