# E-posta Bounce Oranı: Nasıl Ölçülür ve Neler Düzeltilir URL: https://notificationharbor.com/tr/journal/e-posta-bounce-orani-nasil-olculur Type: blog Locale: tr Published: 2026-11-03 Updated: 2026-11-03 --- > E-posta bounce oranı, bounce sayısının gönderilen mesaja bölünmesidir; ama payda, bounce türü ve akış bu sonucu değiştirir. Ölçümü ve neye alarm kuracağınızı anlatıyoruz. E-posta bounce oranı, alıcı sunucunun kabul etmediği mesajların gönderilen mesajlara bölünmüş halidir. Sağlıklı bir listede sert bounce oranını yüzde 1'in altında tutun, yüzde 2'de nedeni araştırmaya başlayın ve yüzde 5'i bir olay olarak ele alın. Çoğu ekip panodaki tek bir karışık sayıya bakar ve paydanın, bounce türünün ve zaman penceresinin sonucu nasıl değiştirdiğini gözden kaçırır. Yazının geri kalanı, önce sayıyı doğru ölçmek ve ardından ne yapılacağına karar vermek üzerine. ## Formül basit. Anlaşmazlık paydadadır. Bounce oranı, bounce olan mesaj sayısının gönderilen mesaj sayısına bölünüp 100 ile çarpılmasıyla bulunur. Bazı ESP'ler bunun yerine iletilen mesajlara bölüm yapar. İletilen sayı bounce'ları zaten dışarıda bıraktığı için bu yöntem oranı daha yüksek gösterir. Bir kıyaslama yapmadan önce sağlayıcınızın hangisini raporladığını kontrol edin. Örneğin Amazon SES, bounce oranını yalnızca sert bounce'lardan hesaplar ve bunu hesapta gönderdiğiniz toplam mesaja göre ölçer. Bu ayrıntı önemlidir: yumuşak ve sert bounce'ları karıştıran bir pano, sağlayıcınızın sizi değerlendirirken kullandığından daha yüksek bir sayı gösterir. Tanımı seçin ve metriğin yanına yazın, gerekirse pano başlığına koyun. Biz sert bounce'ları gönderilene oranlıyoruz; alan adı başına, 24 saatlik ve 7 günlük pencerelerde. Ekibinizde iki kişi aynı hafta için farklı sayılar söylüyorsa, karşılaştırılacak ilk şey paydadır. Pano başlığına aynı tanımı yazmak, aylar sonra o grafiğe bakan yeni bir mühendisin neyi ölçtüğünü anlamasını sağlar. Tanım belgelenmemişse her ekip kendi formülüyle konuşur ve toplantılar sayıların değil, tanımların tartışılmasıyla geçer. ![Klavyenin yanında yükselen bir çizgi grafiğinin defter çizimi bulunan masa](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/0de2bf-img1.webp) ## Sert, yumuşak ve blok bounce'lar üç farklı sinyaldir Sert bounce kalıcı bir hatadır. Adres yoktur, alan adı çözümlenmez ya da posta kutusu kapatılmıştır. SMTP bunu, [RFC 3463](https://datatracker.ietf.org/doc/html/rfc3463) içinde tanımlanan 5.x.x gelişmiş durum koduyla bildirir. Yumuşak bounce geçici bir hatadır: dolu bir posta kutusu, geçici olarak erişilemeyen bir sunucu ya da çok büyük bir mesaj. Bunlar 4.x.x kodlarıyla döner ve iyi davranan bir gönderici bunları yeniden dener. SMTP kodlarının tam sınıflandırması için sert ve yumuşak bounce rehberimizde ayrıntılı olarak ele aldığımız konuya bakabilirsiniz. Üçüncü kategori, panoların gizlediği kategoridir. Blok, 5.x.x koduyla gelen ve adresle ilgili değil, sizinle ilgili bir reddir: kara listedeki bir IP, başarısız bir kimlik doğrulama kontrolü ya da bir içerik veya itibar filtresi. Bloku sert bounce saymak listenizi kirli gösterir, oysa asıl sorun gönderim altyapınızdır. Tek bir "bounce" satırı gösteren raporları atlayın. Üç ayrı seriye bölün; yoksa hiç sorun olmayan bir listeyi temizlemiş olursunuz. ## 2026'da iyi bir bounce oranı nedir? Kabul görmüş tek bir sayı yoktur ve bir sayı verirken bunu bilmek önemlidir. Gmail ve Yahoo şikâyet oranları için eşikler yayımlar, bounce için yayımlamaz. Google, toplu gönderenlerin Postmaster Tools'ta raporlanan spam oranını 0.10'un altında tutmasını ve asla 0.30'a ulaşmamasını ister; bunu [gönderici kuralları SSS sayfasında](https://support.google.com/a/answer/81126) açıkça yazar. Bounce için kullandığımız çalışma sayıları ESP'lerden ve pratikten gelir. Bunlar bir posta sağlayıcısının garantisi değil, bizim uyarı seviyelerimizdir. Alan adı başına, 24 saatlik sert bounce oranı ve bizim buna karşı aldığımız aksiyon: - **0.5'in altı:** katılımcı ve doğrulanmış bir liste için normal. - **0.5 ile 1 arası:** izleyin ve yeni adreslerin kaynağını kontrol edin. - **1 ile 2 arası:** inceleyin ve en yüksek orana sahip segmenti duraklatın. - **2 ile 5 arası:** o akıştan toplu gönderimi durdurun ve arkasındaki içe aktarmayı ya da formu bulun. - **5'in üstü:** olay. Amazon SES hesapları bu seviyede incelemeye alır. Son satır belgelenmiş bir sınırdır. [Amazon SES'in itibar paneli dokümantasyonunda](https://docs.aws.amazon.com/ses/latest/dg/reputationdashboardmessages.html) yazdığına göre, bounce oranı 5 veya üzerinde olan bir hesap incelemeye alınır ve oran 10'un üzerinde kalırsa gönderim duraklatılabilir. Diğer sağlayıcılar farklı sayılar ve ifadeler kullanır; kendi sözleşmenizi okuyun. ## Önce segmentlere ayırın: karışık oran, başarısız olan akışı gizler Hesap genelinde 0.8 olan bir oran, işlemsel akışta 0.1 ve yeniden etkinleştirme içe aktarımında 6 barındırabilir. Karışık sayı kabul edilebilir görünür, ama ikinci akış gönderim alan adınızı sessizce zedeler. Oranı akışa, kaynağa ve alıcı alan adına göre hesaplayın. Dört kesit çoğu sorunu yakalar: - **Akışa göre.** İşlemsel, yaşam döngüsü ve toplu kampanyalar asla tek bir sayıyı paylaşmamalı. - **Kayıt kaynağına göre.** Formlar, API kayıtları, CSV içe aktarımları ve ortak listeleri çok farklı adres kalitesine sahiptir. - **Alıcı alan adına göre.** Tek bir sağlayıcıda görülen artış genellikle kirli bir listeden değil, o sağlayıcının red politikasından kaynaklanır. - **Adres yaşına göre.** 12 aydan önce toplanan adresler, yenilere göre daha yüksek oranda bounce olur. Pratikte bu, her kesit için aynı pencereyi kullanmak demektir. Bir akışı 24 saatlik, diğerini 30 günlük pencerede raporlarsanız, iki satırı yan yana koyup karşılaştırmak anlamsız olur. Pencereyi ve paydayı tüm kesitlerde sabit tutun. Bu sadece bir raporlama detayı değil. Bir form doğrulama hatasını bir saatte düzeltmekle sağlıklı bir listeyi panikle temizlemek arasındaki fark budur. ![Loş bir odada, vurgulanmış satırları olan bir terminal log akışını gösteren dizüstü bilgisayar](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/98b212-img2.webp) Beşinci bir kesit de eklemeye değer: gönderim IP'sine ya da alan adına göre. İşlemsel posta için ayrılmış bir IP ve kampanyalar için paylaşımlı bir havuz kullanıyorsanız, birinde görülen artış tek bir log satırı açmadan nereye bakacağınızı gösterir. ## Sağlayıcınızdan bounce olaylarını kaybetmeden okumak Her ciddi ESP, bounce'ları olay olarak sunar: bir webhook, bir bildirim konusu ya da bir olay API'si. Bu akışı gerçeğin kaynağı sayın ve kendi depolamanıza yazın; çünkü paneller veriyi toplar ve ileride ihtiyaç duyacağınız ayrıntıyı kaybeder. Her olay için şu alanları saklayın: mesaj kimliği, alıcı, bounce türü, gelişmiş durum kodu, tanılama metni ve zaman damgası. Bu altı alanla bir post-mortem'de gelen soruların neredeyse hepsini yanıtlayabilirsiniz. `{ "event": "bounce", "message_id": "msg_01H9", "recipient": "user@example.com", "bounce_type": "permanent", "status": "5.1.1", "diagnostic": "550 5.1.1 user unknown", "stream": "lifecycle", "ts": "2026-11-02T09:14:03Z" }`İşleyiciyi idempotent yapın ve sağlayıcının olay kimliği ile mesaj kimliğine göre anahtarlayın. Sağlayıcılar webhook'ları yeniden dener; iki kez artırılan bir sert bounce sayacı oranınızı çarpıtır ve sorunsuz bir adresi bile bastırabilir. Postmark ve Resend, olaylarında bounce türlerini ayırır ve bunları mesaj akışı bazında çekmenize izin verir. Bu da yukarıdaki akış bazlı ayrımı kolaylaştırır. ## İşin büyük kısmını yapan suppression kuralı En yüksek kaldıraçlı kontrol otomatik suppression'dır. Tek bir sert bounce'tan sonra o adrese, sağlayıcının listesine yalnızca güvenmek yerine, uygulama katmanında kalıcı olarak gönderimi durdurun. Çoğu ESP sert bounce'ları sizin için bastırır. Açık kalan boşluk, sağlayıcı değiştirdiğinizde, ikisini paralel çalıştırdığınızda ya da suppression listesini hiç okumayan bir sistemden gönderim yaptığınızda ortaya çıkar. Normalleştirilmiş bir adrese göre anahtarlanmış kendi tablonuz bu boşluğu kapatır. Yumuşak bounce'lar için tek bir olay yerine sayaç kullanın. Bizim varsayılanımız, en az yedi gün boyunca üç ardışık yumuşak bounce'tan sonra bastırmaktır. Bir hafta boyunca dolu olan bir posta kutusu, yaşam döngüsü amaçları açısından artık oradadır denemez. Bastırma listesini de kontrol altında tutun. Bir adresin neden bastırıldığını, hangi olayın bunu tetiklediğini ve ne zaman eklendiğini kayıtta görebilmelisiniz. Böyle bir kayıt olmadan, "bu adrese neden mail gitmiyor" sorusuna destek ekibinizin cevap vermesi zor olur. Bounce olan adresleri kullanıcı tablonuzdan silmeyin. Durum kodu ve tarihle işaretleyin. Silinmiş bir satır, aynı adresin geçen çeyrekte iki kez bounce olduğunu söyleyemez. Kaydı, bir sonraki CSV'den aynı adresi tekrar içe aktarmamak için tutun; "temizlenmiş" bir listenin yeniden kirlenmesinin en yaygın yolu budur. ![Masada, üçü ayrı bir tepsiye konmuş, üst üste dizilmiş boş zarflar](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-11/dc3638-img3.webp) ## Oran neden birden yükselir: olası nedenler, önem sırasına göre Oran hareket ettiğinde nedeni şu sırayla arayın. İlk üçü çoğu artışı açıklar. - **Yeni bir içe aktarım.** Bir etkinlikten, bir ortaktan ya da eski bir CRM dışa aktarımından gelen CSV. Başka her şeyden önce bounce oranına kayıt kaynağına göre bakın. - **Doğrulamasız bir kayıt formu.** gmial.com gibi yazım hataları ve tek kullanımlık alan adları. Gönderim anında yapılan sözdizimi ve MX kontrolü çoğunu temizler; kalanları ise bir onay e-postası, yaşam döngüsü akışında gönderim sayılmadan önce ayıklar. - **Bir gönderim değişikliği.** Yeni bir IP, yeni bir alan adı ya da çok hızlı artırılmış bir ısınma süreci; bunlar sert bounce yerine bloklara dönüşür. - **Kimlik doğrulama bozulması.** Bir DNS değişikliğinden sonra SPF, DKIM ya da DMARC hizalamasının başarısız olması. - **Sağlayıcı tarafında red politikası.** Bir alıcı alan adı filtrelerini sıkılaştırdı. Oranınız yalnızca o alan adında yükseldi. Tanılama, artışla aynı pencerede, akışa ve alıcı alan adına göre gruplanmış durum kodu dağılımıdır. 5.1.1 (user unknown) artışı listeyi işaret eder. 5.7.x artışı ise politikayı, kimlik doğrulamayı ya da itibarı. Bunlar zıt düzeltmeler gerektirir; bu yüzden kodu saklarsınız. Bu listeyi bir kontrol sırası olarak düşünün, bir suçlular listesi olarak değil. Çoğu olayda birden fazla neden aynı anda çalışır: yeni bir içe aktarım genellikle doğrulamasız bir formla birlikte gelir ve ikisi birlikte oranı yükseltir. Tek bir nedeni bulup durmak yerine kaynakları birbirinden ayırmaya devam edin. ## Neye alarm kurardık Günlük ortalamaya alarm kurmak çok yavaştır. Kötü bir içe aktarım bir saatte 40.000 mesaj gönderebilir. Bunun yerine kayan bir pencereye alarm kurun. - Herhangi bir akışta son 1.000 gönderimde sert bounce oranı 1'in üzerinde. - Herhangi bir tek alıcı alan adında, bir saatte en az 200 gönderimde oran 5'in üzerinde. - 5.7.x blok sayısı, normal tabanınızın belirgin bir farkla üzerinde. Eşikleri ilk hafta gözden geçirin. Yeni bir akışın normal tabanı henüz oturmadığında sert bir alarm gereksiz duraklatmalara yol açar; ilk ayın verisiyle eşikleri yeniden ayarlamak daha güvenlidir. İlk ikisini bir insana sayfa göndermek yerine ilgili akışı duraklatmaya bağlayın. İnsan sonradan inceleyebilir; duraklatma ise sonraki on dakikada itibarınızı koruyan şeydir. Oranı zaten kullandığınız izleme sistemine aktarın, Grafana, Datadog ya da kendi geliştirdiğiniz bir araç olsun. Akış etiketini seriyle birlikte tutun ki ayrım dışa aktarımda kaybolmasın. Yönetime raporlarken 7 günlük pencerede akış bazında sert bounce oranını ve blok sayısını kullanın. Yumuşak bounce'lar mühendislik görünümünde kalsın; orada işe yararlar, yönetici görünümünde ise kafa karıştırırlar. Hesap genelindeki karışık sayıyı tek başına asla raporlamayın; kimsenin odada açıklayamayacağı nedenlerle hareket eder. Tek bir rakam istenirse işlemsel akışın sert bounce oranını verin. Bir hatanın bir şifre sıfırlamasına ya da bir faturaya mal olduğu akış burasıdır ve altyapınızın sağlıklı olup olmadığının en net göstergesidir. Bir sonraki somut adım küçük: son 30 günün bounce olaylarını çekin, akışa ve durum koduna göre gruplayın ve beklemediğiniz satırı bulun. ## FAQ ### İyi bir e-posta bounce oranı nedir? Sert bounce'lar için doğrulanmış ve katılımcı bir listede yüzde 1 makul bir üst sınırdır; doğrulanmış adreslerde yüzde 0.5'in altı yaygındır. Gmail ve Yahoo resmi bir bounce eşiği yayımlamaz, bu yüzden bunlar posta sağlayıcısı kuralı değil, çalışma uyarı seviyeleridir. ### E-posta bounce oranı nasıl hesaplanır? Bounce olan mesaj sayısını gönderilen mesaj sayısına bölün ve 100 ile çarpın. Bazı ESP'ler bunun yerine iletilen mesajlara böler; bu daha yüksek bir sayı verir, bu yüzden bir kıyaslama yapmadan önce paydayı doğrulayın. ### Hangi bounce oranı hesabımın askıya alınmasına yol açar? Bu sağlayıcıya bağlıdır. Amazon SES, bounce oranı yüzde 5 olan hesabı incelemeye alır ve oran yüzde 10'un üzerinde kalırsa gönderimi duraklatabilir. Diğer ESP'ler kendi sınırlarını koyar; sağlayıcınızın koşullarını kontrol edin. ### Yumuşak bounce'lar bounce oranına dahil mi? Bu sağlayıcıya bağlıdır. Bazıları, Amazon SES'in yaptığı gibi yalnızca sert bounce'ları sayar. Yumuşak bounce'ları ayrı bir seride izleyin; böylece geçici bir posta kutusu sorunu hesap durumunuzu belirleyen sayıyı bozmaz. ### E-posta bounce oranımı hızla nasıl düşürürüm? Her sert bounce'lu adresi uygulama katmanında bastırın, kayıtta adresleri sözdizimi ve MX kontrolüyle doğrulayın ve en yüksek orana sahip içe aktarmayı ya da kaynağı göndermeyi durdurun. Kaynağı düzeltmek, tüm listeyi temizlemekten daha etkilidir. ### Blok, sert bounce ile aynı şey mi? Hayır. Blok, adresin geçersizliğinden değil IP'nizden, alan adı itibarınızdan ya da kimlik doğrulamadan kaynaklanan 5.x.x reddidir. Bunu sert bounce saymak, sorun gönderim altyapınızdayken listeyi kötü gösterir.