Bounce Yönetimi: Hard ve Soft Bounce Farkı

Gönderdiğiniz mektup alıcıya ulaşmadığında geri gelen bildirime bounce denir ve bu bildirimlerin nasıl ele alındığı, e-posta altyapınızın kaderini doğrudan belirler. Bounce yönetimi yapmayan bir sistem, var olmayan adreslere haftalarca göndermeye devam eder; alıcı sağlayıcılar bunu "listesini temizlemeyen gönderici" olarak okur ve bir süre sonra sadece o adresleri değil, tüm gönderimlerinizi filtrelemeye başlar.

Bu yazıda hard bounce ile soft bounce arasındaki farkı, SMTP hata kodlarının hangi rakamının ne anlattığını, bir bounce mesajının içinden gerçek sebebi nasıl çıkaracağınızı, hangi adresi ne zaman kalıcı olarak listeden çıkarmanız gerektiğini ve Postfix üzerinde bunu otomatikleştirmenin pratik yollarını anlatacağım. Amacım, geri dönen her mektuba tek tek bakmak yerine kural tabanlı çalışan bir sistem kurmanızı sağlamak.

Bounce Nedir ve Kim Üretir#

Bir mektup iki farklı noktada geri dönebilir. Oturum sırasında (synchronous): sizin sunucunuz alıcı sunucuya bağlanır, RCPT TO komutunu gönderir ve karşı taraf hemen 550 5.1.1 User unknown gibi bir cevap verir. Bu durumda mektup hiç teslim edilmez, hatayı anında görürsünüz ve loglara düşer. Teslimden sonra (asynchronous): alıcı sunucu mektubu 250 OK ile kabul eder, sonra iç sistemine yönlendirirken adresin olmadığını fark eder ve size ayrı bir bildirim mektubu (DSN — Delivery Status Notification) gönderir.

İkinci tür daha sinsidir, çünkü loglarınızda mektup "gönderildi" olarak görünür; hata ise dakikalar hatta saatler sonra gönderici adresinize düşer. Bu yüzden bounce yönetimi yalnızca logları okumakla olmaz, geri dönen bildirimleri toplayan ve işleyen bir adres (bounce adresi) tanımlamanız gerekir. Zarftaki MAIL FROM alanına, kullanıcıya görünen From: adresinden farklı bir bounce adresi koymak standart uygulamadır:

; Kullanıcının gördüğü adres
From: Firmanız Bülten <[email protected]>
; Zarfta, geri dönüşlerin geleceği adres
MAIL FROM: <[email protected]>

Buradaki rastgele kimlik sayesinde geri gelen bildirimi hangi gönderime ve hangi aboneye ait olduğunu ayrıştırabilirsiniz. Bu tekniğe VERP (Variable Envelope Return Path) denir ve toplu gönderim yapan her sistemin uygulaması gereken temel bir düzendir.

Hard Bounce ile Soft Bounce Arasındaki Fark#

Ayrım basittir: hard bounce kalıcı bir hatadır, tekrar denemenin anlamı yoktur ve adres derhal listeden çıkarılmalıdır. Soft bounce geçicidir, sebep ortadan kalktığında teslimat gerçekleşebilir ve sunucunuz zaten belirli aralıklarla yeniden dener.

Tehlikeli olan orta bölgedir. Bazı sağlayıcılar itibar temelli engellemeleri 4xx ile bildirir; bu teknik olarak soft bounce'tur ama sebep geçici bir yoğunluk değil, sizinle ilgili bir karardır. Bu yüzden soft bounce'ları kör bir şekilde "sorun yok, tekrar denenir" diye geçmeyin — gerekçe metnini okuyun. Aynı adrese art arda gelen soft bounce'lar da bir noktada hard bounce gibi işlenmelidir; yaygın kural, beş ardışık soft bounce'tan sonra adresi pasife almaktır.

