SMTP (Simple Mail Transfer Protocol), e-postaların bir sunucudan diğerine iletilmesini sağlayan standart protokoldür (RFC 5321). Bir mektubu postaya verdiğinizde onu toplayan, aktaran ve adresine ulaştıran posta ağının dijital karşılığıdır: uygulamanızın veya e-posta istemcinizin bir maili "teslim etmek üzere sisteme sokması" ve o mailin alıcının posta sunucusuna kadar taşınması hep SMTP ile olur. Bu yazıda SMTP'nin nasıl çalıştığını, 25, 587 ve 465 portları arasındaki farkı, STARTTLS ile implicit TLS ayrımını ve SASL kimlik doğrulamasını açıklıyoruz.
E-posta nasıl iletilir? Submission → Relay → Teslim
Bir mailin yolculuğu üç aşamada özetlenebilir:
- Submission (gönderim): İstemciniz ya da uygulamanız maili kendi çıkış sunucunuza (submission/relay sunucusu) teslim eder. Bu aşama kimlik doğrulama gerektirir ve standardı RFC 6409'dur.
- Relay (aktarım): Çıkış sunucusu, alıcının alan adının MX kaydına bakarak alıcının posta sunucusunu bulur ve maili sunucudan sunucuya aktarır.
- Teslim: Alıcının sunucusu maili kabul eder, spam ve kimlik doğrulama kontrollerinden geçirip alıcının gelen kutusuna (veya spam klasörüne) koyar. Alıcı maili okurken artık IMAP/POP3 gibi başka protokoller devreye girer; okuma SMTP'nin işi değildir.
Buradaki kritik ayrım şudur: submission sizin uygulamanızın kimlik doğrulayarak mail sisteme soktuğu adımdır; relay/transfer ise sunucular arası aktarımdır. Portlar da tam olarak bu ayrıma göre kullanılır.
25, 587 ve 465 portları arasındaki fark
| Port | Kullanım | Şifreleme | Kimlik doğrulama | Öneri |
|---|---|---|---|---|
| 25 | Sunucular arası aktarım (MTA→MTA) | Fırsatçı (STARTTLS varsa) | Genelde yok | Uygulama gönderimi için kullanmayın |
| 587 | Mesaj gönderimi (submission) | STARTTLS ile TLS'e yükseltilir | Zorunlu (SASL) | Önerilen |
| 465 | Mesaj gönderimi (submission) | Implicit TLS (baştan şifreli) | Zorunlu (SASL) | Önerilen alternatif |
Port 25 — sunucular arası aktarım
Port 25, SMTP'nin orijinal portudur ve posta sunucularının birbirine mail aktardığı (MX'e teslim) kanaldır. Sorun şu ki bu port yıllarca virüslü makinelerin doğrudan spam göndermesi için kötüye kullanıldı. Bu yüzden çoğu ISP, hosting ve bulut sağlayıcı giden 25 portunu kapatır. Kendi uygulamanızdan doğrudan 25 ile mail göndermeye çalışmak hem çoğunlukla engellenir hem de teslim edilebilirlik açısından zayıftır.
Port 587 — önerilen gönderim portu
Port 587, RFC 6409'da tanımlanan message submission portudur ve uygulamalar ile e-posta istemcileri için doğru adrestir. Bağlantı düz (şifresiz) başlar, ardından STARTTLS komutuyla aynı bağlantı TLS'e yükseltilir. Kimlik doğrulama zorunludur; bu yüzden yalnızca yetkili göndericiler mail sokabilir.
Port 465 — implicit TLS
Port 465, bağlantının ilk saniyesinden itibaren TLS ile şifreli olduğu (implicit TLS / SMTPS) gönderim portudur. Modern kullanımı RFC 8314 ile yeniden önerilir hale geldi. 587 ile işlevsel olarak aynı amaca hizmet eder; fark yalnızca şifrelemenin nasıl başladığındadır.
STARTTLS vs. implicit TLS
İkisi de bağlantıyı şifreler, ama farklı yoldan:
- STARTTLS (587): Bağlantı düz metin başlar, istemci
STARTTLSkomutunu verir ve bağlantı TLS'e yükseltilir. Bu "fırsatçı" yaklaşım, doğru yapılandırılmadığında teorik olarak downgrade saldırılarına açık olabilir; bu nedenle istemcinin TLS'i zorunlu kılması önemlidir. - Implicit TLS (465): El sıkışma daha ilk anda TLS ile başlar; düz metin bir aşama hiç yaşanmaz. Bu nedenle bazı senaryolarda daha güvenli kabul edilir.
Pratikte her iki port da TLS ile şifrelenir ve modern hizmetlerde güvenle kullanılır. SenderTR SMTP relay'i 587 portunda STARTTLS ile, geçerli TLS sertifikasıyla sunar; 465 (implicit TLS) açık değildir. Hemen her SMTP kütüphanesi 587 + STARTTLS'i destekler.
SASL kimlik doğrulama
Submission portlarında (587/465) mail sokabilmek için kimliğinizi kanıtlamanız gerekir. Bu, SASL çerçevesi üzerinden yapılır; en yaygın mekanizmalar AUTH LOGIN ve AUTH PLAIN'dir ve bir kullanıcı adı/şifre çifti kullanır. Kimlik bilgileri düz metin taşınabildiği için SASL her zaman TLS altında kullanılmalıdır; 587'de STARTTLS sonrası, 465'te baştan itibaren. Bu doğrulama, gönderim yetkisini yalnızca sizin hesabınıza bağlar ve itibarınızı korur.
Relay vs. doğrudan gönderim
Uygulamanızın her alıcının sunucusuna doğrudan 25 ile bağlanmaya çalışması (doğrudan gönderim) hem 25 kapalı olduğu için genelde imkânsız hem de SPF/DKIM, IP itibarı ve tekrar deneme yönetimi açısından son derece kırılgandır. Bunun yerine bir SMTP relay hizmeti kullanılır: uygulamanız 587/465 ile relay'e teslim eder, teslimatın zor kısmını (MX çözümleme, TLS, itibar, tekrar deneme, bounce işleme) relay üstlenir. Transactional e-posta için SMTP relay ve HTTP API yazımızda iki entegrasyon yöntemini karşılaştırıyoruz.
Bir uygulamayı SMTP ile bağlama adımları
- Sunucu ve portu girin: SMTP host adresini ve portu (önerilen: 587) uygulamanızın mail ayarlarına yazın.
- Şifrelemeyi seçin: 587 için STARTTLS/TLS, 465 için SSL/implicit TLS seçeneğini işaretleyin.
- Kimlik bilgilerini girin: Hizmetin verdiği SASL kullanıcı adı ve şifresini ekleyin.
- Gönderen adresini ayarlayın: From adresini, kimlik doğrulaması yapacağınız kendi alan adınızla uyumlu belirleyin.
- Kimlik doğrulama kayıtlarını kurun: Alan adınız için DKIM ve DMARC kayıtlarını ekleyin; teslim edilebilirliğin şartıdır. SPF isteğe bağlıdır: SenderTR'de Return-Path bizim alan adımızdadır ve SPF orada geçer.
- Test gönderin ve doğrulayın: Deneme maili gönderip başlıkları inceleyin, TLS'in aktif ve kimlik doğrulamanın "pass" olduğunu görün.
SMTP'yi doğru portla, TLS ile şifreleyerek ve SASL ile doğrulayarak kullanmak, hem güvenliğin hem de teslim edilebilirliğin temelidir. SenderTR, SMTP relay'ini port 587 (STARTTLS) üzerinden geçerli TLS sertifikası ve SASL kimlik doğrulamasıyla sunar; 465 açık değildir. Platform SPF/DKIM/DMARC doğrulaması, otomatik warmup, gerçek zamanlı bounce geri-beslemesi ve otomatik suppression ile birlikte, verileriniz Türkiye'de barınırken maillerinizin gelen kutusuna güvenle ulaşmasını sağlar.
Gönderen ve yanıt adreslerini ayırt edin
Bir e-postada görünen gönderen adresi, alıcının mesaj üzerinde gördüğü adrestir. Yanıt adresi ise alıcı yanıtla seçeneğini kullandığında cevabın yönlendirileceği adrestir. Bu adresler aynı olabilir; ancak yanıtları farklı bir posta kutusunda toplamak istiyorsanız ayrı belirleyebilirsiniz. Örneğin bildirim gönderen bir uygulama, yanıtları müşteri destek ekibinin izlediği adrese yönlendirebilir. Böyle bir tercih yapmadan önce o posta kutusunun gerçekten takip edildiğinden emin olun.
Mesajın bir de aktarım sırasında kullanılan zarf göndericisi vardır. Teslim edilemeyen iletilere ilişkin hata bildirimleri bu adresle ilişkilendirilebilir. Görünen göndereni değiştirmek, zarf göndericisini kendiliğinden değiştirmez; gönderim hizmetinizin bu adresleri nasıl işlediğini inceleyin. Deneme iletisinde görünen göndereni ve yanıt adresini ayrı ayrı kontrol edin. Ardından alıcı olarak iletiye yanıt verip cevabın beklediğiniz posta kutusuna ulaşıp ulaşmadığına bakın.
Gönderim hatasını nerede arayacağınızı belirleyin
Bir gönderim başarısız olduğunda yalnızca uygulamanın genel hata iletisine bakmayın. Önce uygulama kaydı ile posta sunucusunun verdiği yanıtı karşılaştırın. Bağlantı hiç kurulmadıysa sunucu adresinin yazımını, ağ erişimini ve seçilen portu inceleyin. Bağlantı kurulup şifreleme aşamasında kesildiyse uygulamanın seçtiğiniz bağlantı türünü desteklediğini ve sertifika hatası bildirip bildirmediğini kontrol edin.
Kimlik doğrulama reddedildiyse kullanıcı adını, parolanın güncelliğini ve uygulamanın kullandığı ayarları gözden geçirin. Sunucu mesajı kabul etmediyse yanıt metninde gönderen adresine veya alıcıya ilişkin bir kısıtlama olup olmadığını araştırın. Geçici bir hata ile kalıcı ret aynı şekilde ele alınmamalıdır: geçici sorunda daha sonra yeniden denemek anlamlı olabilir; kalıcı rette ise önce belirtilen nedeni düzeltmek gerekir. Aynı iletiyi denetimsiz biçimde tekrar göndermek, sorunun kaynağını bulmayı zorlaştırabilir.
SMTP kimlik bilgilerini uygulamada koruyun
Gönderim için kullanılan kullanıcı adı ve parolayı uygulamanın kaynak koduna yazmak yerine erişimi sınırlandırılmış yapılandırma alanlarında saklayın. Kodun paylaşıldığı veya yedeklendiği her yerde bu bilgilerin de görünür hale gelmesini önlemek için dağıtım sürecini gözden geçirin. Geliştirme ortamında kullanılan bilgileri gerçek gönderim ortamındakilerden ayrı yönetmek de yanlışlıkla gerçek hesaptan deneme iletisi gönderilmesi riskini azaltır.
Hata ayıklarken bağlantı kayıtları yararlı olsa da parolaların ve ileti içeriklerinin kayıtlara açık biçimde yazılmadığını kontrol edin. Bir kimlik bilgisinin açığa çıktığından şüpheleniyorsanız parolayı değiştirin ve uygulamanın kullandığı kayıtlı bilgiyi de güncelleyin. Değişiklikten sonra yalnızca ayar ekranına bakmakla yetinmeyin; deneme iletisi göndererek uygulamanın yeni bilgiyle bağlanabildiğini doğrulayın.