Mail Başlıklarını (Header) Okuma ve Analiz Etme

Bir müşteri "mailiniz bana gelmedi" diyor, siz "gönderdim" diyorsunuz ve konuşma orada tıkanıyor. Ya da gönderdiğiniz mail üç saat gecikmeyle ulaşıyor ve kimse nerede beklediğini bilmiyor. Bu tartışmaların hepsinin cevabı tek bir yerde duruyor: mail başlıkları. Mail başlığı analizi, bir mesajın hangi sunuculardan geçtiğini, her adımda ne kadar beklediğini, kimlik doğrulamasından geçip geçmediğini ve spam filtresinin ona kaç puan verdiğini tahmine yer bırakmadan gösterir.

Bu yazıda ham başlığa nasıl ulaşacağınızı, Received zincirini hangi yönde okuyacağınızı, Authentication-Results satırındaki SPF/DKIM/DMARC sonuçlarını nasıl yorumlayacağınızı, Return-Path ile From arasındaki farkın neden kritik olduğunu ve zaman damgalarından gecikmeyi nasıl ölçeceğinizi anlatacağım. Sonunda gerçek bir teşhis senaryosunu baştan sona birlikte çözeceğiz.

Ham Başlığı Nasıl Görüntülersiniz#

Mail istemcileri normalde başlıkların yalnızca birkaç satırını (Kimden, Kime, Konu, Tarih) gösterir. Teşhis için ham başlığın tamamına ihtiyacınız var ve her istemcide bu farklı bir menüde saklıdır.

Sunucu tarafında çalışıyorsanız daha hızlı yollar var. Maildir formatında saklanan bir mesajın başlığını doğrudan okuyabilirsiniz:

# Bir Maildir mesajının yalnızca başlık bölümünü yazdır (ilk boş satıra kadar)
sed '/^$/q' /var/mail/vhosts/firmaniz.com/kullanici/new/1756110764.M12345P678.mail

# Kuyrukta bekleyen bir mesajın başlığını Postfix ile göster
postcat -hq 4Wq8xY2Zb1z3Kk

# Belirli bir Message-ID'yi log'da izle
grep "4Wq8xY2Zb1z3Kk" /var/log/mail.log

Başlıkları kopyalayıp bir metin düzenleyiciye yapıştırırken satır kırılmalarını bozmamaya dikkat edin. Başlıklar katlanmış (folded) olabilir: bir başlık satırı devam ediyorsa sonraki satır boşluk veya sekme ile başlar. Bu boşlukları silen bir kopyalama, DKIM imzasını ve uzun Received satırlarını okunmaz hale getirir.

Received Zinciri: Aşağıdan Yukarı Okunur#

Received satırları mesajın yolculuk kaydıdır ve buradaki en önemli kural şudur: en alttaki Received en eski, en üstteki en yenidir. Her sunucu mesajı aldığında kendi satırını başlıkların en üstüne ekler. Yani kronolojik sırayla okumak için aşağıdan yukarı ilerlersiniz.

Tipik bir zincir şöyle görünür:

Received: from mx1.ornek.com (localhost [127.0.0.1])
	by mx1.ornek.com (Postfix) with ESMTP id 4Wq8xY2Zb1z3Kk
	for [email protected]; Mon, 25 Aug 2026 10:12:47 +0300
Received: from mail.firmaniz.com (mail.firmaniz.com [185.12.34.56])
	by mx1.ornek.com (Postfix) with ESMTPS id 4Wq8xY2Zb1z2Kk
	(TLS1.3 with cipher TLS_AES_256_GCM_SHA384)
	for [email protected]; Mon, 25 Aug 2026 10:12:45 +0300
Received: from istemci-pc (88.240.12.9)
	by mail.firmaniz.com (Postfix) with ESMTPSA id 9Kk2Zb1zY8xQ
	for [email protected]; Mon, 25 Aug 2026 10:12:43 +0300

