Başlıklarını Okuyarak Kimlik Avı E-postası Nasıl Anlaşılır

Şüpheli bir e-postanın başlıklarını satır satır okuyun: From, Reply-To, Return-Path, Received zinciri ve SPF, DKIM ile DMARC sonuçlarının neyi kanıtladığı.

PureTempMail Ekibi

PureTempMail'i geliştiren ve işleten mühendisler

Yayınlandığı tarih 30 Ekim 2026

Kısa cevap

Mesaj kaynağını açın ve üç şeyi kontrol edin: From satırındaki alan adı için DMARC denetiminin geçip geçmediğini, Reply-To alanının başka bir yeri gösterip göstermediğini ve ilk Received satırının şirketin kendi sunucularından gelip gelmediğini. Bunlardan herhangi birinin başarısız olması güçlü bir uyarıdır. Üçünden de geçmek yalnızca e-postayı kimin gönderdiğini kanıtlar, göndericinin dürüst olduğunu değil.

Her e-posta, okuduğunuz metnin üstünde bir başlık bloğu taşır. Posta uygulamanız bunu gizler, ama mesajın hangi sunucudan geldiği, hangi alan adının ona kefil olduğu ve yanıtınızın gerçekte nereye gideceği orada kayıtlıdır. Mesajın kendisi kusursuz görünse bile kimlik avı genellikle kendini orada ele verir.

Gelen posta sunucusu işletiyoruz, bu yüzden bir mesaj tuhaf davrandığında okuduğumuz şey ham başlıklardır. Bu rehber, gerçekçi bir kimlik avı başlık bloğunu satır satır inceliyor, ardından tüm denetimlerin geçtiği daha zor durumu gösteriyor. Okurken herhangi bir mesajın başlıklarını e-posta başlığı analiz aracımıza yapıştırabilirsiniz. Araç tarayıcınızda çalışır ve başlıklar asla sunucularımıza gönderilmez.

Birinci adım: başlıkları posta uygulamanızdan çıkarın

Her e-posta istemcisi başlıkları varsayılan olarak gizler. Gmail'de mesajı açın, Yanıtla düğmesinin yanındaki üç nokta menüsüne tıklayın ve Orijinali göster seçeneğini seçin. Web üzerinde Outlook'ta üç nokta menüsünü açın, ardından View ve View message source seçeneklerini seçin. Mac'teki Apple Mail'de View, Message, All Headers yolunu izleyin. Başlık analiz aracı sayfası, Windows için Outlook, Yahoo ve diğerlerinin menü yollarını listeler.

İlk boş satırın üstündeki her şeyi kopyalayın. Başlık bloğu budur. Mesaj gövdesi ondan sonra gelir ve gerekli değildir. iPhone ve iPad'deki yerleşik Mail uygulaması başlıkları hiç göstermez; bu yüzden mesajı bir bilgisayara iletin ya da web postasından kontrol edin.

Bir kimlik avı e-postasının başlıkları, satır satır

Aşağıda, hesap uyarısı kılığındaki tipik bir kimlik avı e-postasının başlık bloğu var; yalnızca önemli satırlar bırakıldı. Alan adları ve adresler kurgusal yer tutuculardır, ama örüntü tekrar tekrar gördüğümüz örüntüdür. Başlıklar en yeniden eskiye doğru üst üste dizilir; yani mesajı size teslim eden sunucu en üste yakındır, mesajın yola çıktığı yer ise daha aşağıdadır.

Return-Path: <[email protected]>
Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=none;
    dmarc=fail (p=none) header.from=examplebank.com
Received: from mail.example.net (unknown [203.0.113.45])
    by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000
Received: from desktop-4kq2 (unknown [198.51.100.23])
    by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000
From: "Example Bank Security" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Unusual sign-in: confirm your account within 24 hours
Date: Thu, 29 Oct 2026 09:14:02 +0000
Message-ID: <20261029091402.4471@desktop-4kq2>

Kısaltılmış bir başlık bloğu. Example Bank kurgusaldır; bu senaryoda examplebank.com gerçek bankanın alan adı, example.net ise saldırganınkidir.

Her satırın size söyledikleri

