Transactional (işlemsel) e-posta, bir kullanıcının eylemi sonucu tetiklenen, kişiye özel ve genellikle beklenen e-postadır: şifre sıfırlama, sipariş onayı, e-posta doğrulama, fatura, kargo bildirimi, giriş uyarısı. Pazarlama (bulk) e-postasının aksine tek bir alıcıya, o an, bir işleme cevaben gönderilir — ve alıcı onu bekler. Bu yüzden açılma oranları pazarlama maillerinin çok üzerindedir ve gecikmesi doğrudan kullanıcı deneyimini bozar.
Transactional vs. pazarlama e-postası
| Transactional | Pazarlama | |
|---|---|---|
| Tetikleyici | Kullanıcı eylemi | Kampanya takvimi |
| Alıcı | Tek kişi | Segment/liste |
| Onay (opt-in) | İşlemin kendisi yeterli | Açık ticari ileti onayı gerekir |
| Zamanlama | Anında (kritik) | Esnek |
| Örnek | Şifre sıfırlama, sipariş onayı | Bülten, indirim duyurusu |
Kritik bir kural: ikisini aynı gönderim IP'sinde karıştırmayın. Pazarlama gönderiminizde yükselen bir şikâyet oranı, aynı IP'yi paylaşan şifre-sıfırlama maillerinizin de spam'e düşmesine yol açabilir. Ayrı IP/alt alan adı kullanmak, kritik transactional teslimatını izole eder.
İki entegrasyon yöntemi: SMTP relay ve HTTP API
SMTP relay
Uygulamanız, standart SMTP protokolü ile bir relay sunucusuna bağlanıp maili teslim eder. Neredeyse her dil ve framework SMTP'yi doğrudan destekler; mevcut sistemleri (WordPress, ERP, yazıcı, eski uygulamalar) değiştirmeden bağlamak kolaydır.
- Port 587 (STARTTLS) — modern gönderim (submission) için önerilen porttur; bağlantı düz başlar, STARTTLS ile TLS'e yükseltilir.
- Port 465 (SMTPS) — baştan TLS ile şifreli bağlantı (implicit TLS).
- Port 25 — sunucular arası aktarım içindir; çoğu bulut sağlayıcı ve ISP kötüye kullanımı önlemek için gidenlerde 25'i kapatır. Uygulama gönderimi için 587 kullanın.
SMTP'de kimlik doğrulama genellikle SASL kullanıcı adı/şifre ile yapılır. Basit ve evrenseldir; ancak her mail için bağlantı kurma maliyeti, çok yüksek hacimlerde API'ye göre biraz daha ağır olabilir.
HTTP API
Uygulamanız maili bir REST API çağrısıyla (JSON gövde, API anahtarıyla yetkilendirme) gönderir. Yüksek hacimde daha performanslı ve düşük gecikmelidir; ek olarak zengin özellikler sunar: gönderim durumu (delivered/bounce/açılma) için webhook, şablon yönetimi, planlama, ayrıntılı hata kodları. Modern uygulamalar için genellikle tercih edilen yöntemdir; karşılığında API'ye özel bir entegrasyon kodu yazmanız gerekir.
Hangisini seçmeli?
- SMTP relay: Mevcut/hazır sistemleri hızlıca bağlamak, çok dilli ortam, minimum kod değişikliği.
- HTTP API: Yüksek hacim, gerçek zamanlı teslimat takibi (webhook), şablon ve otomasyon ihtiyacı.
İyi haber: SenderTR her ikisini de sunar; aynı gönderen itibarı, aynı kimlik doğrulama ve aynı raporlama havuzunu paylaşırlar. İhtiyaca göre birini ya da ikisini birlikte kullanabilirsiniz.
Transactional teslimatını yüksek tutmanın kuralları
- Kimlik doğrulamayı kurun: Transactional için de SPF, DKIM, DMARC şarttır.
- Pazarlamadan ayırın: Kritik mailleri farklı bir IP/alt alan adında tutun.
- Webhook ile izleyin: Bounce ve teslim durumlarını gerçek zamanlı yakalayıp geçersiz adresleri baskılayın.
- İçeriği sade tutun: Transactional maile pazarlama içeriği eklemek hem teslimatı riske atar hem de bazı durumlarda ticari ileti kurallarına tabi olmanıza yol açabilir.
- Hız ve tekrar denemeyi yönetin: Geçici hatalarda (4.x.x) makul aralıklarla yeniden deneyin; kalıcı hatalarda (5.x.x) durun.
SenderTR transactional gönderimini hem SMTP relay (587 STARTTLS / 465 SMTPS, TLS sertifikalı) hem de HTTP API üzerinden sunar; her iki yolda da gerçek zamanlı teslim/bounce webhook'ları, otomatik suppression ve pazarlamadan izole IP seçeneği ile kritik maillerinizin gelen kutusuna anında ulaşmasını sağlar.