SMTP mi API mi: Mail Gönderim Yöntemi Seçimi

Uygulamandan mail göndereceksin ve önünde iki yol var: klasik SMTP bağlantısı açıp mesajı protokol üzerinden teslim etmek, ya da sağlayıcının HTTP API'sine bir JSON gövdesi POST etmek. Bu seçim genelde "hangisi daha kolay" diye sorulur ve cevap kütüphaneye bakılarak verilir. Oysa SMTP mi API mi sorusunun gerçek karşılığı; gecikme bütçen, hata durumunda ne kadar bilgi almak istediğin, kimlik bilgilerini nasıl yönettiğin ve sağlayıcı değiştirmenin sana ne kadara mal olacağıdır.

Bu yazıda iki yöntemi altı somut eksende karşılaştıracağım: bağlantı maliyeti ve gecikme, hata geri bildirimlerinin kalitesi, güvenlik ve kimlik bilgisi yönetimi, ağ ve güvenlik duvarı kısıtları, taşınabilirlik ve son olarak ölçeklenme davranışı. Her iki yöntemin çalışan örneklerini göstereceğim, sonunda da "şu durumdaysan şunu seç" diyen bir karar tablosu bırakacağım. Amaç bir tarafı savunmak değil; ikisinin de nerede kazandığını netleştirmek.

İki Yöntem Temelde Ne Yapıyor#

SMTP, mesaj teslimatı için tasarlanmış bir protokoldür ve konuşma tabanlıdır: bağlanırsın, karşı taraf kendini tanıtır, sen kendini tanıtırsın, şifreleme açarsın, kimlik doğrularsın, göndereni bildirirsin, alıcıyı bildirirsin, gövdeyi yazarsın ve kapatırsın. Her adım ayrı bir gidiş-dönüştür. Ham hâliyle bir SMTP oturumu şuna benzer:

# Bağlantıyı aç ve STARTTLS ile şifrele
openssl s_client -connect smtp.firmaniz.com:587 -starttls smtp

# Sonra elle konuşabilirsin:
EHLO istemci.firmaniz.com
AUTH LOGIN
# (base64 kullanıcı adı ve parola)
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: Test
From: [email protected]
To: [email protected]

Mesaj govdesi burada.
.
QUIT

HTTP API tarafında ise bu konuşmanın tamamı tek bir istekte özetlenir. Sağlayıcı sana bir uç nokta ve bir anahtar verir; sen mesajı yapılandırılmış bir gövdeyle gönderirsin, karşılığında bir kimlik alırsın:

# Genel şablon: sağlayıcının uç noktası ve alan adları değişir
curl -X POST https://api.saglayici.com/v1/mail/send \
  -H "Authorization: Bearer $MAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "from": "[email protected]",
        "to": ["[email protected]"],
        "subject": "Test",
        "text": "Mesaj govdesi burada.",
        "html": "<p>Mesaj govdesi burada.</p>"
      }'

# Tipik cevap:
# {"id":"msg_01H8XQ","status":"queued"}

Aradaki fark yalnızca sözdizimi değil. SMTP'de mesajı sen kurarsın (başlıklar, MIME sınırları, kodlama); API'de bu işi sağlayıcı üstlenir. SMTP'de teslimat sonucunu oturumun kendisinden öğrenirsin; API'de bir kimlik alır, sonucu webhook ya da sorgu ile öğrenirsin.

SMTP ile Gönderim: Güçlü ve Zayıf Yanları#

SMTP'nin en büyük kozu evrenselliğidir. Yazdığın kod bir standardı konuşur; sağlayıcıyı değiştirmek istediğinde tek yapman gereken sunucu adresini, kullanıcı adını ve parolayı değiştirmektir. Uygulama kodunda tek satır değişmez. Bu taşınabilirlik, uzun ömürlü sistemlerde küçümsenmeyecek bir sigortadır: bugün seçtiğin sağlayıcı iki yıl sonra fiyatını üçe katlarsa, göç etmek bir yapılandırma değişikliğinden ibaret olur.

