Uygulamanızın işlemsel e-postaları neden spam'e düşüyor (ve nasıl düzeltilir)

İşlemsel e-posta teslimi neden tamamen başka bir mesele

Teslim edilebilirliği ilk kez ciddi biçimde düşünmeye başlayan pek çok geliştiricinin gözden kaçırdığı, pazarlama e-postaları ile işlemsel e-postalar arasında kritik bir ayrım var. Pazarlama e-postaları — bültenler, kampanyalar, duyurular — izin vermiş abonelere gider. Ara sıra gecikmeleri, hatta ara sıra spam klasörüne düşmeyi kaldırabilirler. Bir bülten listenizin %2'sinde spam'e düşerse bu üzücüdür ama işiniz yürümeye devam eder.

İşlemsel e-postalar tamamen farklıdır. Doğrulama bağlantıları, şifre sıfırlamaları, satın alma onayları, iki faktörlü doğrulama kodları, hesap güvenlik uyarıları — bunlar kullanıcı yolculuğunun kritik anlarında gelir. Spam'e düşen bir şifre sıfırlama e-postası, kullanıcının kendi hesabının dışında kilitli kaldığı, muhtemelen bir destek talebi açacağı ya da daha kötüsü hiç geri dönmeyeceği anlamına gelir. Spam'e düşen bir doğrulama e-postası ise yeni kullanıcının kaydı tamamlayamadığı ve edinim huninizde sessiz, görünmez bir sızıntı olduğu anlamına gelir.

Buna karşın işlemsel e-postalar sıklıkla pazarlama kampanyalarından daha az özenle kurulur. Pek çok geliştirici doğrulama e-postası sistemini özenle kurmak yerine framework'ün sunduğu gönderim kodunu kullanır, paylaşımlı bir SMTP sunucusuna bağlar, dağıtımı yapar, spam eşikleri gayet cömert olan kendi gelen kutusuyla bir kez test eder ve devam eder. Sorunlar ancak Gmail, Outlook veya Yahoo kullanan gerçek kullanıcılar gelmeyen e-postaları bildirdiğinde ortaya çıkar. O noktada arıza haftalardır üretimde sessizce sürüyordur.

SPF: e-posta kimlik doğrulamasının temeli

Sender Policy Framework (SPF), gönderim alan adınızda bulunan ve hangi posta sunucularının sizin adınıza e-posta göndermeye yetkili olduğunu dünyaya bildiren bir DNS TXT kaydıdır. Gmail, [email protected] adresinden geldiği iddia edilen bir e-posta aldığında alan adınızın SPF kaydı için bir DNS sorgusu yapar. E-postayı gerçekten gönderen sunucunun IP adresi SPF kaydınızda listelenmişse e-posta SPF'i geçer. Hiç SPF kaydı yoksa — ya da gönderen sunucu listede değilse — içerik değerlendirmesi başlamadan önce e-posta kuşkuyla karşılanır.

Ne yapacağınızı bildiğinizde SPF kurulumu basittir. Alan adınızın DNS'ine bir TXT kaydı ekleyin. Değer, gönderim sağlayıcınıza göre değişir. SendGrid kullanıyorsanız: v=spf1 include:sendgrid.net ~all. AWS SES kullanıyorsanız: v=spf1 include:amazonses.com ~all. Mailgun kullanıyorsanız: v=spf1 include:mailgun.org ~all. Sağlayıcınızın dokümantasyonu tam include değerini verir. ~all son eki bir "soft fail"dir — listede olmayan sunuculardan gelen e-postalar işaretlenir ama doğrudan reddedilmez. SPF kaydınızın eksiksiz ve doğru olduğundan emin olduğunuzda -all (hard fail) seviyesine geçebilirsiniz; bu, alıcı sunuculara yetkisiz postayı tümüyle reddetmelerini söyler.