Bir başka tuzak, kapatılmış posta kutularının bazı sistemlerde önce 4.2.2 Mailbox full sonra 5.1.1 User unknown döndürmesidir. Kutunun dolması geçici görünse de, kullanıcının artık o kutuyu hiç açmadığının işareti olabilir. Bu yüzden aylardır soft bounce veren adresleri de temizlemek gerekir; bunlar geri dönüştürülmüş spam tuzağına dönüşme riski en yüksek kayıtlardır.

SMTP Hata Kodlarını Okumak#

Bir SMTP cevabı iki katmanlı kod taşır: klasik üç haneli yanıt kodu (550) ve genişletilmiş durum kodu (5.1.1). İkincisi daha bilgilendiricidir ve üç parçadan oluşur: sınıf, alt konu, ayrıntı.

5.7.x ailesi özel dikkat ister, çünkü bunlar adresle değil sizinle ilgili retlerdir. 5.7.1 Message rejected due to policy gördüğünüzde adresi silmek sorunu çözmez; kimlik doğrulama, içerik ya da itibar tarafında bir şey bozulmuş demektir. 5.7.26 özellikle nettir: alıcı, SPF ve DKIM'in ikisinden birinin de geçmediğini söylüyordur. Bu durumda SPF kaydı yazma rehberi ile kaydınızı, DKIM tarafında ise DKIM doğrulaması başarısız yazısıyla imzanızı gözden geçirin.

Bir bounce bildiriminin içindeki asıl bilgi, ekli message/delivery-status bölümündedir. Metin gövdesindeki insan diliyle yazılmış açıklama değil, şu alanlar bağlayıcıdır:

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown

Otomatik işleme yazarken Status alanını temel alın; Diagnostic-Code içindeki serbest metin sağlayıcıdan sağlayıcıya değişir ve düzenli ifadeyle ayrıştırmaya çalışmak kırılgan bir çözümdür.

Postfix Üzerinde Bounce'ları Toplamak ve İşlemek#

Postfix, teslim edemediği mektuplar için bildirim üretir ve bunu zarftaki gönderici adresine yollar. İlk adım, bu bildirimleri toplayacak bir adres tanımlamak ve o adresi bir işleyiciye bağlamaktır. Basit bir kurulumda /etc/aliases üzerinden bir script'e boru bağlantısı yeterlidir:

# /etc/aliases
bounce-handler: "|/usr/local/bin/bounce-isle.sh"

Değişiklikten sonra alias veritabanını yeniden derleyin:

sudo newaliases
sudo systemctl reload postfix

Kuyrukta bekleyen ve henüz sonuçlanmamış mektupları da izlemeniz gerekir; çünkü bir mektup soft bounce alıp kuyrukta beklerken henüz hiçbir bildirim üretilmemiştir. Kuyruk durumunu ve bekleme sebebini görmek için:

# Kuyruktaki mektup sayısı
postqueue -p | tail -1

# Kuyruktaki mektupların bekleme gerekçeleri, en sık görülenler
postqueue -p | grep -A1 '^[0-9A-F]' | grep -v '^[0-9A-F]' \
  | sed 's/^ *//' | cut -c1-70 | sort | uniq -c | sort -rn | head

Kuyruğun nasıl okunacağını, tek bir mektubun nasıl inceleneceğini ve güvenli boşaltma yöntemlerini Postfix kuyruk yönetimi yazısında ayrıntılı anlatıyorum. Bir mektubun neden reddedildiğini log satırından okumak içinse mail loglarını okuma rehberi işinizi görecektir.

Loglardan doğrudan kalıcı hatalı adresleri çıkarmak, elde hazır bir bounce işleyiciniz yoksa hızlı bir başlangıçtır:

# Son bir günün 5.x.x kalıcı hatalarından adres listesi çıkar
grep "status=bounced" /var/log/mail.log \
  | grep -oE 'to=<[^>]+>.*said: 5\.[0-9]\.[0-9]' \
  | grep -oE '<[^>]+>' | tr -d '<>' | sort -u > /tmp/hard-bounce.txt

