NDR (Non-Delivery Report) Nedir, Nasıl Okunur?

E-posta gönderdiğinizde karşı tarafın sunucusundan beklenmedik bir hata mesajı aldıysanız, muhtemelen bir NDR (Non-Delivery Report) ile karşılaştınız. Bu rapor, mesajınızın neden teslim edilemediğini açıklayan teknik bir bildirimdir ve doğru okunduğunda sorunun kaynağını dakikalar içinde tespit etmenizi sağlar.

NDR Nedir?

Non-Delivery Report (Teslim Edilememe Raporu), RFC 5321 kapsamında tanımlanan SMTP protokolünün temel bir parçasıdır. Bir mesaj alıcı sunucuya ulaşamadığında ya da sunucu mesajı kabul etmeyi reddettiğinde, posta altyapısı gönderici adresine otomatik olarak bir geri bildirim mesajı üretir. Bu mesajın yaygın takma adları arasında bounce message, bounce-back veya kısaca bounce terimleri yer alır.

RFC 3464, NDR'lerin biçimini ve içermesi zorunlu alanları standartlaştırır. Buna göre geçerli bir NDR; orijinal mesajın başlık bilgilerini, SMTP durum kodunu ve insanın okuyabileceği bir açıklama metnini barındırmalıdır. Microsoft Exchange, Google Workspace ve benzeri kurumsal posta sistemleri bu standardı uygular; ancak her platform kendine özgü ek bilgiler de ekleyebilir.

Hard Bounce ve Soft Bounce Ayrımı

E-posta sektöründe bounce'lar genel olarak iki kategoriye ayrılır:

• Hard Bounce (Kalıcı Hata): Alıcı adres mevcut değil, etki alanı bulunamıyor ya da sunucu bağlantıyı kalıcı olarak reddediyor. SMTP 5xx durum kodları bu kategoriye girer. Hard bounce alan adreslerin listenizden çıkarılması, gönderici itibarı açısından zorunludur.
• Soft Bounce (Geçici Hata): Hedef posta kutusu dolu, sunucu geçici olarak erişilemiyor veya mesaj boyutu sınırı aşıldı. SMTP 4xx kodları geçici hatayı işaret eder; posta sunucusu belirli aralıklarla yeniden deneme yapabilir.

SMTP Durum Kodları ve Anlamları

RFC 5321, üç haneli SMTP durum kodlarını tanımlar. İlk rakam kategorisini, ikinci rakam alt sınıfını ve üçüncü rakam spesifik durumu belirtir. NDR mesajında gördüğünüz kodu aşağıdaki tabloya göre yorumlayabilirsiniz:

Bir NDR Mesajını Bölüm Bölüm Okumak

Gerçek bir NDR mesajı birden fazla bölümden oluşur. Gmail, Outlook veya herhangi bir posta istemcisinde aldığınız bounce mesajını açtığınızda genellikle şu yapıyı görürsünüz:

1. İnsan Tarafından Okunabilir Açıklama

Mesajın üst kısmında yer alan bu bölüm, hatanın ne olduğunu günlük dille anlatır. Örneğin The email account that you tried to reach does not exist ifadesi, 550 koduna karşılık gelen kullanıcı bulunamadı hatasının insan tarafından okunabilir biçimidir. Google Workspace bu metni otomatik olarak üretirken Microsoft, hata kodunun yanına destek makalesi bağlantısı ekler.

2. Teknik Durum Satırı (Diagnostic Code)

RFC 3464 uyumlu NDR'lerde Diagnostic-Code: smtp; 550 5.1.1 user unknown biçiminde bir satır bulunur. Buradaki 5.1.1 ifadesi RFC 3463 kapsamında tanımlanan Gelişmiş Durum Kodudur (Enhanced Status Code). İlk rakam (5) kalıcı hatayı, ikinci rakam (1) adres sorununu ve üçüncü rakam (1) "bilinmeyen kullanıcı" alt türünü belirtir.

3. Final Recipient ve Action Alanları

NDR'nin message/delivery-status MIME bölümünde şu satırları görürsünüz:

• Final-Recipient: rfc822; hedef@ornek.com — Mesajın son teslim noktası.
• Action: failed — Teslim girişiminin sonucu.
• Status: 5.1.1 — Gelişmiş durum kodu.
• Remote-MTA: dns; mail.ornek.com — Hata veren sunucunun adresi.

4. Özgün Mesaj Başlıkları

