Sunucumdan Mail Gitmiyor: Çıkış 25. Port Engeli ve Relay Çözümü

Yeni bir VDS aldınız, Postfix'i kurdunuz, alan adının MX kaydını yazdınız, SPF ve DKIM'i yerine oturttunuz. Test maili gönderiyorsunuz; komut hatasız dönüyor, mail.log dosyasında status=deferred satırı görünüyor, ama mesaj alıcıya asla ulaşmıyor. Bounce da gelmiyor. Sanki mail sunucudan çıkmış gibi davranıyor, oysa çıkmamış.

Saatler süren yapılandırma kontrolünden sonra insanın aklına gelmeyen şey şudur: yapılandırmada hiçbir sorun yoktur. Türkiye'de satılan VDS ve bulut sunucuların büyük çoğunluğunda giden (outbound) 25. port varsayılan olarak kapalıdır ve bu, ürün sayfasında hemen hiç yazmaz. Sağlayıcı bunu spam kaynaklı IP itibar kaybını önlemek için yapar; sizin sunucunuz da yeni açılmış her sunucu gibi kanıtlanana kadar potansiyel spam kaynağı sayılır.

Engelin sinsi tarafı, sessiz olmasıdır. Paket düşürülür, RST dönmez, bu yüzden Postfix "bağlantı reddedildi" gibi net bir hata almaz; 30 saniye bekler, zaman aşımına düşer, mesajı kuyrukta tutar ve düzenli aralıklarla tekrar dener. Beş gün boyunca hiçbir şey olmaz, sonra maximal_queue_lifetime dolduğunda birikmiş yüzlerce mesaj aynı anda bounce olarak geri döner.

Bu yazıda önce engelin gerçekten var olduğunu kanıtlayacağız — tahmin üzerine yapılandırma değiştirmek bu konudaki en pahalı hatadır. Sonra Postfix'i 587 üzerinden kimlik doğrulamalı bir relay ile kalıcı çıkışa bağlayacağız ve son olarak sağlayıcıdan portu açtırma talebinde neyin yazılması gerektiğine bakacağız. İstemci tarafındaki port seçimlerini (587 mi 465 mi, IMAP 993) burada tekrar etmiyorum; onlar için mail portları rehberi yazısı var. Buradaki konu sunucudan dışarı çıkış.

Belirti: Mailler Kuyrukta Birikiyor, Ekranda Hata Yok#

İlk yapmanız gereken kuyruğa bakmaktır. Postfix'te tek komut:

postqueue -p
# veya eşdeğeri
mailq

Tipik çıktı şuna benzer:

-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
7C3A81C0B21     2184 Mon Aug 18 09:12:41  [email protected]
(connect to gmail-smtp-in.l.google.com[142.251.16.27]:25: Connection timed out)
                                          [email protected]

9F2B41C0C77     1907 Mon Aug 18 09:14:02  [email protected]
(connect to ornek-mx.protection.outlook.com[52.101.68.10]:25: Connection timed out)
                                          [email protected]

Parantez içindeki satır teşhisin kendisidir ve üç şeyi aynı anda söyler: bağlantı 25. porta gidiyor, hedef farklı sağlayıcılar ve sonuç her seferinde Connection timed out. Bir alıcıya özel bir sorun olsaydı diğer sağlayıcı çalışırdı; kimlik doğrulama sorunu olsaydı 5xx kodlu bir SMTP yanıtı alırdınız. Aynı sonucun her hedefte tekrarlanması, sorunun sunucunun kendi çıkış yolunda olduğunu gösterir.

Log tarafında da aynı imza görünür:

# Debian / Ubuntu
sudo tail -f /var/log/mail.log

# RHEL / AlmaLinux / Rocky
sudo tail -f /var/log/maillog

# Dağıtımdan bağımsız
sudo journalctl -u postfix -f

Aradığınız satır şu biçimdedir:

postfix/smtp[2244]: 7C3A81C0B21: to=<[email protected]>, relay=none,
  delay=30, delays=0.02/0/30/0, dsn=4.4.1, status=deferred
  (connect to gmail-smtp-in.l.google.com[142.251.16.27]:25: Connection timed out)

