E-posta bounce kodları: nasıl okunur, ne anlama gelir?

Bounce'un ne olduğu, ve gerçekleştiği iki an

“Bounce” sözcüğü kâğıt postadan ödünç alınmıştır ve yanlış bir tablo çizer — sanki mesaj size geri sekip dönüyormuş gibi. Oysa hiçbir şey geri gitmez. Bir mesaj sunucudan sunucuya elden ele geçer, ve onu hâlâ elinde tutan ve bir türlü elinden çıkaramayan son sunucu, eskisi hakkında, size adreslenmiş yeni bir mesaj yazar — ve bunun yerine onu gönderir. Öğrenebileceğiniz her şey o raporun içindedir, ve rapor da ancak onu yazan makine kadar iyidir.

İki çok farklı anda üretilebilir, ve bunları birbirinden ayırt etmek teşhisin çoğunu oluşturur. Bulunduğunuz yerden hata gibi görünen ama öyle olmayan iki sonuç daha vardır:

Yani “bounce oldu” demek iki şeyi birden adlandırır. Biri kendi yazılımınızın size gösterdiği bir hata, diğeri ise bir yabancının makinesinin size yazdığı bir mektuptur, ve okunacak bir rapor yalnızca ikincisinde vardır. Bu rehberin geri kalanı o rapor hakkındadır.

Asıl neden gerçekte nerede

Bir teslimat raporu üç parçalı bir mesajdır, ve bu biçim RFC 3464'ten beri sabittir. İlk parça özürdür, size en yakın makine tarafından bir insan için yazılmıştır. İkincisi makine tarafından okunabilen bloktur, ve içinde gerçek bilgi taşıyan tek parça odur. Üçüncüsü ise özgün mesajınız, ya da yalnızca onun başlıklarıdır, böylece hangisinin başarısız olduğunu anlayabilirsiniz.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

Orta parçayı şu sırayla okuyun:

Final-Recipient:

Hangi adresin başarısız olduğu. Bir rapor, alıcı başına bir blok taşıyabilir, bu yüzden birden çok kişiye gönderilen bir mesajda hangisinden bahsedildiğini böyle anlarsınız — ve diğerleri gayet iyi ulaşmış olabilir.

Action:

failed bir bounce'tur. delayed, bir sunucunun hâlâ denemekte olduğu ve hiçbir şeyden vazgeçmediği anlamına gelen bir uyarıdır; işe yaradığını söyleyen ikinci bir rapor bile alabilirsiniz. relayed ve delivered ise hiç hata değildir ve bir hatayla kolayca karıştırılır.

Status:

Gelişmiş durum kodu — üç sayı, sizin değil yazılımın okuması amaçlanmış. Sağlayıcılar arasında karşılaştırılabilir olan kısım budur, cümleler ise hiçbir zaman öyle değildir.

Diagnostic-Code:

Önemli olan satır budur. Karşı sunucunun kendi yanıtıdır, kelimesi kelimesine aktarılmıştır, ve kendi yanıt kodunu ve yöneticisinin yazdığı her ne cümleyse onu taşır. Üstündeki her şey bir yeniden anlatımdır; asıl orijinal budur.

Remote-MTA:

Bunu hangi sunucunun söylediği. Hata yönlendirmeyle ilgili olduğunda bir göz atmaya değer: tanımadığınız bir sunucu adı genellikle alan adının postasının beklemediğiniz bir yere gittiği, ya da yalnızca eskiden gittiği bir yere gittiği anlamına gelir.

Raporun en tepesindeki cümle kanıt değildir. Onu, yalnızca aktardığı bir hata hakkında, kendi giden sunucunuz, yazılımının hangi ifadeyle geldiyse o ifadeyle yazar. Birbirinin aynısı iki özür, birbiriyle tamamen ilgisiz iki Diagnostic-Code: satırının üstünde durabilir — bir bounce'un en tepeden okunduğunda bu kadar sık yanlış okunmasının nedeni de budur.

İki sayı, ve karar veren hane

Bir ret şöyle yazılır, ve boşluklarla birleştirilmiş üç ayrı şeyden oluşur:

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

550, yanıt kodudur: RFC 5321'de SMTP'nin kendisi tarafından tanımlanan üç haneli bir sayı, ve protokolün bir sonraki adıma karar vermek için ihtiyaç duyduğu parça. 5.1.1 ise RFC 3463'ten gelen gelişmiş durum kodudur, üç hane yeterince ifade edemediği için eklenmiştir. Ondan sonraki her şey serbest metindir, o sunucuyu kim işletiyorsa onun tarafından yazılmıştır, ve hiçbir şey tarafından standartlaştırılmamıştır.

