Şifre sıfırlama e-postası müşteriye ulaşmıyor: işlemsel posta neden spam'e düşer?

Kullanıcı "şifremi unuttum" diyor, ekranda "e-posta gönderildi" yazıyor, posta hiç gelmiyor. Bu tablonun arkasında neredeyse hiçbir zaman kaprisli bir spam filtresi yoktur. Üç sebepten biri vardır: uygulama postayı hiç göndermemiştir, gönderen kimliğiniz doğrulanmadığı için alıcı sunucu mesajı reddetmiştir, ya da gönderen itibarınız bozuk olduğu için mesaj önemsiz klasörüne düşmüştür. Üçünü ayırt edebilmek, gönderim sonucunu ürünün içine kaydetmekle başlar. Çoğu ekip bugün "gönderildi" derken aslında "SMTP çağrısı hata vermedi" demektedir, ki bu ikisi aynı şey değil.

Bu alanın kuralları son iki yılda yazıya döküldü. 1 Şubat 2024'te Google ve Yahoo, kişisel hesaplara günde 5.000 ve üzeri mesaj gönderenler için SPF, DKIM ve hizalanmış bir DMARC kaydını, TLS ile bağlantıyı, geçerli ileri ve geri DNS kaydını (PTR), RFC 5322'ye uygun mesaj biçimini ve Postmaster Tools'ta %0,30'un altında şikayet oranını şart koştu. Microsoft aynı eşiği benimseyip kurallarını 5 Mayıs 2025'te Outlook.com, Hotmail ve Live için yürürlüğe aldı; uyumsuz gönderen 550 5.7.515 Access denied, sending domain [alanadiniz] does not meet the required authentication level yanıtıyla geri çevriliyor. Google tarafında da Kasım 2025'ten itibaren yaptırım sertleşti ve geçici erteleme veren 421 yanıtlarının yerini kalıcı 550 redleri almaya başladı. Günde 5.000 mesaj göndermiyor olabilirsiniz, ama alıcı sunucunun baktığı sinyaller yine aynı sinyaller.

"Gönderildi" ne demek, ne demek değil

Bir e-postanın ömründe dört ayrı durak var ve ekipler dördünü tek kelimeyle anıyor. Birincisi, uygulamanızın mesajı üretip kuyruğa alması. İkincisi, e-posta sağlayıcınızın mesajı kabul edip size bir mesaj kimliği vermesi. Üçüncüsü, alıcı sunucunun mesajı kabul etmesi; sağlayıcı panelinde gördüğünüz "delivered" tam olarak budur ve mesajın gelen kutusuna düştüğü anlamına gelmez, yalnızca karşı tarafın teslim almayı reddetmediğini söyler. Dördüncüsü, mesajın gerçekten gelen kutusunda görünmesi.

Dördüncü durağı dışarıdan doğrudan göremezsiniz; ölçmenin yolu Postmaster Tools verisi ve test hesaplarına gönderim. Ama ilk üçünü de göremiyorsanız, "e-posta gelmedi" şikayetini çözmenin hiçbir yolu kalmaz. Destek ekibinin bakabileceği tek bir ekran olmadığı sürece bu konuşma her seferinde tahminle biter.

Postayı kendi sunucunuzdan göndermeyin

Bulut sunucusunda kendi posta servisinizi ayağa kaldırma fikri ilk bakışta ucuz görünür, sonra duvara çarpar. AWS, Azure ve Google Cloud dışarı çıkan 25 numaralı portu varsayılan olarak kapatır; AWS'de kaldırılması için talep açmanız gerekir, Google Cloud sanal makinelerde bu bloğu hiç kaldırmaz. Blok olmasa bile sıfırdan bir IP adresinin itibarı yoktur ve yeni IP'ler en baştan şüpheyle karşılanır.