relay=none ve dsn=4.4.1 ikilisi "hedefe hiç bağlanamadım" demektir. delays alanındaki üçüncü sayı (burada 30) bağlantı kurma aşamasında geçen süredir; tam olarak smtp_connect_timeout değerine eşit olması, karşı tarafın hiç cevap vermediğini yani paketin sessizce düşürüldüğünü gösterir.

Kanıt Adımı: Giden 25. Portun Kapalı Olduğunu İspatlama#

Loglar güçlü bir işaret verir ama kanıt değildir. Kanıtı sunucudan elle bağlanmayı deneyerek üretirsiniz. Önce gerçek bir hedef bulun:

# Gmail'in MX sunucularını öğren
dig +short MX gmail.com | sort -n | head -3

Sonra bağlantıyı test edin. En sağlıklı yöntem nc ile zaman aşımı vermektir:

# 25. porta bağlanmayı 8 saniyeyle sınırla
nc -zv -w 8 gmail-smtp-in.l.google.com 25

# Aynı hedefte 587'yi de dene — karşılaştırma için
nc -zv -w 8 smtp.gmail.com 587

nc kurulu değilse bash'in kendi TCP desteği yeterlidir:

timeout 8 bash -c 'exec 3<>/dev/tcp/gmail-smtp-in.l.google.com/25; head -1 <&3' \
  && echo "25 ACIK" || echo "25 KAPALI veya zaman asimi"

Sonucun nasıl okunacağı kritiktir. İki farklı başarısızlık, iki farklı sebep anlamına gelir:

Timeout ile refused arasındaki fark bu yazının en pratik bilgisidir. Bir üst katman güvenlik duvarı trafiği engellerken genellikle paketi sessizce atar (DROP), bu da timeout üretir. Yerel bir iptables REJECT kuralı ise anında "refused" döndürür. Yani timeout görüyorsanız sorun büyük olasılıkla sizin sunucunuzun dışındadır.

Testi en az iki farklı hedefe ve mutlaka 587 ile karşılaştırmalı yapın. 25 timeout verirken 587 banner döndürüyorsa tablo netleşir: internet çıkışınız çalışıyor, engellenen şey yalnızca 25. porttur. Genel port durumunu görmek için açık port taraması yazısındaki yöntemleri de kullanabilirsiniz, ama dikkat: oradaki tarama gelen portları ölçer, buradaki soru giden trafiktir.

Engel Sizde mi: Yerel Güvenlik Duvarı ve IPv6 Yanılgısı#

Sağlayıcıyı suçlamadan önce iki yerel sebebi elemeniz gerekir; ikisi de aynı timeout görüntüsünü üretebilir.

Birincisi kendi güvenlik duvarınız. Çoğu kurulum yalnızca gelen trafiği filtreler ama bazı sıkılaştırma scriptleri OUTPUT zincirine de kural yazar:

# iptables kullanan sistemlerde giden kuralları göster
sudo iptables -L OUTPUT -n -v --line-numbers

# nftables kullanan sistemlerde
sudo nft list ruleset | grep -A5 'chain output'

# ufw
sudo ufw status verbose

ufw status verbose çıktısında Default: deny (outgoing) satırı görüyorsanız engel sizdedir. Bulut sağlayıcılarında ayrıca sunucunun dışında bir güvenlik grubu / firewall paneli olabilir; panelden giden kuralları da kontrol edin.

İkincisi IPv6 tuzağı. Sunucunuzun IPv6 adresi varsa ama IPv6 yönlendirmesi düzgün çalışmıyorsa, Postfix önce AAAA kaydına bağlanmayı dener, timeout alır, sonra IPv4'e döner — ya da hiç dönmez. Bu, 25. port engeliyle birebir aynı görünür. Ayırt etmek kolaydır:

nc -4 -zv -w 8 gmail-smtp-in.l.google.com 25   # sadece IPv4
nc -6 -zv -w 8 gmail-smtp-in.l.google.com 25   # sadece IPv6

IPv4 çalışıp IPv6 çalışmıyorsa sorun port engeli değil, IPv6 yollarınızdır. Geçici çözüm Postfix'i IPv4'e sabitlemektir:

sudo postconf -e "inet_protocols = ipv4"
sudo systemctl restart postfix

Her ikisi de timeout veriyorsa engel gerçekten yukarıdadır ve bir sonraki bölüme geçebilirsiniz.

