Mail Başlığı Nasıl Okunur? From, Return-Path ve Received

Mail başlığı, her mailin gövdesinin üstünde taşınan ve her satırı From:, Received: gibi bir alanın adıyla başlayan kayıt bloğudur. Bu satırların bir kısmını gönderen yazar, bir kısmını yol üstündeki sunucular ekler. Başlığı okumanın anahtarı her satır için aynı soruyu sormaktır: bu satırı kim yazdı?

SMTP yazımızda postayı bir otogar üzerinden anlatmıştık: bagaj etiketi sandığın hangi otobüse yükleneceğini belirler, biletteki isim ise yalnız gösterilir. Mail başlığı bu benzetmede biletin kendisi ve yol boyunca sandığa vurulan aktarma damgalarıdır. Biletteki ismi yolcu yazar, damgaları her aktarma noktası kendisi vurur.

Bu yazıda iş adresimden kişisel bir Gmail adresine gönderdiğim bir test mailinin başlığını baştan sona okudum. Kişisel adresimi <alıcı> diye gizledim, uzun imza değerlerini ... ile kısalttım. Kurumların mail altyapısını kurumsal ağ kurulumu hizmetimiz kapsamında kuruyor ve yönetiyoruz.

Mail Başlığı Nedir? Zarf, Başlık ve Gövde

Bir mail sunucudan sunucuya giderken üç katman taşır. Mail başlığıyla ilgili kafa karışıklığının çoğu bu üçünün birbirine karıştırılmasından çıkar:

1. Zarf. SMTP konuşmasındaki MAIL FROM ve RCPT TO komutlarıdır. Sunucular maili zarfa bakarak yönlendirir. Zarf mailin içinde durmaz, sunucular arasındaki konuşmada kalır.
2. Başlık. Gövdenin üstündeki Alan: değer satırlarıdır. Okurun ekranda gördüğü gönderen, alıcı ve konu buradan gelir.
3. Gövde. Mailin metni ve ekleridir. Başlıktan ilk boş satırla ayrılır.

Örnekteki otogarda karşılıkları şöyledir:

• Zarf bagaj etiketidir. Görevli sandığı ona bakarak yükler.
• Başlık bilettir. Yolcu yalnız onu görür.
• Gövde sandığın içidir.

Zarf mailin içinde durmuyorsa, başlıkta onun bir izi nasıl oluyor? Cevap zarfın ömründe. Zarf her sunucu değişiminde yeniden söylenir: gönderen sunucu bir sonrakine MAIL FROM ile gönderen adresini, RCPT TO ile alıcıyı bildirir, mail aktarılır ve konuşma kapanır. Mail son sunucuya, yani alıcının posta kutusuna vardığında bir sonraki durak kalmaz. Zarfı yeniden söyleyecek bir konuşma da kalmaz.

Zarftaki gönderen adresi bu noktada kaybolmasın diye son teslimi yapan sunucu onu Return-Path: satırı olarak başlığa yazar. RFC 5321’in 4.4 bölümü bunu son teslimin zorunlu adımı sayıyor. Yani Return-Path: zarfın kendisi değil, son durakta zarftan başlığa kopyalanmış bir satırdır. İngilizce kaynaklarda zarftaki bu adrese “envelope from” denir.

Örnekteki otogarda bu, sandık son durakta indirilirken görevlinin bagaj etiketindeki gönderen adresini biletin üstüne geçirmesidir. Etiket sökülür, adres biletin üstünde kalır.

Mail Başlığı Nasıl Görülür? Gmail ve Outlook

Mail programları başlığın çoğunu gizler ve yalnız gönderen, alıcı, konu ve tarihi gösterir. Tamamını açmanın yolu programa göre değişir:

1. Gmail: mailin sağ üstündeki ⋮ menüsünden Aslını göster’e basın, İngilizce arayüzde adı Show original. Google’ın yardım sayfası aynı yolu tarif ediyor.
2. Yeni Outlook ve Outlook web: More actions → View → View message details.
3. Klasik Outlook: maili çift tıklayıp ayrı pencerede açın, sonra File → Properties. Başlık Internet headers kutusunda durur. Microsoft’un yardım sayfası iki yolu da anlatıyor.