wc -l /tmp/hard-bounce.txt

Bu listeyi kampanya aracınızın "suppression" (bastırma) listesine aktarın. Bastırma listesi silinen adresten farklıdır: adres listeden çıkarılsa bile birisi onu yeniden içe aktarabilir, bastırma listesi bunu kalıcı olarak engeller.

Bounce Oranı Eşikleri ve Liste Hijyeni#

Bounce oranı, gönderilen mektup sayısına bölünen geri dönen mektup sayısıdır ve ayrı ayrı hesaplanmalıdır. Hard bounce oranı liste kalitenizin, soft bounce oranı ise altyapı ve itibar durumunuzun göstergesidir.

Yüksek hard bounce oranı neredeyse her zaman üç kaynaktan gelir: satın alınmış listeler, kayıt formunda doğrulama olmaması ve uzun süre kullanılmayan listelerin yeniden devreye alınması. Üçünün de çözümü aynıdır — çift onay (double opt-in). Kayıt sırasında gönderilen onay mektubuna tıklamayan adres listeye hiç girmez; bu tek uygulama, hard bounce ve spam tuzağı riskini birden aşağı çeker.

Rutin hijyen için şu takvimi öneririm:

1. Her gönderimden sonra: hard bounce alan adresleri bastırma listesine ekleyin.
2. Haftalık: art arda beş soft bounce almış adresleri pasife alın.
3. Aylık: son 6 ayda hiç açmamış kayıtları ayrı bir segmente taşıyın.
4. Üç ayda bir: bu segmente yeniden etkileşim kampanyası gönderin, yanıt vermeyeni listeden çıkarın.
5. Yılda bir: kayıt formundaki doğrulamayı ve çift onay akışını test edin.

Etkileşimsiz kayıtları silmek her zaman zor bir karardır, çünkü liste küçülür. Ancak sağlayıcıların gözünde 10 bin kişilik temiz bir liste, 50 bin kişilik kirli bir listeden çok daha değerlidir; ikincisi gelen kutusu yerleşiminizi düşürerek aslında ulaşabildiğiniz kişi sayısını da azaltır. Bu bağlantıyı gönderici itibarı nedir yazısında sayılarla ele aldım.

Sık Yapılan Hatalar#

Bounce adresini noreply@ yapmak ve hiç okumamak. Geri dönen bildirimler bir yere düşer ama kimse bakmaz; sonuç, aylarca var olmayan adreslere gönderim yapmaktır. Bounce adresi mutlaka işlenen bir adres olmalıdır.

Tüm 4xx'leri görmezden gelmek. 4.7.0 Poor reputation mesajı teknik olarak geçicidir ama size "hacmi kıs" diyor demektir. Bunu normal bir yoğunluk gecikmesi sanıp aynı hacimde devam etmek, birkaç gün içinde 5xx'e dönüşür.

Hard bounce'u sadece pasife almak, bastırmamak. Adres pasife alınır, sonra bir CSV içe aktarımıyla geri gelir ve döngü yeniden başlar. Bastırma listesi bu döngüyü kırar.

Otomatik yanıtları bounce sanmak. "Ofis dışındayım" mesajları ve tatil yanıtları bounce değildir; işleyicinizin bunları Auto-Submitted başlığına bakarak ayırt etmesi gerekir, aksi halde sağlıklı adresleri listeden çıkarırsınız.

Geri dönenleri temizlerken ilk gönderimde acele etmek. Yeni bir sunucuya geçtiğinizde ilk günlerdeki bazı 4xx retler greylisting kaynaklıdır ve tamamen normaldir; ayrıntısı greylisting ve mail gecikmesi yazısındadır. Bunları hard bounce gibi işlemek geçerli adresleri kaybettirir.

Sıkça Sorulan Sorular#

Hard bounce alan adresi ne zaman silmeliyim#

