Sipariş E-postası Spam'e Düşüyorsa: 7 Kontrol

Küçük bir online çiçekçi düşünün. Bir müşteri annesinin doğum günü için buket sipariş ediyor, ödüyor ve onay e-postasını bekliyor. E-posta gelmiyor. On dakika sonra yeniden bakıyor, sonra siparişin geçip geçmediğini sormak için dükkânı arıyor. Dükkân sahibi siparişi yönetim panelinde buluyor ve müşteriyi rahatlatıyor. O akşam iki müşteri daha aynı soruyla arıyor; biri garanti olsun diye rakipten de sipariş vermiş.

E-posta gönderilmişti. Ya spam klasörüne düştü ya da müşterinin e-posta sağlayıcısı tarafından sessizce reddedildi. Dükkânda kimse bunu bilmiyordu, çünkü site "gönderildi" diyordu ve başka bir şey demiyordu.

Sitenizde bir işlemle tetiklenen e-postalar, yani sipariş onayları, şifre sıfırlama, rezervasyon onayları ve faturalar, genellikle işlem e-postası (transactional email) diye anılır. Projelerde nadiren konuşulurlar, çünkü geliştiricinin kendi adresiyle bir kez denenir ve çalışırlar. Sonra site yayına girer, hacim artar, e-posta sağlayıcıları kurallarını sıkılaştırır ve müşterilerin en çok beklediği iletiler kaybolmaya başlar. Bu yedi kontrol birkaç saat sürer ve sorunun çoğunu önler.

1. E-postayı web sunucusunun kendisinden göndermeyin

Birçok site e-postayı doğrudan üzerinde çalıştığı sunucudan, platformun sunduğu e-posta fonksiyonuyla gönderir. İlk gün çalışır. Ama o sunucunun adresinin gönderim geçmişi yoktur, çoğu zaman binlerce başka siteyle aynı adres aralığını paylaşır ve e-posta sağlayıcıları iletilerine şüpheyle bakar.

İşlem e-postaları için ayrı bir e-posta gönderim servisi kullanın ve sitenize API'si ya da SMTP ayarlarıyla bağlayın. Bu servisler gönderim adreslerinin itibarını yönetir, bir sağlayıcı yavaşladığında yeniden dener ve her iletiye ne olduğunu raporlar. Küçük bir dükkân için maliyet genellikle o kadar düşüktür ki önlenen ilk telefon araması bunu karşılar.

2. Alan adınızda SPF, DKIM ve DMARC kurun

E-posta sağlayıcıları, alan adınızdan geldiğini söyleyen her ileti için üç soru sorar. Sade bir dille:

• SPF: Bu iletiyi gönderen sunucunun bu alan adı adına göndermeye izni var mı? Gönderim servisinizi listeleyen bir DNS kaydıyla cevap verirsiniz.
• DKIM: İleti alan adı tarafından imzalandı mı ve yolda değişti mi? Gönderim servisi size DNS'te yayınlamanız için bir anahtar verir.
• DMARC: İlk iki kontrol başarısız olursa sağlayıcı ne yapmalı ve raporları nereye göndermeli? Bir DNS kaydı daha.

Gmail ve Yahoo gibi büyük sağlayıcılar artık toplu gönderim yapanlardan üçünü de bekliyor ve bunlar olmadan gelen iletiler küçük hacimlerde bile giderek daha çok filtreleniyor. DMARC'ı yalnızca izleme modunda başlatın, her meşru göndericinin listede olduğundan emin olmak için raporları birkaç hafta okuyun, sonra sıkılaştırın.

Sık görülen bir açık: dükkân sipariş e-postalarını bir servisle, faturaları muhasebe yazılımıyla, bültenleri üçüncü bir araçla gönderir. Her biri SPF'e eklenmeli ve DKIM ile kurulmalıdır; yoksa akışlardan biri kontrollerden geçemez.

3. İşlem ve pazarlama e-postalarını ayırın

Eski bir listeye bülten gönderildiğinde ve birçok kişi onu spam olarak işaretlediğinde, sağlayıcılar göndericinin itibarını düşürür. Bülten ve sipariş onayları aynı adresten ve alan adından geliyorsa, bedeli onaylar öder.

Onları ayrı gönderin. Yaygın bir düzen, işlem iletilerini ana alan adından ya da "siparis" gibi bir alt alan adından, pazarlama iletilerini başka bir alt alan adından, mümkünse gönderim servisinde ayrı bir akış üzerinden göndermektir. Böylece kötü giden bir kampanya şifre sıfırlamayı durdurmaz.

