Yeni kurduğun mail sunucusundan tek bir mesaj bile dışarı çıkmıyorsa, kuyruk sessizce şişiyorsa ve loglarda Connection timed out satırlarını görüyorsan büyük ihtimalle SMTP 25 portu kapalı durumdadır. Bu, yapılandırma hatası gibi görünen ama aslında ağ katmanında alınmış bir karardan kaynaklanan klasik bir durum: sunucunun kendisi mükemmel çalışıyor olabilir, mesajlar kuyruğa düzgün giriyordur, ama giden TCP bağlantısı yolun bir yerinde sessizce düşürülüyordur. Sessizce düşürülmesi de işin en can sıkıcı yanıdır; bağlantı reddedilmez, öylece zaman aşımına uğrar ve bu yüzden teşhis dakikalar yerine saatler alır.
Bu yazıda önce 25 numaralı portun neden bu kadar özel olduğunu ve kimlerin engellediğini netleştireceğim; sonra engelin tam olarak nerede olduğunu adım adım ölçeceğiz. Ardından üç gerçekçi çözüm yolunu karşılaştıracağız: portu açtırmak, bir relay (smarthost) üzerinden çıkmak ya da gönderim işini tamamen ayrı bir altyapıya devretmek. Sonunda da bu konuda en sık yapılan yanlışları toplayacağım — özellikle 25, 587 ve 465 portlarının birbirinin yerine geçtiğini sanmaktan doğan karışıklığı.
25 Numaralı Port Neden Engelleniyor#
25 numaralı port, iki mail sunucusunun birbiriyle konuştuğu porttur. Bir kullanıcı postayı kendi sunucusuna 587 üzerinden verir, o sunucu da alıcının sunucusuna 25 üzerinden teslim eder. Bu tasarımın tarihsel bir yan etkisi var: 25 portu kimlik doğrulaması olmadan bağlantı kabul eder, çünkü karşı taraf zaten bir yabancıdır. Bu da onu, virüs bulaşmış makinelerin ve kiralık sunucuların doğrudan spam pompalamak için kullandığı kanal haline getirdi.
Sonuç olarak neredeyse tüm ev interneti sağlayıcıları, çoğu büyük bulut sağlayıcısı ve pek çok hosting firması giden 25 trafiğini varsayılan olarak kapatır. Bu bir arıza değil, bilinçli bir politikadır ve amacı IP bloklarının kara listelere düşmesini engellemektir. Engeli kimin koyduğuna göre çözüm de değişir, o yüzden ilk iş engelin katmanını tespit etmek olmalı:
| Engeli koyan | Tipik belirti | Çözüm yolu |
|---|---|---|
| Sunucudaki güvenlik duvarı | Anında Connection refused | Yerel kuralı düzelt |
| Hosting / bulut sağlayıcı | Sessiz zaman aşımı (timeout) | Destek talebiyle açtırma |
| İnternet servis sağlayıcı (ev/ofis) | Sessiz zaman aşımı | 587 kullan, 25 açılmaz |
| Karşı taraf kara listede tuttuğu için | Connection refused veya 5xx banner | Kara liste kaydını temizlet |
| Bulut sağlayıcı yeni hesap kısıtı | İlk günler kapalı, sonra açılıyor | Hesap doğrulama süreci |
Ayrımdaki en pratik ipucu şudur: hemen dönen bir ret genellikle senin tarafındaki bir kuraldan, uzun süren bir sessizlik ise yol üstündeki bir güvenlik duvarından gelir. Paketin nereye kadar gittiğini ölçmeden yapılan tahminler seni yanlış yere götürür.
Engelin Nerede Olduğunu Ölçmek#
Teşhise sunucunun kendisinden başla. En hızlı test, bilinen bir mail sunucusuna 25 portundan bağlanmayı denemektir. nc (netcat) bunun için birebirdir:
# Zaman aşımı süresi vererek dene, cevabı bekle
nc -vz -w 8 gmail-smtp-in.l.google.com 25
# Başarılıysa banner'ı da görmek için:
nc -w 8 gmail-smtp-in.l.google.com 25
# 220 mx.google.com ESMTP ... gsmtp <-- bu satırı görüyorsan port AÇIK
nc yoksa telnet gmail-smtp-in.l.google.com 25 de aynı işi görür. Cevap gelmiyor ve komut 8-10 saniye asılı kalıp düşüyorsa, giden bağlantı bir yerde filtreleniyor demektir. Aynı testi ikinci bir hedefe daha yap; tek bir hedefte başarısız olmak o hedefin seni engellediğini, her hedefte başarısız olmak ise senin çıkışının kapalı olduğunu gösterir.
Sırada paketin nereye kadar gidebildiğini görmek var. traceroutenin TCP modu bunu doğrudan ölçer:
# 25 portuna TCP ile iz sür (root gerekir)
sudo traceroute -T -p 25 gmail-smtp-in.l.google.com
# Alternatif: hangi atlamada durduğunu gör
sudo mtr -T -P 25 -c 20 --report gmail-smtp-in.l.google.com
Çıktıda paketler kendi sunucunun ilk atlamasında ölüyorsa engel makinenin kendisinde ya da sağlayıcının kenar yönlendiricisindedir. Birkaç atlama gidip sonra kayboluyorsa yol üstünde bir filtre var demektir ve bunu ancak sağlayıcı kaldırabilir. Yerel güvenlik duvarını da mutlaka doğrula:
# nftables kullanıyorsan
sudo nft list ruleset | grep -A3 'oif\|output'
# iptables kullanıyorsan giden zinciri gör
sudo iptables -L OUTPUT -n -v --line-numbers
# UFW kullanıyorsan
sudo ufw status verbose
Son olarak sunucunun mesajı gerçekten göndermeye çalıştığını doğrula. Postfix'te log satırı şuna benzer ve Connection timed out ifadesi teşhisin kendisidir:
sudo tail -f /var/log/mail.log | grep -i 'connect to'
# postfix/smtp[2411]: connect to alt1.gmail-smtp-in.l.google.com[...]:25:
# Connection timed out
Bu satırı görüyorsan artık tahmin etmiyorsun: sunucu deniyor, ağ izin vermiyor. Kuyruğun bu yüzden şiştiğini görmek için mail kuyruğu birikti yazısındaki teşhis komutlarını da yanına alabilirsin.
25, 587 ve 465 Portlarının Farkı#
Bu üç portun karıştırılması, konuyla ilgili yanlış çözümlerin yarısının kaynağıdır. Üçü aynı protokolü taşır ama farklı işler için ayrılmıştır:
| Port | Adı | Kim kullanır | Kimlik doğrulama | Şifreleme |
|---|---|---|---|---|
| 25 | SMTP relay | Sunucudan sunucuya teslim | Yok (anonim) | Fırsatçı STARTTLS |
| 587 | Submission | Kullanıcı → kendi sunucusu | Zorunlu | STARTTLS |
| 465 | Submission (implicit TLS) | Kullanıcı → kendi sunucusu | Zorunlu | Baştan TLS |
Buradan çıkan pratik sonuç şu: 587 portunun açık olması 25 portunun kapalı olmasını telafi etmez. 587, senin uygulamanın kendi mail sunucuna posta teslim etmesini sağlar; ama o sunucunun postayı Gmail'e ulaştırmak için 25 portuna ihtiyacı vardır. Yani mail sunucusu işletiyorsan giden 25 zorunludur. Buna karşılık yalnızca bir uygulamadan posta gönderiyorsan ve teslimatı başka bir sunucuya bırakacaksan 587 tamamen yeterlidir; bu ayrım, aşağıdaki relay çözümünün de temelini oluşturur.
465 portu uzun süre "kullanımdan kaldırıldı" diye anlatıldı, sonra tekrar standartlaştırıldı. İkisi arasında güvenlik açısından anlamlı bir fark yok; 465 bağlantıyı baştan TLS ile açar, 587 önce düz metin başlayıp STARTTLS ile yükseltir. İstemci kütüphanen hangisini daha az sorunla destekliyorsa onu kullan, ama 587'yi kullanıyorsan sunucu tarafında TLS'i zorunlu yapmayı unutma.
Çözüm 1: Portu Sağlayıcıya Açtırmak#
Kendi mail sunucunu işletmek istiyorsan doğru çözüm budur. Ciddi hosting ve sunucu sağlayıcıları, meşru bir kullanım gerekçesi gördüklerinde giden 25 portunu açar; kapalı tutmalarının nedeni müşteriye zorluk çıkarmak değil, IP bloklarını korumaktır. Destek talebini şu bilgilerle açarsan süreç ciddi biçimde hızlanır:
- Sunucunun IP adresi ve kullanmayı planladığın hostname (örneğin
mail.firmaniz.com). - Gönderimin niteliği: kurumsal yazışma mı, işlemsel bildirim mi, bülten mi.
- Tahmini günlük gönderim hacmi — abartma, gerçekçi bir sayı yaz.
- PTR (rDNS) kaydının
mail.firmaniz.comolarak ayarlanması talebi. - SPF, DKIM ve DMARC kayıtlarını kurduğuna dair kısa bir not.
Son madde göründüğünden önemlidir: sağlayıcı açısından bu kayıtları kurmuş bir müşteri, işi ciddiye alan bir müşteridir ve risk profili düşüktür. Kayıtların tamamı ve doğru biçimleri için mail sunucusu DNS kayıtları yazısına bakabilirsin. PTR kaydını da mutlaka talep et; PTR'siz bir IP'den çıkan postayı büyük sağlayıcıların önemli bir kısmı doğrudan reddeder, port açılsa bile teslimat sorunun devam eder.
Bir uyarı: ev internetinden ya da mobil bağlantıdan giden 25 portu pratikte hiçbir zaman açılmaz. Bu bloklar sağlayıcı politikası olmanın ötesinde, birçok yerde kara liste operatörlerinin dinamik IP aralıklarına uyguladığı toplu engellemelerle de birleşir. Evdeki makineden mail sunucusu işletme fikrini en baştan bırakmanı öneririm.
Çözüm 2: Relay (Smarthost) Üzerinden Çıkmak#
Port açılmıyorsa ya da hızlıca çözüm gerekiyorsa en sağlam yol, giden postayı 587 üzerinden kimlik doğrulamalı bir relay sunucusuna teslim etmektir. Senin sunucun postayı toplar, imzalar, kuyruklar; dış dünyaya teslim işini relay yapar. Postfix'te bu yapılandırma şöyledir:
# /etc/postfix/main.cf
# Tüm giden postayı bu smarthost'a ver (köşeli parantez MX aramasını atlar)
relayhost = [smtp.firmaniz.com]:587
# Kimlik doğrulamayı aç
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
# TLS'i zorunlu kıl; düz metin gönderimi kabul etme
smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
Kimlik bilgilerini ayrı bir dosyaya yaz ve yetkilerini daralt:
# Kullanıcı adı ve parolayı yaz
echo '[smtp.firmaniz.com]:587 [email protected]:GUCLU_PAROLA' \
| sudo tee /etc/postfix/sasl_passwd
# Sadece root okuyabilsin, hash veritabanını üret
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl reload postfix
# Test gönderimi yap ve logu izle
echo "test govdesi" | mail -s "relay testi" [email protected]
sudo tail -n 30 /var/log/mail.log
Bu kurgunun avantajı, relay sağlayıcısının IP itibarını devralmandır; dezavantajı ise gönderim hacmi ve içerik politikası konusunda o sağlayıcının kurallarına tabi olmandır. Parolayı düz metin dosyada tuttuğun için chmod 600 adımını asla atlama. Güçlü bir parola üretmek istersen şifre üretici aracımızı kullanabilirsin.
Çözüm 3: Gönderimi Ayrı Bir Altyapıya Taşımak#
Üçüncü yol, "mail sunucusu işletmek" ile "posta göndermek" işlerini ayırmaktır ve özellikle uygulama bildirimleri, sipariş onayları, parola sıfırlama gibi işlemsel postalar için en sağlıklı yaklaşım budur. Uygulaman 587 üzerinden kimlik doğrulamalı bir gönderim servisine bağlanır; 25 portuna hiç ihtiyaç duymaz, kuyruk yönetimi, yeniden deneme, kara liste takibi gibi işler senin sorumluluğundan çıkar.
Bu ayrımın ikinci faydası itibar yalıtımıdır. Bülten trafiğinle kurumsal yazışmanı aynı IP'den göndermek, bir bülten şikayeti yüzünden kurumsal postalarının da spam'e düşmesi anlamına gelir. Gönderimi ayırmak bu riski ortadan kaldırır. Uygulamanın SMTP ayarlarını test etmek için SMTP test aracı sayfamızdaki komut üreticiyi kullanabilir, gönderim hacmine göre kaynak planlaması yapmak istersen mail sunucusu kaynak gereksinimleri yazısına göz atabilirsin.
Sık Yapılan Hatalar#
En yaygın hata, sorunun mail sunucusu yapılandırmasında olduğunu varsayıp saatlerce main.cf kurcalamaktır. Ağ testini yapmadan yapılandırmaya dokunma; nc -vz hedef 25 komutu bu ayrımı otuz saniyede yapar. İkinci sık hata, 587 portunun çalıştığını görüp "port açık" sonucuna varmaktır — az önce anlattığım gibi bu ikisi farklı işlerdir ve biri diğerinin yerini tutmaz.
Üçüncü hata, gelen ve giden yönü karıştırmaktır. Sunucuna posta gelmiyorsa bu 25 portunun gelen yönüyle ilgilidir ve genellikle güvenlik duvarında INPUT kuralı ya da MX kaydı sorunudur; posta gitmiyorsa giden yön engellidir. ss -lntp | grep :25 komutu sunucunun portu dinleyip dinlemediğini gösterir, bu gelen yönle ilgilidir ve giden engeli hakkında hiçbir şey söylemez.
Dördüncü hata, relay yapılandırdıktan sonra relayhost değerini köşeli parantezsiz yazmaktır. relayhost = smtp.firmaniz.com:587 yazarsan Postfix o isim için MX kaydı arar; [smtp.firmaniz.com]:587 yazarsan doğrudan A kaydına gider. Relay sunucusunun MX kaydı yoksa ilk biçim sessizce başarısız olur. Beşinci hata ise engel kaldırıldıktan sonra kuyruğu boşaltmayı unutmaktır; Postfix'te postqueue -f komutu bekleyen tüm mesajları hemen yeniden dener. Son olarak, port açıldıktan sonra teslimatın hâlâ sorunlu olması genellikle DNS ya da itibar kaynaklıdır; büyük sağlayıcılara özgü davranışlar için Gmail'e mail gitmiyor yazısı iyi bir kontrol listesi sunar.
Sıkça Sorulan Sorular#
25 portu kapalıysa mail hiç gönderemez miyim#
Kendi sunucundan doğrudan teslimat yapamazsın, ama gönderim tamamen imkânsız değildir. Giden postayı 587 portu üzerinden kimlik doğrulamalı bir relay ya da gönderim servisine teslim ederek postalarını çıkarabilirsin. Bu durumda dış dünyaya teslim işini relay üstlenir ve senin sunucunun 25 portuna ihtiyacı kalmaz.
25 portunun açık olup olmadığını nasıl kontrol ederim#
Sunucuya SSH ile bağlan ve bilinen bir mail sunucusuna bağlanmayı dene: nc -vz -w 8 gmail-smtp-in.l.google.com 25. Bağlantı kurulup 220 ile başlayan bir banner geliyorsa port açıktır. Komut cevapsız kalıp zaman aşımına uğruyorsa giden trafiğin engelleniyordur. Testi iki farklı hedefe yaparak tek bir sunucunun seni engellemesi ihtimalini eleyebilirsin.
25 portunu açtırmak ne kadar sürer#
Sağlayıcıya ve talebin içeriğine göre değişir; genellikle birkaç saat ile birkaç iş günü arasındadır. Süreci hızlandırmak için talebi açarken sunucu IP'sini, planladığın hostname'i, gönderim türünü ve tahmini hacmi belirt, ayrıca SPF/DKIM/DMARC kayıtlarını kurduğunu ve PTR talebini de aynı mesaja ekle. Eksik bilgi, sürecin ileri geri yazışmayla uzamasının en büyük sebebidir.
Ev internetimden mail sunucusu çalıştırabilir miyim#
Pratikte hayır. Ev ve mobil internet sağlayıcılarının neredeyse tamamı giden 25 portunu kalıcı olarak kapatır ve bu engel bireysel talepler üzerine açılmaz. Bunun ötesinde dinamik IP aralıkları çoğu kara liste tarafından toplu olarak işaretlenmiştir, yani port açılsa bile postaların büyük sağlayıcılar tarafından reddedilir. Bu iş için bir sunucu kiralamak tek gerçekçi yoldur.
587 portu 25 portunun yerine geçer mi#
Hayır, ikisi farklı görevler için tasarlanmıştır. 587 kullanıcının ya da uygulamanın kendi sunucusuna kimlik doğrulayarak posta teslim ettiği porttur; 25 ise iki mail sunucusunun birbirine teslim yaptığı porttur. Kendi sunucun postayı alıcının sunucusuna ulaştıracaksa giden 25 portuna ihtiyacı vardır. 587 yalnızca teslimatı başka bir sunucuya bıraktığın senaryolarda yeterli olur.
Port açık ama postalarım hâlâ gitmiyor, sırada ne var#
Bu noktada sorun ağ değil, itibar ve DNS tarafındadır. Sırasıyla şunları doğrula: IP'nin PTR kaydı var mı ve HELO adıyla eşleşiyor mu, SPF kaydında bu sunucu yetkili mi, DKIM imzası doğrulanıyor mu, IP herhangi bir kara listede mi. Logdaki ret mesajını okumak da çok değerlidir; büyük sağlayıcılar reddederken genellikle sebebi ve bir yardım bağlantısı verir.
Kapanış#
25 portu sorunu teknik olarak basit ama teşhisi yanlış yerden başlatıldığında saatler yiyen bir konudur. Aklında tutman gereken dört alışkanlık şu: yapılandırmaya dokunmadan önce nc ile ağ testini yap; hemen dönen ret ile sessiz zaman aşımının farklı katmanları işaret ettiğini unutma; 587 ile 25'i asla birbirinin yerine koyma; ve port açıldıktan sonra PTR, SPF, DKIM üçlüsünü doğrulamadan işin bittiğini varsayma. Kuyruğu boşaltmayı da unutma, yoksa engel kalksa bile mesajlar bir sonraki yeniden deneme zamanına kadar bekler.
Kendi mail altyapını kurarken bu engellerle uğraşmak istemiyorsan Clou.TR tarafında işini kolaylaştıracak birkaç seçenek var. Giden posta için hazır yapılandırılmış SMTP sunucu paketlerimiz PTR ve imzalama ayarlarıyla birlikte teslim edilir; kendi sunucunu kurmak istersen tam root erişimli VDS çözümlerimizde port talebini destek üzerinden iletebilirsin. Kurulum ve bakımı bize bırakmak istersen sunucu yönetimi, kurumsal posta kutuları için ise e-posta paketlerimiz doğrudan hazır bir çözüm sunar.