E-Posta Header Analizi ile Gecikme Nerede Oluşuyor Tespit Etme

Gönderdiğiniz bir e-posta alıcıya saatler sonra ulaşıyorsa ya da hiç ulaşmıyorsa, sorunun kaynağını bulmak için tek güvenilir yol e-posta başlıklarını (header) satır satır okumaktır. Bu yazıda, RFC 5321 ve RFC 5322 standartlarının tanımladığı Received başlıklarını nasıl yorumlayacağınızı, hangi zaman damgasının hangi sunucuya ait olduğunu nasıl ayırt edeceğinizi ve gecikmenin gerçek noktasını dakika içinde nasıl tespit edeceğinizi adım adım ele alıyoruz.

E-Posta Header Nedir ve Neden Önemlidir?

Her e-posta mesajı, kullanıcının görmediği ancak alıcı sunucunun ve istemcinin okuduğu bir başlık bloğu (header) taşır. RFC 5322 bu başlık alanlarının sözdizimini tanımlar; RFC 5321 ise SMTP protokolünün bu başlıklara nasıl veri eklediğini açıklar. Header içindeki Received satırları, mesajın her aktarım noktasında otomatik olarak eklenen bir tür "kargo takip etiketi" işlevi görür.

Bir e-posta gönderildiğinde şu süreç işler: gönderen MTA (Mail Transfer Agent), alıcı MTA'ya bağlanır; alıcı MTA mesajı kabul edip kendi Received satırını üste ekler ve bir sonraki sunucuya iletir. Bu zincir, mesaj son kullanıcının posta kutusuna düşene kadar devam eder. Zincirun altındaki satır en erken noktayı, üstündeki satır en son noktayı temsil eder.

Received Satırlarını Okuma Yöntemi

Ham header'ı görmek için kullandığınız istemciye göre farklı bir yol izlemeniz gerekir: Gmail'de "Orijinal mesajı göster", Outlook'ta "İleti kaynağı" ve Apple Mail'de "Ham Kaynak" seçeneği bu verilere erişim sağlar.

Tipik bir Received satırı şu biçimdedir:

Received: from mail.ornekgonderici.com (mail.ornekgonderici.com [203.0.113.45])
        by mx.hedef.com with ESMTPS id abc123
        for <ali@hedef.com>;
        Mon, 26 May 2026 08:14:32 +0300 (TRT)

Bu satırda from gönderen sunucuyu, by alan sunucuyu, with kullanılan protokolü (ESMTP, ESMTPS, LMTP vb.) ve en sonda tarih-saat bilgisini gösterir. Farklı Received satırlarının saat damgaları arasındaki fark, o noktadaki işlem ya da kuyruk bekleme süresini yansıtır.

Gecikme Analizi: Adım Adım

1. Tüm Received Satırlarını Listeleyin

Header'ı bir metin editörüne yapıştırarak yalnızca Received: ile başlayan satırları ayıklayın. Ardından her birini numaralandırın; altta kalan 1 numaralı satır, en erken adımı temsil eder.

2. Zaman Damgalarını Birleştirin ve Sıralayın

Her satırdaki saat değerini UTC'ye dönüştürün ve bir tabloya yazın. Ardından her atlama noktasındaki farkı hesaplayın. RFC 5321, bölüm 4.4'e göre bir mesajın her atlama noktasında bekleme süresi teorik olarak sınırsız olabilir; ancak iyi yapılandırılmış sunucularda bu süre saniyeler düzeyinde kalmalıdır.

3. Anormal Farkları İşaretleyin

Birbirini izleyen iki Received satırı arasındaki fark 60 saniyeyi aşıyorsa inceleme gerektirir. 5 dakikayı aşıyorsa ciddi bir sorun (gri listeleme, kuyruklama, DNS çözümleme gecikmesi veya içerik filtrelemesi) söz konusu olabilir.

Gecikmeye Yol Açan Başlıca Sebepler

SPF, DKIM ve DMARC Header'larını da Kontrol Edin

Gecikmenin doğrudan nedeni kimlik doğrulama başarısızlıkları da olabilir. RFC 7208 kapsamında tanımlanan SPF, RFC 6376 kapsamındaki DKIM ve RFC 7489 kapsamındaki DMARC sonuçları, alıcı sunucunun eklediği Authentication-Results başlığında yer alır. Bu başlıkta şu gibi satırlar görebilirsiniz:

Authentication-Results: mx.hedef.com;
  spf=pass (google.com: domain of info@gonderici.com designates 198.51.100.10 as permitted sender)
  dkim=fail header.i=@gonderici.com
  dmarc=fail (p=quarantine) header.from=gonderici.com