Pratik cevap, işlemsel postayı bir e-posta API'si ya da SMTP röle servisi üzerinden göndermek: Amazon SES, Postmark, SendGrid, Mailgun, Brevo, Resend gibi seçenekler var. Burada yayın gününde patlayan klasik bir sürpriz var: Amazon SES yeni hesapları sandbox modunda açar. Sandbox'ta yalnızca doğrulanmış adreslere gönderebilirsiniz, 24 saatte en fazla 200 mesaj ve saniyede en fazla 1 mesaj hakkınız vardır. Üretim erişimi talebi onay ister, yani bunu canlıya çıkacağınız sabah değil, haftalar öncesinden halletmeniz gerekir.

Kimlik doğrulamada atlanan kısım: hizalama

SPF, DKIM ve DMARC kayıtlarının nasıl kurulacağını ve p=none'dan p=reject'e nasıl çıkılacağını e-posta sahteciliği ve alan adı koruması yazımızda adım adım anlatmıştık. Uygulama e-postasına özgü olan ve sürekli atlanan kısım ise hizalama.

Bir mesajın iki farklı gönderen adresi vardır: alıcının gördüğü From adresi ve zarfın üstündeki MAIL FROM (Return-Path, yani geri dönen postaların gideceği adres). Sağlayıcılar varsayılan olarak MAIL FROM alanına kendi alan adlarını yazar, örneğin SES'te bounces+...@amazonses.com. Bu durumda SPF kontrolü geçer, ama geçtiği alan adı amazonses.com olur; sizin From adresinizle aynı organizasyon alan adını paylaşmadığı için DMARC hizalaması SPF ayağında başarısız kalır. Geriye tek dayanak DKIM kalır ve DKIM imzası da sizin alan adınızla atılmıyorsa DMARC tamamen düşer.

Çözüm iki adımda: DKIM'i kendi alan adınızla imzalatın ve sağlayıcınızın sunduğu özel MAIL FROM alt alan adını yapılandırın. SES'te bunun için alt alan adına bir MX ve bir SPF kaydı eklemeniz gerekir; karşılığında hem geri dönen postalar sizin alan adınızda toplanır hem de SPF hizalaması doğal olarak sağlanır. Microsoft'un beklentisi de net: en azından p=none seviyesinde bir DMARC kaydı olsun ve SPF ya da DKIM'den en az biri hizalı geçsin.

İşlemsel postayı pazarlama postasından ayırın

Kampanya e-postalarınız ile sipariş onaylarınız aynı alan adından çıkıyorsa, tek bir kötü kampanya şifre sıfırlama postalarınızı da aşağı çeker. Standart çözüm gönderimleri ayrı alt alan adlarına bölmek (örneğin bildirim ve kampanya için ayrı alt alan adları) ve her birini kendi SPF, DKIM, DMARC kayıtlarıyla kurmak. Böylece iki akışın itibarı ayrı ayrı birikir.

Burada yaygın bir yanlış anlama var: alt alan adına bölmek sizi 5.000 eşiğinin altına indirmez. Google'ın kendi sıkça sorulan sorular sayfası eşiğin ana alan adı düzeyinde, alt alan adları dahil hesaplandığını ve bir kez toplu gönderen sayıldıysanız bu statünün kalkmadığını söylüyor. Ayrım itibar içindir, eşikten kaçmak için değil.

İkinci ayrım içerikte. Google tek tıkla abonelikten çıkma başlığını (RFC 8058) yalnızca pazarlama ve abonelik mesajları için zorunlu tutuyor; sipariş onayı, fatura, şifre sıfırlama gibi işlemsel mesajlar bu kapsamda değil. Ama faturanın altına bir kampanya kutusu koyduğunuz anda o mesaj pazarlama mesajı haline gelir ve kuralların tamamı devreye girer. Türkiye tarafında da benzer bir ayrım var: sipariş, teslimat, borç hatırlatma gibi bilgilendirme iletileri ticari elektronik ileti sayılmadığı için İYS onayı gerektirmez, aynı iletiye ürün tanıtımı eklendiğinde bu istisna ortadan kalkar.

Geri bildirimi ürüne bağlayın