İkinci avantajı, aradaki her katmanın SMTP'yi anlamasıdır. Sunucunda çalışan Postfix, mesajı kuyruğa alır, geçici hatalarda kendi başına yeniden dener, log tutar ve teslim edemezse sana bounce mesajı üretir. Yani uygulaman "yerel SMTP'ye teslim ettim" dediği anda, arkasında olgun bir kuyruk yönetimi devralır. Bu mimariyi kurmak için SMTP relay kurulumu yazısındaki relayhost yapılandırması yeterlidir.

Zayıf yanları da net. Birincisi gidiş-dönüş sayısı: her oturum en az beş-altı tur atar ve TLS el sıkışması da eklenince yüksek gecikmeli ağlarda mail başına yüzlerce milisaniye harcanabilir. İkincisi ağ kısıtları: bulut sağlayıcılarının çoğu 25. portu kapatır, kurumsal güvenlik duvarları 587'yi de kısıtlayabilir. Üçüncüsü kimlik bilgisi: SMTP kullanıcı adı ve parolası, kapsamı daraltılamayan bir kimliktir; sızarsa gönderim yetkisinin tamamı gider. Dördüncüsü geri bildirim: SMTP oturumu sana yalnızca "kuyruğa alındı" bilgisini verir; açılma, tıklama ya da yumuşak bounce ayrıntısı protokolde yoktur.

HTTP API ile Gönderim: Ne Kazandırır#

API'nin ilk kazancı tek gidiş-dönüştür. HTTPS bağlantısı zaten havuzlanabilir ve modern istemciler bağlantıyı yeniden kullanır; yüksek hacimli gönderimde bu, SMTP'nin çok turlu konuşmasına göre gözle görülür bir hız farkı yaratır. Ayrıca çoğu API toplu gönderim destekler: tek istekte yüzlerce alıcıya kişiselleştirilmiş mesaj kuyruğa alınabilir.

İkinci kazanç zengin geri bildirimdir. API sana mesaj kimliği verir ve o kimlik üzerinden yaşam döngüsünü izlersin: kuyruğa alındı, teslim edildi, açıldı, bağlantıya tıklandı, geri döndü, şikâyet edildi. Bu olaylar webhook ile uygulamana anlık iletilebilir; böylece geçersiz adresleri otomatik pasife çekebilir, teslimat sorunlarını dakikalar içinde fark edebilirsin. SMTP tarafında bunu kurmak için bounce kutusu okuyan ayrı bir mekanizma yazman gerekir.

Üçüncü kazanç kimlik bilgisi yönetimidir. API anahtarları genellikle kapsamlıdır: yalnızca gönderim yapabilen, yalnızca belirli alan adı adına yazabilen, IP kısıtı olan anahtarlar üretebilirsin. Sızıntı durumunda tek anahtarı iptal edersin, diğerleri çalışmaya devam eder. Anahtar rotasyonu da parola değişikliğinden çok daha az risklidir.

Bedeli ise bağımlılıktır. Yazdığın kod artık bir standardı değil, belirli bir sağlayıcının şemasını konuşur. Sağlayıcı değiştirmek, gönderim katmanını yeniden yazmak demektir. Bu riski azaltmanın yolu, uygulamanın içine ince bir soyutlama katmanı koymaktır: kodun kendi MailGonderici arayüzünü çağırsın, o arayüzün arkasında ister SMTP ister API sürücüsü dursun.

Performans, Hata Yönetimi ve Güvenlik Karşılaştırması#

Üç ekseni tek tabloda toplayalım; kararın çoğu bu tabloda saklı:

Hata yönetimi tarafında ayrım özellikle keskindir. SMTP'de aldığın cevap üç haneli bir koddur ve sınıflandırmayı sen yaparsın: 4xx geçici, 5xx kalıcı. API'de ise HTTP durum kodu ile mesaj durumu iki ayrı katmandır — istek 202 Accepted dönebilir ama mesaj daha sonra bounce edebilir. Bu yüzden API kullanırken HTTP cevabını teslimat kanıtı sanma; asıl bilgi webhook'tan gelir. Bu ayrımı kaçıran ekiplerin en sık yaşadığı sorun, gönderilmiş sanılan ama hiç teslim edilmemiş maillerdir.