Gmail’in açtığı sayfanın üstündeki SPF, DKIM ve DMARC özetini SPF yazımızda gösterdik. Bu yazının konusu özetin altındaki ham satırlar.

Mail Başlığındaki Alanları Kim Yazar?

Ham satırlara geçince karşınıza çıkan alanlar üç farklı elden çıkar: gönderenin mail programı, gönderen sunucu ve alıcının sunucusu. Test mailimizin başlığında 26 alan vardı. Okurken en sık karşılaşacağınız alanlar şunlar:

Tabloyu okumanın kuralı tek cümledir: gönderenin elindeki alana gönderen ne isterse onu yazar. RFC 5321’in 7.1 bölümü SMTP’yi bu yüzden doğası gereği güvensiz sayıyor. Sıradan bir kullanıcı bile alıcı sunucuyla doğrudan konuşup başka bir yerden gelmiş gibi duran bir mail üretebilir. From: satırı bir iddiadır, kanıt değildir. Kanıt, alıcının sunucusunun yazdığı satırlardadır.

From, Reply-To ve Return-Path: Üç Ayrı Adres

Kafa karıştıran üç alan da mailin “gönderen”i gibi görünür, ama üçü ayrı işler yapar:

1. From: mailin yazarıdır ve okurun ekranında görünen adres odur. RFC 5322 onu mesajı yazmaktan sorumlu kişi ya da sistem diye tanımlıyor.
2. Reply-To: yazarın cevap için önerdiği adrestir. Varsa, okur Yanıtla’ya bastığında cevap From alanındaki adrese değil buraya gider.
3. Return-Path: zarftaki gönderen adresidir. Teslim edilemeyen mailin bildirimi buraya döner ve SPF bu adresin alan adına bakar.

Test mailimizde From ve Return-Path alanları aynı adresi gösteriyordu, Reply-To alanı ise hiç yoktu. Örnekteki otogarda bu, biletteki isimle bagaj etiketindeki iade adresinin aynı firmaya çıkmasıdır. Bülten ve toplu mail servisleri ise teslim edilemeyen mailleri kendileri işlemek için zarfa kendi adreslerini yazar. Bu yüzden bir kampanya mailinin Return-Path satırında servisin alan adını görmek olağandır.

Test mailimizdeki From: satırı ilk bakışta okunmuyordu:

From: =?UTF-8?B?xLBsa2VyIFBFSEzEsFZBTg==?= <ilker.pehlivan@sistemkusu.com>

Bu bir şifre değil, bir kodlama. Başlık satırları tarihsel olarak yalnız ASCII karakter taşıdığı için gönderen program Türkçe harfli adı RFC 2047 ile kodlar:

1. =?UTF-8?B? karakter kümesini ve kodlamayı söyler. B Base64 demektir.
2. xLBsa2VyIFBFSEzEsFZBTg== kodlanmış addır, çözülünce “İlker PEHLİVAN” olur.
3. ?= kodlamayı kapatır. Gerçek adres < ile > arasındaki kısımdır.

Görünen ad ile adres iki ayrı parçadır. Ad istenen her şey olabilir, mailin hangi alan adına ait olduğunu adres söyler.

Received Satırları: Mail Başlığında Yolculuğun Kaydı

Gönderenin yazdığı alanlar birer iddiadır. Mailin gerçekten hangi yoldan geldiğini ise yol üstündeki sunucuların eklediği Received: satırları söyler. RFC 5321’e göre her sunucu kendi satırını en üste ekler. Önceki satırların sırasını değiştirmemeli, onları silmemelidir. Bu yüzden mailin izlediği yol aşağıdan yukarı okunur. Yığının nasıl oluştuğunu bir diyagramla SMTP yazımızın Received bölümünde gösterdik. Burada gerçek bir zinciri okuyoruz.

Test mailinin başlığındaki Received: ve Google’ın kendi X-Received: satırlarını başlıktaki sırasıyla bıraktım. Okunsun diye uzun satırları kırdım ve en alta gönderenin Date: satırını ekledim:

Received: by 2002:a05:6359:a397:b0:2b6:6abf:1c6d with SMTP id ky23csp5163408rwc;
        Tue, 6 Oct 2026 11:12:31 -0700 (PDT)
X-Received: by 2002:ad4:5c44:0:b0:912:517b:844 with SMTP id 6a1803df08f44-9198b850940mr40628926d6.40.1791310350794;
        Tue, 06 Oct 2026 11:12:30 -0700 (PDT)
Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65])
        by mx.google.com with SMTPS id 6a1803df08f44-917e0b45b60sor107928956d6.5.2026.10.06.11.12.30
        for <alıcı>
        (Google Transport Security);
        Tue, 06 Oct 2026 11:12:30 -0700 (PDT)
X-Received: by 2002:a05:622a:580a:b0:535:33a0:520c with SMTP id d75a77b69052e-5356634ef38mr40907081cf.3.1791310349983;
        Tue, 06 Oct 2026 11:12:29 -0700 (PDT)
Date: Tue, 6 Oct 2026 21:11:52 +0300

Okuma aşağıdan yukarı yapılır:

1. Date: (21:11:52, +0300). Gönderenin programına göre mail İstanbul saatiyle bu anda tamamlandı.
2. En alttaki X-Received: (11:12:29, -0700). Google’ın gönderim tarafındaki ilk iç adım. 2002: ile başlayan adres Google’ın iç ağına ait, gönderen bilgisayarın adresi değil.
3. Received: from mail-sor-f65.google.com ... by mx.google.com (11:12:30). Maili alıcının tarafı burada teslim aldı. from kısmı gönderen sunucunun adını ve köşeli parantez içinde IP adresini taşıyor. RFC 5321 bu kısmın kaynağın adını ve IP adresini birlikte taşımasını istiyor.
4. Üstteki iki satır (11:12:30 ve 11:12:31). Gmail’in kendi içindeki iki adım. Mail bu noktada kutuya ulaştı.

Saatleri tek bir saate çevirmeden karşılaştırmayın. Date: İstanbul saatini (+0300), Received: satırları Google sunucusunun Pasifik saatini (-0700) taşıyor. UTC’ye çevirince sıra şöyle:

Mail Google’ın gönderim sunucusuna ulaştıktan sonra iki saniyede kutuya düştü. Gmail’in özetindeki “38 saniye sonra teslim edildi” bilgisinin 37 saniyesi ise ilk sunucu satırından önce geçti, yani mail o sürede henüz gönderen taraftaydı.

Gönderenin IP Adresi Hangi Satırda?

Mail başlığından gönderenin IP adresinin bulunacağı sık tekrarlanan bir bilgidir. Beklenti, en alttaki Received: satırının gönderen bilgisayarın adresini taşımasıdır.

Bu test mailinde öyle değil. Mail Gmail’in web arayüzünden gönderildi ve başlığın hiçbir satırında benim bilgisayarımın adresi yok. Görünen tek dış adres 209.85.220.65. ARIN’in RDAP kaydına göre bu adres Google LLC’nin 209.85.128.0 - 209.85.255.255 bloğunda, yani Google’ın gönderim sunucularından birine ait.

Başlıkta bulunan IP, maili alıcının sunucusuna teslim eden sunucunun adresidir. O sunucu bir kurumun kendi mail sunucusuysa adres kurumu gösterir. Gmail ya da Microsoft 365 gibi bir servisse servisin sunucusunu gösterir, kişiyi göstermez. Hangi satırın neyi taşıdığı sağlayıcıya göre de değişir. Bazı servisler ve masaüstü programları gönderen bilgisayarın adresini de bir satıra yazabilir.

Hangi Received Satırına Güvenilir?

Yukarıdaki okuma, satırların gerçek olmasına dayanıyor. Her sunucu satırını en üste eklediği için, maili sizin sağlayıcınıza getiren taraf kendi altına istediği kadar sahte Received: satırı yazmış olabilir. Güvenebileceğiniz satırlar, sizin sağlayıcınızın eklediği satırlardır.

