E-posta Gönderilmiyor: Sunucuda Port 25 Kontrol Rehberi

E-posta gönderimi kesildiğinde genellikle “sunucu çöktü” sanılır; oysa en sık neden, SMTP trafiğinin (özellikle port 25) dış dünyaya doğru şekilde açılmaması veya sağlayıcı/filtre düzeyinde engellenmesidir. Bu rehberde, NetKıyas’ta karşılaştırma yaparken de işe yarayan şekilde, port 25 kontrolünden başlayıp mail sunucusu ayarlarına kadar ilerleyeceksiniz. Her adımda neyin test edileceğini ve hangi sonuca göre bir sonraki adıma geçeceğinizi net biçimde göreceksiniz.

Aşağıdaki akış, VDS/VPS/dedicated sunucularda kurulu kendi mail altyapısı veya yönetilen bir MTA (Mail Transfer Agent) kullanan senaryolar için hazırlanmıştır. (Gmail/Outlook gibi sağlayıcıların “spam/engelleme” davranışları bu yazının kapsamı dışında; burada hedef SMTP teslim sürecini başlatan ilk kapıyı açmak.)

Önce netleştirin: Sizde hangi e-posta senaryosu var?

Sorun giderme doğru ilerlemek için önce “gönderici” ve “alıcısı” rolünü ayırın.

1) Gönderme (outbound SMTP) mi, yoksa alma (inbound) mı?

• Gönderim çalışmıyorsa: Gönderici tarafın SMTP bağlantısı (çoğunlukla port 25 veya alternatif portlar) karşı sunucuya ulaşamıyor olabilir.
• Alım çalışmıyorsa: Dışarıdan IMAP/POP3/SMTP (genelde 25) trafiği sununuza ulaşmıyor olabilir.

Bu yazı “gönderim” odaklıdır: kullanıcı sizden e-posta gönderebiliyor ama gönderim kuyruğa düşüyor veya gönderim raporunda zaman aşımı/bağlantı hatası görünüyor.

2) Sunucunuzda hangi yazılım var?

Aşağıdaki paketler tipik örneklerdir: - Postfix - Exim - OpenSMTPD - Microsoft Exchange (daha farklı mimari) - Harici relay (ör. üçüncü parti SMTP relay)

Yazılım fark etmeksizin, port 25 trafiğinin açılması ve yönlendirme/firewall kuralları ortak konudur.

Port 25 nedir, neden e-posta gönderiminde kritik?

E-postada SMTP (Mail Transfer Protocol) ilk temas genellikle TCP 25 üzerinden başlar. Bazı sistemler alternatif portlar kullanır: - 587: Submission (çoğu istemci için) - 465: SMTPS (implicit TLS) - 2525 gibi özel portlar (kurum içi/alternatif kurulum)

Ancak dış dünyaya mail göndermek için pek çok senaryoda karşı sunucular hâlâ 25/TCP bekler. Bu nedenle “içeride gönderim var ama dışarı çıkmıyor” problemlerinin ilk kontrolü port 25 olmalıdır.

Not: Veri merkezi sağlayıcıları, spam riskine karşı bazı abonelerde port 25’i kısıtlayabilir. Bu durumda sunucunuzda her şey doğru olsa bile dışarıdan bağlantı engellenir.

Adım adım: Port 25 açık mı, çalışıyor mu?

Aşağıdaki testler sırayla yapılmalıdır. Hedef: “Ağ katmanı açık mı?” ile başlayıp “MTA port dinliyor mu?” ve “firewall/sunucu politikası engelliyor mu?”ya kadar net teşhis koymak.

1) Sunucu port 25 dinliyor mu? (lokal kontrol)

Sunucuda MTA’nız portu dinliyor olmalı. Linux’ta şu kontroller genellikle yeterlidir:

• ss -ltnp | grep ':25'
• netstat -ltnp | grep ':25' (netstat yüklüyse)

Beklenen durum: - Postfix/Exim gibi süreçlerin 0.0.0.0:25 veya sunucu IP’nizde x.x.x.x:25 dinlediğini görürsünüz.

Bekleniyorsa: - 25 açık görünmüyorsa MTA yapılandırması yanlış olabilir (ör. main.cf içindeki inet_interfaces/master.cf ayarları) ya da servis çalışmıyor olabilir.

2) Firewall (UFW/iptables) port 25’i dışarı açıyor mu?