Güvenlik tarafında ise iki yöntem de doğru kullanıldığında güvenlidir ama yanlış kullanımları farklıdır. SMTP'de klasik hata, TLS'i zorunlu kılmadan kimlik doğrulaması yapmaktır — parola ağ üzerinde açık gider. Bunu engellemek için istemcide smtp_tls_security_level = encrypt gibi bir zorunluluk ayarlaman, sunucu tarafında da TLS'i doğru kurman gerekir; adımları Postfix'e Let's Encrypt TLS sertifikası kurma yazısında bulabilirsin. API'de klasik hata ise anahtarı kaynak koda gömmektir; anahtar mutlaka ortam değişkeninde ya da bir sır yönetim sisteminde durmalıdır.

Ağ Kısıtları ve Ölçeklenme Davranışı#

Pratikte kararı en çok etkileyen faktör çoğu zaman ne performans ne de estetiktir: hangi port açık? Bulut sağlayıcılarının önemli bir kısmı yeni hesaplarda 25. portu varsayılan olarak kapatır, bazıları 587'yi de kısıtlar. Kurumsal ağlarda giden SMTP trafiği genelde tek bir çıkış noktasına zorlanır. Buna karşılık 443 portu her yerde açıktır ve TLS trafiği içinde kaybolur. Uygulaman kısıtlı bir ağda çalışacaksa API bu yüzden tek başına haklı çıkabilir.

Ölçeklenme tarafında ise iki yöntem farklı yerlerde tıkanır. SMTP'de darboğaz eşzamanlı bağlantı sayısıdır; sağlayıcılar oturum başına ve saat başına sınır koyar, bağlantı havuzunu doğru yönetmezsen 421 too many connections ile karşılaşırsın. API'de darboğaz istek hız sınırıdır (rate limit) ve genelde 429 Too Many Requests ile bildirilir. Her iki durumda da doğru davranış aynıdır: üstel artan gecikmeyle yeniden denemek. Uygulaman ne kadar mail göndereceğini ve bunun bant genişliğine etkisini kabaca görmek istersen bant genişliği hesaplayıcı aracıyla ek dosya boyutu × gönderim adedi hesabını yapabilirsin.

Karar Tablosu ve Hibrit Yaklaşım#

Yıllardır aynı soruya verdiğim cevapları özetleyeyim. Kendini hangi satırda buluyorsan, o satırın önerisiyle başla:

Son satırdaki hibrit yaklaşım en sık önerdiğim modeldir ve şöyle kurulur: uygulaman kendi soyut arayüzünü çağırır, arayüzün arkasında hem SMTP hem API sürücüsü bulunur. Birincil kanal başarısız olursa ikincil kanala düşer. Böylece hem sağlayıcı kesintisine karşı dayanıklı olursun hem de bir gün göç etmen gerektiğinde kodun tamamını değil tek sürücüyü değiştirirsin. Bu ayrımı işlemsel ve pazarlama trafiği arasında da uygulamalısın; gerekçesini işlemsel e-posta nedir yazısında ayrıntılı anlattım.

Hangi yöntemi seçersen seç, iki şey değişmez: SPF, DKIM ve DMARC kayıtlarını doğru kurman gerekir, ve mail gönderimini HTTP isteğinin içinde senkron yapmamalısın. Bu ikisini atlarsan seçtiğin yöntem hiç fark etmez, sonuç yine spam klasörü olur. Kurulum sonrası kimlik doğrulamanın gerçekten geçtiğini görmek için SMTP test aracı ile üretilen komutlar en hızlı yoldur.

Sıkça Sorulan Sorular#

SMTP mi API mi daha hızlı#

Tek bir mail için fark milisaniyeler düzeyindedir ve genelde hissedilmez. Fark hacimde ortaya çıkar: SMTP her mesaj için çok turlu bir konuşma yürütürken API tek istekte yüzlerce alıcıyı kuyruğa alabilir. Günde birkaç yüz mail gönderiyorsan hız kriteri kararında belirleyici olmamalı; günde on binlerce mail gönderiyorsan API belirgin biçimde öne geçer.

