Mailim Geri Döndü: Bounce Mesajı Nasıl Okunur

Bir mail gönderirsiniz, birkaç saniye sonra gelen kutunuza "Mail Delivery Subsystem" ya da "Postmaster" adında bir gönderenden İngilizce bir bildirim düşer: Delivery Status Notification (Failure). İçinde on beş satır anlamsız görünen teknik metin vardır. Çoğu kullanıcı bu ekranın görüntüsünü alıp doğrudan hosting desteğine açar; oysa o metnin içinde sorunun kimde olduğunu birebir söyleyen tek bir satır vardır ve onu bulmak beş saniye sürer. Mail geri döndü diye arattığınızda karşınıza çıkan Türkçe sayfalar genellikle "spam klasörüne bakın" düzeyinde kalır, çünkü bildirimdeki satırların ne anlama geldiğini kimse açıklamaz.

Bu yazıda geri dönen e-posta bildirimini (bounce) satır satır sökeceğiz: hangi satır alıcıyı, hangisi reddeden sunucuyu, hangisi gerçek hata metnini taşır; kalıcı (hard) bounce ile geçici (soft) bounce nasıl ayrılır; 5.1.1, 4.2.2, 5.7.26 gibi durum kodları nasıl okunur ve her biri için ne yapılır. Sonunda elinizde, gelen bildirime bakıp "bu benim sunucumun sorunu değil, alıcının kutusu dolu" diyebileceğiniz bir karar mekanizması olacak. Komutlar Postfix ve Exim (cPanel) tarafı için verilecek, panel adımları da eklenecek.

Bounce Mesajı Nedir ve Kim Gönderir#

Bounce, mailinizi teslim edemeyen bir sunucunun size gönderdiği otomatik iade bildirimidir. Burada kritik nokta şudur: bounce'u her zaman size en yakın sunucu yazar, ama hata metnini genellikle karşı taraf üretmiştir.

Bir mail yolculuğu şöyledir: Outlook/Roundcube → sizin gönderim sunucunuz (SMTP) → alıcının MX sunucusu → alıcının posta kutusu. Bu zincirin herhangi bir halkasında iş tıkanırsa, tıkandığı yerdeki sunucu bir hata döner; sizin sunucunuz o hatayı alır, kendi başlığını ekler ve size "Undelivered Mail Returned to Sender" başlıklı bir mesaj yollar. Yani gelen bildirimin zarfı sizin sunucunuza, içindeki hata metni genelde alıcının sunucusuna aittir. Bu ayrımı kurmadan bounce okumak mümkün değildir.

İki tür bounce vardır ve isimlendirme İngilizce kaynaklarda standarttır:

• Hard bounce (kalıcı): Adres yok, alan adı yok, sunucu kalıcı olarak reddediyor. Tekrar denemek anlamsızdır; sunucu zaten denemez.
• Soft bounce (geçici): Kutu dolu, sunucu meşgul, ağ zaman aşımı, hız sınırı. Gönderim sunucunuz mesajı kuyrukta tutar ve saatlerce yeniden dener. Size gelen ilk bildirim çoğu zaman "delayed" (gecikti) uyarısıdır, gerçek iade birkaç gün sonra gelir.

Bu ayrımı yapan şey, hata metninin başındaki sayının ilk rakamıdır: 5 ile başlıyorsa kalıcı, 4 ile başlıyorsa geçicidir. Kodların ayrıntılı tablosu için SMTP hata kodları ve anlamları yazısına da bakmanızı öneririm; burada bildirim metnini okumaya odaklanacağız.

Geri Dönen Mailde Hangi Satırlar Önemli#

Standart bir bounce bildiriminin gövdesinde, RFC 3464 formatında bir "delivery status" bloğu bulunur. Tipik bir örnek:

Reporting-MTA: dns; mail.ornekfirma.com.tr
X-Postfix-Queue-ID: 4B2xY13Zk1z
X-Postfix-Sender: rfc822; [email protected]
Arrival-Date: Mon, 11 Aug 2026 09:12:44 +0300

Final-Recipient: rfc822; [email protected]
Original-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx1.hedefdomain.com
Diagnostic-Code: smtp; 550 5.1.1 <[email protected]>: Recipient
    address rejected: User unknown in virtual mailbox table

Bu bloktaki satırların işlevi:

Yıllardır gördüğüm en yaygın hata, kullanıcıların bildirimin en üstündeki genel açıklamayı ("Your message wasn't delivered") okuyup Diagnostic-Code satırını hiç görmemesi. O satır çoğu mail istemcisinde alıntı bloğunun içinde, küçük puntoyla ve bazen "Ayrıntıları göster" bağlantısının arkasında durur. Gmail arayüzünde bildirimin altındaki üç noktaya tıklayıp "Orijinali göster" dediğinizde tam metni ham hâliyle görürsünüz.

