E-posta yapılandırması yaparken karşınıza üç port çıkar ve hangisini seçeceğiniz her zaman açık değildir. Yanlış seçim, çalışmayan bir gönderim veya güvenlik açığı anlamına gelir.
Bu yazı, e-posta gönderimi için port seçimini ve her birinin doğru kullanım alanını netleştiriyor.
Üç Port, Üç Amaç
| Port | Amaç | Şifreleme | Kimlik doğrulama |
|---|---|---|---|
| 25 | Sunucular arası aktarım | Fırsatçı (varsa) | Genellikle yok |
| 587 | İstemciden gönderim | STARTTLS | Zorunlu |
| 465 | İstemciden gönderim | Baştan TLS | Zorunlu |
Temel ayrım şudur: port 25 sunucular arasındadır, 587 ve 465 ise kullanıcı veya uygulama gönderimi içindir. Bu ayrımı karıştırmak, en yaygın yapılandırma hatasıdır.
Port 25: Neden Sizin İçin Değil?
Bu port, posta sunucularının birbirine ileti teslim ettiği kanaldır. Alıcı tarafındaki sunucu bu portu dinler ve dünyanın her yerinden gelen iletileri kabul eder.
Uygulamanızdan gönderim için bu portu kullanmamanızın nedenleri:
- İnternet servis sağlayıcıları genellikle engeller. Spam kaynağı olduğu için giden 25 numaralı port trafiği çoğu ağda kapalıdır.
- Bulut sağlayıcıları da kısıtlar. Sunucunuzdan çıkan bu trafik varsayılan olarak engellenmiş olabilir.
- Kimlik doğrulama beklenmez. Bu, gönderim için değil teslim alma için tasarlanmıştır.
- Şifreleme garanti değildir. Karşı sunucu desteklemiyorsa açık metin gönderim yapılabilir.
Uygulamanız e-posta gönderemiyorsa ve port 25 kullanıyorsa, sorun büyük ihtimalle budur: trafik ağ seviyesinde engellenmektedir. Çözüm, kimlik doğrulamalı bir gönderim portuna geçmektir.
587 mi 465 mi?
İkisi de aynı işi yapar: kimlik doğrulamalı, şifreli gönderim. Fark, şifrelemenin ne zaman başladığındadır.
Port 587 (STARTTLS): Bağlantı şifresiz başlar, ardından şifrelemeye yükseltilir. Standart olarak önerilen yöntemdir.
Port 465 (örtük TLS): Bağlantı ilk andan itibaren şifrelidir. Bir dönem kullanımdan kaldırılmış, sonra yeniden standartlaşmıştır.
Hangisini seçmeli? Pratik yaklaşım:
- Sağlayıcınız hangisini öneriyorsa onu kullanın. İkisi de güvenlidir.
- 465, yapılandırma hatasına karşı daha dayanıklıdır. Şifreleme baştan zorunlu olduğu için, yanlış ayar sonucu açık metin gönderim riski yoktur.
- 587 kullanıyorsanız TLS'i zorunlu kılın. İstemci ayarında "varsa şifrele" yerine "şifreleme zorunlu" seçeneğini işaretleyin.
Üçüncü madde kritik bir güvenlik ayrıntısıdır: STARTTLS, yükseltmeyi isteğe bağlı bırakabilir. Zorunlu kılınmazsa, bağlantı şifresiz devam edebilir ve kimlik bilgileriniz açık metin gider.
Kimlik Doğrulama Yöntemleri
Gönderim portlarında sunucu kim olduğunuzu doğrular. Yaygın yöntemler:
- Kullanıcı adı ve parola. En yaygın yöntem. Şifreli bağlantı üzerinde güvenlidir.
- API anahtarı. Gönderim servisleri genellikle parola yerine anahtar kullandırır. Kullanıcı hesabından bağımsızdır ve iptal edilebilir.
- IP tabanlı yetkilendirme. Belirli IP'lerden gelen bağlantılar parolasız kabul edilir. Sunucudan sunucuya gönderimde kullanılır.
İkinci seçenek uygulama gönderimlerinde tercih edilmelidir: bir API anahtarı sızarsa yalnızca onu iptal edersiniz. Kullanıcı parolası sızdığında ise posta kutusuna da erişim açılır.
Sık Yapılan Hatalar
Parolayı Kod İçine Yazmak
Gönderim kimlik bilgileri kaynak koda gömülmemelidir. Sürüm kontrolüne girdiğinde geçmişte kalır ve silinse bile okunabilir. Ortam değişkeni veya yapılandırma yönetimi kullanın.
Sertifika Doğrulamasını Kapatmak
Bağlantı hatası alındığında en sık başvurulan "çözüm" sertifika doğrulamasını devre dışı bırakmaktır. Bu, şifrelemenin sağladığı korumanın önemli kısmını ortadan kaldırır. Asıl sorun genellikle eksik bir kök sertifika listesidir.
Test ve Üretim İçin Aynı Kimlik Bilgisi
Test ortamından yanlışlıkla gerçek müşterilere e-posta gönderilmesi, sık yaşanan ve maliyetli bir kazadır. Ayrı kimlik bilgileri ve tercihen ayrı bir test hedefi kullanın.
Zaman Aşımı Ayarlamamak
Gönderim sunucusu yanıt vermediğinde uygulamanız sonsuza kadar bekleyebilir. Bu, web isteklerini kilitler. Makul bir zaman aşımı tanımlayın ve gönderimi mümkünse arka plana alın.
Doğru Mimari
Uygulamanızın doğrudan alıcı sunuculara gönderim yapması yerine, kimlik doğrulamalı bir gönderim sunucusuna teslim etmesi tercih edilir. Bu yapının faydaları:
- Kuyruk yönetimi ve yeniden deneme merkezi olarak yapılır
- Kimlik doğrulama ve imzalama tek yerde yapılandırılır
- Gönderim IP itibarı yönetilebilir
- Teslimat raporları tek noktadan izlenir
Bu nedenle uygulama gönderimlerinde smarthost yapısı kullanmak, hem güvenlik hem teslimat açısından doğrudan gönderime göre belirgin avantaj sağlar.
Sonuç
Port seçiminde tek kural yeterlidir: port 25 sunucular arasındadır, uygulamanız 587 veya 465 kullanmalıdır. Uygulamanız e-posta gönderemiyorsa ve 25 kullanıyorsa, sorun büyük ihtimalle ağ seviyesindeki engellemedir. 587 ve 465 arasında güvenlik farkı yoktur, ancak 587 kullanıyorsanız TLS'i zorunlu kılmayı unutmayın — isteğe bağlı bırakıldığında bağlantı şifresiz devam edebilir. Ve kimlik doğrulamada mümkünse parola yerine iptal edilebilir bir API anahtarı kullanın.
Sıkça Sorulan Sorular (SSS)
Uygulamam port 25'ten e-posta gönderemiyor, neden?
Bu portun giden trafiği çoğu internet servis sağlayıcısı ve bulut sağlayıcısı tarafından engellenir — spam kaynağı olduğu için. Çözüm, kimlik doğrulamalı bir gönderim portuna (587 veya 465) geçmektir.
587 mi 465 mi kullanmalıyım?
İkisi de güvenlidir; sağlayıcınızın önerdiğini kullanın. 465 şifrelemeyi baştan zorunlu kıldığı için yapılandırma hatasına karşı biraz daha dayanıklıdır. 587 kullanıyorsanız istemci ayarında TLS'i zorunlu hâle getirin.
Sertifika hatası alıyorum, doğrulamayı kapatabilir miyim?
Kapatmayın — şifrelemenin sağladığı korumanın önemli kısmını ortadan kaldırır. Sorun genellikle sisteminizdeki kök sertifika listesinin eksik veya eski olmasıdır. Önce onu güncelleyin.
Parola mı API anahtarı mı kullanmalıyım?
Uygulama gönderimlerinde API anahtarı tercih edilmelidir. Sızması hâlinde yalnızca o anahtarı iptal edersiniz; kullanıcı parolası sızdığında ise posta kutusuna erişim de açılmış olur. Her iki durumda da kimlik bilgisini kaynak koda gömmeyin.
