E-posta başlık analizi: Received zinciri, SPF, DKIM ve DMARC

E-posta başlık analizi, iletinin ham başlık alanlarından hangi sunuculardan geçtiğini, hangi saatlerde aktarıldığını ve alıcı sunucusunun SPF, DKIM ve DMARC denetimlerine ne sonuç yazdığını çıkarma işidir. Başlıkları aşağıya yapıştırın ya da .eml dosyasını açın; çözümleme tamamen bu tarayıcıda yapılır.

E-posta başlıkları (ham metin ya da .eml içeriği)

Gövdeyle birlikte yapıştırsanız da yalnızca ilk boş satıra kadarki başlık bölümü çözümlenir. Kısayol: Ctrl + Enter (Mac'te ⌘ + Enter).

.eml dosyası seçin ya da dosyayı bu alana sürükleyip bırakın

Metin ve dosya bu tarayıcıda işlenir; hiçbir sunucuya gönderilmez ve kaydedilmez. Araç DNS ya da IP sorgusu yapmaz.

Hangi metni yapıştırmalısınız?

Araç, iletinin ham başlık bölümüyle çalışır. Bu, e-posta programının ekranda gösterdiği "Kimden, Kime, Tarih" özeti değildir; Received:, Authentication-Results:, DKIM-Signature: gibi satırlarla dolu, çoğu zaman birkaç ekran uzunluğunda bir metindir. Gmail'de "Orijinali göster", Outlook masaüstü uygulamasında Dosya > Özellikler altındaki "İnternet üst bilgileri" kutusu bu metni verir. Diğer programlarda nerede bulunduğunu e-posta başlığı nasıl okunur yazısında adım adım anlattık.

İletiyi .eml olarak kaydettiyseniz dosyayı doğrudan açın. Araç yalnızca ilk boş satıra kadar olan başlık kısmını okur; gövde ve ekler çözümlenmez. Outlook'un .msg dosyaları ikili (binary) biçimdedir ve desteklenmez, onlardan başlık metnini kopyalayın.

Received zinciri nasıl okunur?

Received zinciri aşağıdan yukarıya okunur. İletiyi alan her sunucu başlığın en üstüne kendi satırını ekler; bu yüzden en alttaki satır ilk aktarımı, en üstteki satır alıcının posta kutusuna teslimi gösterir. Tablodaki 1. adım, başlıktaki en alt Received satırıdır.

Her satırda from bağlanan sunucunun kendini tanıttığı adı ve satırı yazan sunucunun gördüğü IP adresini, by satırı yazan sunucuyu, with protokolü (ESMTPS, TLS ile şifrelenmiş SMTP demektir), id sunucunun kuyruk numarasını, for alıcı adresini taşır. Noktalı virgülden sonraki zaman damgası (timestamp) UTC'ye ve Türkiye saatine çevrilir. Gecikme sütunu, bir önceki adımla aradaki farktır.

Hangi satıra güvenilebilir?

Received satırları imzalı değildir; her birini onu ekleyen sunucu istediği gibi yazar. Güvenilebilecek satırlar, alıcının kendi e-posta sağlayıcısının eklediği en üstteki satırlardır. Sağlayıcının iletiyi dışarıdan kabul ettiği satırın altındaki her şeyi gönderen taraf yazmıştır ve sahte iletilerde uydurma Received satırı eklemek yaygın bir yöntemdir. Araç bu sınırı by alanındaki alan adlarına bakarak tahmin eder ve tabloda vurgular.

Birkaç saniyelik eksi gecikme olağandır; dakikalar süren eksi değer ise bozuk bir sunucu saatine ya da sonradan eklenmiş bir satıra işaret edebilir. UTC dönüşümünün ince noktalarını zaman damgaları ve saat dilimi yazısında topladık.

Satırlardaki IP adresleri özel ağ, CGNAT, dokümantasyon ya da genel adres olarak sınıflandırılır; adresin kime ait olduğu sorgulanmaz. Tek bir adresi ayrıca incelemek için IP adresi kontrol aracını kullanabilirsiniz. Genel bir IPv4 adresi CGNAT arkasında çok sayıda aboneyle paylaşılıyor olabilir; bunun abone tespitine etkisini CGNAT nedir yazısında anlattık.

SPF, DKIM ve DMARC sonuçları ne anlatır?

Üç denetim de iletinin gerçekten o alan adı adına gönderilip gönderilmediğine farklı açılardan bakar. Hiçbiri içeriğin doğruluğunu ölçmez.

Denetim	Neye bakar	"pass" ne demektir	Neyi göstermez
SPF	İletiyi teslim eden sunucunun IP'si, zarf göndericisinin (Return-Path) alan adı adına göndermeye yetkili mi	Bu IP, o alan adının DNS'teki SPF kaydında yer alıyor	From alanındaki adresin doğru olduğunu
DKIM	`d=` alan adının özel anahtarıyla atılmış imza	`h=` listesindeki alanlar ve gövde, imzalandığı andan beri değişmemiş	İletiyi kimin yazdığını, içeriğin doğru olduğunu
DMARC	SPF ya da DKIM'den biri From alan adıyla hizalı olarak geçti mi	From alan adı adına gönderim doğrulandı	Hesabın ele geçirilmediğini

Araç bu sonuçları kendisi hesaplamaz. Alıcı sunucusunun Authentication-Results alanına yazdığını okur; Received-SPF ve ARC alanlarını da gösterir. Sunucu DMARC sonucu yazmamışsa hizalamaya bakarak yaklaşık bir değerlendirme yapar ve bunun yalnızca bir tahmin olduğunu belirtir. DNS sorgusu yapmadığı için DKIM imzasını kriptografik olarak doğrulamaz. İmzadaki etiketleri (v, a, d, s, h, t, x) açıklar ve l= ya da From'u kapsamayan bir h= listesi gibi zayıflıkları işaretler. Başlıkta birden fazla Authentication-Results varsa en üstteki esas alınır, çünkü alttakileri gönderen taraf da yazmış olabilir. En üstteki kaydın yeri ya da onu yazan sunucunun adı alıcı sağlayıcısıyla uyuşmuyorsa araç bu kayıttaki "pass" sonuçlarını olumlu değil, yalnızca bilgi olarak gösterir.

Hizalama (alignment) kontrolü neden önemli?

Hizalama, From alanındaki alan adının SPF'te kullanılan zarf alan adıyla ya da DKIM imzasındaki d= alan adıyla eşleşmesidir. DMARC iki mod tanımlar. Katı (strict) modda alan adları birebir aynı olmalıdır. Gevşek (relaxed) modda aynı kurumsal alan adına ait olmaları yeter: bounce.example.com ile example.com hizalıdır.

RFC 7489, kurumsal alan adını belirlemek için Public Suffix List gibi bir genel uzantı listesine başvurur. Araç bu listenin tamamını taşımaz; com.tr, gov.tr, co.uk gibi yaygın iki düzeyli uzantıları tanır, diğerlerinde son iki etiketi alır. Sıra dışı uzantılarda gevşek hizalama sonucu yanılabilir.

Return-Path'in From'dan farklı olması tek başına sahtecilik göstermez: bülten servisleri, fatura ve CRM sistemleri geri dönen iletileri kendi alan adlarında toplar. Message-ID için de durum benzer; Microsoft 365 kullanan bir şirketin iletilerinde Message-ID çoğunlukla prod.outlook.com ile biter. Bizce en anlamlı üçlü şudur: DMARC sonucu, From ile DKIM d= hizası ve alıcı sağlayıcısının kaydettiği bağlanan IP.

Bu analiz neyi gösteremez?

Metnin değiştirilmediğini. Yapıştırılan başlık elle düzenlenmiş olabilir; araç bunu anlayamaz.
Göndereni. IP adresi bir sunucuyu ya da ağ geçidini gösterir, kişiyi değil. Webmail ile gönderilen iletilerde kullanıcının IP'si çoğu zaman başlıkta hiç yoktur.
DKIM imzasının kriptografik geçerliliğini. Bunun için d= alan adının DNS'teki açık anahtarı gerekir.
Yönlendirilmiş iletilerin özgün sonucunu. Yönlendirme ve posta listeleri SPF'i, bazen DKIM'i bozar. ARC alanları bu durumda ara sunucunun gördüğünü taşır.
Ekran görüntüsündeki bir iletiyle ilgili hiçbir şeyi. Görüntüde başlık alanları bulunmaz.

Bir uyuşmazlıkta e-postanın teknik olarak değerlendirilmesi gerekiyorsa başlığı okumak işin yalnızca başlangıcıdır. Orijinal .eml dosyasının hash değerini alıp kopyası üzerinde çalışmak, bulguları sunucu kayıtlarıyla karşılaştırmak gerekir. Bu kapsamdaki çalışmayı e-posta incelemesi sayfasında anlattık. Bulguların hukuki değerlendirmesi avukata ve mahkemeye aittir.

Başlıklarınız nerede işlenir?

Yalnızca bu tarayıcıda. Çözümleme, sayfadaki JavaScript ile sizin cihazınızda yapılır: araç ağ isteği göndermez, IP ya da alan adı sorgulamaz, yapıştırılan metni tarayıcı depolamasına yazmaz. Açtığınız .eml dosyası yüklenmez; tarayıcı dosyanın ilk 2 MB'lık kısmını bellekte okur ve yalnızca başlık bölümünü kutuya aktarır. Sayfayı kapattığınızda bu veri de bellekten silinir. "Raporu indir" düğmesi de metin dosyasını cihazınızda oluşturur. Sayfa yüklendikten sonra internet bağlantınızı kesip aracı deneyerek bunu kendiniz doğrulayabilirsiniz.

Sık sorulan sorular

E-posta başlığındaki IP adresi göndereni gösterir mi?

Doğrudan göstermez. Received satırlarındaki IP adresleri iletiyi aktaran sunuculara aittir. Gönderenin kendi cihazının adresi yalnızca bazı sistemlerde, genellikle zincirin en altında görünür ve o satırı gönderen tarafın sunucusu yazdığı için doğrulanamaz. Webmail ile gönderilen iletilerde kullanıcının IP'si çoğu zaman hiç yer almaz. Kişiye ulaşmak için sağlayıcıdan yasal yoldan kayıt istenir; adres CGNAT kapsamındaysa port bilgisi de gerekir.

SPF, DKIM ve DMARC sonucu pass ise e-posta kesin gerçek midir?

Hayır. Bu sonuçlar iletinin, From alanındaki alan adının yetkilendirdiği bir sunucudan geldiğini ve imzalı kısımların yolda değişmediğini gösterir. Ele geçirilmiş bir hesaptan gönderilen oltalama iletisi de üç denetimi geçer. Ayrıca sonucu okuduğunuz Authentication-Results alanı alıcı sunucusuna ait olmalıdır; başlığın alt kısımlarına eklenmiş bir kopya, gönderenin yazdığı sahte bir satır olabilir.

Return-Path ile From adresi farklıysa e-posta sahte midir?

Tek başına değildir. Return-Path, geri dönen iletilerin gideceği zarf adresidir; bülten servisleri, fatura sistemleri ve CRM yazılımları burada kendi alan adlarını kullanır. Şüpheyi artıran, bu farka DMARC fail sonucunun, From ile hizalı olmayan bir DKIM imzasının ya da From'daki kurumla ilgisiz bir bağlanan sunucunun eşlik etmesidir. Araç bu nedenle farkı olumsuz değil, dikkat gerektiren bir gösterge olarak işaretler.

Received satırlarındaki saatler neden birbirini tutmuyor?

Her sunucu kendi saatini ve çoğu zaman kendi saat dilimini yazar: biri +0300, diğeri -0700 kullanabilir. Araç hepsini UTC'ye ve Türkiye saatine çevirip karşılaştırır. Çevirdikten sonra birkaç saniyelik eksi fark kalıyorsa sunucu saatleri tam eşit değildir, bu olağandır. Dakikalar ya da saatler süren eksi fark ise saat ayarı bozuk bir sunucuya ya da zincire sonradan eklenmiş bir satıra işaret edebilir.

Ekran görüntüsü e-posta başlık analizi için yeterli mi?

Hayır. Ekran görüntüsünde yalnızca e-posta programının gösterdiği ad, adres ve tarih bulunur; Received zinciri, kimlik doğrulama sonuçları ve DKIM imzası yer almaz. Görüntü kolayca düzenlenebildiği için tek başına zayıf bir kayıttır. Teknik değerlendirme için iletinin orijinal .eml dosyası ya da en azından ham başlık metni gerekir. İleti mümkünse posta kutusundan silinmeden saklanmalıdır.

Yapıştırdığım başlıklar bir sunucuya gönderiliyor mu?

Hayır. Araç tamamen tarayıcınızda çalışır; ağ isteği yapmaz, IP ya da alan adı sorgulamaz ve metni kaydetmez. Bir .eml dosyası açtığınızda da dosya yüklenmez; tarayıcı dosyayı cihazınızın belleğinde açar ve yalnızca başlık bölümünü çözümler. Sayfayı yükledikten sonra internet bağlantınızı kesip aracı kullanarak bunu kendiniz doğrulayabilirsiniz.