Sınır şöyle bulunur. Kendi sağlayıcınızın maili dışarıdan teslim aldığı satırı arayın, bu mailde by mx.google.com yazan satır. O satırın from kısmındaki IP adresini karşı taraf değil sizin sağlayıcınız yazdı. Bu adres, maili size getiren sunucunun gerçek adresidir.

Sağlayıcı aynı adımda bir grup satır daha ekler ve aşağıdaki şemada hepsi çizginin üstünde duruyor. Bu grubun altındaki her şey maille birlikte geldi ve gönderen tarafın beyanıdır.

Authentication-Results: Alıcının Mail Başlığına Yazdığı Karar

Güven çizgisinin üstünde, alıcının sunucusu bir karar satırı daha yazar: Authentication-Results:. Test mailimizde Google’ın yazdığı satırın üç sonucu şöyleydi, satırı kısalttım:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@sercebilisim.com header.s=google ...;
       spf=pass (...) smtp.mailfrom=ilker.pehlivan@sercebilisim.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sistemkusu.com

Mail başlığı açısından bu satırın değeri, üç adresi birbirine bağlamasıdır. header.from= okurun gördüğü From adresinin alan adını, smtp.mailfrom= zarftaki adresi, header.i= imzayı atan alan adını gösterir. Üçünün nasıl karşılaştırıldığını ve dmarc= sonucunun nasıl okunduğunu SPF, DKIM ve DMARC yazımızda parça parça anlattık.

DKIM-Signature: Mail Başlığının Hangi Alanları İmzalı?

DKIM-Signature: satırı gönderen sunucunun imzasıdır ve başlığın hangi alanlarının imzayla korunduğunu da kendisi söyler. Test mailimizdeki satırın ilgili kısmı şöyleydi:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sercebilisim.com; s=google;
        t=1791310350; x=1791915150; dara=google.com;
        h=content-type:to:subject:message-id:date:from:mime-version:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=/TANKIQx3P8CN0c6Wx261lsEA6CzRIUSQe+PsN7Uyag=; b=hi/2edN+...

Satırda okunacak dört şey var:

1. d=sistemkusu.com ve s=google. İmzayı atan alan adı ve doğrulamada kullanılacak anahtarın DNS’teki seçicisi.
2. h= listesi. İmzanın kapsadığı başlık alanları. Bu alanlardan biri yolda değişirse imza bozulur. RFC 6376, From alanının bu listede bulunmasını zorunlu tutuyor.
3. İki kez yazılmış adlar. from, to, subject, date ve message-id listede ikişer kez geçiyor. RFC 6376 bir alanın listede gerçekte olduğundan fazla yazılmasına izin veriyor. Amaç, imzadan sonra aynı alanın ikinci bir kopyasının eklenmesini fark ettirmek.
4. Mailde olmayan iki alan. cc ve reply-to listede var, ama mailin başlığında yoktu. RFC 6376’nın 5.4 bölümüne göre var olmayan bir alanı imzalamak, o alanın sonradan eklenmesini doğrulayana gösterir. Biri bu maile yolda bir Reply-To: eklerse imza bozulur.

Örnekteki otogarda mühür yalnız sandığın kapağına değil, biletin belirli satırlarına da basılır. Boş bırakılmış cevap adresi satırına da basıldığı için o satıra sonradan yazılan her şey mührü bozar.

Başlıktaki X-Google-DKIM-Signature: adlı ikinci imza ise 1e100.net alan adıyla atılmış. Bu, Google’ın kendi iç imzasıdır. Adı standart DKIM-Signature olmadığı için alıcı sunucuların DKIM denetimi ona bakmaz.

Sahte Mail Başlıktan Nasıl Anlaşılır?

Buraya kadar okunan alanlar birleşince şüpheli bir maili sınamak birkaç dakikalık iştir. Başlığı açın ve şu sırayla bakın:

1. Authentication-Results: içindeki dmarc= sonucu. Sonuç fail ise ya da hiç yoksa, From alanındaki alan adı kanıtlanmamıştır.
2. Üç alan adı aynı kuruma mı çıkıyor? From adresi, smtp.mailfrom= ve DKIM’deki d= birbiriyle ilgisiz alan adları gösteriyorsa bunu DMARC sonucuyla birlikte okuyun. Toplu mail servisleri bu farkı meşru olarak da yaratır.
3. Reply-To: var mı? Görünen gönderen tanıdık, cevap adresi yabancı bir alan adıysa cevabınız başka birine gider. Yazışmayı ele geçirmek isteyen biri için bu kadarı yeterlidir.
4. Görünen ad ile adres örtüşüyor mu? “Muhasebe Müdürü” yazan bir adın arkasında ücretsiz bir mail adresi durabilir. Adı değil < ile > arasını okuyun.
5. Sağlayıcınızın teslim aldığı Received: satırında maili kim getirdi? Gönderen kurumun mail servisiyle ilgisi olmayan bir sunucu, From satırının iddiasıyla çelişir.

Bu kontrolleri kurum içinde tek başınıza yapmak zorunda değilsiniz. Şüpheli maili BT ekibine iletirken ek olarak iletin. Normal iletme yeni bir mail başlatır ve orijinal başlığı geride bırakır. Ek olarak iletmede ise mail bir .eml dosyası olarak, başlığıyla birlikte gider.

Gmail’de maili seçip üstteki ⋮ menüsündeki ek olarak iletme seçeneğine basarsınız, İngilizce arayüzde adı Forward as attachment. Google’ın yardım sayfası da iletilen mailin .eml dosyasına dönüştüğünü yazıyor. Çalışanların bu ayrımı tanıması farkındalık eğitiminin konusudur.

Mail Başlığı Okurken Sık Yapılan Hatalar

Başlık okumanın hataları çoğunlukla satırları bir belge gibi yukarıdan aşağı okumaktan doğar:

1. Received: satırlarını yukarıdan aşağı okumak. En üstteki satır son durak, en alttaki başlangıçtır.
2. Saatleri dönüştürmeden karşılaştırmak. Bu mailde Date: 21:11’i, gönderim tarafındaki ilk X-Received: 11:12’yi gösteriyordu. Aralarında on saat var gibi görünse de gerçek fark 37 saniyeydi.
3. Date alanını teslim zamanı sanmak. RFC 5322’nin 3.6.1 bölümü bu alanın mailin tamamlandığı anı gösterdiğini, taşındığı anı göstermediğini açıkça söylüyor.
4. Alanların sırasına anlam yüklemek. RFC 5322’nin 3.6 bölümüne göre başlık alanlarının sırası garanti değildir. Sırası korunmak zorunda olan yalnız Received: gibi iz alanlarıdır.
5. X- ile başlayan alanları standart sanmak. X-Gm-Message-State gibi alanlar sağlayıcının kendi kayıtlarıdır, başka bir serviste karşılıkları yoktur.

Sonuç: Mail Başlığında Önce Satırı Kimin Yazdığına Bakın

Mail başlığını okumayı kolaylaştıran tek alışkanlık, her satırda o satırı kimin yazdığını sormaktır. Girişteki benzetmeye dönersek: örnekteki otogarda biletteki ismi yolcu yazar, damgaları ise her aktarma noktası kendisi vurur. From: biletteki isimdir, Received: satırları aktarma damgalarıdır ve en güvenilir damga sizin otogarınızın vurduğudur.

Test mailimizin başlığı üç şey gösterdi:

1. Gönderen bilgisayarın adresi başlıkta yoktu. Görünen tek dış adres Google’ın gönderim sunucusuydu.
2. Saatler iki ayrı saat diliminde yazılmıştı. Gerçek gecikme ancak UTC’ye çevirince görünüyordu.
3. İmza, mailde olmayan Reply-To: alanını da kapsıyordu. Yolda eklenecek bir cevap adresi imzayı bozardı.

Mailin sunucular arasında nasıl taşındığını SMTP yazımızda, alan adının kimliğinin nasıl doğrulandığını SPF, DKIM ve DMARC yazımızda anlattık.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn