SMTP submission ne demektir?
Şirket e-postalarında “SMTP” genellikle iki farklı işi ifade eder: Sunucuların birbirine e-posta teslim ettiği SMTP trafiği ve kullanıcıların (Outlook, telefon, uygulama, CRM, yazıcı, web sitesi formu gibi) e-posta göndermek için sunucuya bağlandığı “submission” trafiği. SMTP submission, bir kullanıcının veya uygulamanın kimlik doğrulama yaparak (kullanıcı adı/parola gibi) e-posta göndermesidir. Bu ayrım önemlidir çünkü submission tarafında güvenlik beklentileri daha yüksektir: Kimlik doğrulama zorunluluğu, şifreli bağlantı kullanımı ve kötüye kullanımın engellenmesi gibi.
Birçok teslim edilebilirlik ve güvenlik sorununun kökü, kullanıcıların yanlış porta bağlanması, TLS’in doğru başlatılamaması veya sunucunun “açık relay” gibi riskli bir şekilde yapılandırılmasıdır. Bu nedenle 587 ve 465 portlarının ne işe yaradığını netleştirmek, hem IT ekipleri hem de profesyonel e-posta kullanıcıları için kalıcı bir kazanımdır.
Port 587 ve port 465: Temel fark nedir?
Port 587, modern e-posta mimarisinde SMTP submission için önerilen standart porttur. Bu portta bağlantı genellikle düz başlar ve ardından STARTTLS komutuyla TLS’e yükseltilir. Port 465 ise “implicit TLS” yaklaşımıyla çalışır: Bağlantı en baştan itibaren TLS ile şifreli olarak kurulur. İkisi de pratikte güvenli gönderim amacıyla kullanılır; ancak davranış biçimleri ve uyumluluk detayları farklıdır.
Port 587 (Submission + STARTTLS)
- Kullanım amacı: İstemciden sunucuya kimlik doğrulamalı e-posta gönderimi.
- Şifreleme modeli: Bağlantı kurulur, ardından STARTTLS ile şifreleme başlatılır.
- Avantajı: Standart ve yaygın; kurumsal politikalarda “TLS zorunlu” kuralı kolay uygulanır.
- Dikkat edilmesi gereken: İstemci STARTTLS’i desteklemeli ve “TLS kullan” seçeneği doğru işaretlenmelidir.
Port 465 (SMTPS + Implicit TLS)
- Kullanım amacı: İstemciden sunucuya şifreli e-posta gönderimi (pratikte submission).
- Şifreleme modeli: TLS, bağlantının ilk anından itibaren aktiftir.
- Avantajı: Bazı ağlarda STARTTLS engellenebildiğinde veya istemci davranışları tutarsız olduğunda daha “net” bir TLS kurulumu sağlayabilir.
- Dikkat edilmesi gereken: İstemcide genellikle “SSL/TLS” seçilmelidir; “STARTTLS” seçilirse bağlantı başarısız olabilir.
Neden doğru port seçimi şirketler için kritiktir?
Yanlış port veya yanlış TLS seçimi sadece bağlantı hatası üretmez; bazen daha sinsi sonuçlar doğurur. Örneğin kullanıcı, e-posta göndermeyi başaramadığı için webmail dışına çıkar, farklı ve kontrolsüz bir yöntemle (kişisel e-posta, üçüncü taraf uygulama) iş akışını sürdürmeye çalışır. Bu da veri yönetimi, denetim ve kurumsal iletişim açısından risk yaratabilir.
Ayrıca yanlış yapılandırılmış gönderim, sunucunun kimlik doğrulama olmadan iletim yapmasına (açık relay) yol açacak şekilde hatalı kural/port kullanımını tetikleyebilir. Açık relay doğrudan spam suistimaline, IP itibarının düşmesine ve e-postaların spam’e düşmesine kadar uzanan zincirleme etkiler yaratabilir.
Hangi senaryoda 587, hangi senaryoda 465 tercih edilmeli?
Genel kural olarak, kurumsal istemci gönderimlerinde önce 587 tercih edilir. 587 hem dokümantasyonlarda hem de modern istemcilerde “submission” seçeneği olarak beklenen yaklaşımdır. 465 ise özellikle bazı eski istemcilerde veya ağ koşullarında daha sorunsuz çalıştığı için ikinci seçenek olarak değerlendirilebilir.
587’yi tercih edin (önerilen)
- Outlook, Apple Mail, Thunderbird gibi modern istemciler kullanılıyorsa
- Mobil cihazlarda “STARTTLS/TLS” seçenekleri net bir şekilde sunuluyorsa
- Şirket içinde standardizasyon hedefleniyorsa (tek doküman, tek ayar)
- Kimlik doğrulama ve TLS kullanımını politika haline getirmek isteniyorsa
465’i değerlendirin
- İstemci veya cihaz STARTTLS ile sorun çıkarıyor ve bağlantı kararsızsa
- Bazı ağlarda STARTTLS pazarlığı (upgrade) kesintiye uğruyorsa
- Uygulama yalnızca “SSL/TLS” seçeneğiyle port 465’te düzgün çalışıyorsa
En sık yapılan yanlışlar (ve sonuçları)
1) Yanlış TLS seçimi
587 kullanırken istemcide “SSL/TLS” seçmek bazen bağlantının kurulamamasına neden olur; 587’de çoğu kurulum “STARTTLS” veya “TLS (STARTTLS)” şeklindedir. 465’te ise tam tersi görülür: “SSL/TLS” gerekir, STARTTLS seçilirse hatayla karşılaşılır.
2) Kimlik doğrulamasını kapalı bırakmak
Submission portları için kimlik doğrulama neredeyse her zaman zorunludur. “Sunucum kimlik doğrulaması gerektiriyor” benzeri seçenek kapalı kalırsa, sunucu gönderimi reddedebilir veya istemci sürekli parola sorarak kullanıcı deneyimini bozar.
3) Gönderen adresi ile oturum açma hesabının uyumsuzluğu
Birçok sistem, güvenlik ve suistimali önlemek için “From” adresinin, oturum açan hesapla veya izinli alias/dağıtım kurgusuyla uyumlu olmasını bekler. Kullanıcı farklı bir gönderici adresi seçtiğinde gönderim reddedilebilir veya alıcı tarafında güven sinyalleri zayıflayabilir.
4) Ağ güvenlik cihazlarında yanlış kural
Şirket ağında outbound kurallarında 587/465 engellenmiş olabilir. Kullanıcılar bu durumda rastgele portlara yönelir ya da geçici çözümler üretir. IT ekipleri için doğru yaklaşım, hangi portların izinli olduğunu netleştirmek ve bunu uç kullanıcı dokümanına yansıtmaktır.
Doğru istemci ayarı için pratik kontrol listesi
Aşağıdaki kontrol listesi, istemciden bağımsız olarak doğru submission kurgusunu doğrulamanıza yardımcı olur:
- Sunucu adı: Sağlayıcınızın verdiği SMTP sunucu adını kullanın (ör. mail alan adınız veya sağlanan host adı).
- Port: Öncelik 587; gerekirse 465.
- Şifreleme: 587 için STARTTLS/TLS; 465 için SSL/TLS (implicit).
- Kimlik doğrulama: Açık olmalı. Kullanıcı adı genellikle tam e-posta adresidir.
- Parola: Güncel ve doğru. Parola değiştiyse tüm cihazlarda güncelleyin.
- Gönderen adresi: Kullanıcının yetkili olduğu adres/alias ile gönderin.
- Test: Şirket dışı bir adrese deneme gönderimi yapın ve gecikme/bounce var mı kontrol edin.
Teslim edilebilirlik açısından port seçimi bir “sihirli çözüm” değildir
587 veya 465 kullanmak, tek başına e-postaların inbox’a düşeceği anlamına gelmez. Teslim edilebilirlik daha geniş bir resimdir: SPF/DKIM/DMARC doğrulaması, alan adı ve IP itibarı, içerik kalitesi, gönderim hacmi ve alıcıların etkileşimi gibi faktörler rol oynar. Ancak doğru submission yapılandırması, en temel noktayı sağlar: Gönderimin güvenli, kimliği doğrulanmış ve tutarlı şekilde yapılması.
Uygulamalar ve cihazlar için özel notlar
Çok fonksiyonlu yazıcılar ve eski cihazlar
Yazıcı, tarayıcı veya eski uygulamalar bazen STARTTLS’i desteklemez. Böyle bir durumda 465 ile implicit TLS destekleniyorsa tercih edilebilir. Hiç TLS desteklemeyen cihazlarda ise IT ekipleri, riskleri değerlendirerek ayrı bir çözüm tasarlamalı (örneğin güvenli bir iç aktarıcı üzerinden gönderim) ve cihazı internetten doğrudan çıkarmamayı düşünmelidir.
Web siteleri ve uygulamalar
Bir web sitesi formu, uygulama sunucusu veya CRM entegrasyonu üzerinden e-posta gönderirken de aynı prensip geçerlidir: Kimlik doğrulamalı submission ve TLS. Uygulama tarafında hata günlükleri (log) incelenmeli; “TLS handshake failed”, “authentication failed” gibi hatalar genellikle port/şifreleme uyumsuzluğunu işaret eder.
Sonuç: Standartlaştırın, dokümante edin, düzenli test edin
Kurumsal e-posta operasyonlarında küçük görünen istemci ayarları, büyük destek yükü ve güvenlik riski doğurabilir. En iyi yaklaşım; şirket içinde 587 + STARTTLS’yi varsayılan olarak standardize etmek, 465’i uyumluluk alternatifi olarak tanımlamak, kimlik doğrulama ve TLS’i zorunlu kılmak ve değişikliklerden sonra düzenli gönderim testleri yapmaktır.
MX1Mail gibi profesyonel bir iş e-posta platformuna geçerken veya mevcut kurulumunuzu iyileştirirken, kullanıcı dokümanlarınızı bu port/şifreleme mantığıyla güncellemek; helpdesk taleplerini azaltır, gönderim sorunlarını hızla teşhis etmenizi sağlar ve güvenli gönderim alışkanlığını kurum geneline yayar.