Deliverability

E-posta Bounce Nedir? Hard Bounce, Soft Bounce ve Suppression Yönetimi

19 Temmuz 2026 · 6 dk okuma · Admin · 01 Ekim 2026 tarihinde güncellendi
Kısa özet
  • Hard bounce (kalıcı teslim hatası) ve soft bounce (geçici teslim hatası), farklı işlemler gerektiren teslim sorunlarıdır.
  • Bazı politika kaynaklı retler adresin geçersiz olduğunu değil, gönderim altyapısında incelenmesi gereken bir sorunu gösterir.
  • Kalıcı hatalı, şikâyet eden ve çıkış isteyen adresler baskılanmalı; geçici hatalar ise nedenine göre değerlendirilmelidir.
  • Liste temizliği, baskılama kayıtlarının korunması ve sunucu yanıtlarının incelenmesi gönderen itibarını korumaya yardımcı olur.

Bounce, bir e-postanın alıcıya teslim edilemeyip gönderen sunucuya geri dönmesidir. Her bounce, alıcı sunucusunun döndürdüğü bir SMTP durum kodu taşır ve bu koda göre iki temel türe ayrılır. Türü doğru anlamak, doğru aksiyonu almanın ve gönderen itibarınızı korumanın anahtarıdır.

Hard bounce — kalıcı hata (SMTP 5.x.x)

Hard bounce, adresin kalıcı olarak teslim edilemediğini gösterir. En yaygın nedenleri: alıcı adresinin var olmaması (user unknown), alan adının geçersiz olması veya sunucunun maili kesin olarak reddetmesidir. Hard bounce eden adreslere bir daha gönderim yapılmamalıdır; tekrar denemek boşuna gönderimdir ve sağlayıcılara "bu gönderen listesini bilmiyor" sinyali vererek itibarınızı bozar.