Kalıcı Çözüm: Postfix relayhost ile 587 Üzerinden Çıkış#

Engel doğrulandıysa iki seçeneğiniz vardır: sağlayıcıdan portu açtırmak (zaman alır, reddedilebilir) ya da mailleri kimlik doğrulamalı bir SMTP relay üzerinden 587/465 ile göndermek. İkincisi hem hemen çalışır hem de çoğu senaryoda daha iyi teslimat sağlar, çünkü relay sağlayıcısının IP itibarını devralırsınız.

1. SASL modüllerini kurun#

Bu adım atlanınca alınan hata SASL authentication failed: no mechanism available olur ve insanı saatlerce parola aramaya yönlendirir. Oysa eksik olan şey kimlik doğrulama modülüdür:

# Debian / Ubuntu
sudo apt update && sudo apt install -y libsasl2-modules

# RHEL / AlmaLinux / Rocky
sudo dnf install -y cyrus-sasl-plain

2. Kimlik bilgilerini yazın#

sudo tee /etc/postfix/sasl_passwd >/dev/null <<'EOF'
[smtp.saglayici.com]:587 [email protected]:GUCLU_PAROLA
EOF

sudo chown root:root /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd

Köşeli parantezler tesadüf değildir: [host] yazımı Postfix'e "bu isim için MX araması yapma, doğrudan bu ana bağlan" der. Parantezsiz yazarsanız Postfix relay sunucusunun MX kaydını arar ve çoğunlukla yanlış yere gider. postmap komutu yanına .db (veya sisteminize göre .lmdb) uzantılı derlenmiş dosyayı üretir; parolayı her değiştirdiğinizde postmap komutunu tekrar çalıştırmayı unutmayın, yoksa Postfix eski parolayı kullanmaya devam eder.

3. main.cf yapılandırması#

# /etc/postfix/main.cf
relayhost = [smtp.saglayici.com]:587

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous

smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

smtp_tls_security_level = encrypt şifrelemeyi zorunlu kılar; may yazarsanız TLS başarısız olduğunda Postfix parolayı düz metin gönderebilir. Değişikliği uygulayın:

sudo postfix check && sudo systemctl reload postfix

4. 465 kullanacaksanız wrappermode#

Relay sağlayıcınız yalnızca 465 sunuyorsa port numarasını değiştirmek yetmez; 465 baştan şifreli (implicit TLS) çalışır ve Postfix'in bunu bilmesi gerekir. Bu özellik Postfix 3.0 ve sonrasında vardır:

postconf mail_version    # 3.0 veya üzeri olmalı

sudo postconf -e "relayhost = [smtp.saglayici.com]:465"
sudo postconf -e "smtp_tls_wrappermode = yes"
sudo postconf -e "smtp_tls_security_level = encrypt"
sudo systemctl reload postfix

Kendi mail sunucunuzu sıfırdan kuruyorsanız bu ayarların tam bağlamı için Postfix ve Dovecot ile mail sunucu kurulumu yazısına bakabilirsiniz.

Relay Sonrası En Sık Görülen Hata: Gönderici Uyuşmazlığı#

Relay kurulduktan sonra mailler çıkmaya başlar ama bir kısmı 550 5.7.1 Sender address rejected: not owned by user gibi bir hatayla geri döner. Sebep şudur: relay sağlayıcıları, kimlik doğruladığınız hesabın sahibi olmadığı bir adresten gönderim yapmanıza izin vermez. Sunucunuz [email protected] gibi bir zarf göndericiyle çıkmaya çalışıyorsa reddedilir.

Çözüm giden adresleri yeniden yazmaktır:

sudo tee /etc/postfix/generic >/dev/null <<'EOF'
root@localhost           [email protected]
www-data@localhost       [email protected]
@vds-1234.hosting.local  [email protected]
EOF

sudo postmap /etc/postfix/generic
sudo postconf -e "smtp_generic_maps = hash:/etc/postfix/generic"
sudo systemctl reload postfix

İkinci ve daha az bilinen etki SPF üzerindedir. Artık mailleriniz relay sağlayıcısının IP'lerinden çıktığı için, alan adınızın SPF kaydı o sağlayıcıyı kapsamıyorsa SPF başarısız olur ve mesajlar spam klasörüne düşer. SPF kaydınıza sağlayıcının include: değerini eklemeniz gerekir; bu mekanizmanın ayrıntıları SPF, DKIM ve DMARC yazısında anlatılıyor.