Bildirimi ham hâlde görmenin yolu#

• Gmail: Mesajı açın → sağ üstteki üç nokta → Orijinali göster.
• Outlook masaüstü: Mesajı çift tıklayarak ayrı pencerede açın → Dosya → Özellikler → İnternet üstbilgileri.
• Roundcube: Mesajı açın → Diğer → Kaynağı göster. Roundcube webmail kullanımı yazısında arayüzün geri kalanını da bulabilirsiniz.

Durum Kodu (Status) Nasıl Okunur#

DSN durum kodu X.Y.Z biçimindedir ve üç parçanın her biri ayrı bir soruya cevap verir: birinci hane kalıcılığı, ikinci hane sorunun sınıfını, üçüncü hane ayrıntıyı söyler.

• Birinci hane: 2 başarılı, 4 geçici hata, 5 kalıcı hata.
• İkinci hane: 0 genel, 1 adresleme, 2 posta kutusu, 3 sunucu/sistem, 4 ağ ve yönlendirme, 5 protokol, 7 güvenlik/politika.
• Üçüncü hane: ayrıntı; sunucudan sunucuya küçük farklılıklar gösterebilir.

Bu şemayı bir kez kavradığınızda hiç görmediğiniz bir kodu bile yorumlayabilirsiniz. 4.4.1 gördüğünüzde "geçici (4), ağ sorunu (4)" dersiniz: karşı sunucuya bağlanılamıyor, kendiliğinden düzelebilir. 5.7.1 gördüğünüzde "kalıcı (5), güvenlik politikası (7)" dersiniz: karşı sunucu sizi bilerek reddediyor, ağ sorunu değil.

En sık karşılaşılan kodlar ve karşılıkları:

Tablodaki "sorun kimde" sütunu bu yazının asıl faydasıdır: 5.1.1 aldıysanız hosting firmanızı aramanın hiçbir faydası yoktur, çünkü karşı sunucu adresin var olmadığını söylüyor. Buna karşılık 5.7.1 veya 5.7.26 aldıysanız top tamamen sizdedir.

Diagnostic-Code Satırındaki Metni Yorumlama#

Kodlar tabloyu verir, ama asıl bilgi Diagnostic-Code satırındaki serbest metindedir. Aynı 550 kodunun arkasında bambaşka üç sorun olabilir. Gerçek örnekler ve karşılıkları:

Örnek 1 — alıcı yok:

Diagnostic-Code: smtp; 550 5.1.1 <[email protected]>: Recipient address
    rejected: User unknown in virtual mailbox table

Karşı sunucu "böyle bir kullanıcı yok" diyor. Adreste yazım hatası, kapatılmış hesap ya da işten ayrılmış personel olması muhtemel. Yapılacak: adresi doğrulamak.

Örnek 2 — relay reddi:

Diagnostic-Code: smtp; 554 5.7.1 <[email protected]>: Relay access denied

Bu, "senin adına başkasına mail taşımam" demektir ve neredeyse her zaman kimlik doğrulamasız bağlanmaktan kaynaklanır. Mail programınız giden sunucuda kimlik doğrulamayı kapatmıştır ya da yanlış sunucu adına bağlanıyorsunuzdur. Ayrıntılı teşhis için SMTP kimlik doğrulama hatası yazısındaki kontrol listesini uygulayın.

Örnek 3 — DMARC politikası:

Diagnostic-Code: smtp; 550-5.7.26 Unauthenticated email from ornekfirma.com.tr is not
    accepted due to domain's DMARC policy. Please contact the administrator of
    ornekfirma.com.tr domain.

Burada suçlanan sizin alan adınızdır. Gönderdiğiniz mail SPF veya DKIM doğrulamasını geçemiyor, DMARC politikanız da p=reject olduğu için Google mesajı düşürüyor. Çözüm DNS tarafındadır; SPF, DKIM ve DMARC kayıtları yazısındaki adımlarla kayıtlarınızı doğrulamanız gerekir.

Örnek 4 — itibar/kara liste:

Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host [203.0.113.45]
    blocked using zen.spamhaus.org

Gönderim yaptığınız IP bir kara listede. Bu durumda kimlik doğrulaması, SPF, her şey doğru olsa bile mail girmez. Mail blacklist sorgulama ve çıkma sürecini başlatmanız, aynı zamanda IP'nin neden listelendiğini (sunucudaki bir sitenin spam göndermesi gibi) bulmanız gerekir.