DKIM imza doğrulama başarısız olduğunda bazı sunucular mesajı hemen reddetmek yerine geciktirerek karantinaya alır ya da ek filtrelemeden geçirir. DMARC politikası quarantine veya reject olarak ayarlanmışsa bu süreç gecikmeyi daha da uzatabilir. Google Postmaster Tools ve Microsoft SNDS panelleri bu başarısızlıkların hacmini göndericiye geri bildirir.

Kullanabileceğiniz Araçlar

MXToolbox Email Header Analyzer (mxtoolbox.com/EmailHeaders.aspx): Ham header'ı yapıştırır yapıştırmaz her atlama noktasındaki süreyi renkli çubuk grafiğiyle görselleştirir. Kırmızı renkli çubuklar anormal gecikme noktalarını işaret eder.

Google Admin Toolbox — Messageheader (toolbox.googleapps.com/apps/messageheader/): RFC uyumlu ayrıştırma yapar; özellikle Gmail'den gelen mesajlarda X-Google-DKIM-Signature gibi özel başlıkları da çözümler.

mail-tester.com: Mesajı doğrudan test adresine göndererek SPF/DKIM/DMARC, içerik skoru ve blacklist durumunu tek raporda sunar.

Postfix log analizi: Kendi altyapınızı işletiyorsanız /var/log/mail.log ya da /var/log/maillog dosyasında queue_id değerini arayarak mesajın sunucu tarafındaki yaşam döngüsünü milisaniye hassasiyetiyle takip edebilirsiniz.

X-Originating-IP ve Forwarder Başlıkları

Mesaj bir yönlendirme (forward) veya liste sunucusu üzerinden geçmişse zincirde fazladan atlama noktaları oluşur. X-Forwarded-To, X-Original-To veya Delivered-To başlıkları bu yönlendirme adımlarını kaydeder. Kurumsal bir e-posta güvenlik ağ geçidi (örneğin Proofpoint, Mimecast veya Cisco Email Security) kullanılıyorsa ağ geçidinin eklediği özel başlıklar da gecikme analizine dahil edilmelidir; çünkü bu sistemler bazen mesajı virüs taraması ya da sandbox analizine göndererek ekstra 30 saniye ile birkaç dakika arasında bekleme süresi ekler.

Toplu Gönderim Sistemlerinde Gecikme Yönetimi

Connect365 gibi toplu e-posta gönderim platformlarında gecikme analizi özellikle kritiktir. Transaksiyonel e-postalar için RFC 5321'in bölüm 4.5.4'ü, teslim denemelerinin üstel geri çekilme (exponential backoff) mantığıyla yapılmasını önerir: ilk yeniden deneme 5 dakika, ikincisi 15 dakika, üçüncüsü 1 saat aralıklı olarak denenir. Bu durum header'da birden fazla Received satırı arasında belirgin sıçramalar olarak görünür.

IP havuzu rotasyonu, özelleştirilmiş gönderim zamanlaması ve hedef alan adına özel MX kayıt izleme gibi özellikler gecikme oranını düşürür. Bir kampanya raporunda açılma oranlarının beklenenden düşük çıktığı durumlarda ilk kontrol noktanız her zaman birkaç örnek mesajın header analizi olmalıdır.

Pratik Örnek: Gmail'e Gönderilen Mesajda Gecikme

Aşağıdaki senaryoyu ele alalım: Saat 08:10:00'da gönderilen bir mesaj Gmail'e 08:24:17'de ulaşmış, yani 14 dakika 17 saniyelik bir gecikme oluşmuş. Header'ı incelediğimizde:

• 08:10:05 — Gönderen MTA mesajı kuyruğa aldı (Received #1)
• 08:10:07 — İlk SMTP bağlantısı kuruldu (Received #2, 2 saniye fark)
• 08:24:15 — Google'ın giriş MX sunucusu mesajı kabul etti (Received #3, 14 dakika 8 saniye fark)
• 08:24:17 — Gmail posta kutusuna teslim edildi (Received #4, 2 saniye fark)

14 dakikalık fark, Google'ın greylisting davranışına ya da gönderen IP'nin kısa süreli kısıtlanmasına (throttling) işaret eder. Google Postmaster Tools'daki alan adı itibar paneli bu anlarda sıklıkla "Düşük" itibar uyarısı gösterir. Çözüm: gönderim hızını geçici olarak düşürmek ve IP ısınma programını gözden geçirmek.

Sık Sorulan Sorular