Birçok NDR, orijinal mesajın başlıklarını veya tam içeriğini üçüncü MIME bölümü olarak ekler. Bu bölüm, mesajın Message-ID değerini, gönderim tarihini ve DKIM imza bilgisini içerir; dolayısıyla kimlik doğrulama sorunlarını araştırırken bu kısım kritik önem taşır.

Kimlik Doğrulama Hatalarından Kaynaklanan NDR'ler

Modern e-posta güvenlik altyapısı üç temel standart üzerine kuruludur: RFC 7208 ile tanımlanan SPF (Sender Policy Framework), RFC 6376 ile tanımlanan DKIM (DomainKeys Identified Mail) ve RFC 7489 ile tanımlanan DMARC (Domain-based Message Authentication, Reporting and Conformancy). Bu standartlardan herhangi birinin ihlali, alıcı sunucunun mesajı reddetmesine ve NDR göndermesine yol açabilir.

Bir NDR'de 550 5.7.26 This message does not have authentication information veya 550 5.7.1 SPF check failed gibi ifadeler görüyorsanız sorun kimlik doğrulama katmanındadır. Google Postmaster Tools ve Microsoft'un SNDS (Smart Network Data Services) hizmeti, bu tür reddedilmelerin kaynağını analiz etmek için başvurulabilecek resmi platformlardır.

SPF kaydı DNS'te TXT kaydı olarak yayınlanır ve hangi IP adreslerinin etki alanı adına e-posta gönderebileceğini tanımlar. DKIM ise mesaj başlığına eklenen kriptografik bir imzadır; alıcı sunucu bu imzayı DNS'teki genel anahtarla doğrular. DMARC ise SPF ve DKIM sonuçlarını birleştirerek politika uygular ve raporlama sağlar.

İçerik ve Politika Kaynaklı NDR'ler

Kimlik doğrulama sorunlarının yanı sıra, mesajın içeriği veya gönderici itibarı da NDR üretilmesine neden olabilir. Bu durumda alıcı sunucu genellikle 554 kodu ile yanıt verir. Yaygın sebepler şunlardır:

• IP veya etki alanı kara listeye alınmış: Spamhaus, Barracuda veya Microsoft'un Exchange Online Protection (EOP) gibi sistemlerde listelenen gönderici adresleri reddedilir.
• Yüksek şikayet oranı: Alıcıların mesajları "spam" olarak işaretlemesi, gönderici itibarını düşürür ve reddedilme oranını artırır.
• Mesaj boyutu sınırı: RFC 1870, SMTP SIZE uzantısını tanımlar. Sunucu, kabul edeceği maksimum mesaj boyutunu EHLO yanıtında bildirir; bu sınırı aşan mesajlar 552 koduyla reddedilir.

NDR Sorunlarını Gidermek İçin Kullanılan Araçlar

NDR analizi sırasında başvurabileceğiniz yerleşik ve üçüncü taraf araçlar mevcuttur. MXToolbox Suite, bir etki alanının MX kayıtlarını, SPF ve DMARC yapılandırmasını ve kara liste durumunu tek ekranda gösterir. mail-tester.com, test mesajı göndererek kimlik doğrulama, içerik ve isim sunucusu yapılandırmasını puanlar. dig ve nslookup gibi standart DNS araçları ise MX, SPF ve DKIM kayıtlarını doğrudan sorgulamak için kullanılır. Microsoft, Exchange Online'da teslim edilemeyen iletileri incelemek için Exchange Yönetim Merkezi'nde yerleşik bir mesaj izleme paneli sunar.

E-posta Pazarlamacıları İçin NDR Yönetimi

Toplu e-posta gönderimi yapan platformlar için NDR yönetimi, yalnızca teknik bir sorun değil aynı zamanda itibar meselesidir. Google, 2024 yılı itibarıyla toplu gönderici koşullarını güncelleyerek günlük 5.000'den fazla mesaj gönderen tüm hesapların DMARC politikasına uymasını zorunlu kılmıştır. Microsoft da benzer gereklilikleri Exchange Online Protection üzerinden uygulamaktadır.

Etkili bir NDR yönetimi için şu adımlar izlenmelidir: hard bounce alan adresler listeden hemen çıkarılmalı, soft bounce alan adresler belirli bir deneme sayısından sonra "risk altında" olarak işaretlenmeli ve bounce oranı gönderilen mesajın yüzde ikisinin altında tutulmalıdır. Bu oran, büyük posta sağlayıcılarının gönderici itibarı değerlendirmesinde kritik bir eşik olarak kabul edilmektedir.

Sık Sorulan Sorular