Her iki sayı da aynı haneyle başlar, ve o hane karardır:

İkinci sayı konudur — ne türden bir şeyin yanlış gittiğidir. Daha önce hiç görmediğiniz bir kodu yerine oturtmanın en hızlı yoludur:

Kalıcı bounce (hard bounce)

Bir 5. Adres yanlıştır, artık yoktur, ya da bir politika gereği reddedilmiştir, ve aynı mesajı yeniden göndermek hiçbir şeyi değiştirmez. Toplu gönderenler bir adresi ilkinde listeden düşürür, çünkü devam etmek, gönderen alan adının her yerde birden kısıtlanmasına yol açan şeydir.

Geçici bounce (soft bounce)

Bir 4. Dolu bir posta kutusu, meşgul bir sunucu, geçici bir politika reddi. Kimsenin yardımı olmadan yeniden denenir ve genellikle ulaşır; bunu ancak yeniden denemeler önce tükenirse duyarsınız.

İkisi de hiçbir teknik standartta yoktur. Bunlar, gönderim sektörünün o ilk hane için kullandığı kısaltmalardır — asıl önemli olan da odur — ve bu kısaltmaları bilmeye değer, çünkü elinize geçecek her teslim edilebilirlik aracı size bu terimlerle rapor verir.

Gerçekte karşılaşacağınız kodlar

IANA'nın tuttuğu kayıtta düzinelercesi vardır, sıradan hayatta ise yaklaşık bir düzine. Bunlar, herkesin okuduğu neredeyse her bounce'u kapsar:

Bu listenin dışında da kodlar vardır ve hepsinin bir anlamı vardır, ama daha önce hiç görmediğiniz bir kod neredeyse her zaman bir .7.'dir — birinin politikası, yanındaki satırda kendi sözcükleriyle anlatılmıştır.

Geçici bir adreste nelerin bounce olup nelerin olamayacağı

Neredeyse hiçbir şey — ve bunu açıkça söylemek gerekir, çünkü insanların burada bounce olarak tanımladığı şeylerin üçü aslında bounce değildir:

“Kullanıcı bulunamadı” diye bir şey olamaz

Sunucu, herkese açık alan adlarındaki her adı kabul eder. anything@grabmail.io kimse yazmadan önce bile geçerli bir adrestir, çünkü karşılaştırılacak bir posta kutusu listesi yoktur — bu yüzden GrabMail'den gelen bir 5.1.1 diye bir şey yoktur. Geçici postanın altında nasıl çalıştığı mekanizmanın tamamını anlatır.

Süre dolması bir bounce değildir

Bir mesaj, ulaşmasından 5 gün sonra silinir, ve o zamana kadar gönderen sunucuya çoktan 250 söylenmiş ve tüm alışverişi unutmuştur. Kimseye bildirim gitmez, çünkü hiçbir şey başarısız olmamıştır: mesaj teslim edilmiş, ve daha sonra silinmiştir. Bir gelen kutusu ne kadar sürer, bu yarısını anlatan rehberdir.

Adresi reddeden bir form bounce değildir

Hiç posta gönderilmedi. Site, alan adını bir listeyle karşılaştırdı ve formu reddetti; hiçbir şey bir posta sunucusuna ulaşmadı, ve okunacak hiçbir şey yok. Kayıt formları neden geçici e-postayı engeller, farklı yanıtları olan farklı bir sorundur.

Sessizlik de bir bounce değildir

Beklediğiniz bir şey hiç ulaşmadıysa ve kimse size bir rapor göndermediyse, hata — eğer varsa — sizin göremeyeceğiniz gönderen tarafında gerçekleşmiştir. Ulaşmayan posta, nedenleri kontrol etmeye değer sırayla ele alır.

Bu da geriye tam olarak tek bir gerçek reddi bırakır, ve o da boyut sınırıdır. Boyutu en baştan bildiren bir gönderen sunucu, tek bir bayt bile saklanmadan hemen geri çevrilir:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Boyutu önceden bildirmeyen bir gönderen, bunun yerine baytlar kendisi için sayıldıktan sonra mesajın sonunda aynı yanıtı alır. Her iki durumda da kod 5.3.4'tür, hiçbir şey saklanmaz, ve gerçek bir kişiye kendi posta sistemi tarafından haber verilir — kabul edip sonra atmak yerine kapıda reddetmenin bütün nedeni de budur.

Sınırı yükselten ne bir plan ne de bir başlık vardır, ve burada başka hiçbir şey için bounce yoktur: gelen kota yok, hız sınırı yok, biri o adı zaten kullanıyor diye bir ret yok. Paylaşımlı bir alan adında aynı adı yazan iki kişi, o posta kutusunu basitçe paylaşır — ki bu bir teslimat özelliği değil, bir gizlilik özelliğidir.

Buraya az önce yönlendirdiğiniz bir alan adındaki bounce'lar

Bir alan adını bir catch-all gelen kutusuna yönlendirmek tek bir DNS kaydıdır, ve bunun ürettiği neredeyse her bounce, kurulumun kendisine değil değişikliğin olduğu saate aittir. Beş durum vardır, ve birbirlerinden farklı görünürler:

1. Kayıt var olmadan önce. Ne MX'i ne de geri düşülecek bir adres kaydı olan bir alan adı, gönderenlere 5.4.4 ya da 5.1.2 verir: teslim edilecek hiçbir yer yoktur ve yeniden denemeye değecek hiçbir şey yoktur.
2. Değişiklik yayılırken. Kaydı zaten sorgulamış olan gönderenler, TTL'i bitene kadar eski yanıtı kullanmaya devam eder. Bu pencerede oluşan bir bounce, Remote-MTA: satırında eski sunucuyu adlandırır — onu yanlış girilmiş bir kayıttan ayırt etmenin yolu tam olarak budur.
3. Yayıldıktan sonra. Alan adındaki her ad kabul edilir, bu yüzden orada da “kullanıcı bulunamadı” imkânsız hâle gelir. Tek bir kayıt, öncelik 10, smtp.grabmail.io'e işaret eden, ve postanın ulaşması için yayınlanacak başka hiçbir şey yok.
4. Alan adı eskiden boş bir MX yayınlıyorsa. Park edilmiş alan adları genellikle “bu alan adı asla posta almaz” anlamına gelen kaydı taşır. Onu önbelleğe almış gönderenler, siz o zamandan beri her ne yayınladıysanız da, süresi dolana kadar 5.1.10 yanıtı verir.
5. Alan adı posta da gönderiyorsa. Giden postadaki bir 5.7.26, bunların hiçbiriyle ilgili değildir — bu, kendi SPF ya da DMARC'ınızın mesajı her ne gönderdiyse onu kapsamaması demektir. Yalnızca alım amaçlı alan adı rehberi sıkı durum içindir; hem de gönderen bir alan adının ihtiyacı olansa bunun yerine sıradan, aşamalı bir devreye alma sürecidir.

Kaydı okumak, kimse bir bounce okumak zorunda kalmadan bunun çoğunu yanıtlar:

$ dig +short MX yourdomain.com

Yanıt tek bir satır olmalıdır: önce öncelik, sonra sunucu, sonra sondaki nokta. Bunun dışındaki her şey — iki satır, tanımadığınız bir sunucu, ya da hiçbir şey — üç dakika sonra alacağınız bounce'un ta kendisidir. Kendi alan adınızı buraya yönlendirmek kurulumun tamamıdır, ve sahteciliği durduran üç kayıt, posta ulaşmaya başladığında yayınlanacak olandır.

Hiç göndermediğiniz bir mesaj için bounce

Tam olarak sıradan bir hata raporu gibi görünerek gelir, hiç görmediğiniz bir mesajı, hiç duymadığınız bir alıcıya alıntılayarak. Hiçbir şeye izinsiz girilmemiştir. Biri, zarfa gönderen olarak sizin adresinizi yazdığı bir posta gönderdi, bir alıcı sunucu onu teslim edemeyeceğini keşfetmeden önce içeri aldı, ve sonra başarısız bir mesajla yapılması gerekeni yaptı: bir rapor yazdı ve kendisine verilen gönderene postaladı. Yani size.

Bunun adı backscatter'dır, ve bunun ne kanıtladığını açıkça söylemekte fayda var: posta kutunuz hakkında hiçbir şey. Bir zarf göndereni sahtelemek hiçbir şeye erişim gerektirmez — bir görüşmeye yazılan tek bir satırdır. Bunu her kim yaptıysa yalnızca adresinize ihtiyaç duydu, başka hiçbir şeye, ve muhtemelen onu tahmin de etmiş olabilir.

