İşlemsel e-posta takibi: Teslim, bounce ve yeniden gönderim
· PoolByte Technology
Sipariş e-postası için uygulamada “gönderildi” yazması, müşterinin mesajı aldığı anlamına gelmez. Sunucu mesajı kabul etmiş olabilir; alıcı sunucusu daha sonra reddedebilir veya geçici sorun bildirebilir. İşlemsel e-postaları güvenilir yönetmek için gönderim talebi, teslim olayı ve geri dönüşler ayrı izlenmelidir.
Durum adlarını doğru kullanın
İşlemsel mesaj; sipariş durumu, parola sıfırlama veya hizmet bildirimi gibi belirli bir işlemle ilişkili olabilir. Bu yazının konusu mesajın hukuki sınıfı değil, teknik tesliminin izlenmesidir. Bir mesaj türünün hangi izinlerle gönderilebileceği ayrıca değerlendirilir; teknik olarak teslim edilebilmesi izin bulunduğunu göstermez.
Amazon SES teslim edilebilirlik açıklaması, kabul, ret ve alıcı davranışlarıyla ilgili temel ayrımları anlatır. “Delivered” olayı bile mesajın mutlaka gelen kutusuna düştüğünü veya okunduğunu kanıtlamaz. Panelde bu sınırı koruyan adlar kullanın; okunma hakkında kesinlik üretmeyin.
Kalıcı ve geçici hatayı ayırın
Geçici bir sorun yeniden deneme gerektirebilir. Kalıcı olarak bulunamayan bir adrese aynı mesajı sürekli göndermek ise yarar sağlamaz ve gönderim itibarını etkileyebilir. Sağlayıcının durum kodlarını kendi uygulama durumlarınıza açık bir eşleştirmeyle bağlayın. Bütün hataları tek bir “tekrar dene” kuyruğuna atmayın.
Örneğin müşteri e-posta adresini yanlış yazmış olabilir. Panel, hangi bildirimin ulaşmadığını gösterebilir ve doğrulanmış adres düzeltmesinden sonra kontrollü yeniden gönderim sağlayabilir. Önceki hatayı silmek yerine işlem geçmişi tutulmalıdır. Adres değişikliği, özellikle hesap kurtarma gibi hassas işlemlerde yetkili doğrulama gerektirir.
Sağlayıcı olaylarını güvenli eşleştirin
Bildirim servisinden gelen teslim, bounce veya şikâyet olaylarını doğru gönderim kaydına bağlayın. SES olay bildirimi dokümanı, izlenebilen olay türlerine örnek verir. Kullandığınız sağlayıcının imza ve teslim kurallarını ayrıca uygulayın; olay kaynağını doğrulamadan gönderim durumunu değiştirmeyin.
Aynı olay tekrar gelebilir veya sırası değişebilir. Geç gelen bir “kabul edildi” bildirimi, daha sonra oluşmuş kalıcı hata kaydını yanlışlıkla başarılıya çevirmemelidir. Mesaj kimliği ve olay zamanı kullanışlıdır; ancak özel bağlantı token’larını, tam mesaj gövdelerini veya gereksiz kişisel bilgileri günlüklerde tutmayın.
Günlük işletim ekranı
- Mesaj türüne göre gönderim ve hata sayıları.
- Kalıcı ret, geçici ret ve şikâyetlerin ayrı görünümü.
- Son başarılı gönderim ve sağlayıcı kesintisi bilgisi.
- Yeniden denenen kaydın gerekçesi ve yetkili kişi.
- Ulaşılamayan kritik bildirimler için uygun alternatif süreç.
Teslim sorunu yalnız e-posta kimlik doğrulamasından kaynaklanmaz; buna rağmen SPF, DKIM ve DMARC ayarları temel kontroller arasında kalır. İşlemsel e-posta takibi, müşteriye “gönderdik” demek yerine sistemin gerçekten hangi aşamayı doğruladığını gösterebilmektir.