Kuyruğu Boşaltma ve Doğrulama#

Relay çalışır hâle geldikten sonra beklemekte olan mesajları elle tetikleyin:

# Kuyruktaki tüm mesajları yeniden dene
sudo postqueue -f

# Belirli bir mesajın tam içeriğini ve başlıklarını incele
sudo postcat -q 7C3A81C0B21

# Kuyruğun boşaldığını doğrula
postqueue -p

Ardından gerçek bir test maili gönderip logu izleyin:

echo "relay testi" | mail -s "Test $(date +%H:%M)" [email protected]
sudo tail -20 /var/log/mail.log

Başarılı bir teslimatta göreceğiniz satır şudur:

postfix/smtp[3311]: A1B2C3D4E5: to=<[email protected]>,
  relay=smtp.saglayici.com[203.0.113.44]:587, delay=1.9,
  dsn=2.0.0, status=sent (250 2.0.0 OK)

status=sent ve 250 2.0.0 OK ikilisi mesajın relay tarafından kabul edildiğini gösterir. Bu, alıcının gelen kutusuna düştüğü anlamına gelmez — mesaj spam klasörüne de düşmüş olabilir. Teslim edilip edilmediğini anlamak için alıcı tarafındaki başlıkları okuyun; geri dönen mesajları yorumlamak içinse bounce mesajı nasıl okunur yazısı yardımcı olur.

Kuyrukta günlerdir bekleyen ve artık anlamsız hâle gelmiş mesajları temizlemek isterseniz dikkatli olun; bu komut geri alınamaz:

sudo postsuper -d ALL deferred

Sağlayıcıdan 25. Portu Açtırma Talebi: Ne Yazmalı#

Relay çoğu ihtiyaca yeter, ama kendi MTA'sından doğrudan teslimat yapmak isteyen (yüksek hacimli gönderim, kendi mail hizmetini satan, uyum gerekçesiyle üçüncü tarafa mail emanet edemeyen) kullanıcılar için portun açılması gerekir. Talep formu yazarken sağlayıcının sormadan cevabını istediği bilgiler şunlardır:

1. Sunucu kimliği: IP adresi ve hizmet numarası.
2. Kullanım amacı: "Kurumsal alan adımızın mail sunucusu" gibi somut bir tanım; "test edeceğim" cevabı neredeyse hep reddedilir.
3. Beklenen hacim: Günlük tahmini gönderim adedi ve alıcıların nereden geldiği (müşteri veritabanı, form bildirimleri, sipariş mailleri).
4. rDNS/PTR kaydı: IP'nin mail.ornekfirma.com gibi bir isme çözüldüğünü ve bu ismin aynı IP'ye A kaydıyla döndüğünü belirtin. Kayıt yoksa aynı talepte isteyin.
5. Kimlik doğrulama kayıtları: SPF, DKIM ve DMARC kayıtlarının hazır olduğunu, DKIM imzalamanın aktif olduğunu yazın.
6. Kötüye kullanım politikası: Toplu pazarlama maili göndermeyeceğinizi, listelerin izinli olduğunu ve abonelikten çıkma mekanizmasının bulunduğunu taahhüt edin.
7. İletişim: abuse@ ve postmaster@ adreslerinin çalıştığını belirtin.

Bu maddelerin hepsini içeren bir talep genellikle aynı gün sonuçlanır. Eksik bilgiyle açılan talep ise ek soru turlarına girer ve günler alır.

Talep Neden Reddedilir#

Reddedilmenin dört tipik sebebi vardır ve hiçbiri kişisel değildir:

Hesap yaşı. Birçok sağlayıcı hesap belirli bir yaşı (genellikle 7–30 gün) doldurmadan giden 25. portu açmaz. Kredi kartı doğrulaması yapılmış ve en az bir ödeme tamamlanmış hesaplar öne geçer.

Kimlik doğrulaması eksik. Kurumsal başvurularda vergi levhası, bireysel başvurularda kimlik doğrulaması istenebilir. Spam kaynaklı bir engelden sonra sağlayıcı kendi IP bloğunu savunmak zorundadır.