Sunucu üzerinde aktif firewall kuralını kontrol edin.

• UFW: ufw status
• İptables: iptables -S

Beklenen durum: - Giden/iletişim hedefi olarak 25/TCP kuralı engellemeye takılmamalıdır.

Örnek mantık: - Sunucuda inbound için 25’i kapatsanız bile “gönderim” (outbound) genelde başka bir akıştan çalışır; fakat bazı uygulamalar NAT/route üzerinden dinamik davranış gösterdiği için iki tarafın da net kontrol edilmesi gerekir.

3) Sunucu yönlendirme (routing/NAT) doğru mu?

VDS/VPS’lerde NAT veya özel ağ (private network) kullanımı varsa, dışarı çıkış route’u engellenebilir. Şu sorulara net cevap arayın: - Sunucudan internete çıkış yapılıyor mu? - Default gateway var mı? - Public IP gerçekten aktif mi?

4) Sağlayıcı düzeyinde port 25 kısıtı var mı?

Birçok bulut sağlayıcısı, kötüye kullanım riskine karşı port 25’i kısıtlar. Bu durumda sunucuda firewall “açık” olsa bile dış dünya bağlantı kuramaz.

Bunu test etmek için iki yöntem kullanın: - Harici bir makineden (başka bir VPS/PC) sunucu IP’nize 25/TCP denemesi - Mail sunucusunun loglarında “connection timed out / connection refused” türü hataların hangi tarafta oluştuğunu okumak

Basit test (Windows/Linux için): - telnet <sunucu-ip> 25 - veya nc -vz <sunucu-ip> 25

Beklenen durum: - “succeeded” veya benzeri bir bağlantı cevabı alınır.

İstenen hata: - Bağlantı “timed out” ise genellikle yol/failwall/sağlayıcı kısıtı vardır. - “refused” ise hedef makine 25’te dinlemiyor veya yerel firewall/daemons engelliyor olabilir.

Sağlıklı teşhis için log okumayı tek tek uygulayın

Sadece “port açık mı kapalı mı” değil, MTA’nın yaptığı denemelerin nereye takıldığını görmek gerekir. Bu sayede yanlış yere zaman kaybetmezsiniz.

Hangi loglar işinizi hızlandırır?

Postfix için tipik lokasyonlar: - /var/log/mail.log - journalctl -u postfix --since "2 hours ago"

Exim için: - /var/log/exim/mainlog - journalctl -u exim4 --since "2 hours ago"

Aranacak tipik ifadeler: - connection timed out - connection refused - no route to host - relay access denied - host not found

Bu başlıklardan connection timed out doğrudan ağ/port engeliyle; connection refused ise hedefte dinleme/servis engeliyle; relay access denied ise kimlik doğrulama ve relay yetkileriyle ilgilidir.

Port 25 yerine 587/465 kullanımı: Ne zaman çözüm, ne zaman risk?

Bazı sistemlerde dışarıya çıkmak yerine istemci gönderimi 587 (submission) üzerinden alınır. Fakat burada kritik ayrım şudur: - 587 çoğunlukla istemciden sunucuya iç akıştır. - Sunucudan dış dünyaya giden teslimat hâlâ MTA’nın kullandığı çıkış portları üzerinden yürür.

Bu nedenle port 25 kısıtlıysa yalnızca “formdan gönderiyorum ama gidmiyor” değil; MTA’nın dış hedeflere nasıl bağlandığına bakmanız gerekir.

Net kontrol listesi

Aşağıdaki sorulara net cevap verin: - MTA çıkış kuyruğu (queue) artıyor mu? - Loglarda dış hedeflere to=<...>, relay=..., delay=..., status=... satırları nasıl bitiyor? - Hedef sunuculara bağlanırken hangi hata oluşuyor?

Eğer tüm dış denemelerde 25/TCP üzerinden çıkış deneniyor ve kısıt varsa, alternatif portlar ancak karşı sunucunun gerçekten kabul etmesiyle çalışır. Bu noktada “evrensel çözüm” olarak port 25’in önemi devam eder.

Bağlantı engeli için düzeltme planı (net adımlar)

Sorun kaynağını bulduktan sonra şu aksiyonlar standarttır.

Senaryo A: ss ile port 25 dinlenmiyor

1. MTA servis durumunu kontrol edin: systemctl status postfix (örnek)
2. Konfigürasyonda dinlenen arayüzü kontrol edin: - Postfix: inet_interfaces, myhostname, mydestination
3. Servisi yeniden başlatın: systemctl restart postfix