Sık düşülen bir tuzak: 10 DNS sorgusu sınırı. Birden fazla include: yönergesini birbirine zincirleyen SPF kayıtları bu sınırı aşabilir ve tüm sunucularınız teknik olarak listede olsa bile SPF başarısız olur. SPF kaydınızı MXToolbox ile kontrol edin — sorgu sayısı sorunlarını açıkça gösterir. SPF, DKIM ve DMARC'ın birbiriyle nasıl ilişkilendiği SendGrid'in e-posta kimlik doğrulama dokümantasyonunda güzelce açıklanıyor.

DKIM: e-postanızın değiştirilmediğinin kriptografik kanıtı

DomainKeys Identified Mail (DKIM), gönderdiğiniz her e-postaya kriptografik bir imza ekler. İmza, gönderim sağlayıcınızın elindeki özel anahtarla üretilir ve alıcı posta sunucuları bunu, sizin DNS TXT kaydı olarak yayınladığınız açık anahtarla doğrular. İmza tutarsa iki şey kanıtlanmış olur: e-posta gerçekten sizin gönderim altyapınızdan çıkmıştır ve içerik gönderim ile alım arasında değiştirilmemiştir.

DKIM yapılandırılmadığında kötü niyetli kişilerin alan adınızı taklit etmesi çok daha kolay hale gelir; yani gerçekte bambaşka biri tarafından gönderilmiş olmasına rağmen [email protected] adresinden geliyormuş gibi görünen e-postalar yollayabilirler. Kimlik avı kampanyaları tam olarak böyle işler. Spam filtreleri de bunu bilir; bu yüzden DKIM imzası olması gereken bir alan adından geçerli imza olmadan gelen bir e-posta daha yüksek bir kuşkuyla ele alınır. Spamhaus ve diğer itibar servisleri de DKIM imzalama geçmişini alan adı itibar puanlarına katar.

DKIM kurulumu gönderim sağlayıcınız üzerinden yapılır. Sağlayıcı bir anahtar çifti üretir, özel anahtarı kendi altyapısında tutar ve DNS'inize TXT kaydı olarak eklemeniz için size bir açık anahtar verir. O DNS kaydı yayınlanıp yayıldıktan sonra sizin adınıza gönderilen her e-posta otomatik olarak geçerli bir DKIM imzası taşır. SendGrid, Mailgun, Amazon SES, Postmark gibi büyük sağlayıcıların çoğu ilk kurulum sırasında sizi bu süreçten geçirir. Bu adımı atladıysanız geri dönüp şimdi yapılandırın.

DMARC: her şeyi birbirine bağlayan politika katmanı

DMARC (Domain-based Message Authentication, Reporting and Conformance), bir e-posta bu kontrolleri geçemediğinde alıcı sunucuların ne yapması gerektiğini tanımlayarak SPF ve DKIM'in üzerine kurulur. Ayrıca "hizalama" kavramını getirir: e-postanın From başlığındaki alan adının, SPF veya DKIM'i gerçekten geçen alan adıyla eşleşmesini zorunlu kılar. Bu, saldırganların bir alan adıyla SPF kontrolünü geçerken görünen From adresinde başka bir alan adını taklit etmesini engeller.

DMARC'a doğru yaklaşım kademeli başlamaktır. Yalnızca izleme yapan bir politikayla başlayın: v=DMARC1; p=none; rua=mailto:[email protected]. p=none, alıcı sunuculara başarısızlıklarda işlem yapmamalarını, yalnızca size rapor göndermelerini söyler. Bu toplu raporlar sizin adınıza hangi sunucuların e-posta gönderdiğini ve SPF ile DKIM'i geçip geçmediklerini gösterir. Politikada değişiklik yapmadan önce birkaç hafta bunları inceleyin.