Return-Path: Geri dönen postaların gittiği adres; zarf göndericisi olarak da bilinir. Burada bankanın alan adında değil, mail.example.net üzerinde. Tek başına pek bir şey kanıtlamaz, çünkü toplu e-posta sağlayıcısı üzerinden gönderilen bültenler de aynı görünür. Sonraki satırlar için aklınızda tutun.
Authentication-Results: Mesaj geldiğinde sağlayıcınızın kaydettiği karar. SPF geçmiş, ama saldırganın sunucusu olan mail.example.net için. DKIM imzası yok. Gerçekten gördüğünüz From alan adına bakan tek denetim olan DMARC, examplebank.com için başarısız olmuş. Bloktaki en işe yarar satır budur.
Received (en üst): Mesajı 203.0.113.45 adresinden kabul ettiğinde kendi sağlayıcınızın sunucusu mx.example.com tarafından eklenmiş. Sağlayıcınızın yazdığı satırlar güvenilirdir. Bu noktanın altındaki her şeyi, hakkında hiçbir şey bilmediğiniz makineler yazmıştır.
Received (en alt): En eski adım; bu yüzden zinciri aşağıdan yukarıya okuyun. Mesaj kendine desktop-4kq2 diyen bir makinede başlamış ve oturum açılmış bir gönderimle (ESMTPA) mail.example.net sunucusuna verilmiş. Bir bankanın uyarı sistemi birinin masaüstü bilgisayarında çalışmaz. Çalınmış ya da kiralanmış bir posta kutusu ise çalışır.
From: Görünen ad Example Bank Security diyor, adres de examplebank.com olduğunu iddia ediyor. Bu alana herkes istediğini yazabilir. Yukarıdaki DMARC başarısızlığı, bu From satırının sahte olduğunun kanıtıdır.
Reply-To: Yanıtla'ya basarsanız cevabınız üçüncü bir alan adına, example.org adresine gider. Sizden aramanızı ya da oturum açmanızı isteyen bir bankanın yanıtları başka birinin alan adında toplaması için hiçbir neden yoktur. Bilgilerinizle yanıt vermenizi isteyen kimlik avı e-postaları bu alanı neredeyse her zaman ayarlar.
Subject ve Date: Aciliyet artı bir son tarih. Date yalnızca gönderen makinenin iddiasıdır, ama onu Received zaman damgalarıyla karşılaştırın: Date ile ilk adım arasında saatler ya da günler süren bir fark, mesajın size ulaşmadan önce bir spam kuyruğunda beklediği anlamına gelebilir.
Message-ID: Gönderen yazılımın uydurduğu benzersiz bir kimlik. Büyük şirketlerin sistemleri buna kendi alan adlarını ekler. Bu kimlik, en alttaki Received satırındaki aynı ev makinesi olan desktop-4kq2 ile bitiyor. Buradaki bir uyuşmazlık kanıt değil, ipucudur; çünkü pek çok meşru yazılım genel kimlikler kullanır.

Hepsini bir araya getirince hikâye açık: bankadan geldiğini iddia eden bir mesaj, bir masaüstü bilgisayardan bir yabancının posta sunucusu üzerinden gönderilmiş, bankanın kendi kimlik doğrulamasından geçememiş ve yanıtınızı üçüncü bir alan adında istiyor. Nereye bakacağınızı bildiğinizde bu sonuca bir dakikadan kısa sürede varırsınız; başlık analiz aracı da DMARC başarısızlığını ve Reply-To uyuşmazlığını sizin için işaretler.

SPF, DKIM ve DMARC'ın sade bir açıklaması

Bu üç denetim, başlıkların göndericinin yazdığı metin değil, alıcı sunucunun mesajı test ettikten sonra yazdığı kısmıdır. Her biri farklı bir soruyu yanıtlar.

SPF: Bu sunucunun, zarf göndericisinin alan adı adına posta göndermesine izin var mı? Alan adı sahibi izin verilen sunucuların listesini DNS'te yayımlar, alıcı da bunu bağlanan IP adresiyle karşılaştırır. SPF, gördüğünüz From adresini değil Return-Path alan adını denetler; bir kimlik avı e-postasının kendi alan adı için SPF'ten geçebilmesinin nedeni budur. Sözlüğümüzdeki SPF maddesine bakın.
DKIM: Mesaj bir alan adı tarafından imzalanmış mı ve o zamandan beri değiştirilmiş mi? Gönderen sunucu kriptografik bir imza ekler, alıcı da bunu imzalayanın DNS'indeki ortak anahtarla doğrular. header.d= değeri imzalayan alan adını belirtir. İlgisiz bir alan adından gelen geçerli bir imza, From satırındaki marka hakkında hiçbir şey söylemez.
DMARC: From satırındaki alan adı, SPF ya da DKIM'den geçen bir alan adıyla eşleşiyor mu? Denetimleri gerçekten okuduğunuz ada bağlayan şey bu hizalama adımıdır. DMARC ayrıca alan adı sahibinin, başarısız mesajlarla ne yapılacağını alıcılara söylemesini sağlar: hiçbir şey (p=none), karantina ya da reddetme. Gerçek şirket bu politikayı uygulamaya almadığında sahte bir mesajın yine de gelen kutunuza ulaşabilmesinin nedeni budur.