Beklenti: Port tekrar 0.0.0.0:25 veya ilgili public IP’de görünür.

Senaryo B: Port dinleniyor ama harici test başarısız

1. Sunucu firewall kuralını gözden geçirin.
2. Sağlayıcı tarafında port 25 kısıtı var mı kontrol edin: - Kontrol panel / destek biletinde “outbound/inbound port 25” durumu
3. Çözüm uygulanacaksa iki yoldan biri: - Port 25’in açılması - Alternatif relay (ör. bulut e-posta relay) kullanımı

Senaryo C: Loglarda “relay access denied” var

Bu port problemi değildir; MTA relay yetkisi yanlıştır. - IP izinleri (ör. mynetworks) - Kimlik doğrulama (AUTH) - Gönderenin (client) doğru şekilde authenticate olup olmadığı

Burada çözüm, portu değil yetkileri düzenlemektir.

Port 25 doğrulaması için karşılaştırma: “Hedefe ulaşma” mantığı

Bu bölüm, karar verirken tek bakışla sonuca götüren bir karşılaştırma sağlar: Hangi koşulda ne beklenmeli?

Bu tabloyu, elinizdeki log hata mesajıyla birlikte kullanın. Çünkü aynı “gönderim çalışmıyor” semptomu, farklı kök nedene işaret edebilir.

NetKıyas mantığıyla VDS/VPS seçerken port 25 kontrol kriterleri

E-posta teslimatı için sadece CPU/RAM değil, ağ politikaları ve destek kalitesi kritik. VDS/VPS seçerken şu kontrol maddelerini kullanın:

• Sağlayıcının dokümantasyonunda port 25 kısıtı var mı?
• Hesabın “abuse” kategorisinde mi? (çoğu sağlayıcı spam tetiklenirse port kısıtlar)
• Panel/Control Panel üzerinden ek IP talebi veya port açma süreci nasıl?
• Destek ekibi port 25 istisnası sağlıyor mu, sağlayabiliyorsa prosedür nedir?
• Yedekleme (backup) ve log erişimi: Sorun teşhisinde loglara erişim hız kazandırır.

Hız ve gecikme (latency) e-posta için ne kadar önemli?

Port 25 açık olsa bile teslimat gecikebilir; ancak bu genelde ilk etap “bağlantı kurulamadı” seviyesinde yaşanmaz. Burada doğru sıralama şöyledir: 1. Bağlantı kurulabiliyor mu? (25) 2. MTA kuyrukta ilerliyor mu? 3. Hedef teslimat kabul ediyor mu? (MX, SPF/DKIM/DMARC gibi katmanlar ayrı konu)

Sık yapılan hatalar (zaman kaybettiren noktalar)

• Sadece web panelden “SMTP ayarları doğru” diye bakmak: Port düzeyinde doğrulama yapılmadan sonuç alınmaz.
• Port 25’in kapalı olduğunu sanıp MTA konfigürasyonunu sürekli değiştirmek: Önce harici nc/telnet testi yapılır.
• 587’yi açınca her şeyin düzeleceğini düşünmek: Bu genellikle istemciden sunucuya akıştır; dış dünya teslimatı için MTA çıkışı belirleyicidir.
• Güncel olmayan güvenlik duvarı kuralı: UFW/iptables sürüm farkı veya otomasyon scriptleri kuralı tekrar kapatabilir.

Sonuç: Bugün yapılacak en kısa aksiyon planı

E-posta gönderilmiyor sorununda en hızlı ilerleme, port 25 için şu sırayı izlemektir: (1) Sunucuda 25 dinleniyor mu kontrol edin (ss -ltnp | grep ':25'), (2) harici bir makineden 25/TCP bağlantısını deneyin (nc -vz ... 25), (3) loglarda oluşan hataya göre firewall/MTA config mi yoksa sağlayıcı kısıtı mı olduğunu ayırın. Bu üç adımın sonunda kök nedeni genellikle net şekilde bulursunuz.

Eğer harici test başarısızsa, MTA ayarlarına harcayacağınız zamanı azaltın: sağlayıcıdan “port 25 outbound/inbound politikası”nı doğrulatın veya relay çözümüne geçin. Doğru teşhisle yapılan düzeltme, hem teslimatı geri getirir hem de tekrar yaşanma riskini düşürür.