Üç şey, onu gerçek bir bounce'tan yaklaşık on saniyede ayırır:

• İade edilen mesaj size ait değildir. Raporun üçüncü parçası özgün mesajı, ya da en azından onun başlıklarını taşır. Onu hiç yazmadıysanız, göndermediniz demektir, ve rapordaki geri kalan her şey başkasının sorunuyla ilgilidir.
• Received: zinciri hiç kullanmadığınız bir yerden başlar. Onu aşağıdan yukarıya okuyun: en alttaki satır mesajı gerçekte ağa sokan makinedir, ve bu sizin sağlayıcınız olmayacaktır. Bir e-posta başlığını okumak yönü ve alttakinin neden dürüst uç olduğunu ele alır.
• Tarihler tutmaz. Backscatter genellikle, rapor size ulaşmadan saatler ya da günler önce gönderilmiş, o zamandan beri başkasının kampanyasını yeniden deneyen bir kuyruktan çıkmış bir mesajı bildirir.

Düzeltecek hiçbir şey ve yanıtlayacak hiçbir şey yoktur. Adres sahip olduğunuz bir alan adına aitse, SPF ve DMARC yayınlamak bunu işe yarayan tek şekilde azaltır: kabul etmeden önce gönderenin politikasını kontrol eden bir alıcı sunucu, sahteciliği görüşmenin içinde reddeder ve kimse için asla bir rapor üretmez. Yalnızca alım amaçlı bir alan adında üç kayıt, bunun en katı biçimidir, ve yayınlaması açık ara en kolay olanıdır.

Paylaşımlı, herkese açık bir alan adındaki kısa bir ad, tıpkı daha fazla spam toplamasıyla aynı nedenle, özel bir adresten daha fazlasını toplar: tahmin edilmesi kolaydır, ve zarf göndereni seçen bir sahtekâr özellikle sizi hedeflemez. Bu, başkasıyla ilgili bir gürültüdür, ve spamdan farklı olarak hiçbir şeyi eğiten bir düğme yoktur — spam denetimlerinin gerçekte ne yaptığı, işe yarayan düğmelerin rehberidir.

Bir tanesini okuma sırası

1. Elinizdekinin hangi tür olduğuna karar verin. Gönder'e bastığınız anda kendi posta uygulamanızda beliren bir hata bir reddir. Daha sonra ulaşan ve MAILER-DAEMON'dan gelen bir mesaj ise bir rapordur, ve okunacak bir şey yalnızca raporda vardır.
2. Gerçekten gönderdiğiniz bir mesajla ilgili olduğunu kontrol edin. İade edilen kopya üçüncü parçadadır. Size ait değilse, bu backscatter'dır, ve işiniz bitmiştir.
3. Ham kaynağı açın. Üstteki özür, kendi sunucunuzun kalıp ifadesidir, neden değildir, ve makine tarafından okunabilen blok hiçbir yerde varsayılan olarak gösterilmez.
4. Status: satırını bulun ve ilk haneyi okuyun. Bir 4 hâlâ yeniden deneniyordur ve kendi kendine başarılı olabilir; bir 5 ise kesindir ve başka hiçbir şey olmayacaktır.
5. Diagnostic-Code: satırını okuyun. Bu, karşı tarafın kendi cümlesidir, ve sizi reddeden kuralın gerçekte adlandırıldığı tek yerdir.
6. İkinci haneyi yerine oturtun. .1. adrestir, .2. posta kutusudur, .4. yoldur, .7. birinin politikasıdır. Bu genellikle kimin sorunu olduğunu bilmeye yeter.
7. Kimin sorunu olduğuna göre hareket edin. Bir adresleme hatası doğru adrese sahip olmakla düzelir; bir yönlendirme hatası DNS'i düzeltmekle; bir politika hatası ise politikayı karşılamakla, ya da karşı taraftaki kişiden kendi günlüklerine bakmasını istemekle — orada aynı ret, size gönderdiklerinden çok daha uzun biçimde yazılıdır.

İki şey asla çözüm değildir. Bir 5'ten sonra mesajı değiştirmeden yeniden göndermek aynı reddi tekrarlar, ve yeterince sık yapıldığında, gönderen alan adının itibarını her yerde birden zedeler. Ve rapora yanıt vermek kimseye ulaşmaz: boş bir zarf göndereninden geldi, ki zaten size teslim edilebilmesinin tek nedeni de budur.

Sorular