Bu üç satırı aşağıdan yukarı okuyalım. En alttaki satır, kullanıcının bilgisayarından mail.firmaniz.com sunucusuna gönderim yapıldığını söylüyor; ESMTPSA protokol adındaki A harfi kimlik doğrulamasının yapıldığını belirtir, yani bu bir submission oturumudur. Ortadaki satır mesajın sizin sunucunuzdan alıcının MX'ine ESMTPS ile (yani TLS üzerinden) teslim edildiğini gösteriyor. En üstteki satır ise alıcı tarafındaki iç işlemedir.

Protokol adlarındaki harfler bilgi taşır ve bunları tanımak çok işinize yarar:

Received satırındaki köşeli parantez içindeki IP, bağlanan tarafın gerçek IP'sidir ve alıcı sunucu tarafından yazılır; parantez içindeki isim ise o IP'nin ters DNS (PTR) karşılığıdır. Bu ikisi uyuşmuyorsa ya da PTR yoksa, alıcı sunucular bunu olumsuz bir sinyal olarak değerlendirir. Kendi sunucunuzun PTR kaydını doğrulamak için dig +short -x 185.12.34.56 komutunu çalıştırın.

Authentication-Results Satırını Çözmek#

Alıcı sunucu, kimlik doğrulama kontrollerinin sonucunu tek bir başlıkta özetler. Bu satır bir teslim sorununu teşhis ederken bakacağınız ilk yerdir, çünkü SPF, DKIM ve DMARC'ın üçünün sonucunu birden verir:

Authentication-Results: mx1.ornek.com;
	spf=pass (mx1.ornek.com: domain of [email protected]
	 designates 185.12.34.56 as permitted sender)
	 smtp.mailfrom=mail.firmaniz.com;
	dkim=pass header.d=firmaniz.com header.s=s1;
	dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=firmaniz.com

Bu satırda dört kritik bilgi var. spf=pass gönderen IP'nin SPF kaydında yetkili olduğunu; smtp.mailfrom SPF'in hangi alan adını kontrol ettiğini; dkim=pass header.d imzanın hangi alan adına ait olduğunu; dmarc=pass ... header.from ise DMARC'ın hangi alan adı üzerinden değerlendirildiğini gösterir.

Şimdi kritik nokta: spf=pass ve dkim=pass görmeniz DMARC'ın da geçeceği anlamına gelmez. DMARC ek olarak "hizalama" (alignment) arar, yani smtp.mailfrom ile header.from alan adlarının veya header.d ile header.from alan adlarının birbiriyle uyuşmasını bekler. Bu iki alan adı farklıysa sonuç dmarc=fail olur. Bu mekanizmayı ayrıntısıyla DMARC alignment nedir yazısında ele aldım; SPF sonucunun softfail mi fail mi olduğu ayrımı içinse SPF SoftFail ve HardFail farkı yazısına bakın.

Karşılaşabileceğiniz sonuç değerleri şunlardır:

permerror özellikle önemlidir ve çoğu zaman SPF kaydındaki DNS sorgu limitinin aşılmasından kaynaklanır: SPF değerlendirmesi en fazla 10 DNS sorgusuna izin verir ve arka arkaya eklenen include mekanizmaları bu sınırı sessizce aşar. dkim=fail görüyorsanız imzanın yolda bozulmuş olma ihtimali yüksektir; DKIM doğrulaması başarısız yazısı bu durumun sebeplerini sıralıyor.

Return-Path, From ve Reply-To: Üç Farklı Gönderici#

Bir mailde "gönderici" tek bir şey değildir; en az üç ayrı adres vardır ve bunları karıştırmak teşhisi tamamen yanlış yöne çevirir.

Return-Path (SMTP zarfındaki MAIL FROM adresi) teslim edilemeyen mesajların geri döneceği adrestir. Kullanıcı bunu normalde görmez. SPF kontrolü bu adresin alan adı üzerinden yapılır, From başlığı üzerinden değil. Bir gönderim servisi kullanıyorsanız Return-Path genellikle servisin kendi alan adını taşır.

From başlığı kullanıcının ekranında gördüğü isim ve adrestir. DMARC değerlendirmesi bu alan adı üzerinden yapılır ve alıcıya güven veren şey budur. Bir mesajda From adresi ile Return-Path alan adının farklı olması normaldir, ancak DMARC hizalamasının sağlanması için ya SPF ya da DKIM tarafında bir uyum olması gerekir.

