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 DKIM ve DMARC şarttır; SPF isteğe bağlıdır, çünkü SenderTR'de Return-Path bizim alan adımızdadır ve SPF orada geçer.
- 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, 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.
İşlemsel e-posta ticari ileti midir?
Hayır. Sipariş onayı, kargo bildirimi veya şifre sıfırlama gibi alıcının kendi talebiyle tetiklenen iletiler ticari elektronik ileti sayılmaz; bu yüzden onay ve abonelikten çıkma zorunluluğu aranmaz. Ancak içine kampanya veya indirim eklerseniz ileti pazarlama karakteri kazanır ve İYS kuralları devreye girer. Entegrasyon seçenekleri: Entegrasyonlar.
Gönderim olayını doğru alıcıyla eşleştirme
İşlemsel iletiyi göndermeden önce hangi uygulama olayının hangi alıcıya karşılık geldiğini açıkça tanımlayın. Sipariş onayını siparişte kayıtlı adrese, şifre sıfırlama iletisini ise ilgili hesabın doğrulanmış adresine yönlendirin. Kullanıcının formda yazdığı adres ile hesapta kayıtlı adres farklıysa hangi adresin kullanılacağını önceden belirleyin. Bu karar, özellikle hesap erişimiyle ilgili iletilerde yanlış kişiye bilgi gönderilmesini önler.
Aynı olay uygulama tarafından yeniden işlendiğinde gereksiz kopyalar oluşabilir. Gönderim kararını uygulamanızdaki işlem kaydıyla ilişkilendirin; aynı sipariş onayının veya doğrulama isteğinin tekrar üretilip üretilmediğini denetleyin. Gerçekten yeni bir kullanıcı talebi varsa bunu önceki olaydan ayırın. Böylece tekrarları azaltırken kullanıcının yeni isteğini de engellememiş olursunuz. Alıcı adresi, işlem türü ve gönderim nedeni gibi bilgileri kayıt altına almak, sonradan yaşanan karışıklıkları incelemeyi kolaylaştırır.
İleti şablonunda güvenlik ve okunabilirlik
Şablondaki değişken alanların doğru işlemden veri aldığını denetleyin. Alıcının adı, sipariş bilgisi veya bağlantı yanlış kayıtla eşleşirse ileti zamanında gönderilse bile kullanıcıya zarar verebilir. Başlık, gönderen adı ve ileti gövdesi birlikte okunduğunda hangi işlemin gerçekleştiği anlaşılmalıdır. Alıcının ne yapması gerektiğini açık bir ifadeyle belirtin; işlem gerekmiyorsa bunu da söyleyin.
Şifre sıfırlama gibi güvenlik iletilerinde parolayı e-postaya yazmayın. Bağlantıyı açamayan kullanıcı için uygulamaya nasıl dönebileceğini anlatın. Bağlantı metni tek başına okunduğunda nereye götürdüğünü açıklasın; yalnızca belirsiz bir çağrı ifadesine dayanmayın. Görsel yüklenmese de temel işlem bilgileri okunabilmeli, uzun sipariş ayrıntıları küçük ekranda anlaşılır kalmalıdır. Kullanıcının bir işlemi kendisinin başlatmadığını düşünmesi halinde başvurabileceği destek yolunu belirtin. Şablonu gerçek kullanıcı verileri yerine örnek verilerle gözden geçirmek, gereksiz kişisel bilgi paylaşımını fark etmeyi kolaylaştırır.
Canlıya geçmeden önce sınama listesi
Gönderimi yalnızca başarılı işlem üzerinden sınamayın. Boş veya hatalı alıcı adresi, eksik şablon verisi, uygulamanın bağlantısının kesilmesi ve aynı olayın tekrar işlenmesi gibi durumları da deneyin. Her durumda uygulamanın kullanıcıya ne gösterdiğini ve gönderim kaydına ne yazdığını kontrol edin. Gönderim isteğinin kabul edilmesi ile iletinin alıcıya ulaşmasının ayrı aşamalar olduğunu ekip içinde netleştirin; kabul yanıtını son teslimat olarak göstermeyin.
Deneme iletilerinde gerçek müşteri bilgisi kullanmamaya özen gösterin. Deneme ortamından çıkan iletilerin yanlışlıkla gerçek alıcılara yönlenmediğini doğrulayın. Ardından uygulama kayıtlarında işlem türü, alıcı ve gönderim sonucunun birbirine bağlanabildiğini kontrol edin. Bir sorun çıktığında hangi olayın iletiyi oluşturduğunu bulabilmek, yalnızca hata metnine bakmaktan daha yararlıdır. Son olarak şablon değişikliklerinden sonra örnek iletileri yeniden okuyun: yeni bir alan eklemek, daha önce doğru çalışan bir işlemin içeriğini veya alıcı eşleştirmesini bozabilir.
Gönderim erişimini nasıl korursunuz?
Gönderim için kullanılan kullanıcı bilgilerini veya uygulama anahtarlarını kaynak koduna yazmayın. Bu bilgileri uygulamanın erişebildiği, yetkileri sınırlandırılmış bir ortamda saklayın. Yazılım deposuna erişimi olan herkesin gönderim yetkisine de sahip olması gerekmez. Geliştirme ve canlı ortamların erişim bilgilerini ayrı tutmak, deneme sırasında yapılan bir değişikliğin gerçek gönderimleri etkileme riskini azaltır.
Gönderim yetkisini yalnızca ihtiyaç duyan uygulama bileşenlerine verin. Bir çalışanın görevi değiştiğinde veya bir erişim bilgisinin açığa çıktığından şüphelendiğinizde ilgili yetkiyi gözden geçirin. Bilgiyi yenilemeden önce uygulamanın yeni bilgiyle çalışabildiğini doğrulayın; ardından eski bilgiyi devre dışı bırakın. Hata kayıtlarına erişim bilgilerini, yetkilendirme başlıklarını veya bağlantılardaki gizli değerleri yazdırmayın. Böylece gönderim sorunlarını incelerken yeni bir güvenlik açığı oluşturmazsınız.
Yoğunluk anında hangi iletiler önce gönderilmeli?
Uygulamanız kısa sürede çok sayıda ileti üretebilir. Her iletiyi aynı iş akışına bırakmak yerine kullanıcıyı bekleten işlemleri belirleyin. Şifre sıfırlama veya giriş uyarısı gibi zaman duyarlı iletiler, daha sonra okunabilecek işlem özetlerinin gerisinde kalmamalıdır. Bu öncelik kararını gönderim hizmetinden bağımsız olarak uygulamanızın iş akışında tanımlayabilirsiniz.
Gönderim isteği hemen işlenemediğinde kullanıcıya gösterilecek metni de önceden hazırlayın. İleti henüz gönderilmediyse gönderildi demeyin; kullanıcının aynı işlemi art arda başlatmasını teşvik edecek belirsiz ifadelerden kaçının. Bekleyen işlemleri incelerken iletinin neden oluşturulduğunu ve hâlâ gerekli olup olmadığını denetleyin. Örneğin daha yeni bir şifre sıfırlama talebi varsa eski talebe ait iletinin gönderilmesi kullanıcıyı şaşırtabilir. Öncelik ve geçerlilik kararlarını birlikte ele almak, yoğunluk sırasında ileti sırasının kullanıcı açısından anlamlı kalmasını sağlar.
Gönderim kayıtlarında hangi bilgileri saklamalısınız?
Bir sorunu incelemek için gönderim kaydı gerekir; ancak iletinin bütün içeriğini saklamak her zaman gerekli değildir. Önce hangi sorulara yanıt arayacağınızı belirleyin: İleti hangi işlem nedeniyle oluştu, hangi adrese yönlendirildi ve uygulama hangi sonucu aldı? Ardından yalnızca bu soruları yanıtlamak için gereken alanları kaydedin. Şifre sıfırlama bağlantıları, doğrulama kodları ve fatura içeriği gibi hassas verileri sırf inceleme kolaylığı için kayıtlara eklemeyin.
Kaydı görme yetkisini destek ve geliştirme ekiplerinin gerçek ihtiyaçlarına göre sınırlandırın. Bir destek talebini çözerken alıcının tüm kişisel bilgilerini paylaşmak yerine ilgili işlem kaydına başvurulmasını sağlayın. Kayıtların ne kadar süre gerekli olduğunu kurumunuzun saklama kurallarına göre değerlendirin; ihtiyaç sona erdiğinde silme sürecini uygulayın. Böylece sorun çözmek için yararlı olan kayıtlar, zamanla gereksiz bir kişisel veri birikimine dönüşmez.