Sağlayıcınız her mesaj için olay gönderir: kabul edildi, teslim edildi, geri döndü (bounce), şikayet edildi, ertelendi. Bu olayları bir webhook uç noktasıyla toplamıyorsanız, ürününüz gönderdiği postaların akıbetinden habersiz demektir.

Kurulması gereken üç davranış var. Sert geri dönen (hard bounce) adresler kalıcı olarak baskı listesine alınmalı; olmayan bir adrese göndermeye devam etmek itibarınızı doğrudan aşağı çeker. Şikayet eden alıcılar anında listeye girmeli, çünkü şikayet oranı en pahalı metriktir. Yumuşak geri dönüşler (geçici kutu dolu, sunucu meşgul) sınırlı sayıda yeniden denenmeli, sonra bırakılmalı. Bu baskı listesini yalnız sağlayıcıya bırakmayın; kendi veritabanınızda da tutun ki hangi kullanıcıya neden ulaşamadığınızı ekranda gösterebilesiniz.

Webhook tüketmenin kendine özgü tuzakları var: imza doğrulaması, aynı olayın iki kez gelmesi, olayların sırasız düşmesi. Bunların hepsini ödeme tarafında da yaşıyorsunuz ve çözümleri aynı; ödeme entegrasyonunda webhook ve mutabakat yazımızda bu deseni ayrıntısıyla anlatmıştık. Bir kullanıcının adresine neden gönderilmediğini altı ay sonra açıklayabilmek istiyorsanız, bu olayları denetim izi kaydınızın yanına yazmak iyi bir alışkanlık.

Gönderimi istek hattından çıkarın

E-posta göndermek ağ üzerinden yapılan ve başarısız olabilen bir çağrıdır. Kayıt formunun içinde senkron çağrıyla posta gönderiyorsanız, sağlayıcı yavaşladığında kayıt formunuz da yavaşlar; sağlayıcı hata verdiğinde kullanıcı hesabı oluşmuş ama hoş geldin postası hiç gönderilmemiş olur. Doğrusu mesajı kuyruğa almak, arka planda göndermek ve yalnızca geçici hataları yeniden denemektir. Yeniden deneme yapıyorsanız her mesaja bir benzersizlik anahtarı verin, yoksa kullanıcı aynı faturayı dört kez alır. Bu mekaniğin tamamını arka plan işleri ve kuyruk mimarisi yazımızda kurmuştuk.

Zamana duyarlı mesajlarda bir ayrıntı daha var. Şifre sıfırlama ve tek kullanımlık kod postaları gecikmeye en tahammülsüz olanlardır; alıcı tarafındaki greylisting uygulaması ilk denemeyi geçici olarak reddedip mesajı dakikalarca bekletebilir. Bağlantının geçerlilik süresini buna göre belirleyin ve kritik akışlarda ikinci bir kanal düşünün. Girişin kendisini hazır bir kimlik servisine bırakmak da bu yükü azaltır; o kararı kimlik doğrulamayı kendimiz mi yazalım yazımızda tartışmıştık.

Şikayet oranı bir bütçedir

Google, Postmaster Tools'ta görünen şikayet oranının %0,30'un altında kalmasını şart koşuyor ve %0,10'un altını hedeflemenizi öneriyor. Haziran 2024'ten itibaren bu oranı aşan toplu gönderenler, sorun çözme desteğinden yararlanamıyor. Sayı küçük görünüyor: on bin mesajda otuz şikayet sınırı aşmaya yeter.

İşlemsel postada şikayet genellikle tek bir şeyden gelir: alıcı o mesajı beklemiyordur. Kayıt sırasında başkasının adresinin yanlışlıkla (ya da kasten) yazılması, tanınmayan bir gönderen adı, ya da aylar sonra gelen alakasız bir bildirim. Kayıt anında adres doğrulaması yapmak, gönderen adını markanızla eşleştirmek ve bildirim tercihlerini kullanıcıya açmak bu oranı düşüren en ucuz üç önlemdir.

Sıkıcı ama işe yarayan birkaç kural

• Düz metin alternatifi koyun. Yalnızca HTML gövdeyle giden mesajlar filtrelerde dezavantajlıdır; multipart/alternative ile düz metin sürümünü de gönderin.
• Bağlantı kısaltıcı kullanmayın. İşlemsel mesajda kısaltılmış bağlantı, filtreler için spam işaretidir. Tıklama takibi yapacaksanız sağlayıcının paylaşımlı takip alan adını değil, kendi alan adınıza bağlı bir takip alt alan adını kullanın.
• noreply@ adresini bırakın. İzlenen bir adresten gönderin; hem yanıt veren kullanıcıyı kaybetmezsiniz hem de "posta gelmedi" şikayetlerini ilk elden görürsünüz.
• Gönderen adını sabitleyin. Her modül farklı bir addan gönderirse alıcı sizi tanımaz, tanımadığı gönderene şikayet düğmesine basar.
• Test hesaplarına gönderin. Gmail, Outlook ve kurumsal bir alan adında birer hesap tutun; büyük bir değişiklikten sonra mesajın nereye düştüğünü kendi gözünüzle görün.

Ölçmediğiniz şeyi düzeltemezsiniz

Üç kaynağı birlikte izleyin. Google Postmaster Tools alan adı itibarınızı, şikayet oranınızı ve kimlik doğrulama başarı oranınızı gösterir; kaydı ücretsizdir ve bir DNS doğrulaması yeterlidir. DMARC toplu raporları (rua) alan adınızdan gerçekte kimin gönderdiğini ortaya çıkarır ve çoğu ekip burada unuttuğu üçüncü taraf bir aracı bulur. Sağlayıcı paneliniz de geri dönüş ve şikayet oranlarınızı verir.

Bu üçünü panoya koymak yetmez, eşik alarmı gerekir. Geri dönüş oranı bir günde iki katına çıktığında, yeni bir entegrasyon yanlış adres listesine yazmaya başladığında ya da kimlik doğrulama başarı oranı düştüğünde haberi kullanıcıdan değil sistemden almalısınız. Eşik ve alarm kurmanın genel yöntemini izlenebilirlik, SLO ve hata bütçesi yazımızda anlatmıştık.

"E-posta gelmedi" dendiğinde izlenecek sıra

1. Uygulama kaydına bakın. Mesaj üretildi mi, kuyruğa girdi mi, gönderim denendi mi? Burada kayıt yoksa sorun e-posta tarafında değil, sizin kodunuzda.
2. Sağlayıcı kaydını mesaj kimliğiyle arayın. Kabul edildi mi, geri mi döndü, ertelendi mi?
3. Geri döndüyse kodu okuyun. 5.7.515 kimlik doğrulama sorunudur, 5.1.1 adres yok demektir, 4.x.x ile başlayanlar geçicidir ve yeniden denenmelidir.
4. Kabul edilmiş ama alıcıda yoksa alıcı tarafındaki filtrelemeye bakın: önemsiz klasörü, kurumsal karantina, alan adı düzeyinde engelleme.
5. Adresin baskı listesinde olup olmadığını kontrol edin. Aylar önceki bir geri dönüş yüzünden sessizce susturulmuş olabilir.

Bu beş adımı bugün mevcut sisteminizde deneyin. İlk adımda takılıyorsanız, yani "mesaj üretildi mi" sorusuna tek bir ekrandan cevap veremiyorsanız, teslim edilebilirlikten önce kapatılması gereken boşluk orada. Wedevit olarak ürününüzün e-posta akışını baştan sona çıkarıyor, gönderim altyapısını ve kimlik doğrulama hizalamasını kuruyor, geri dönüş ve şikayet olaylarını ürünün içine bağlıyoruz. Aynı çalışma içinde gönderim uçlarınızı API güvenliği tarafındaki kontrollerle birlikte gözden geçiriyoruz. Tüm çalışma uzaktan yürür.