Her sonucun anlamı

Sonuç	Anlamı	Ne kadar endişelenmeli
`pass`	Denetim, yanında adı geçen alan adı için başarılı oldu.	Düşük, ama hangi alan adının geçtiğini okuyun. Benzer görünen bir alan adı için pass sonucu yine de kimlik avıdır.
`fail`	Alan adının kendi kuralları, bu mesajın geldiği yerden gelmemesi gerektiğini söylüyor.	Tanıdığınız bir markada DMARC söz konusuysa yüksek.
`softfail`	Yalnızca SPF. Alan adı, sunucunun büyük olasılıkla yetkili olmadığını söylüyor ama alıcılardan mesajı doğrudan reddetmemelerini istiyor.	Orta. Yönlendirmede ve kötü bakılan SPF kayıtlarında yaygındır, başka işaretlerle birlikteyse şüphelidir.
`neutral`	Alan adı bu sunucu hakkında olumlu ya da olumsuz hiçbir beyanda bulunmuyor.	Kanıt yok olarak değerlendirin.
`none`	Denetlenecek bir kayıt ya da imza yoktu.	Normalde üçünü de yayımlayan büyük bir şirket için orta.
`temperror / permerror`	Denetim çalıştırılamadı: bir DNS zaman aşımı ya da gönderen tarafta bozuk bir kayıt.	Tek başına düşük. Diğer sonuçlara bakın.

Daha zor durum: tüm denetimler geçiyor

Dikkatli saldırganlar bir bankanın alan adını hiç taklit etmez. Benzer bir alan adı kaydeder, SPF, DKIM ve DMARC'ı düzgünce kurar ve oradan gönderirler. O zaman başlıklar tertemiz görünür:

Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=examplebank-secure.com;
    dkim=pass header.d=examplebank-secure.com;
    dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>

Üç denetim de geçiyor, çünkü examplebank-secure.com saldırgana ait ve onu doğru yapılandırmış.

Kimlik doğrulama, bu e-postayı examplebank-secure.com alan adının gönderdiğini kanıtlar. O alan adının bankanıza ait olup olmadığını söyleyemez. Bu kısım sizin işinizdir ve alan adının kendisini çok yavaş okumaya dayanır. En sık gördüğümüz hileler şunlar:

Fazladan sözcükler. Gerçek ad artı -secure, -login, -support ya da -verify.
Değiştirilmiş karakterler. m yerine rn, o harfi yerine sıfır, iki kez yazılmış ya da eksik bir harf.
Farklı bir uzantı. Doğru ad, şirketin kullandığı uzantı yerine .co, .net ya da yeni bir üst düzey alan adı üzerinde.
Alt alan adı olarak gerçek ad. examplebank.com.account-check.net adresinde alan adı account-check.net olur. Alan adlarını sağdan okuyun.
Benzer görünen alfabeler. Kiril а harfi, Latin a harfiyle aynı görünür. Ham başlıklarda bu tür alan adları çoğu zaman xn-- ile başlar; Latin olmayan alan adları bu şekilde kodlanır.
İşi görünen adın yapması. Ücretsiz bir web postası alan adındaki bir adresin önünde "Example Bank". Birçok telefon yalnızca adı gösterir, bu yüzden adresi görmek için ada dokunun.

Bir alan adının şirkete ait olup olmadığından emin değilseniz, bunu öğrenmek için e-postadaki hiçbir şeyi kullanmayın. Şirketin adresini tarayıcınıza kendiniz yazın ve karşılaştırın.

E-posta başlıklarındaki tehlike işaretleri, öneme göre

Bazı işaretler neredeyse kanıttır, bazıları ise ancak birikince önem kazanır. Onları kabaca şöyle tartıyoruz.

İşaret	Nereye bakılmalı	Ağırlık
Bilinen bir markada DMARC başarısız	Authentication-Results, `dmarc=fail header.from=`	Güçlü. From satırı büyük olasılıkla sahte.
From alan adı gerçeğine yakın ama tam olarak aynı değil	From ve `header.from=` değeri	Her şey geçse bile güçlü.
Farklı bir alan adında Reply-To	Reply-To	Mesaj sizden yanıt istiyorsa güçlü.
İlk adım bir ev makinesi ya da ilgisiz bir sağlayıcı	En alttaki Received satırı	Orta. Meşru posta genellikle şirketin içinden ya da onun toplu e-posta sağlayıcısından başlar.
Hiç kimlik doğrulama sonucu yok	Eksik Authentication-Results	SPF, DKIM ve DMARC yayımlayan büyük markalar için orta.
Göndericiyle ilgisiz Message-ID alan adı	Message-ID	Zayıf. Yalnızca destekleyici kanıt.
Farklı bir alan adında Return-Path	Return-Path	Zayıf. Toplu e-posta hizmeti üzerinden gönderilen bültenlerde normaldir.

