E-posta başlığı (header) nasıl bulunur ve okunur?

Bu rehber, şüphelendiği bir e-postanın başlığını kendisi açıp okumak isteyen okur için yazıldı: başlık hangi programda nerede durur, hangi satıra güvenilir, SPF, DKIM ve DMARC sonuçları nasıl yorumlanır. Başlığı yapıştırıp satır satır ayrıştırmak isterseniz e-posta başlık analizi aracı aynı işi tarayıcınızda, metni hiçbir yere göndermeden yapar.

E-posta başlığı nedir, ekranda gördüğünüzden farkı ne?

E-posta başlığı, iletinin gövdesinden önce gelen ve her biri Alan-adı: değer biçiminde yazılmış satırlardan oluşan bölümdür (RFC 5322). E-posta programı bunlardan yalnızca birkaçını gösterir: Kimden, Kime, Tarih, Konu. Ham başlıkta ise çoğu zaman onlarca satır vardır ve bunların büyük kısmını gönderen kişi değil, iletiyi yolda taşıyan sunucular ekler.

Standart yalnızca iki alanı zorunlu tutar: Date ve From (RFC 5322 §3.6). Geri kalanı ya taşıma sırasında eklenir (Received, Authentication-Results, Return-Path) ya da gönderen programın tercihidir (Message-ID, X-Mailer). Bir karışıklığı da baştan giderelim: "e-posta başlığı" gündelik dilde bazen konu satırı için kullanılır. Bu yazıdaki başlık konu satırı değil, iletinin teknik üst bilgisidir; Microsoft'un Türkçe arayüzündeki adı "İnternet üst bilgileri"dir.

Başlık nerede bulunur? Gmail, Outlook, Apple Mail, Yandex

Her programda ham başlığa giden yol farklıdır. Aşağıdaki adımlar üreticilerin yardım sayfalarına dayanır; menü adları sürüme göre küçük farklar gösterebilir.

Telefon uygulamalarında ham başlığı gösteren bir seçenek genellikle yoktur. Gmail'in yardım sayfası da iletiyi indirme ve ek olarak yönlendirme adımlarını yalnızca bilgisayar için veriyor. En kolayı, aynı hesaba bilgisayardaki tarayıcıdan girmektir. Gmail'de "Orijinali göster" sayfasının üstünde Gmail'in kendi kısa özeti (ileti kimliği, SPF, DKIM ve DMARC sonuçları) bulunur; incelenecek asıl metin bu özetin altındaki ham başlıktır.

Başlık hangi sırayla okunur?

Başlığı yukarıdan aşağı düz okumak yanıltır, çünkü satırların bir kısmını güvendiğiniz sunucular, bir kısmını gönderen taraf yazmıştır. Aşağıdaki sıra önce güvenilebilecek satırları ayırır, gerisini onlarla sınar.

1. Satırları birleştirin. Uzun alanlar birden fazla satıra bölünür; boşluk ya da sekmeyle başlayan satır bir üstteki alanın devamıdır (RFC 5322 §2.2.3). Önce hangi satırın hangi alana ait olduğunu netleştirin.
2. Kendi sağlayıcınızın Authentication-Results satırını bulun. Bu satırı iletiyi teslim alan sunucu yazar ve SPF, DKIM, DMARC sonuçlarını taşır (RFC 8601). Satır, onu yazan sunucunun adıyla (authserv-id) başlar; Gmail'de bu ad mx.google.com'dur. Birden fazla sonuç satırı varsa sizin sağlayıcınızın adını taşıyan en üstteki esas alınır. Alıcı sunucu kendi adını taşıyan ama dışarıdan gelmiş sonuç satırlarını silmekle yükümlüdür (RFC 8601 §5); başka bir ada ait satırı ise gönderen taraf yazmış olabilir. Microsoft 365'te bu satır çoğu zaman sunucu adı olmadan doğrudan spf= ile başlar ve yanında Microsoft'un birleşik değerlendirmesi compauth bulunur.
3. Güven sınırını işaretleyin. Sağlayıcınızın iletiyi dışarıdan kabul ettiği Received satırını bulun: by kısmında sizin sağlayıcınızın sunucusu, from kısmında dışarıdaki bir sunucu yazar. Bu satırın altında kalan her şey gönderen tarafın ya da aradaki sunucuların beyanıdır ve doğrulanamaz; SMTP'nin kendisi göndericiyi doğrulamaz (RFC 5321 §7.1).
4. Received zincirini aşağıdan yukarı izleyin. Her sunucu kendi satırını en üste ekler ve öncekileri değiştiremez (RFC 5321 §4.4); en alttaki satır ilk aktarımdır. Her halkada from (bağlanan sunucunun kendini tanıttığı ad ve parantez içinde bağlantıdan görülen IP), by (satırı yazan sunucu), with (protokol; ESMTPS TLS'li bağlantı demektir) ve noktalı virgülden sonraki zamanı not edin.
5. Saatleri UTC'ye çevirin. Sunucular farklı saat dilimleri yazar: biri +0300, diğeri -0700. Sıralama ancak hepsi aynı referansa çevrilince anlamlıdır. Ayrıntısı zaman damgaları ve saat dilimi yazısında.
6. Adres alanlarını yan yana koyun. From ekranda görünen ad ve adrestir; Reply-To yanıtın gideceği adrestir; Return-Path zarftaki göndericidir ve son teslimi yapan sunucu ekler. Farklı olmaları tek başına sahtelik değildir: fatura, bülten ve CRM sistemleri zarfta kendi alan adlarını kullanır.
7. DKIM imzasına bakın. DKIM-Signature alanındaki d= imzayı atan alan adıdır; From'daki alan adıyla aynı mı ya da aynı kuruma mı ait? h= imzalanan başlıkları listeler ve From'un bu listede bulunması zorunludur (RFC 6376). s= seçicidir; aynı göndericinin eski iletileriyle karşılaştırmada işe yarar.
8. Sonucu olasılık diliyle yazın. "Bu ileti sahtedir" değil, "başlık bulguları, iletinin From alanındaki alan adının yetkili altyapısından çıktığıyla uyumlu değildir".

Kurgusal bir örnek: taklit edilmiş gönderici

Örnek: Aşağıdaki başlık kurgusaldır; alan adları ve IP adresleri dokümantasyon için ayrılmış aralıklardandır. İleti example.com şirketinin muhasebesinden geliyormuş gibi görünüyor; alıcının sunucusu mx.example.org.

Return-Path: <bounce@mailer.example.net>
Received: from smtp.example.net (smtp.example.net [198.51.100.77])
	by mx.example.org with ESMTPS id 7Qk2Zr0Lm4
	for <satinalma@example.org>; Tue, 14 Apr 2026 09:12:41 +0300
Authentication-Results: mx.example.org;
	spf=pass smtp.mailfrom=mailer.example.net;
	dkim=none;
	dmarc=fail (p=none) header.from=example.com
Authentication-Results: mx.example.com;
	spf=pass smtp.mailfrom=example.com;
	dkim=pass header.d=example.com;
	dmarc=pass header.from=example.com
Received: from mail.example.com (mail.example.com [192.0.2.10])
	by mx.example.com with ESMTP id 55AC01;
	Tue, 14 Apr 2026 06:14:02 +0000
From: "Example A.Ş. Muhasebe" <muhasebe@example.com>
Reply-To: <muhasebe.example@example.net>
Subject: Güncel banka bilgilerimiz
Date: Tue, 14 Apr 2026 09:12:38 +0300
Message-ID: <a81f3c2e-77d0@smtp.example.net>

Okuma sırasıyla:

• En üstteki Received ve ilk Authentication-Results satırlarını alıcının kendi sunucusu mx.example.org yazmış. Güven sınırı burası: ileti 198.51.100.77 adresindeki smtp.example.net'ten gelmiş, example.com'un altyapısından değil.
• Alıcının sonucu: SPF geçmiş, ama example.com için değil, zarftaki mailer.example.net için. DKIM imzası yok. DMARC fail: From'daki alan adı hiçbir hizalı doğrulamayla desteklenmiyor. Alan adının politikası p=none olduğu için ileti yine de gelen kutusuna düşmüş.
• İkinci sonuç satırı her şeyi "pass" gösteriyor, ama mx.example.com adına yazılmış ve güven sınırının altında duruyor. Bu satırı gönderen taraf eklemiştir; itibar edilmez.
• Alttaki Received satırı UTC'ye çevrilince 06:14:02, alıcının kabul satırı 06:12:41 ediyor. Zincirde aşağıdaki halka yukarıdakinden bir buçuk dakika sonra görünüyor; gerçek bir aktarımda bu olmaz. Satır büyük olasılıkla uydurmadır.
• Reply-To başka bir alan adına gidiyor: "Yanıtla"ya basan kişi saldırgana yazacak. Message-ID'nin sağ tarafı da iletinin gerçekte çıktığı smtp.example.net'i gösteriyor.

Bulgu cümlesi şöyle kurulur: başlık, iletinin example.com'un yetkili altyapısından çıkmadığıyla uyumludur. example.com politikasını p=reject'e taşımış olsaydı bu iletinin reddedilmesi ya da karantinaya alınması beklenirdi. Aynı iletinin bütün denetimlerden geçmiş bir sürümü de olabilirdi; o durumu e-posta incelemesi sayfasındaki örnekte anlattık.

SPF, DKIM ve DMARC sonuçları ne anlama gelir?

Sonuç satırındaki her değerin standartta tanımlı bir anlamı vardır. Aynı kelime üç mekanizmada farklı şey söyler:

Microsoft 365, standart değerlere ek olarak dmarc=bestguesspass yazabilir: alan adının DMARC kaydı yoktur, olsaydı ileti geçerdi. Bu bir tahmindir, doğrulama değildir.

İki pratik kural bu tablodan daha önemlidir. Birincisi, pass iletinin gerçek olduğunu göstermez. Ele geçirilmiş gerçek bir hesaptan ya da saldırgana ait benzer bir alan adından gelen ileti üç denetimden de geçer; DMARC yalnızca alan adının birebir taklidini hedefler ve benzer görünümlü alan adlarını ya da görünen ad oyunlarını kapsamaz (RFC 9989 §2.2). İkincisi, fail her zaman sahtelik demek değildir: yönlendirme SPF'i, posta listeleri DKIM'i bozabilir. Aylar sonra yapılan bir DKIM denetimi de, gönderen anahtarını DNS'ten kaldırdıysa başarısız olur (RFC 6376 §6). O yüzden esas alınan, iletinin alındığı anda yazılmış sonuçtur.

Sahte göndericinin tipik işaretleri

• Görünen ad ile adres uyuşmuyor. "Example A.Ş. Muhasebe" adının arkasında ücretsiz bir posta adresi durabilir. Telefonlarda çoğu zaman yalnızca ad görünür; adrese dokunmadan fark edilmez.
• Benzer alan adı. example.com yerine examp1e.com, example-tr.com ya da example.com.tr.example.net. Latin harflerine benzeyen başka alfabelerden harflerle yazılmış adlar başlıkta xn-- ile başlayan biçimde görünebilir. Alan adı saldırganınsa SPF, DKIM ve DMARC geçebilir.
• Reply-To başka bir alan adına gidiyor. Özellikle ödeme, belge ya da şifre isteyen iletilerde ilk bakılacak yerdir.
• En üstteki sonuç satırında dmarc=fail.
• Gmail'in uyarıları. Gönderen adının yanında soru işareti, iletinin kimliğinin doğrulanmadığını; "aracılığıyla" ibaresi, iletinin gönderildiği kaynağın Gönderen alanındaki alan adıyla eşleşmediğini gösterir. İkincisi bülten servislerinde olağandır.
• Güven sınırının altında tutarsızlık. Şirketin postası bilinen bir sağlayıcıdan çıkar ama bu ileti tanınmayan bir sunucudan bağlanmıştır; ya da alttaki Received satırının saati üsttekinden sonradır.
• Birden fazla Authentication-Results satırı ve alttakilerin hepsinin "pass" göstermesi.
• Message-ID'nin sağ tarafı gönderenin bilinen altyapısıyla ilgisiz. Zayıf bir işarettir: bazı programlar burada cihaz adı ya da rastgele bir değer kullanır.

Bu işaretlerin hiçbiri tek başına hüküm kurdurmaz; birkaçı bir araya geldiğinde anlam kazanır. İleti ödeme bilgisini değiştiriyorsa başlığı okumak ikinci iştir, ilk iş bankayı aramaktır: sahte IBAN e-postasında ilk 24 saat.

Başlık neyi gösteremez?

Başlık, iletinin hangi sunuculardan geçtiğini ve hangi alan adı adına doğrulandığını gösterir; klavyenin başındaki kişiyi göstermez. Ele geçirilmiş gerçek bir hesaptan giden ileti, başlığıyla her bakımdan olağan görünür. Bu durumda cevap başlıkta değil, hesabın oturum açma ve posta kutusu kayıtlarındadır.

Gönderenin IP adresi de çoğu zaman başlıkta yoktur. Başlıktaki IP'lerin çoğu sunuculara aittir; istemci IP'sini taşıyan X-Originating-IP standart bir alan değildir ve bazı büyük sağlayıcılar bu alanı kaldırmış ya da maskelemiştir. Bir IP bulunsa bile kişiyi değil bağlantıyı gösterir; nedenlerini IP adresi tek başına delil mi yazısında anlattık. Bir adresin özel ağ, CGNAT ya da genel adres olup olmadığını IP adresi kontrol aracıyla görebilirsiniz.

Son olarak, yapıştırılan başlık metni kolayca düzenlenebilir. Bir uyuşmazlıkta başlığın kayıt olarak kullanılması gerekiyorsa kopyalanmış metin değil, posta kutusundan alınmış orijinal ileti dosyası ve sunucu kayıtları incelenir. Bulguların hukuki değerlendirmesi avukata ve mahkemeye aittir.