“Gönderildi Ama Ulaşmadı” Hatasını Ürün Ekibi Gibi Debug Etmek: Uçtan Uca Rehber

1) Önce dil birliği: “Gönderildi” hangi aşamayı temsil ediyor?

Ürün tarafında en sık yapılan hata, tek bir durum metniyle (Sent/Delivered/Failed) çok farklı gerçeklikleri aynı sepete atmak. İlk adım, ekip içinde ortak sözlük oluşturmak:

• Accepted (Kabul edildi): Uygulamanız isteği aldı ve e-posta işini kuyruğa koydu.
• Enqueued (Kuyruğa alındı): Mesaj bir job/queue sisteminde bekliyor.
• Submitted (MTA’ya teslim): Uygulamanız mesajı SMTP/ESP API üzerinden sağlayıcıya teslim etti.
• Delivered (Teslim edildi): Alıcının mail sunucusu 250 OK ile kabul etti (bu, inbox’a düştü demek değildir).
• Inboxed (Gelen kutusuna düştü): Provider filtrelerinden geçip inbox’a yerleşti.
• Bounced/Rejected (Reddedildi): Alıcı sunucusu kabul etmedi.
• Suppressed (Baskılandı): Sağlayıcı daha önceki bounce/complaint nedeniyle göndermeyi durdurdu.

Bu ayrım yapılmadığında, ekip “Sent” zannedip günlerce yanlış yeri debug eder. Ürün metinleri ve durum etiketleri bu sözlüğe göre yeniden hizalanmalıdır.

2) Teslimat zincirini bir boru hattı gibi düşünün

E-posta teslimatı tek bir servis değil, bir pipeline’dır. Problemi çözmenin en hızlı yolu, zinciri parçalara ayırıp her aşamaya ölçüm koymaktır:

• Uygulama katmanı: template render, adres doğrulama, event tetikleme, retry mantığı
• Kuyruk/işçi: job status, concurrency, timeouts, dead-letter queue
• Gönderim katmanı: SMTP/ESP API yanıtı, rate limit, auth
• Alan adı doğrulama: SPF, DKIM, DMARC uyumu
• Alıcı tarafı: 250 OK / 4xx greylisting / 5xx reject, spam filtreleri
• Kullanıcı cihazı: spam/önemsiz, kategori sekmeleri, kurallar/filtreler

Ürün ekibi açısından önemli olan: her aşamada bir “kanıt” üretmek. Böylece “nerede kayboldu?” sorusunun cevabı tahmine değil, veriye dayanır.

3) En kritik veri: Message-ID, correlation id ve ham SMTP/ESP kayıtları

“Gönderildi ama gelmedi” vakalarında en değerli üç bilgi şunlardır:

• Message-ID: E-postanın global kimliği. Her hop’ta iz sürmek için altın anahtar.
• Correlation ID (istek/iş kimliği): Uygulama event’i ile kuyruk job’u ve ESP çağrısını bağlar.
• Provider response: SMTP response code veya ESP API response body (accepted/rejected/reason).

Ürün ekibi için pratik öneri: Her outbound e-postayı “işlem” gibi ele alın ve loglarda şu alanları standartlaştırın: user_id, email_type, to_domain, message_id, provider_request_id, send_attempt, status, error_code. Destek ekibi bir ticket açtığında “bu bilgiler olmadan debug yok” seviyesinde net olun.

4) İlk triage: 10 dakikada sınıflandırma

Her vakayı aynı derinlikte incelemek pahalıdır. Ürün ekipleri için en verimli yaklaşım hızlı sınıflandırmadır. Aşağıdaki sorularla 10 dakikada “hangi sınıfa” girdiğini anlarsınız:

4.1 Kullanıcı doğru adresi mi yazdı?

En banal ama en yaygın: typo, nokta/alt çizgi, domain hatası, plus addressing (“+”) kuralları, kurum mailinde alias politikası. Uygulama tarafında giriş doğrulaması ve “adres doğrulama ekranı” bu sınıfı ciddi azaltır.

4.2 Bizim sistem maili gerçekten gönderim katmanına iletti mi?

Event üretildi mi? Job kuyruğa girdi mi? Worker aldı mı? Timeout oldu mu? “Sent” etiketi burada erken veriliyorsa ürün metni yanlış konumlanmıştır. Bazı sistemler “UI’da sent” deyip arkada job fail olabiliyor.