Her şüpheli e-posta için beş dakikalık bir rutin

Başlıkların tamamını kopyalayın
Yukarıda anlatıldığı gibi Orijinali göster ya da View source seçeneğini kullanın ve her Received satırı dahil bloğun tamamını kopyalayın.
Bunları bir başlık analiz aracına yapıştırın
E-posta başlığı analiz aracımız From, Reply-To ve Return-Path alanlarını yan yana koyar, SPF, DKIM ve DMARC sonuçlarını gösterir ve teslimat rotasını en eskiden başlayarak listeler. Ayrıştırma tarayıcınızda yapılır.
DMARC'ı From alan adıyla karşılaştırın
dmarc= ifadesini ve yanındaki alan adını bulun. Tanıdığınız bir markada fail sonucu, burada durup mesajı silmek için yeterlidir.
Her alan adını sağdan başlayarak yavaşça okuyun
From, Reply-To ve DKIM'den geçen alan adının hepsi şirkete ait olmalıdır. Yukarıdaki benzer alan adı hilelerine dikkat edin.
Received zincirini aşağıdan okuyun
En alttaki satır, mesajın başladığı yerdir. Yalnızca en üstte, kendi sağlayıcınızın eklediği satırlara güvenin. Bir gönderici sahte Received satırları, hatta bunların altına sahte bir Authentication-Results satırı ekleyebilir.
Bağlantıları tıklamadan kontrol edin
Başlıklar gövdedeki bağlantıları göstermez. Bilgisayarda her düğmenin üzerine gelin ve pencerenin köşesindeki adresi okuyun. Şirketin gerçek alan adına gitmeyen her şey, oradan ayrılmak için bir nedendir.

Kimlik avı olduğunu düşünüyorsanız

Tıklamayın, yanıtlamayın, ekleri açmayın. Yanıt vermek adresinizin okunduğunu doğrular; ekler ise kötü amaçlı yazılımın en sık geldiği yoldur.
Şirketle başka bir yoldan iletişime geçin. Adresini tarayıcınıza yazın ya da kartınızdaki veya sözleşmenizdeki numarayı kullanın, asla e-postadakini değil.
Posta uygulamanızda bildirin. Gmail'de üç nokta menüsünü ve Kimlik avını bildir seçeneğini kullanın. Outlook'ta Bildir ve ardından Kimlik avını bildir seçeneğini kullanın. Bu, o hizmetteki herkes için filtreyi eğitir.
E-postayı Anti-Phishing Working Group'a iletin: [email protected] adresi, bildirimleri güvenlik şirketleri ve tarayıcılarla paylaşır.
ABD'deyseniz FTC'ye bildirin: ReportFraud.ftc.gov adresini kullanın, özellikle para ya da kişisel bilgiler söz konusuysa.
Zaten bir şifre girdiyseniz, şifreyi hemen gerçek sitede değiştirin, iki adımlı oturum açmayı etkinleştirin ve aynı şifreyi kullandığınız her yerde değiştirin. E-postanızın bir veri sızıntısında yer alıp almadığını kontrol etme rehberimiz, bir ifşadan sonraki ilk saati anlatır.

Sonuç

Bir kimlik avı e-postasını başlıklarından anlamak için yalnızca kendi sağlayıcınızın yazdıklarına güvenin, From satırındaki alan adının tam olarak kendisi için DMARC'ın geçtiğini kontrol edin ve benzer bir alan adını yakalayacak kadar dikkatle o alan adını okuyun. Bu üç alışkanlık sahte postaların çoğunu yakalar. Geri kalanı için en güvenli hamle her zamanki gibidir: e-posta üzerinden değil, doğrudan şirkete gidin. Bir sonraki şüpheli mesajı başlık analiz aracına yapıştırın ve ne gösterdiğine bakın.

Kaynaklar

IETF, RFC 7208: Sender Policy Framework (SPF); pass, fail, softfail ve neutral sonuçlarının anlamı dahil.
IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.
IETF, RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC); 2026'da yayımlandı ve RFC 7489'un yerini aldı.
IETF, RFC 8601: Message Header Field for Indicating Message Authentication Status; Authentication-Results başlığını tanımlar.
ABD Federal Ticaret Komisyonu, How to Recognize and Avoid Phishing Scams; FTC ve APWG bildirim adresleri için.
Anti-Phishing Working Group, Report Phishing.