Meşru tüm trafiğin geçtiğinden emin olduğunuzda p=quarantine (başarısız e-postalar spam klasörüne gider) seviyesine, ardından nihayetinde p=reject (başarısız e-postalar doğrudan reddedilir) seviyesine geçin. Bu kademeli ilerleme alan adınızın itibarını taklit girişimlerinden korurken gözden kaçırmış olabileceğiniz meşru gönderim kaynaklarını yakalamanız için zaman tanır. SPF ve DKIM geçerken uygulanan p=reject DMARC politikası, saldırganların alan adınızı etkili biçimde taklit etmesini neredeyse imkânsız kılar.

IP itibarı: gönderim sunucunuz neden önemli

SPF, DKIM ve DMARC kusursuz olsa bile, e-postalarınızın gönderildiği IP adresinin itibarı kötüyse yine spam'e düşebilirler. Alıcı posta sunucuları gönderen IP adresleri için engelleme listeleri ve itibar puanları tutar ya da bunları tutan üçüncü taraf servisleri sorgular. Spam gönderim geçmişi olan veya Spamhaus gibi servislerin engelleme listelerinde görünen bir IP, kimlik doğrulama yapılandırmanız ne kadar iyi olursa olsun giden e-postalarının kuşkuyla ele alınmasına yol açar.

Paylaşımlı bir barındırma sağlayıcısından ya da ucuz bir SMTP servisinden gelen paylaşımlı IP adresi kullanıyorsanız itibarınız aynı IP'yi kullanan herkese bağlıdır. Aynı paylaşımlı havuzdaki tek bir spam göndericisi, o IP'deki tüm göndericilerin teslim edilebilirliğini dibe çekebilir. Bu, e-postayı doğrudan uygulama sunucunuzdan ya da paylaşımlı bir SMTP üzerinden göndermek yerine SendGrid, Amazon SES, Postmark, Mailgun gibi işlemsel e-postaya özel bir sağlayıcı kullanmanın en güçlü gerekçelerinden biridir.

Yeni bir gönderim IP'sinde ayrıca IP'yi kademeli olarak "ısıtmanız" gerekir. Yepyeni bir IP'den ani bir hacim patlaması, alıcı sunucuların gözünde spam davranışına benzer. Düşük hacimlerle başlayıp günler ya da haftalar içinde kademeli olarak artırın. Paylaşımlı bir gönderim havuzundaysanız çoğu özel e-posta sağlayıcısı IP ısınmasını otomatik olarak yönetir; özel IP kullanıyorsanız ısınma takvimleri sunar.

İçerik ve konu satırı: filtreleri tetikleyen şeyler

Kimlik doğrulama ve IP itibarının ötesinde, e-postanızın içeriğinin kendisi de spam filtreleri tarafından değerlendirilir. Bazı kalıplar spam sınıflandırmasını neredeyse her seferinde tetikler. Konu satırındaki tetikleyici kelimeler — "BEDAVA", "GARANTİLİ", "HEMEN HAREKETE GEÇ", aşırı ünlem işaretleri, TAMAMI BÜYÜK HARF — çoğu geliştiricinin kaçındığı bariz örneklerdir. Daha az bariz olanlar: fazla belirsiz konular ("Size özel önemli bir mesaj"), fazla aciliyet yayan konular ("Hesabınız kapatılacak") ya da işlemsel bir e-posta olması gereken şey için fazla reklam kokan konular.

Metin-görsel oranı da önemlidir. Çoğunlukla görsellerden oluşan, metni çok az olan bir e-posta klasik bir spam kalıbıdır — toplu gönderim yapanlar anahtar kelimeleri metin tabanlı filtrelerden saklamak için görsel kullanır. İşlemsel e-postalar ağırlıklı olarak metin tabanlı olmalı ve az görsel içermelidir. Bozuk HTML — kapatılmamış etiketler, hatalı biçimlendirilmiş nitelikler — başka bir uyarı işaretidir. HTML sürümünün yanında her zaman düz metin alternatifi gönderin. Spam filtreleri yalnızca HTML içeren e-postalara daha yüksek kuşkuyla bakar ve kurumsal e-posta sistemleri sıklıkla HTML'i tümüyle temizler.