Reply-To yalnızca yanıt tuşuna basıldığında kullanılacak adresi belirtir; kimlik doğrulamasında hiçbir rolü yoktur. Sahtecilik girişimlerinde en çok manipüle edilen alan budur: From adresi tanıdık bir kurumu gösterirken Reply-To saldırganın adresini taşır. Bu tür girişimlere karşı alan adınızı korumak için e-posta spoofing önleme yazısındaki önlemleri uygulayın.

Bir başlıkta bu üçünü hızlıca çıkarmak için:

# Ham mesaj dosyasından üç göndericiyi de yan yana çıkar
grep -iE "^(Return-Path|From|Reply-To|Sender):" mesaj.eml

# Kuyruktaki bir mesaj için aynısı
postcat -hq 4Wq8xY2Zb1z3Kk | grep -iE "^(Return-Path|From|Reply-To):"

Message-ID, Date ve Gecikmeyi Ölçmek#

Message-ID her mesajı benzersiz biçimde tanımlar ve genellikle üreten sunucunun alan adını içerir. Bu değer, bir mesajı log'larda uçtan uca izlemenin en güvenilir yoludur — konu satırı değişebilir, alıcı değişebilir ama Message-ID sabittir. Bir mesaj sizin sunucunuzdan çıktı mı sorusunun cevabı bu değerle log'da aranır.

Gecikme teşhisi için Received satırlarındaki zaman damgalarını karşılaştırırsınız. Yukarıdaki örnekte alt satır 10:12:43, orta satır 10:12:45, üst satır 10:12:47 gösteriyor; yani mesaj toplam 4 saniyede teslim edilmiş, sorun yok. Şimdi şöyle bir zincir düşünün: alt satır 09:14:02, orta satır 12:47:31. Aradaki üç buçuk saatlik boşluk, mesajın sizin sunucunuzun kuyruğunda beklediğini gösterir — yani sorun alıcıda değil sizde ve kuyruk log'unuza bakmanız gerekir.

Tersi durumda, yani boşluk alıcı tarafındaki iki Received satırı arasındaysa gecikme onların sisteminde olmuştur. Bunun en yaygın sebebi greylisting'tir: alıcı sunucu tanımadığı bir göndericiyi ilk denemede geçici olarak reddeder ve yeniden denenmesini bekler. Bu davranışın ayrıntıları için greylisting ve mail gecikmesi yazısına bakabilirsiniz.

Zaman damgalarını okurken saat dilimlerini normalize etmeyi unutmayın. Her sunucu kendi yerel saatini yazar ve satırın sonundaki +0300 gibi ofset bunu belirtir. Farklı ofsetli iki damgayı doğrudan çıkarmak yanlış sonuç verir:

# İki zaman damgasını UTC'ye çevirip farkı saniye olarak hesapla
BAS=$(date -d "Mon, 25 Aug 2026 09:14:02 +0300" +%s)
SON=$(date -d "Mon, 25 Aug 2026 12:47:31 +0000" +%s)
echo "Gecikme: $(( SON - BAS )) saniye"

Spam Filtresi Başlıkları ve Skorlar#

Alıcı tarafındaki filtreler kararlarını genellikle X- ile başlayan özel başlıklara yazar. Bunlar standart değildir, kullanılan yazılıma göre değişir, ama bir mesajın neden spam sayıldığını anlamanın en doğrudan yoludur.

SpamAssassin kullanan bir sunucuda şöyle satırlar görürsünüz:

X-Spam-Status: Yes, score=7.3 required=5.0
	tests=DKIM_INVALID,HTML_IMAGE_ONLY_28,RDNS_NONE,URIBL_BLOCKED
X-Spam-Level: *******
X-Spam-Checker-Version: SpamAssassin 4.0.0

Buradaki score toplam puan, required ise spam sayılma eşiğidir. Asıl değerli bilgi tests listesidir: her kural adı puanın nereden geldiğini söyler. Yukarıdaki örnekte RDNS_NONE gönderen IP'nin PTR kaydı olmadığını, DKIM_INVALID imzanın doğrulanamadığını, HTML_IMAGE_ONLY_28 ise mesajın neredeyse tamamen görselden oluştuğunu belirtir. Üç sorunun da somut ve çözülebilir olduğuna dikkat edin.