4.3 Provider kabul etti mi, reddetti mi?

SMTP’de 250 OK gördünüz mü? ESP “accepted” döndü mü? Eğer provider kabul etmediyse bu bir “teslimat” sorunu değil; gönderim/konfig sorunudur.

4.4 Provider kabul ettiyse, alıcı tarafı ne yaptı?

Mail “delivered” olsa bile spam’e düşebilir, kategori sekmesine gidebilir, kullanıcı kuralı ile arşivlenebilir ya da kurum gateway’i tarafından karantinaya alınabilir.

5) En yaygın kök nedenler (ürün ekibi perspektifiyle)

5.1 SPF/DKIM/DMARC uyumsuzluğu

Kimlik doğrulama kayıtları düzgün değilse, bazı alıcılar maili sessizce spam’e atar veya gateway’de karantinaya alır. Ürün ekibi açısından bu “teknik borç” değil, doğrudan kayıp aktivasyon demektir. Aktivasyon maili spam’e düşen kullanıcı, onboarding’i yarıda bırakır.

Debug ipucu: E-postanın header’ında Authentication-Results satırlarına bakın. SPF=pass/fail, DKIM=pass/fail, DMARC=pass/fail bilgisi genellikle burada görünür.

5.2 Suppression list / blocklist

Önceden bounce ya da spam şikâyeti alan bir alıcıya bazı sağlayıcılar tekrar gönderim yapmaz. Ürün ekibi için bu, “kullanıcıya mail gitmedi” yerine “biz hiç göndermedik” sınıfıdır. Bu yüzden UI’da “sent” göstermek yanlış olabilir.

Debug ipucu: Provider panelinde suppression reason (hard bounce, complaint, unsubscribe) ve tarih bilgisi aranmalı. Destek ekibine “adresinizi doğrulayalım” yerine “suppression temizliği” akışı tanımlayın.

5.3 Rate limit, throttling ve greylisting

Yoğun gönderim dönemlerinde provider rate limit uygulayabilir veya alıcı sunucu 4xx ile geçici reddedebilir. Sisteminizin retry/backoff stratejisi zayıfsa, mail “gönderildi” sanılır ama aslında sıra beklerken zaman aşımına uğrar.

Debug ipucu: SMTP 4xx kodları ve retry sayıları izlenmeli. Ürün metriklerinde “send latency” (event → accepted) ölçümü kritik.

5.4 İçerik/şablon kaynaklı spam tetiklenmesi

Aşırı link, kısa metin, takip pikseli, agresif CTA, “free/urgent” gibi kelimeler, bozuk HTML veya görsel ağırlığı spam skorunu artırabilir. Ürün ekibi için bu, tasarım ve metin kararlarının teslimata etkisini gösterir.

Debug ipucu: Aynı kullanıcıya “plain text” alternatif şablonla test gönderin. Fark varsa içerik tetikliyordur. E-postada hem HTML hem text part mutlaka bulunsun.

5.5 Yanlış From/Return-Path yapılandırması

From alanı marka alan adınızda, Return-Path başka bir yerdeyse bazı alıcılar bunu riskli görür. Bu problem genellikle “gönderildi ama görünmüyor” gibi şikâyetlerle gelir çünkü teknik olarak delivered olur ama görünürlük düşer.

6) Ürün ekibi için “kanıt toplama” checklist’i

Her incident’te aynı soruları tekrar tekrar sormamak için ürün içinde bir “teslimat kanıtı” standardı oluşturun:

• Olay zamanı (timestamp) ve kullanıcı saat dilimi
• Alıcı adresi (maskeleme ile) ve domain
• E-posta türü (login code, signup verify, receipt vs.)
• Message-ID ve correlation id
• Provider response (accepted/rejected + reason)
• Delivery event’leri (delivered, bounced, deferred)
• Suppression kontrolü
• Header örneği (kullanıcıdan forward istenebilir)

Bu checklist, destek ekibinin “kullanıcıya spam’e bakın” demeden önce elinde somut veri olmasını sağlar. Böylece hem kullanıcı deneyimi iyileşir hem de ekip içi güven artar.

7) “Ürün odaklı” debug akışı: Karar ağacı

Aşağıdaki akışı bir runbook olarak kullanabilirsiniz:

• Adım 1: Event üretildi mi? Üretildiyse correlation id var mı?
• Adım 2: Kuyruğa girdi mi? Worker aldı mı? Fail/retry var mı?
• Adım 3: Provider’a submit edildi mi? Provider request id var mı?
• Adım 4: Provider “accepted” mı dedi, “rejected” mi?
• Adım 5: Accepted ise: delivered/bounced/deferred event’i geldi mi?
• Adım 6: Delivered ise: spam/junk, kategori, kullanıcı kuralı, kurum gateway senaryosu
• Adım 7: Rejected/bounced ise: reason sınıfına göre aksiyon (DNS, suppression, rate, content)

Bu yaklaşım, “problem kimde?” tartışmasını azaltır. Çünkü zincirin hangi halkasında kırıldığını objektif olarak gösterir.

8) Kalıcı çözüm: Ürün metrikleri ve uyarılar

“Sent but Not Received” şikâyetleri genelde sadece destek ticket’larında görünür. Ürün ekibi olarak bunu ölçülebilir hâle getirmeniz gerekir. Önerilen metrikler:

• Acceptance rate: Provider’ın kabul ettiği mesaj oranı
• Delivery rate: Delivered event’i gelen oran
• Bounce rate: Hard/soft bounce oranları
• Suppression hit rate: Gönderilmeyen/suppressed mesaj oranı
• Send latency: Event → accepted süresi (p95/p99)
• Inbox placement proxy: Spam şikâyeti, açılma oranı, domain bazlı düşüşler

Uyarı mekanizması: Belirli bir domain’de (ör. büyük provider’lar) bounce artışı veya delivery düşüşü varsa otomatik alarm. Bu, “kullanıcılar şikâyet etmeden önce” sorunu yakalamanızı sağlar.

9) İletişim dili: Kullanıcıya ne denir, ne denmez?

Ürün ekiplerinin gözden kaçırdığı bir nokta da destek metinleridir. Kullanıcıya “spam’e bak” demek çoğu zaman yetersiz ve soğuk kalır. Daha iyi bir yaklaşım:

• Net: “Gönderim kaydınızı kontrol ettik, mesaj sağlayıcı tarafından kabul edilmiş görünüyor.”
• Yönlendirici: “Lütfen Spam/Junk klasörüne ve ‘Promotions’ gibi sekmelere bakın.”
• Alternatif: “Mümkünse farklı bir e-posta adresiyle tekrar deneyebilir misiniz?”
• Kanıt odaklı: “İsterseniz size mesaj kimliğini iletebiliriz; kurum e-posta yöneticiniz bu kimlikle kontrol edebilir.”

Bu yaklaşım, kullanıcıya “sorun sende” demeden, süreci birlikte çözme hissi verir. Ayrıca ürün tarafında feedback toplamanızı kolaylaştırır.

10) Mini vaka: Bir doğrulama kodu neden gelmez?

Elif bir uygulamaya kayıt olur. “Kodu gönderdik” yazar ama inbox boş. Spam’e bakar, yok. Yeniden gönder der, yine yok. Üçüncü denemede hâlâ yok.

Ürün ekibi runbook’u çalıştırır:

• Event var, job kuyruğa girmiş.
• Provider accepted dönmüş ama delivered event yok; deferred görünüyor.
• Loglarda aynı domain için 4xx artışı var: greylisting + rate limit.
• Worker retry policy agresif; 2 denemeden sonra drop ediyor.

Çözüm: backoff’u iyileştirir, retry sayısını artırır ve “Sent” durumunu “İşleniyor” gibi daha doğru bir metne çevirir. Sonuç: hem gerçek teslimat artar hem de kullanıcı şikâyeti azalır.

Sonuç: “Sent” bir başlangıç, bitiş değil

“Gönderildi ama alınmadı” problemi, e-posta teslimatının doğası gereği tek bir butonla çözülemez. Ürün ekibi yaklaşımı; zinciri aşamalara bölmek, her aşamayı ölçmek ve kullanıcıya doğru beklenti yönetimi yapmak üzerine kuruludur.

Doğru kurgulanmış loglar (Message-ID + correlation id), sağlam retry stratejisi, domain doğrulaması ve suppression yönetimi; bu şikâyetlerin büyük kısmını ya tamamen bitirir ya da yönetilebilir seviyeye indirir. En önemlisi: bir sonraki incident geldiğinde “tahmin” değil, “kanıt” ile ilerlersiniz.