Örnek 5 — hız sınırı:

Diagnostic-Code: smtp; 421 4.7.0 [TSS04] Messages from 203.0.113.45 temporarily
    deferred due to unexpected volume or user complaints

Kod 4 ile başlıyor, yani geçici. Fazla hızlı gönderim yapıyorsunuz veya alıcılar "spam" işaretlemiş. Toplu gönderim yapıyorsanız hızınızı düşürmeniz ve listenizi temizlemeniz gerekir.

Sorun Sizde mi Karşı Tarafta mı: Karar Sırası#

Bir bounce geldiğinde şu sırayı izleyin; her adım bir sonrakini gereksiz kılabilir.

1. Action satırına bakın. delayed ise henüz iade değildir; mail kuyrukta, sunucu denemeye devam ediyor. Hiçbir şey yapmayın, ikinci bildirimi bekleyin.
2. Status kodunun ilk rakamına bakın. 4 ise geçicidir; genelde beklemek çözer. 5 ise kalıcıdır, müdahale gerekir.
3. Status kodunun ikinci rakamına bakın. 1 veya 2 ise sorun alıcı adresi/kutusuyla ilgilidir, yani karşı taraftadır. 7 ise sorun politika/güvenliktir ve büyük olasılıkla sizdedir.
4. Diagnostic-Code metnini okuyun. İçinde relay, authentication, DMARC, SPF, blocked, blacklist kelimelerinden biri geçiyorsa sorun sizde; user unknown, no such user, over quota, mailbox full geçiyorsa karşı taraftadır.
5. Aynı hata tek adrese mi geliyor, herkese mi? Tek adrese geliyorsa o adres bozuktur. Gönderdiğiniz herkese geliyorsa sunucunuzda/DNS'inizde sistemik bir sorun vardır.

Beşinci adım tek başına en hızlı ayrımdır. Bir test için farklı sağlayıcılarda (Gmail, Outlook, kurumsal bir adres) üç ayrı hedefe aynı anda mail atın: üçü de dönüyorsa DNS/kimlik doğrulama/IP itibarı tarafına bakın; sadece biri dönüyorsa o hedefin sorunudur.

Sunucu Tarafında Kuyruk ve Log İncelemesi#

Kendi sunucunuzu yönetiyorsanız bildirim beklemenize gerek yok; mail zaten kuyrukta durur ve neden bekliyor olduğunu size söyler.

Postfix kullanıyorsanız:

# Kuyruktaki mailleri ve bekleme sebeplerini listele
mailq

# Belirli bir mesajın tam içeriğini ve başlıklarını gör
postcat -q 4B2xY13Zk1z

# Bir alıcıya ait tüm teslim satırlarını logdan çek
grep "[email protected]" /var/log/mail.log | tail -40

# Kuyruğu hemen yeniden denemeye zorla
postqueue -f

mailq çıktısının sağında her mesajın altında parantez içinde sebep yazar; bu, bildirimdeki Diagnostic-Code ile aynı metindir ve saatler önce oradadır.

cPanel/WHM sunucularında posta yazılımı Exim'dir:

# Kuyruk listesi
exim -bp

# Belirli mesajın log satırları
exim -Mvl 1uJ2xY-0004aB-9K

# Ana log içinde arama
grep "[email protected]" /var/log/exim_mainlog | tail -40

Kabuk erişiminiz yoksa cPanel'in E-posta → E-posta Teslimatını İzle (Track Delivery) ekranı aynı bilgiyi arayüzde verir: her satırın sonundaki "Teslimat Ayrıntıları" simgesi, karşı sunucunun ham cevabını gösterir. Paylaşımlı hosting kullanıcıları için bu ekran, bounce metnini beklemeden görmenin en pratik yoludur.

Gönderim yolunun kendisini sınamak isterseniz SMTP test aracı ile port/TLS uyumunu kontrol edebilir, ürettiği openssl ve swaks komutlarını kendi terminalinizde çalıştırarak elle bir SMTP oturumu açabilirsiniz. Elle bağlanıp MAIL FROM / RCPT TO yazdığınızda karşı sunucunun cevabını canlı görürsünüz — bu, bounce metnini beklemeden aynı bilgiyi almanın en kısa yoludur.

Sık Yapılan Yorumlama Hataları#

"Bounce geldi, demek ki hosting bozuk." Hayır. Bounce, sisteminizin çalıştığının kanıtıdır; bozuk bir sistem hiç cevap vermez. Bildirimin gelmesi, mailinizin işlendiğini ve bir noktada bilinçli olarak reddedildiğini gösterir.

"5.1.1 aldım, SPF kaydımı düzelteyim." SPF 5.7.x ailesini ilgilendirir. 5.1.1 alıcının adresiyle ilgilidir; SPF'e dokunmak hiçbir şey değiştirmez, üstelik çalışan bir kaydı bozma riski taşırsınız.

"421 aldım, hemen tekrar göndereyim." 4 ile başlayan kodlarda tekrar tekrar göndermek durumu kötüleştirir; karşı sunucu bunu ısrarcı davranış olarak görüp kalıcı bloka çevirebilir. Kuyruk zaten yeniden deneyecektir.

"Kendi adresime attım, geldi; demek ki sorun yok." Kendi sunucunuz içindeki teslimat dış dünyaya çıkmaz; SPF, DKIM, PTR ve IP itibarı hiç devreye girmez. Test mutlaka dış bir sağlayıcıya yapılmalıdır.

"Bildirimdeki e-posta adresine cevap yazayım." MAILER-DAEMON veya postmaster adresleri çoğunlukla otomasyondur; yazdığınız cevabı okuyan kimse yoktur.

Bounce Oranını Baştan Düşürmek#

Tek tek mail atan bir kullanıcıysanız bounce nadirdir. Ama sitenizden otomatik bildirim gönderiyor veya toplu duyuru yapıyorsanız, bounce oranı doğrudan itibar puanınıza yazılır ve bir eşiği geçtiğinizde normal mailleriniz de düşmeye başlar. Korunma yolları:

1. Hard bounce alan adresi listeden anında silin. 5.1.1 almış bir adrese ikinci kez göndermek, alıcı sunucularına "listesini temizlemiyor" sinyali verir.
2. Soft bounce'ları sayın. Aynı adres üst üste birkaç kez 4.2.2 veriyorsa pratikte ölü kabul edin.
3. Kayıt formlarına doğrulama koyun. Çift opt-in, yani kayıt sonrası onay maili, listeye yazım hatalı adres girmesini büyük ölçüde engeller.
4. DNS üçlünüzü tamamlayın. SPF, DKIM ve DMARC eksikse 5.7.26 ailesi kaçınılmazdır.
5. PTR kaydınızı tanımlayın. Kendi IP'nizden gönderiyorsanız PTR kaydı ve ters DNS tanımı yapılmadan büyük sağlayıcılara giriş şansınız düşüktür.
6. Gönderim hızını sınırlayın. Aynı anda binlerce mesaj yerine dakikada sabit sayıda gönderim, 421 ailesini büyük ölçüde önler.

Sıkça Sorulan Sorular#

Mail geri döndü ama karşı taraf maili aldığını söylüyor#

Bu durumda büyük olasılıkla mail birden fazla alıcıya gitmiştir ve yalnızca biri başarısız olmuştur. Bounce bildirimindeki Final-Recipient satırına bakın; orada yazan adres, teslim edilemeyen tek adrestir. Diğer alıcılar mesajı sorunsuz almış olabilir. Bir diğer ihtimal, alıcının sunucusunun mesajı önce kabul edip sonra iç dağıtımda hata vermesidir; bu durumda mesaj karşı tarafın sisteminde kalmış ama posta kutusuna düşmemiştir.

Hard bounce ile soft bounce arasındaki fark nedir#

Hard bounce kalıcı bir reddir ve durum kodu 5 ile başlar: adres yok, alan adı yok veya sunucu sizi kesin olarak reddediyordur. Soft bounce geçicidir ve kod 4 ile başlar: kutu dolu, sunucu meşgul ya da ağ ulaşılamıyordur. Soft bounce'ta gönderim sunucunuz mesajı kuyrukta tutar ve genellikle birkaç gün boyunca artan aralıklarla yeniden dener; bu süre sonunda teslim edemezse kalıcı iade bildirimi gönderir. Hard bounce'ta ise ilk denemede işlem biter, tekrar deneme yapılmaz.

Bounce mesajında hangi satır gerçek hatayı gösterir#

Gerçek hata Diagnostic-Code satırındadır. Bu satır, alıcının sunucusunun ham SMTP cevabını olduğu gibi taşır ve hem sayısal kodu hem de açıklama metnini içerir. Bildirimin en üstündeki genel açıklama cümlesi çoğu zaman standart bir şablondur ve teşhis için yeterli bilgi vermez. Diagnostic-Code bazen iki satıra bölünmüş olarak görünür; devam satırı boşlukla girintilenmiştir ve o da metnin parçasıdır.

Kod 5.7.1 aldım, ne yapmalıyım#

5.7.1 kalıcı bir politika reddidir ve sorun neredeyse her zaman gönderen taraftadır. Önce Diagnostic-Code metnini okuyun: "Relay access denied" yazıyorsa mail programınızda giden sunucu kimlik doğrulaması kapalıdır. "blocked using" ifadesi ve bir liste adı geçiyorsa IP'niz kara listededir. "not authorized" veya "sender rejected" ifadesi varsa SPF kaydınız gönderim yaptığınız sunucuyu kapsamıyordur. Her üç durumun da çözümü farklıdır, bu yüzden metni okumadan işlem yapmayın.

Gmail'e attığım mailler geri dönüyor ama diğerlerine gidiyor#

Bu tablo, teknik yapınızda büyük sağlayıcıların zorunlu tuttuğu bir gerekliliğin eksik olduğunu gösterir. Küçük sunucular SPF/DKIM eksikliğini görmezden gelebilirken Gmail bunu doğrudan reddeder. Bounce metninde 5.7.26 görüyorsanız kimlik doğrulama kayıtlarınız eksiktir. 5.7.25 görüyorsanız gönderim IP'nizin ters DNS kaydı yoktur veya hostname ile uyuşmuyordur. Her iki durumda da düzeltme DNS tarafında yapılır ve yayılması birkaç saat sürebilir.

Bounce mesajını sildim, tekrar nasıl görebilirim#

Sunucu erişiminiz varsa posta loglarında aynı bilgi durur; Postfix için /var/log/mail.log, cPanel/Exim için /var/log/exim_mainlog dosyasında alıcı adresini aratmanız yeterlidir. Paylaşımlı hosting kullanıyorsanız cPanel'in "E-posta Teslimatını İzle" ekranı son günlerin teslim kayıtlarını ve her birinin hata metnini saklar. Bunların hiçbirine erişemiyorsanız aynı adrese tek bir test maili göndererek bounce'u yeniden üretebilirsiniz; kalıcı hatalar aynı sonucu verecektir.

Delayed bildirimi aldım, mail gitti mi#

Hayır, henüz gitmedi ama kaybolmadı da. "Delayed" bildirimi, sunucunuzun mesajı teslim edemediğini ancak denemeye devam ettiğini bilmeniz için gönderilen bir ara uyarıdır; Action: delayed satırıyla ayırt edilir. Sunucu genellikle birkaç gün boyunca yeniden dener. Bu süre içinde teslim gerçekleşirse size ikinci bir bildirim gelmez, mail sessizce ulaşır. Süre dolarsa Action: failed içeren kalıcı bir iade bildirimi alırsınız.

Toplu gönderimde bounce oranı kaç olmalı#

Sağlıklı bir listede hard bounce oranı yüzde birin altında tutulmalıdır. Bu oran yükseldiğinde alıcı sağlayıcıları listenizin bakımsız olduğunu varsayar ve gönderim itibarınız düşer; sonuç olarak geçerli adreslere gönderdiğiniz mailler de spam klasörüne düşmeye başlar. Oranı düşük tutmanın en etkili yolu, hard bounce alan adresleri gönderim sonrası otomatik olarak listeden çıkarmak ve kayıt formlarında onay maili (çift opt-in) kullanmaktır.

Kapanış#

Geri dönen bir mail bildirimini okumak, göründüğünden çok daha basit bir işlemdir: Action satırı bunun kalıcı bir iade mi yoksa geçici bir uyarı mı olduğunu, Status kodunun ilk iki rakamı sorunun sınıfını, Diagnostic-Code satırı da gerçek sebebi söyler. Bu üç satıra bakmayı alışkanlık hâline getirdiğinizde, destek talebi açmadan önce sorunun sizde mi karşı tarafta mı olduğunu kendiniz belirleyebilirsiniz. Kalıcı hatalarda tekrar denemek zaman kaybıdır; geçici hatalarda ise sabırlı olmak çoğu zaman tek doğru davranıştır.

Kurumsal e-posta altyapınızı kurarken SPF, DKIM, DMARC ve PTR kayıtlarının doğru tanımlanması bounce'ların büyük kısmını daha oluşmadan engeller; bu tarafta desteğe ihtiyacınız varsa kurumsal e-posta çözümleri sayfasındaki paketler kayıtların kurulumunu da kapsar. Sitenizden çıkan otomatik bildirimler ya da düzenli duyuru gönderimleri için ayrı bir gönderim altyapısı kurmak istiyorsanız SMTP sunucu paketleri hazır yapılandırmayla teslim edilir. Mail trafiğiyle birlikte site barındırmayı tek yerden yönetmek isteyen firmalar için kurumsal hosting paketleri, gönderim kotası ve teslimat izleme araçlarıyla birlikte gelir.