Rspamd kullanan sunucularda karşılığı X-Rspamd-Score ve X-Spamd-Result başlıklarıdır; sembol adları farklıdır ama mantık aynıdır. Büyük sağlayıcılar (Gmail, Outlook) kendi skorlarını başlığa yazmaz — onlarda teşhis için gönderici panellerine ve Authentication-Results satırına bakarsınız. Gmail tarafında karşılaştığınız sorunlar için Gmail'e mail gitmiyor, Microsoft tarafı için Hotmail ve Outlook'a mail gitmiyor yazıları doğrudan çözüm adımları veriyor.

Gerçek Bir Teşhis Senaryosu ve Sık Yapılan Hatalar#

Somut bir vakayla bitirelim. Şikâyet şu: "Fatura mailleri müşterilerin spam klasörüne düşüyor, ama aynı adresten gönderdiğim normal mailler kutuya geliyor." Başlığa bakınca spf=pass, dkim=fail ve dmarc=fail görüyoruz. Adım adım ilerleyelim:

1. dkim=pass olan normal mail ile dkim=fail olan fatura mailinin DKIM-Signature satırlarındaki d= ve s= değerlerini karşılaştırın. Farklıysa iki mail farklı sistemlerden çıkıyor demektir.
2. Fatura mailinin Received zincirine bakın. Muhtemelen bir ara sunucu (fatura yazılımı, CRM veya bir liste servisi) görürsünüz; imza o noktada eklenmemiş ya da mesaj imzalandıktan sonra değiştirilmiştir.
3. DKIM-Signature içindeki h= listesine bakın: imzalanan başlıklar arasında ara sunucunun değiştirdiği bir başlık varsa imza kaçınılmaz olarak bozulur.
4. Return-Path alan adı ile From alan adını karşılaştırın. spf=pass alıyor ama dmarc=fail görüyorsanız, SPF farklı bir alan adı üzerinden geçmiş ve hizalama sağlanmamış demektir.
5. Çözüm genellikle şudur: fatura yazılımının çıkış yolunu kendi alan adınızın DKIM anahtarıyla imzalayacak biçimde yapılandırmak ve o çıkışın IP'sini SPF kaydına eklemek.

Bu tür teşhislerde en sık yapılan dört hata şunlardır. Birincisi Received zincirini yukarıdan aşağı okumak — sıra terstir ve bu yanlış okuma sizi baştan yanlış sunucuya yönlendirir. İkincisi From adresine bakıp SPF'in onu kontrol ettiğini sanmaktır; SPF Return-Path üzerinden çalışır, ikisi farklı olabilir ve bu normaldir. Üçüncüsü spf=pass görünce kimlik doğrulamanın tamam olduğunu varsaymaktır; DMARC hizalaması ayrı bir kontroldür. Dördüncüsü ise başlıkları kopyalarken satır katlamalarını bozmaktır; girintili devam satırları silinirse DKIM imzası anlamsızlaşır ve doğrulama testleri yanlış sonuç verir.

Sıkça Sorulan Sorular#

Mail başlığında hangi IP gönderenin gerçek IP'si#

En alttaki Received satırındaki köşeli parantez içinde yer alan IP, mesajı ilk kabul eden sunucuya bağlanan tarafın adresidir. Ancak dikkat: gönderen kendi sistemine sahte Received satırları ekleyebilir. Güvenebileceğiniz tek satır, sizin kendi sunucunuzun yazdığı Received satırıdır; ondan aşağıdaki satırlar gönderenin iddiasıdır ve doğrulanmış değildir.

Received satırları neden ters sırada#

Her sunucu mesajı aldığında kendi kaydını başlıkların en üstüne ekler; bu SMTP standardının davranışıdır ve bir mesajın yolculuğunu bozulmadan yığmak için tasarlanmıştır. Sonuç olarak en son işlem en üstte, ilk işlem en altta yer alır. Kronolojik okumak için daima aşağıdan yukarı ilerleyin.