E-posta teslimini doğru şekilde test etmek

E-posta teslimi için en hızlı ve en pratik test yöntemi şudur: yeni oluşturulmuş bir geçici e-posta gelen kutusuna test e-postası gönderin ve hem gelen kutusunu hem de spam klasörünü kontrol edin. Bu size e-postanızın gelen kutusuna ulaşıp ulaşmadığı ya da filtrelenip filtrelenmediği konusunda anında ve tartışmasız bir geri bildirim verir. Sizi sık gönderen olarak beyaz listeye almış olabilecek kendi Gmail hesabınızla test etmenin aksine, yeni bir geçici adresin alan adınızla hiçbir geçmişi yoktur; bu da yeni bir kullanıcının ilk temas deneyimini çok daha doğru biçimde taklit eder.

Teslimi etkileyebilecek herhangi bir şeyi değiştirdiğinizde her seferinde doğrulama e-postasının gerçekten ulaşıp ulaşmadığını test etmelisiniz: e-posta sağlayıcısını değiştirmek, HTML şablonunu önemli ölçüde güncellemek, gönderim alan adını değiştirmek, yeni bir gönderim alt alan adı eklemek ya da yeni bir ortama (staging, üretim) dağıtım yapmak. İki dakika sürer ve kesin kanıt sağlar. Alternatifi — kullanıcıların sorunu bildirmesini beklemek — teslim edilebilirlik sorunlarınızın bilinmeyen bir süredir sessizce devam ettiği anlamına gelir.

Gelen kutusu/spam kontrolünün ötesinde, alan adınızın genel sağlığını incelemek için MXToolbox e-posta sağlık denetleyicisini kullanın: SPF, DKIM, DMARC, kara liste durumu ve MX kaydı yapılandırması tek yerde. Bunu her yeni uygulama ve gönderim alan adı için yayın öncesi kontrol listenizin parçası yapın. Ayrıca güvenlikle ilgili e-posta en iyi uygulamaları için OWASP yönergelerine de bakın.

Geri dönme oranı ve spam şikâyetleri: gerçekten önemli metrikler

İki metrik uzun vadeli teslim edilebilirlik üzerinde orantısız biçimde büyük etkiye sahiptir: geri dönme (bounce) oranı ve spam şikâyet oranı. %2'nin üzerindeki bir geri dönme oranı, alıcı sunuculara ve gönderim sağlayıcınıza çok sayıda geçersiz veya var olmayan adrese gönderim yaptığınızı söyler — bu da satın alınmış listelerle ve spam operasyonlarıyla ilişkilendirilen bir kalıptır. Diğer her şeyi doğru yapsanız bile yüksek geri dönme oranı teslim sorunlarına yol açar. Kalıcı geri dönmeleri (hard bounce) gönderim listenizden derhal ve kalıcı olarak çıkarın.

%0,1'in (gönderilen her bin e-postada bir şikâyet) üzerindeki bir spam şikâyet oranı, çoğu gönderim sağlayıcısının hesabınızı kısıtlamaya başladığı eşiktir. Gmail Postmaster Tools'u yapılandırdıysanız şikâyet oranlarını doğrudan raporlar. Bu metrikleri gönderim sağlayıcınızın panelinden izleyin. Şikâyet oranları yükseliyorsa nedenini araştırın — açıkça izin vermemiş kullanıcılara mı gönderiyorsunuz? E-postalarınız fazla sık mı? Kullanıcıların beklediği şeyle aldıkları şey arasında bir uyumsuzluk mu var?

Eksiksiz teslim edilebilirlik kontrol listesi