API kullanırsam SPF ve DKIM kaydına gerek kalır mı#

Kesinlikle kalır. Gönderim yöntemi değişse de alıcı sağlayıcılar aynı kimlik doğrulama kontrollerini uygular. API kullandığında sağlayıcının verdiği include: ifadesini SPF kaydına eklemen ve DKIM için sunulan CNAME ya da TXT kayıtlarını DNS'ine yazman gerekir. Bu kayıtlar eksikse mailler yine spam'e düşer, API kullanıyor olman hiçbir şey değiştirmez.

Sağlayıcı değiştirmek ne kadar zor#

SMTP kullanıyorsan neredeyse hiç zor değil: sunucu adresi, kullanıcı adı ve parolayı değiştirir, SPF kaydını güncellersin; uygulama kodu aynı kalır. API kullanıyorsan gönderim katmanını yeniden yazman gerekir çünkü her sağlayıcının şeması farklıdır. Bu maliyeti baştan düşürmek istiyorsan uygulamanın içine kendi gönderim arayüzünü koy ve sağlayıcıya özgü kodu tek bir sürücü dosyasında topla.

API anahtarımı nerede saklamalıyım#

Kaynak kodda ve sürüm kontrolünde asla tutma. Anahtar ortam değişkeninde, bir sır yönetim servisinde ya da en azından sürüm kontrolüne dahil edilmeyen ve dosya izinleri kısıtlanmış bir yapılandırma dosyasında durmalıdır. Mümkünse gönderim yetkisiyle sınırlı, IP kısıtlı ayrı bir anahtar üret ve düzenli aralıklarla döndür.

Serverless ortamda hangisini kullanmalıyım#

API neredeyse her zaman doğru tercihtir. Serverless fonksiyonlar kısa ömürlüdür ve kalıcı bağlantı havuzu tutamazlar; her çağrıda yeni bir SMTP oturumu açmak hem yavaştır hem de bağlantı sınırlarını hızla doldurur. Ayrıca birçok serverless ortamda giden SMTP portları kapalıdır, HTTPS ise her zaman açıktır.

Mail gönderdim ama teslim edilip edilmediğini nasıl öğrenirim#

SMTP kullanıyorsan sunucunun mail logunda her teslimat denemesi için status=sent, status=deferred ya da status=bounced satırı bulunur; ayrıca geri dönen mesajlar Return-Path adresine düşer. API kullanıyorsan HTTP cevabındaki 202 ya da queued bilgisi teslimat kanıtı değildir; asıl sonucu webhook olaylarından ya da mesaj kimliğiyle yapılan durum sorgusundan öğrenirsin.

Kapanış#

SMTP ile API arasındaki seçim, aslında "taşınabilirlik mi görünürlük mü" sorusudur. SMTP sana standart bir protokol, olgun bir yerel kuyruk ve kolay göç imkânı verir; API sana tek gidiş-dönüş, zengin olay geri bildirimi ve kapsamlı kimlik yönetimi verir. Aklında tutman gereken dört alışkanlık şunlar: gönderimi mutlaka kuyruğa al ve senkron yapma, HTTP 202 cevabını teslimat sanma, kimlik bilgilerini koddan ayrı tut ve hangi yöntemi seçersen seç SPF/DKIM/DMARC üçlüsünü eksiksiz kur. Uygulamanın içine ince bir gönderim arayüzü koyarsan bu kararı ileride tekrar vermek maliyetsiz hâle gelir.

Gönderimi kendi altyapında tutmak istiyorsan Postfix, Dovecot ve DKIM kurulu hâlde teslim edilen SMTP sunucu paketimiz SMTP tarafını hazır getirir; uygulamayı barındıracak makine için VDS ve bulut sunucu paketlerimize bakabilirsin. Kurulum ve teslimat ayarlarını devretmek istersen sunucu yönetimi hizmetimiz DKIM, SPF ve rDNS dahil tüm zinciri üstlenir.