4. Bir insanın okuduğu yanıt adresi kullanın

"No-reply" adresinden gelen iletiler biraz iş kazandırır, çok güven kaybettirir. Müşteriler sipariş onaylarına gerçek sorularla cevap verir: bir teslimat notu, yanlış bir adres, kart mesajını değiştirme isteği. Cevap geri dönerse ya da kaybolursa, bir sonraki temas bir telefon araması ya da şikâyet olur.

Yanıt adresini mesai saatlerinde birinin baktığı bir posta kutusu yapın. Cevaplar daha sessiz bir yoldan da yardım eder: sağlayıcılar insanların bir göndericinin iletilerine cevap verdiğini fark eder ve o göndericiyi insanların haber almak istediği biri olarak görür.

5. İletiyi sade ve somut tutun

İşlem e-postalarının bir kampanya gibi görünmesine gerek yoktur. En güvenilir ulaşanlar ne olduğunu söyler, müşterinin arayacağı ayrıntıları verir ve tek bir açık sonraki adım sunar: sipariş numarası, ürünler, toplam, teslimat adresi ve tarihi, sipariş sayfasına bir bağlantı.

Bazı alışkanlıklar filtrelenmeyi kolaylaştırır: çoğu tek bir büyük görselden oluşan bir ileti, bağlantı kısaltıcılar, farklı alan adlarına giden çok sayıda bağlantı, reklam gibi okunan bir konu satırı. Tanıtımı makbuza değil, ayrı bir e-postaya koyun.

6. Başarısızlıkları yönetin ve yalnızca e-postaya güvenmeyin

Gönderim servisi her ileti için teslim edildiğini, geri döndüğünü ya da spam olarak bildirildiğini söyler. Bu durumu siparişin ya da hesabın yanında saklayın. Bir şifre sıfırlama iletisi geri döndüyse, destek ekibi müşteriden üçüncü kez "spam klasörünüze bakın" demek yerine bunu hemen görür.

Müşterinin ne olduğunu öğrenmek için e-postaya hiç muhtaç kalmadığından da emin olun. Ödemeden sonraki onay sayfası sipariş numarasını göstermeli ve siparişin alındığını açıkça söylemelidir. Hesap sayfası siparişleri ve rezervasyonları listelemelidir. Şifre sıfırlamada kullanıcıya bağlantının hangi adrese gönderildiğini söyleyin ve bir dakika sonra yeniden isteme imkânı verin.

7. Her değişiklikten sonra gerçek gelen kutularını test edin

E-posta teslimi sessizce bozulur, genellikle ilgisiz bir değişiklikten sonra. Site yeni bir barındırmaya taşınır ve eski SPF kaydı artık tutmaz. Alan adının DNS'i başka bir sağlayıcıya taşınır ve DKIM kayıtları kopyalanmaz. Yeni bir fatura aracı SPF'e eklenmeden sizin adınıza göndermeye başlar.

Böyle her değişiklikten sonra bir deneme siparişi verin ve şifre sıfırlama isteyin; ikisinin de yalnızca kendi şirket adresinize değil, iki üç yaygın sağlayıcıda gelen kutusuna düştüğünü kontrol edin. Ayda bir DMARC raporlarına ya da gönderim servisinin paneline geri dönen iletiler ve spam bildirimleri için bakın. Amaç, bir sorunu telefondaki bir müşteriden değil, bir rapordan duymaktır.

Kısaca

• İşlem e-postalarını web sunucusundan değil, ayrı bir gönderim servisiyle gönderin.
• Alan adınız için SPF, DKIM ve DMARC yayınlayın ve sizin adınıza gönderen her aracı dahil edin.
• İşlem ve pazarlama e-postalarını ayrı adreslerden ya da alt alan adlarından gönderin.
• Bir insanın okuduğu yanıt adresi kullanın.
• Makbuzları sade tutun: ne oldu, ayrıntılar, tek bağlantı.
• Her iletinin teslim durumunu saklayın ve aynı bilgiyi sitede de gösterin.
• Her barındırma, DNS ya da araç değişikliğinden sonra gerçek gelen kutularını test edin ve raporları ayda bir okuyun.

E-ticaret ve web projelerimizde gönderim servisini ve alan adı kayıtlarını yayının bir parçası olarak kuruyor, sipariş ve şifre e-postalarını teslimden önce yaptığımız testlere dahil ediyoruz.