Önemli istisna — 5.7.x (politika bloğu): Bazı 5.7.1 gibi kodlar aslında adres sorunu değil, IP itibar/politika bloğudur (örneğin Microsoft'un "messages from [IP] weren't sent … block list" yanıtı). Bu durumda sorun alıcı adresi değil, gönderim IP'nizdir. Adresi baskılamak yerine IP itibarını ve gerekiyorsa delisting sürecini ele almalısınız.

Soft bounce — geçici hata (SMTP 4.x.x)

Soft bounce geçici bir sorunu gösterir: alıcının posta kutusu dolu, sunucu geçici olarak kullanılamıyor (greylisting dahil), mesaj boyut sınırını aşıyor gibi. Soft bounce'lar genellikle sistem tarafından belirli aralıklarla otomatik yeniden denenir. Ancak aynı adres ısrarla ve uzun süre soft bounce ediyorsa, pratikte hard bounce gibi ele alınıp baskılanmalıdır.

SenderTR'de nasıl işler? Geçici hata alan işlemsel e-postalar 24 saat, kampanya e-postaları 3 gün boyunca yeniden denenir; süre dolunca ileti geri döndü (soft bounce) olarak kaydedilir. Posta kutusu dolu olduğu için teslim edilemeyen adres, son 90 gün içinde ilk kez 7 gün, ikinci kez 15 gün, üçüncü ve sonraki seferlerde 30 gün geçici olarak engellenir; süre dolunca engel kendiliğinden kalkar. Engel süresince API bu adrese gönderimi suppressed_until tarihiyle reddeder, kredi düşülmez.

Bounce oranı neden bu kadar önemli?

  • Yüksek bounce, sağlayıcılara doğrudan bir kirli liste sinyali verir ve gönderen itibarınızı düşürür.
  • Sektör verilerine göre opt-in listelerde ortalama hard bounce ~%0,2, soft bounce ~%0,7 civarındadır. Toplam bounce oranını %2'nin altında tutmak hedeflenir; %2–5 riskli, %5 ve üzeri tehlikelidir.
  • 2024'te Gmail ve Yahoo kurallarını sıkılaştırdıktan sonra bounce artık "izlenmesi zorunlu" bir metriktir; hata oranları yükseldiğinde hacmi düşürmek gerekir.
  • Bazı geçersiz adresler spam-trap olabilir; bunlara gönderim ciddi ve kalıcı itibar hasarı yaratır.

Suppression (baskılama) listesi nedir?

Suppression listesi, bir daha gönderim yapılmaması gereken adreslerin merkezî kaydıdır. Bu listeye üç grup girer:

  • Hard bounce edenler (kalıcı geçersiz adresler),
  • Şikâyet edenler (maili spam olarak işaretleyenler),
  • Çıkış (unsubscribe) talep edenler.

Bu liste otomatik ve kalıcı uygulanmalıdır: bir adres suppression'a girdiğinde, hangi kampanya olursa olsun o adrese mail gönderilmez. Baskılama, hem yüksek bounce/şikâyeti önler hem de 6563 kapsamında ret taleplerine uymanın teknik karşılığıdır.

Bounce'ları azaltmak için ne yapmalı?

  1. Gönderim öncesi doğrulama: Geçersiz adresleri hiç göndermeden ayıklayın (bkz. liste temizleme).
  2. Double opt-in: Yanlış/sahte adreslerin listeye girmesini baştan engelleyin.
  3. Otomatik suppression: Hard bounce ve şikâyetleri anında baskılayın.
  4. Bounce geri bildirimini gerçek zamanlı işleyin: Sağlayıcı yanıtlarını (webhook/geri besleme) toplayıp listenizi güncel tutun.

SenderTR, gönderim sonrası her sağlayıcının döndürdüğü bounce/şikâyet sonucunu gerçek zamanlı yakalar; hard bounce ve şikâyet eden adresleri otomatik baskılar ve 5.7.x gibi IP-politika bloklarını ayrı ele alarak IP itibarınızı korur. Böylece bounce oranınız düşük, deliverability'niz yüksek kalır.

Liste aktarırken baskılama kayıtlarını nasıl korursunuz?

Yeni bir alıcı listesi hazırlarken yalnızca listenin güncel olup olmadığına bakmayın. Önce eski kampanyalardan kalan baskılama kayıtlarının yeni listeyle karşılaştırılabileceğinden emin olun. Aynı adres farklı kaynaklardan yeniden eklenirse önceki ret, şikâyet veya kalıcı teslim hatası kaydı gözden kaçabilir. Özellikle başka bir araçtan dışa aktarılan dosyaları ve ekiplerin ayrı tuttuğu adres tablolarını bu açıdan inceleyin.

  • Adres alanlarındaki baştaki ve sondaki boşlukları temizleyin; farklı yazımlarla tutulan kayıtları karşılaştırın.
  • Yeni listenin tamamını, gönderim hazırlığından önce mevcut baskılama kayıtlarıyla eşleştirin.
  • Bir kişiye ait farklı adresleri aynı adresmiş gibi değerlendirmeyin; baskılama kararını ilgili kayıt üzerinden verin.
  • Eski bir listeden yeniden aktarılan adresin geçmişte neden çıkarıldığını kontrol edin.

Listenin silinip yeniden yüklenmesi, geçmiş ret taleplerini geçersiz kılmaz. Kaynağı belirsiz bir adresi yalnızca eski bir dosyada bulunduğu için yeniden gönderime açmayın. Böylece liste birleştirme işlemi, daha önce alınmış gönderim kararlarını yanlışlıkla tersine çevirmez.

Geçici teslim hatasını incelerken nereden başlamalısınız?

Tek tek adreslere bakmadan önce hataların aynı kampanyada mı, aynı alıcı alan adında mı, yoksa aynı içerikte mi yoğunlaştığını karşılaştırın. Aynı alıcı alan adına giden iletilerde benzer yanıtlar görülüyorsa, sorun her adresin posta kutusundan kaynaklanmayabilir. Yalnızca belirli bir iletide görülen hatalarda ise iletinin boyutunu ve eklerini incelemek daha anlamlı olabilir.

  • Sunucunun döndürdüğü açıklamayı kodla birlikte okuyun; benzer kodlar farklı ayrıntılar taşıyabilir.
  • Hatanın başladığı zamanı ve etkilenen gönderimleri kaydedin; sorunun sürüp sürmediğini sonraki yanıtlarla karşılaştırın.
  • İleti boyutu sınırına işaret eden yanıtlarda ekleri ve gereksiz büyük görselleri gözden geçirin.
  • Bir alan adında yoğunlaşan geçici retleri, tek bir adresin tekrar eden hatasından ayrı değerlendirin.

Bu inceleme, sorunun adres, ileti veya alıcı sunucusu kaynaklı olup olmadığını anlamaya yardımcı olur. Nedeni belirlemeden tüm adreslere aynı işlemi uygulamak yerine, kararınızı yanıtların ortak özelliğine dayandırın.

Baskılanmış bir adres için düzeltme talebi gelirse ne yapmalısınız?

Bir kişinin yeniden ileti almak istemesi, eski baskılama kaydının doğrudan silinmesi için tek başına yeterli değildir. Önce kaydın neden oluşturulduğunu bulun. Yazım hatası nedeniyle teslim edilemeyen bir adres, düzeltilmiş adresle aynı kayıt değildir; eski geçersiz adres baskılamada kalmalıdır. Çıkış talebi veya şikâyet söz konusuysa, önceki tercihi yok sayarak gönderime devam etmeyin.

  • Talepte belirtilen adresle baskılanan adresin aynı olup olmadığını doğrulayın.
  • Düzeltme gerekiyorsa yeni adresin doğru yazıldığını ve kişiye ait olduğunu teyit edin.
  • Yeniden ileti alma isteğini açık biçimde kaydedin; belirsiz bir yazışmayı izin yerine koymayın.
  • İşlem sırasında baskılama nedenini ve alınan kararı kayıt altında tutun.

Bu ayrım, adres düzeltme işlemini eski bir ret kaydını kaldırma işleminden ayırır. Kararın gerekçesini saklamak, aynı adres daha sonra başka bir listede göründüğünde ne yapılacağını anlamayı kolaylaştırır.

Baskılama kayıtlarına erişimi nasıl düzenlemelisiniz?

Baskılama listesinin doğru tutulması kadar, bu listedeki kararları kimlerin değiştirebildiği de önemlidir. Kampanya hazırlayan herkesin bir kaydı kaldırabilmesi, yanlışlıkla yeniden gönderime yol açabilir. Görevleri ayırın: kampanya ekibi adresin gönderime uygun olup olmadığını görebilsin; baskılama kararını değiştirme yetkisi ise bu işten sorumlu kişilerde bulunsun. Böylece ret ve şikâyet gibi hassas kararlar, gerekçesi anlaşılmadan değiştirilmez.

  • Hangi görevlerin baskılama kaydı eklemeyi, incelemeyi ve kaldırmayı gerektirdiğini belirleyin.
  • Bir kaydı değiştirmeden önce gerekçesini ve dayandığı alıcı yanıtını inceleyin.
  • Değişikliği yapan kişiyi, kararın nedenini ve kaydın önceki durumunu saklayın.
  • Ekipten ayrılan veya görevi değişen kişilerin erişimini gözden geçirin.

Listeleri dışa aktarırken de aynı özeni gösterin. Baskılanmış adreslerin kopyaları farklı ekiplerde dolaşıyorsa güncel gönderim kararından kopuk dosyalar oluşabilir. Dosyanın kimlerle paylaşılacağını sınırlayın ve eski kopyaları yeni kampanyalar için hazır alıcı listesi saymayın. Bir değişiklik sonrasında yalnızca ilgili kayda bakmakla yetinmeyin; değişikliğin gönderim için kullanılan listelere nasıl yansıdığını da kontrol edin. Böyle bir denetim düzeni, hatalı bir işlemin kaynağını bulmayı ve kararın hangi bilgiye dayanarak alındığını açıklamayı kolaylaştırır.

Gönderim sürerken gelen yeni retleri nasıl ele almalısınız?

Uzun süren veya aynı anda hazırlanan gönderimlerde, alıcı listesi seçildikten sonra yeni bir çıkış talebi, şikâyet ya da kalıcı teslim hatası gelebilir. Listeyi yalnızca kampanya hazırlanırken kontrol etmek bu değişikliği yakalamaya yetmeyebilir. Gönderim düzeninizi, adresin gerçekten gönderime alınacağı anda geçerli baskılama kararının dikkate alınacağı şekilde kurun. Kampanyalar ayrı ekiplerce hazırlanıyorsa kararların ortak bir kaynaktan okunması özellikle önem taşır.

  • Gönderim başlamadan önce bekleyen hata ve talep kayıtlarının işlenip işlenmediğini kontrol edin.
  • Gönderim sırasında gelen yeni bir baskılama kararının henüz gönderilmemiş iletilere nasıl uygulanacağını belirleyin.
  • Yanıtların işlenmesinde gecikme fark ederseniz etkilenen gönderimi durdurup bekleyen kayıtları inceleyin.
  • Bir adresin neden gönderime alındığını araştırabilmek için liste seçimiyle gönderim kararını birbirinden ayırarak kaydedin.

Buradaki ayrım önemlidir: ileti alıcı sunucusuna iletildikten sonra gelen bir kayıt, geçmişteki gönderimi geri alamaz; ancak sonraki gönderim kararını değiştirmelidir. Ayrıca aynı adres birden fazla kampanyada yer alıyorsa bir kampanyada alınan ret kararını yalnızca o kampanyanın listesine özgü tutmayın. Uygulamanızı sınarken, gönderim hazırlığı tamamlandıktan sonra gelen bir çıkış talebinin henüz gönderilmemiş iletilerde dikkate alınıp alınmadığını kontrol edin. Böylece baskılama kuralının yalnızca liste hazırlığında değil, gönderimin işleyişinde de geçerli olup olmadığını görürsünüz.

Sık sorulan sorular

Hard bounce eden adrese tekrar gönderebilir miyim?

Hayır. Kalıcı hata verdiği için tekrar denemek itibarınızı bozar; adres baskılanmalıdır.

Soft bounce'lar için ne yapmalı?

Sistem genelde otomatik yeniden dener. Aynı adres uzun süre soft bounce ediyorsa baskılamaya alınmalıdır.

Kabul edilebilir bounce oranı nedir?

Toplam bounce'u %2 altında tutmak önerilir; hard bounce ortalaması opt-in listelerde ~%0,2'dir.

5.7.1 bounce ne anlama gelir?

Genelde IP itibar/politika bloğudur (örn. Microsoft). Sorun alıcı adresi değil gönderim IP'nizdir; adresi baskılamak yerine IP itibarını/delisting'i ele alın.

Bunu SenderTR ile nasıl yönetirsiniz?

Gönderen itibarınızı korumak elle takip edilecek bir iş olmaktan çıkar: kademeli IP warmup, alan adı doğrulama, bounce ve şikâyet geri-beslemesi ile kara liste izleme gönderim akışının içindedir.

← Tüm rehberler