Authentication-Results başlığına güvenebilir miyim#

Yalnızca kendi sunucunuzun veya güvendiğiniz alıcı sunucunun yazdığı satıra güvenin. Bu başlık ham metindir ve gönderen tarafından uydurulabilir; bu yüzden düzgün yapılandırılmış sunucular, dışarıdan gelen mesajlardaki kendi adlarına yazılmış Authentication-Results satırlarını siler. Başlıkta birden fazla Authentication-Results görüyorsanız, kendi sunucunuzun adını taşıyanı bulun ve yalnızca ona bakın.

Mail neden geç geldi, başlıktan anlayabilir miyim#

Evet, bu başlık analizinin en net kullanımlarından biridir. Received satırlarındaki zaman damgalarını aşağıdan yukarı sıralayıp aralarındaki farkları hesaplayın; büyük boşluk hangi iki sunucu arasındaysa gecikme orada yaşanmıştır. Saat dilimi ofsetlerini normalize etmeyi unutmayın. Alıcı tarafındaki tipik bir gecikme sebebi greylisting, sizin tarafınızdaki tipik sebep ise kuyrukta bekleyen bir teslimattır.

DKIM imzasının bozulup bozulmadığını başlıktan nasıl görürüm#

Authentication-Results satırındaki dkim= sonucu size doğrudan söyler. dkim=fail görüyorsanız DKIM-Signature başlığındaki d= (imzalayan alan adı), s= (seçici) ve h= (imzalanan başlıklar) değerlerine bakın. En sık sebep, mesajın imzalandıktan sonra bir ara sunucu tarafından değiştirilmesidir — konu satırına eklenen bir etiket veya gövdeye eklenen bir alt bilgi imzayı geçersiz kılar.

Başlıkları analiz eden hazır bir araç var mı#

Birkaç çevrimiçi başlık çözümleyici mevcuttur ve zincir görselleştirme için pratiktirler. Ancak başlıklar hassas bilgi içerir: alıcı adresleri, iç sunucu adları ve IP'ler. Kurumsal yazışmaların başlığını üçüncü taraf bir siteye yapıştırmadan önce bunu düşünün. Sunucuya erişiminiz varsa postcat, grep ve date ile aynı analizi kendi makinenizde ve dışarı hiçbir şey vermeden yapabilirsiniz.

X-Spam-Status başlığını görmüyorum, neden#

Bu başlığı yalnızca SpamAssassin gibi bir filtre çalıştıran sunucular ekler ve genellikle alıcı tarafında eklenir. Kendi gönderdiğiniz mailin kopyasına bakıyorsanız bu başlık orada olmaz. Ayrıca Gmail ve Outlook gibi büyük sağlayıcılar skorlarını başlığa yazmaz; onlarda teşhis Authentication-Results satırı ve sağlayıcının kendi gönderici panelleri üzerinden yapılır.

Kapanış#

Mail başlıkları, bir teslim sorununda tahmin yürütmeyi bitiren tek kaynaktır. Aklınızda kalması gereken dört alışkanlık: Received zincirini daima aşağıdan yukarı okuyun; teşhise Authentication-Results satırından başlayın; Return-Path ile From'un farklı olabileceğini ve SPF'in birinciyi, DMARC'ın ikinciyi kontrol ettiğini unutmayın; ve gecikme ararken zaman damgalarını saat dilimiyle birlikte normalize edin. Bu dördü, "gönderdim ama gelmedi" tartışmasının çoğunu dakikalar içinde bitirir.

Kendi sunucunuzda bu başlıkları üretecek ve okuyacak bir altyapı kurmak isterseniz Postfix, Dovecot, Rspamd ve DKIM'i yapılandırılmış gelen SMTP sunucu paketleri sizi kurulum aşamasından kurtarır; daha genel bir altyapı için tam root erişimli VDS sunucularına bakabilirsiniz. Posta kutularınızı hazır yapılandırmayla almak isterseniz e-posta paketlerimize, sunucu tarafındaki teşhis ve bakımı devretmek isterseniz sunucu yönetimi hizmetimize göz atın.