SMTP relay ve SMTP submission neden karıştırılır?
Şirketlerde “mail gönderimi” tek bir işlem gibi görünse de altyapı tarafında iki farklı kullanım modeli vardır: kullanıcıların e-posta istemcisiyle yaptığı gönderim (SMTP submission) ve bir sistemin başka bir sisteme e-posta aktarması (SMTP relay). Bu iki kavram günlük dilde çoğu zaman “SMTP” diye tek kelimeyle ifade edildiği için karışır. Oysa doğru seçilmediğinde güvenlik açıkları, spam riski, erişim sorunları ve teslim edilebilirlik problemleri oluşabilir.
Bu yazıda SMTP relay’in ne olduğunu, SMTP submission’dan farklarını, yaygın senaryoları ve işletmeler için güvenli yapılandırma prensiplerini ele alıyoruz. Amaç, hem IT ekiplerinin hem de teknik karar vericilerin “hangi gönderim türünü nerede kullanmalıyım?” sorusuna net cevap almasıdır.
Temel kavramlar: MUA, MSA, MTA nedir?
Kavramları oturtmak, doğru tasarımı kolaylaştırır. E-posta gönderim yolculuğunda genellikle üç rol öne çıkar:
- MUA (Mail User Agent): Outlook, Apple Mail, mobil uygulamalar gibi kullanıcı istemcileri.
- MSA (Mail Submission Agent): Kullanıcıdan e-postayı “kabul eden” ve kimlik doğrulayan katman. Genellikle submission portları üzerinden çalışır.
- MTA (Mail Transfer Agent): E-postayı sunucudan sunucuya aktaran transfer katmanı. Relay kavramı daha çok bu seviyededir.
Pratikte aynı mail sunucusu hem MSA hem MTA görevini üstlenebilir. Önemli olan, hangi port ve hangi kuralla hangi trafiğin kabul edildiğidir.
SMTP submission nedir?
SMTP submission, kullanıcıların veya kullanıcı adına çalışan istemcilerin (ör. telefon, e-posta uygulaması) e-posta göndermek için mail sunucusuna bağlandığı yöntemdir. Buradaki kritik nokta, submission trafiğinin “gönderim niyetiyle” geldiğinin varsayılması ve bu nedenle kimlik doğrulama ile politika kontrollerinin sıkı uygulanmasıdır.
Submission genellikle şu özelliklerle tanımlanır:
- Kimlik doğrulama (SMTP AUTH) beklenir.
- TLS ile şifreleme zorlanır ya da güçlü biçimde teşvik edilir.
- Gönderen adresi, kullanıcı/hesap yetkileriyle ilişkilendirilebilir (policy enforcement).
- Kullanıcı bazlı kota, hız limiti, anomali tespiti gibi kontroller uygulanabilir.
Özetle submission, “kullanıcıdan sunucuya” güvenli gönderim kapısıdır.
SMTP relay nedir?
SMTP relay, bir mail sunucusunun başka bir mail sunucusuna e-posta iletmesidir. Bu, internet üzerindeki standart e-posta akışının doğal parçasıdır. Ayrıca şirket içinde uygulamalar, yazıcılar, CRM sistemleri veya başka sunucular da bir “relay” üzerinden e-posta gönderebilir.
Relay’in tipik özellikleri şunlardır:
- Kimlik doğrulama her zaman zorunlu değildir; bunun yerine IP bazlı yetkilendirme veya ağ segmenti kısıtları kullanılabilir.
- Sunucudan sunucuya teslimatta TLS kullanılabilir, ancak her zaman garanti değildir; bu nedenle ek politikalar gerekebilir.
- Yanlış yapılandırılırsa “open relay” riskine yol açabilir ve spam kaynaklı ciddi itibar kaybı yaşanabilir.
Relay, “sunucudan sunucuya” taşıma hattıdır; güvenlik ve yetkilendirme modeli submission’dan farklı düşünülmelidir.
SMTP relay ve submission arasındaki kritik farklar
1) Kimlik doğrulama ve yetkilendirme modeli
Submission’da kimlik doğrulama neredeyse standarttır. Relay’de ise çoğu tasarım, belirli IP’lerin ya da ağların relay yapmasına izin verir. Uygulama sunucuları (web app, ERP) çoğu zaman kullanıcı adı/parola yerine IP allowlist ile çalıştırılır. Burada “en kolay” yaklaşım çoğu zaman “en riskli” yaklaşıma dönüşebilir; IP allowlist kullanılıyorsa ağ izolasyonu, güvenlik duvarı ve log izleme önem kazanır.
2) Portlar ve trafik türü
Submission trafiği çoğu ortamda ayrı portlarda tutulur. Böylece kullanıcı trafiği ile sunucudan sunucuya relay trafiği ayrışır; politika ve güvenlik kontrolleri daha net uygulanır. Relay trafiği ise çoğu zaman standart SMTP transfer portu üzerinden gerçekleşir. Bu ayrım, sorun giderirken de büyük kolaylık sağlar: “Kullanıcı gönderemiyor” ile “sunucular arası iletimde sorun var” farklı teşhis süreçleri gerektirir.
3) Teslim edilebilirlik (deliverability) etkisi
Submission tarafında hatalı kimlik bilgileri, kötü amaçlı oturum açma denemeleri veya ele geçirilmiş hesaplar, kısa sürede yüksek hacimli spam çıkışına neden olabilir. Relay tarafında ise open relay veya yanlış yetkilendirme, dışarıya kontrolsüz spam akıtabilir. Her iki durum da IP ve domain itibarını zedeleyerek meşru e-postaların spam klasörüne düşmesine yol açabilir.
4) Günlükleme (logging) ve izlenebilirlik
Submission’da “hangi kullanıcı hangi cihazdan ne gönderdi?” sorusuna cevap üretmek daha kolaydır. Relay senaryolarında ise kaynağı doğru etiketlemek için uygulama bazlı header ekleme, ayrı outbound IP kullanımı veya sistem hesabı bazlı kimlik doğrulama gibi yöntemler gerekebilir.
Hangi senaryoda hangisini kullanmalısınız?
Kullanıcılar (Outlook, telefon, masaüstü istemcisi)
Kural nettir: Kullanıcı istemcileri için submission kullanın. Çünkü kimlik doğrulama, TLS ve kullanıcı politikaları bu model için tasarlanmıştır. Kullanıcının evden, otelden veya mobil ağdan bağlandığı düşünülürse IP bazlı relay zaten pratik değildir.
Web sitesi iletişim formları ve uygulamalar
Uygulamalar iki şekilde e-posta gönderir: ya submission ile bir servis hesabı kullanır ya da ağ içinde bir relay noktasına bağlanır. Güvenlik açısından genellikle tercih edilen yaklaşım, uygulamaya özel bir hesapla kimlik doğrulamalı gönderim yapmaktır. IP allowlist ile relay yapılacaksa yalnızca gerekli sunuculara izin verilmesi, ağ segmentinin izole edilmesi ve rate limit uygulanması gerekir.
Yazıcılar, tarayıcılar, IoT cihazları
Bu cihazlar bazen modern TLS/kimlik doğrulama özelliklerini desteklemez. Bu durumda şirket içi ağda kısıtlı bir relay noktası oluşturulabilir. Ancak bu relay, internete açık “herkese” hizmet vermemeli; sadece belirli IP’lerden gelen trafiği kabul etmeli ve mümkünse sadece şirket alan adları için gönderime izin vermelidir.
Sunucudan sunucuya e-posta aktarımı
İnternet üzerindeki normal e-posta akışı relay mantığıyla çalışır. Burada temel hedef, doğru DNS ve kimlik doğrulama temeli (SPF/DKIM/DMARC) ile tutarlı bir çıkış politikası oluşturmaktır. Ayrıca TLS politikaları, kuyruk yönetimi ve geri dönüş kodlarının izlenmesi operasyonel kaliteyi belirler.
Güvenli yapılandırma için pratik kontrol listesi
Open relay riskini sıfırlayın
Relay yapılandırmasında en büyük risk, yetkisiz kaynakların sunucunuzu kullanarak dışarıya e-posta gönderebilmesidir. Bu, çok kısa sürede kara listeye girmeye kadar uzanabilir. Güvenli yaklaşım:
- Relay iznini yalnızca belirli IP’lerle veya kimliği doğrulanmış hesaplarla sınırlandırın.
- İç ağdan bile gelse, gönderim alan adlarını ve alıcı kapsamını politika ile sınırlamayı değerlendirin.
- Gereksiz portları kapatın, güvenlik duvarında kaynak/destinasyon kısıtları tanımlayın.
TLS kullanımını standartlaştırın
Submission tarafında TLS’i mümkün olduğunca zorunlu kılın. Relay tarafında ise “her zaman TLS olur” varsayımı gerçekçi olmayabilir; bu nedenle TLS’i teşvik eden ve raporlanabilir kılan bir yaklaşım tercih edilir. Hangi tarafın hangi düzeyde TLS sağladığını bilmek, risk yönetimi açısından önemlidir.
Rate limit ve anomali kontrolleri uygulayın
Ele geçirilmiş bir hesap veya hatalı yapılandırılmış bir uygulama, dakikalar içinde binlerce e-posta gönderebilir. Gönderim hız limiti, eşik uyarıları ve karantina benzeri kontroller; hem itibarınızı hem de operasyonel sürekliliği korur.
Gönderen adresi kontrolü yapın
Submission’da, kullanıcının “From” alanında farklı bir alan adı kullanmasını engellemek ya da en azından izlemek iyi bir pratiktir. Relay’de de uygulama veya cihazların, beklenmedik gönderen adresleriyle mail çıkarmasını önleyecek kurallar planlanmalıdır. Bu, DMARC uyumu ve marka bütünlüğü açısından da faydalıdır.
Logları anlamlı hale getirin
Sorun olduğunda hızlı teşhis için logların işe yarar olması gerekir. Öneriler:
- Uygulama kaynaklarını ayrı IP, ayrı kimlik veya ayrı etiketlerle ayrıştırın.
- Gönderim hatalarını (bounce) düzenli inceleyin ve tekrarlayan nedenleri giderin.
- Kimlik doğrulama hatalarını ve başarısız oturum açma denemelerini izleyin.
Yanlış seçimlerin tipik sonuçları
“Cihaz relay yapsın” deyip internetten açık bırakmak
En sık görülen hatalardan biridir. Bir yazıcı veya uygulama e-posta göndersin diye relay açılır, sonra bu servis internete açık kalır. Sonuç: istenmeyen gönderimler, itibar kaybı ve teslim edilebilirlik sorunları.
Kullanıcıları relay üzerinden göndermeye zorlamak
Bazı ortamlarda kullanıcılar 25 benzeri transfer mantığıyla göndermeye çalıştırılır. Bu, kimlik doğrulama, dolaşım kullanıcıları ve güvenlik politikaları açısından sorun çıkarır. Kullanıcılar için doğru model submission’dır.
Sonuç: doğru akışı seçmek, hem güvenliği hem teslimatı iyileştirir
SMTP submission, kullanıcı gönderimi için kimlik doğrulamalı ve politika kontrollü bir kapıdır. SMTP relay ise sunucudan sunucuya aktarımın ve bazı sistem entegrasyonlarının temelidir. İkisini doğru ayırmak; open relay riskini azaltır, izlenebilirliği artırır ve teslim edilebilirlik dalgalanmalarını önlemeye yardımcı olur.
MX1Mail gibi kurumsal e-posta altyapılarında da gönderim akışlarını planlarken kullanıcı gönderimi (submission) ile sistem/entegrasyon trafiğini (relay) ayrı düşünmek; port, yetkilendirme, TLS ve loglama kararlarını daha tutarlı hale getirir. Mevcut kurulumunuzu değerlendirirken ilk adım, hangi kaynakların hangi yöntemle mail gönderdiğini envanterlemek ve her birini uygun modele taşımaktır.