Hemen. Kalıcı bir 5xx hatası, adresin var olmadığını ya da kalıcı olarak kapatıldığını söyler; bir sonraki gönderimde tekrar denemek yalnızca bounce oranınızı yükseltir. Adresi listeden çıkarmakla kalmayın, bastırma listesine ekleyin ki ileride bir içe aktarımla geri gelmesin. Tek istisna 5.7.x politika retleridir; bunlar adresle değil sizinle ilgilidir.

Soft bounce kaç kez tekrarlanırsa listeden çıkarmalıyım#

Yaygın ve makul kural, aynı adrese art arda beş gönderimde soft bounce alındığında adresi pasife almaktır. Kutunun geçici olarak dolması normaldir, ancak haftalarca dolu kalan bir kutu artık kullanılmayan bir hesabın işaretidir ve zamanla geri dönüştürülmüş spam tuzağına dönüşebilir. Sayacı adres bazında tutun ve başarılı bir teslimde sıfırlayın.

Bounce oranı kaç olmalı#

Hard bounce oranınız binde beşin altında olmalıdır; yüzde ikinin üzerine çıkması ciddi bir liste kalitesi sorununa işaret eder. Soft bounce oranı için tek bir eşik vermek zordur, çünkü alıcı taraftaki geçici koşullara bağlıdır; yüzde beşin üzerine çıkması ve sürekli kalması genellikle hız sınırı veya itibar uyarısı anlamına gelir.

Bounce mesajının içindeki gerçek sebebi nasıl bulurum#

Bounce bildiriminin insan diliyle yazılmış açıklamasına değil, ekli message/delivery-status bölümündeki Status ve Diagnostic-Code alanlarına bakın. Status alanı standart üç parçalı kodu verir ve otomatik işleme için güvenilir olan budur. Diagnostic-Code içindeki metin sağlayıcıya göre değişir, sadece insan okuması için kullanın.

Kendi sunucumdaki bounce'ları nasıl otomatik işlerim#

Zarfta ayrı bir bounce adresi kullanın ve bu adresi /etc/aliases üzerinden bir işleyici script'e bağlayın. Script gelen DSN mektubunu ayrıştırıp Status kodu 5. ile başlıyorsa adresi bastırma listesine, 4. ile başlıyorsa soft bounce sayacına yazsın. VERP kullanırsanız hangi gönderime ait olduğunu da ayrıştırabilirsiniz.

Bounce ile spam şikâyeti aynı şey mi#

Hayır, iki farklı sinyaldir. Bounce, mektubun teslim edilememesidir ve alıcı sunucudan gelir. Spam şikâyeti ise mektup teslim edildikten sonra kullanıcının "bunu spam olarak işaretle" demesidir ve size ancak feedback loop kaydınız varsa ulaşır. İkisi de itibarı etkiler, ama şikâyet genellikle çok daha ağır cezalandırılır.

Kapanış#

Bounce yönetimi, e-posta altyapısının en az ilgi gören ama en yüksek getirili işidir. Aklınızda dört kural kalsın: zarfta işlenen bir bounce adresi kullanın, kalıcı 5xx hatalarını anında bastırma listesine yazın, art arda beş soft bounce alan adresleri pasife alın ve 5.7.x politika retlerini adres sorunu değil altyapı sorunu olarak ele alın. Bunları otomatikleştirdiğinizde liste hijyeni kendiliğinden işleyen bir süreç haline gelir.

Kendi gönderim sunucunuzu kurmak isterseniz Postfix ve bounce yapılandırması hazır gelen SMTP sunucu paketlerimize, kurumsal posta kutuları için e-posta çözümlerimize göz atabilirsiniz. Toplu gönderimlerde bounce işleme ve bastırma listesini araç düzeyinde yönetmek isterseniz e-posta pazarlama hizmetimiz bunu üstlenir; sunucu tarafındaki log ve kuyruk takibini devretmek isterseniz sunucu yönetimi hizmetimiz devreye girer.