IP bloğunun geçmişi. Size tahsis edilen IP daha önce başka bir müşteri tarafından spam için kullanılmış olabilir. Bu durumda port açılsa bile mailleriniz düşer. Talep etmeden önce IP'nizi sorgulayın; yöntemler mail kara listesi sorgulama ve listeden çıkma yazısında. Kirli bir IP'de en verimli hamle portu açtırmak değil, IP değişikliği istemektir.

Ürün politikası. Bazı sağlayıcılar giriş seviyesi paketlerde 25. portu hiç açmaz; bunu ürün farklılaştırması olarak kullanırlar. Böyle bir durumda tek seçenek relay ya da ayrı bir gönderim hizmetidir. Düzenli ve yüksek hacimli gönderim yapıyorsanız, itibar yönetimi de dahil olmak üzere işi devralan SMTP hizmeti seçenekleri çoğu zaman kendi MTA'nızı beslemekten daha ucuza gelir.

Sıkça Sorulan Sorular#

Mailler kuyrukta birikiyor ama hata mesajı yok, neden?#

Çünkü henüz bir hata oluşmadı. Postfix hedefe hiç bağlanamadığı için mesajı kalıcı olarak reddetmez; geçici sorun varsayıp status=deferred ile kuyrukta tutar ve artan aralıklarla yeniden dener. Gerçek hata ancak maximal_queue_lifetime süresi (varsayılan 5 gün) dolduğunda bounce olarak üretilir. Yani sessizlik, hatanın yokluğu değil ertelenmesidir.

25. portun kapalı olduğunu nasıl kesin anlarım?#

Sunucudan en az iki farklı sağlayıcının MX adresine nc -zv -w 8 hedef 25 ile bağlanmayı deneyin ve aynı komutu 587 için tekrarlayın. 25 her hedefte zaman aşımına düşerken 587 banner döndürüyorsa engel kesindir. Ek olarak yerel güvenlik duvarınızın OUTPUT kurallarını ve IPv6 yollarını da eleyin; ikisi de aynı görüntüyü üretebilir.

Relay kullanmak teslimat kalitemi düşürür mü?#

Genellikle tam tersini yapar. Yeni açılmış bir VDS'in IP'sinin hiçbir gönderim geçmişi yoktur ve alıcı sunucular geçmişi olmayan IP'lere temkinli davranır. Kurumsal bir relay sağlayıcısı ise ısıtılmış, izlenen ve kara listelerden uzak tutulan IP havuzları kullanır. Karşılığında SPF kaydınıza sağlayıcıyı eklemeniz ve gönderici adresini onların izin verdiği biçimde kullanmanız gerekir.

Portu açtırdım ama mailler hâlâ spam'e düşüyor#

Port engeli bir teslimat sorunu değil, bir bağlantı sorunudur; açılması yalnızca mesajın çıkabilmesini sağlar. Spam'e düşme ayrı bir konudur ve rDNS/PTR kaydı, SPF hizalaması, DKIM imzası, DMARC politikası ve IP itibarı ile ilgilidir. Bunların hepsi doğru olsa bile yeni bir IP'nin itibar kazanması günler alır; hacmi kademeli artırmak gerekir.

cPanel sunucumda aynı sorun varsa ne yapmalıyım?#

cPanel varsayılan olarak Postfix değil Exim kullanır; kuyruğu exim -bp ile görür, logu /var/log/exim_mainlog dosyasında okursunuz. Tanı adımları aynıdır: aynı nc testleriyle 25. portun kapalı olduğunu doğrulayın. Çözüm tarafında WHM üzerinden "Exim Configuration Manager" içindeki smarthost ayarı, Postfix'teki relayhost karşılığıdır.

Sadece bazı alıcılara gitmiyorsa yine port engeli midir?#

Hayır. Port engeli ayrım gözetmez; bütün hedeflere aynı şekilde vurur. Yalnızca belirli bir alan adına gitmiyorsa sorun büyük olasılıkla karşı tarafın filtresinde, kara listede ya da o alan adının MX kaydındadır. Bu durumda log satırındaki hata kodu 4xx/5xx biçiminde bir SMTP yanıtı içerir; Connection timed out yerine karşı sunucudan gelen açıklayıcı bir metin görürsünüz.