• SPF kaydı: yetkili tüm gönderim sunucularını listeleyen, gönderim alan adınızdaki DNS TXT kaydı. MXToolbox ile test edin.
• DKIM: gönderim sağlayıcınız üzerinden kriptografik imzalama yapılandırılmış, açık anahtar DNS'te yayınlanmış olmalı.
• DMARC: p=none izlemesiyle başlayın, toplu raporları inceledikten sonra p=quarantine ve ardından p=reject seviyesine geçin.
• Özel gönderim sağlayıcısı: SendGrid, SES, Postmark veya Mailgun kullanın — uygulama sunucunuzu ya da paylaşımlı SMTP'yi değil.
• Temiz konu satırları: belirli, ilgili, tetikleyici kelime içermeyen, aşırı noktalama ya da büyük harf barındırmayan.
• HTML + düz metin: her zaman ikisini birlikte gönderin. Asla yalnızca HTML içeren e-posta göndermeyin.
• URL kısaltıcı kullanmayın: e-posta gövdesinde ve doğrulama bağlantılarında tam, doğrudan URL kullanın.
• Abonelikten çıkma bağlantısı: uygun olduğu yerde işlemsel e-postalara da ekleyin — bazı sağlayıcılar bunu zorunlu tutar.
• Fiziksel adres: CAN-SPAM ve birçok ülkedeki benzer düzenlemeler tarafından zorunlu tutulur.
• Kalıcı geri dönme yönetimi: derhal çıkarın; kalıcı geri dönmeye asla yeniden gönderim yapmayın.
• Şikâyet izleme: Gmail Postmaster Tools'u kurun; şikâyet oranını panelden izleyin.
• Gelen kutusu testi: her dağıtımdan önce ve her şablon ya da yapılandırma değişikliğinden sonra yeni geçici gelen kutularına test e-postası gönderin.
• MXToolbox sağlık kontrolü: her yeni alan adı ve ortam için yayın öncesi kontrol listenize ekleyin.

Özel bir işlemsel e-posta servisi ne zaman kullanılmalı

Uygulamanız, kullanıcının ürünü kullanabilmesi için alması gereken herhangi bir e-posta gönderiyorsa — doğrulama bağlantıları, şifre sıfırlamaları ve baştan sona kayıt ve ödeme yolculuğunu kapatan satın alma onayları — ilk günden itibaren özel bir işlemsel e-posta sağlayıcısı kullanmalısınız. Maliyet düşüktür (genellikle ayda on binlerce e-postaya kadar ücretsiz), güvenilirlik kendi kurduğunuz SMTP'den çarpıcı biçimde daha iyidir ve teslim edilebilirlik altyapısı — itibarı yönetilen paylaşımlı IP havuzları, otomatik DKIM imzalama, geri dönme ve şikâyet yönetimi — tüm işi e-postaları gelen kutusunda tutmak olan ekipler tarafından sürdürülür.

En yaygın kendin-yap hatası, posta sunucusunu web uygulamasıyla aynı IP'de çalıştırmak ya da ucuz bir barındırma sağlayıcısının paket SMTP servisini kullanmaktır. Barındırma ortamı kötü niyetli kişilerle paylaşıldığı için bu IP'ler Spamhaus gibi servislerin engelleme listelerine rutin olarak eklenir. Özel bir işlemsel sağlayıcıya geçmek genellikle bir öğleden sonralık iştir ve teslim edilebilirlik üzerinde anında olumlu etki yaratır. Küçük bir ekibin yapabileceği en yüksek getirili altyapı iyileştirmelerinden biridir. Gizliliğe önem veren ekipler, e-postanın devreye girdiği durumlarda kullanıcı verilerinin sorumlu biçimde ele alınmasına dair Electronic Frontier Foundation rehberliğini de incelemelidir. Ek olarak, yeni hesaplar oluşturulurken adresleri Have I Been Pwned üzerinden bilinen sızıntı veritabanlarıyla karşılaştırmak dolandırıcılık önleme çabanızı tamamlayabilir.