Şüpheli E-posta İncelemesi: Başlık Analizi ve Received Zinciri

Kullanıcı “bu e-posta tuhaf” diye bildirdiğinde iki soruya hızlı cevap lazım: ileti gerçekten iddia ettiği yerden mi geldi, ve aynısı başka kimlere ulaştı? Cevap iletinin görünen kısmında değil, başlıklarında. Görünen ad yalan söyleyebilir. Received zinciri ve kendi sunucunuzun yazdığı kimlik doğrulama sonucu çok daha az yalan söyler. Bu rehber, güvenlik ve sistem ekipleri için başlıkların nasıl okunacağını, Received zincirinin nasıl yorumlanacağını, SPF/DKIM/DMARC sonuçlarının neyi kanıtlayıp neyi kanıtlamadığını ve Microsoft 365’te benzer iletilerin nasıl bulunup temizleneceğini sırasıyla anlatır.

Başlık analizine ne zaman ihtiyaç duyulur

Her şüpheli iletiye derin inceleme gerekmez. E-posta güvenliği filtresinin zaten yakaladığı toplu spam için saat harcamak boşa emektir. Başlık analizi şu durumlarda şarttır:

• İleti bir yöneticiden, tedarikçiden veya bankadan geliyor gibi görünüyor ve ödeme, IBAN değişikliği ya da kimlik bilgisi istiyor.
• İleti kendi alan adınızdan geliyor gibi görünüyor.
• Kullanıcı bağlantıya tıklamış veya eki açmış.
• Aynı içerik birden fazla kullanıcıdan bildirilmiş.

İlk koşul ham başlıklara erişmektir. Outlook’ta ileti özellikleri altındaki “İnternet üst bilgileri” alanı, Outlook web’de “İleti ayrıntılarını görüntüle” kullanılır. Sahada en sık gördüğümüz hata kullanıcıdan iletiyi düz iletmesini istemektir; düz iletme başlıkları kaybettirir ve inceleme daha başlamadan körleşir. Ek olarak iletme veya yerleşik Rapor düğmesi kullanılmalı.

Önemli başlık alanları

E-postada iki ayrı “gönderen” vardır: SMTP oturumundaki zarf gönderen (RFC 5321, MAIL FROM) ve kullanıcının gördüğü ileti başlığındaki gönderen (RFC 5322, From). Sahteciliğin büyük kısmı bu ikisi arasındaki boşluktan beslenir. Önce bu ayrımı oturtun.

Alan	Ne söyler	Dikkat
From	Kullanıcının gördüğü gönderen	Görünen ad serbestçe yazılır
Return-Path	Zarf gönderen; SPF bunu doğrular	From ile farklı olabilir
Reply-To	Yanıtın gideceği adres	BEC’in klasik izi
Message-ID	Gönderen sistemin ileti kimliği	Alan adı ipucu verir
Received	İletinin geçtiği sunucular	Aşağıdan yukarı okunur
Authentication-Results	SPF, DKIM, DMARC sonuçları	Yalnız kendi sunucunuzunkine güvenin
DKIM-Signature	İmzalayan alan adı (d=) ve seçici (s=)	İmza varlığı geçerlilik değildir

Exchange Online ayrıca X-Forefront-Antispam-Report ve X-Microsoft-Antispam başlıklarını ekler. Bunlarda bağlanan IP (CIP), ülke (CTRY), filtre kararı (SFV; örneğin SPM spam, NSPM spam değil, SKA izin listesi nedeniyle atlandı), kategori (CAT; örneğin PHSH, SPOOF, UIMP) ve toplu posta düzeyi (BCL) bulunur. SFV:SKA veya SFV:SKN görüyorsanız ileti bir izin listesi ya da taşıma kuralı yüzünden filtrelemeyi atlamıştır. O noktada inceleme iletiden çıkar, o kuralın incelenmesine döner. Sorun filtrede değil, istisnadadır.

Received zincirinin okunması

Her SMTP sunucusu iletiyi aldığında başlığın en üstüne bir Received satırı ekler. Zincir bu yüzden aşağıdan yukarı okunur: en alttaki satır ilk sunucuyu, en üstteki kendi posta kutusu sunucunuzu gösterir. Aşağıdaki örnek, inceleme için kısaltılmış kurgusal bir iletidir.

Received: from DB9PR02MB0000.eurprd02.prod.outlook.com ... (iç aktarım)
Received: from mailer.example.net (203.0.113.45) by
 AM2PEPF0000ABCD.mail.protection.outlook.com (10.0.0.10) with ESMTPS;
 Wed, 4 Nov 2026 09:12:41 +0000
Received: from [192.168.1.20] (unknown [198.51.100.77])
 by mailer.example.net with ESMTPSA; Wed, 4 Nov 2026 09:12:40 +0000
Authentication-Results: spf=pass (sender IP is 203.0.113.45)
 smtp.mailfrom=mailer.example.net; dkim=none (message not signed)
 header.d=none; dmarc=fail action=quarantine
 header.from=tedarikci.com.tr; compauth=fail reason=000
From: "Muhasebe - Tedarikci A.S." <muhasebe@tedarikci.com.tr>
Reply-To: <odeme.birimi@example.org>
Return-Path: bounce@mailer.example.net
Message-ID: <20261104091240.1A2B3C@mailer.example.net>

Okuma sırası şöyle. Önce kendi sınırınızı bulun: Exchange Online’da bu, mail.protection.outlook.com ile biten sunucunun “by” olarak geçtiği satırdır. Bu satırdaki “from” kısmı bağlantıyı kuran IP’yi (203.0.113.45) verir. Güvenilir ilk veri budur. Altındaki satırlar gönderen tarafın beyanıdır; doğru olabilir, ama sahte satır eklemek de mümkündür. Örnekte en alttaki satır iletinin kimliği doğrulanmış bir SMTP oturumuyla (ESMTPSA) 198.51.100.77 adresinden gönderildiğini söylüyor. Bu, ele geçirilmiş bir hesabın veya kiralık bir gönderim servisinin izi olabilir.

Zaman damgaları arasındaki büyük boşluklar kuyrukta beklemeyi ya da iletinin önceden hazırlanıp sonra gönderildiğini gösterebilir; saat dilimlerini UTC’ye çevirip karşılaştırın. Bağlanan IP için ters DNS ve sahiplik kontrolü yapın:

dig -x 203.0.113.45 +short
whois 203.0.113.45 | grep -iE 'orgname|netname|country'
# DKIM imzası varsa seçicinin yayımlanmış anahtarı
dig TXT s1._domainkey.example.net +short

Ters DNS kaydı olmayan, konut tipi bir IP bloğundan gelen “kurumsal fatura” iletisi tek başına kanıt değildir. Ama şüpheyi ciddi biçimde büyütür.

Authentication-Results yorumlama

Authentication-Results alanının biçimi RFC 8601’de tanımlıdır. Yalnız kendi alıcı sunucunuzun eklediği satıra güvenin; gönderen taraf da aynı adla başlık ekleyebilir. Örnekteki sonuçlar şunu söylüyor:

• spf=pass: mailer.example.net alan adı bu IP’den göndermeye yetkili. Ancak bu, kullanıcının gördüğü tedarikci.com.tr hakkında hiçbir şey söylemez.
• dkim=none: İleti imzalanmamış.
• dmarc=fail: From alan adıyla hizalı geçerli bir SPF veya DKIM sonucu yok. action=quarantine, gönderen alan adının yayımladığı politikaya göre uygulanan eylemdir.
• compauth=fail reason=000: Microsoft’un bileşik kimlik doğrulaması başarısız; 000 kodu açık bir DMARC başarısızlığını ifade eder.

SPF pass, From doğru demek değildir. Tedarikçinin alan adında DMARC politikası p=none olsaydı karar Microsoft’un örtük kimlik doğrulamasına kalırdı ve aynı iletinin gelen kutusuna ulaşma olasılığı artardı. Tedarikçilerinizin DMARC durumunu bilmek bu yüzden risk değerlendirmesinin parçasıdır. Hizalama mantığının ayrıntısı için DMARC p=reject geçiş rehberine, SPF’nin permerror ve temperror sonuçları için SPF DNS sorgu limiti yazısına bakın.

Sahtecilik ve yönlendirme izleri

Kimlik doğrulama sonuçları temiz çıksa bile ileti sahte olabilir. Saldırgan kendi kayıtlı alan adından bütün denetimleri geçerek gönderebilir. Şu izlere bakın:

İz	Örnek	Yorum
Görünen ad – adres uyumsuzluğu	“Genel Müdür” <gm.ofis@example.org>	Görünen ad sahteciliği
Benzer alan adı	tedarikci-tr.com, tedarlkci.com.tr	Kayıt tarihi yeni mi?
Reply-To farklı alan adında	Yanıt ücretsiz posta servisine	BEC göstergesi
Message-ID alan adı	Beklenmeyen bir servis	Destekleyici ipucu, kanıt değil
İç gönderen gibi dış ileti	X-MS-Exchange-Organization-AuthAs: Anonymous	Dış kaynaklı, iç görünümlü

En zor vaka, tedarikçinin gerçek posta kutusundan gelen ama içeriği sahte olan iletidir. Tüm doğrulamalar geçer, Received zinciri tedarikçinin gerçek altyapısını gösterir. Başlıklar “ileti tedarikçiden geldi” der. “Tedarikçi bunu gönderdi” demez. Bu noktada teknik inceleme biter, telefonla doğrulama başlar; senaryonun süreç tarafı BEC ve sahte fatura dolandırıcılığı yazısında.

Benzer iletilerin bulunması ve temizlenmesi

İleti zararlı çıktıysa, kurumsal siber güvenlik açısından iş daha yeni başlıyor: aynı kampanyanın diğer alıcılarını bulmanız gerekir. Arama ölçütü olarak bağlanan IP, zarf gönderen, From adresi, konu ve iletideki URL alan adı kullanılır. Tek ölçüt yetmez; en az ikisini birleştirin.

1. İleti izleme: Exchange Online’da ileti izleme (message trace) ile aynı gönderenden gelen iletiler listelenir. PowerShell’de güncel cmdlet Get-MessageTraceV2’dir.
2. Threat Explorer (Plan 2): Gönderen, IP, URL veya konuya göre filtrelenir, iletiler seçilir; yumuşak silme, kalıcı silme veya önemsiz klasörüne taşıma eylemi başlatılır.
3. Purview içerik araması: Plan 2 yoksa arama oluşturulur, sonuç sayısı doğrulanır, ardından temizleme eylemi çalıştırılır. Bu yöntemin posta kutusu başına silebileceği öğe sayısı sınırlıdır; büyük kampanyada eylem tekrarlanır.
4. Engelleme: Gönderen ve URL’ler Tenant Allow/Block List’e eklenir; aynı kampanyanın yeni dalgası teslim edilmez.

Connect-ExchangeOnline
Get-MessageTraceV2 -SenderAddress muhasebe@tedarikci.com.tr `
  -StartDate (Get-Date).AddDays(-3) -EndDate (Get-Date) |
  Select-Object Received, RecipientAddress, Subject, Status, FromIP

Connect-IPPSSession
New-ComplianceSearch -Name "Olay-2026-11-04" -ExchangeLocation All `
  -ContentMatchQuery '(From:muhasebe@tedarikci.com.tr) AND (Received:2026-11-03..2026-11-05)'
Start-ComplianceSearch -Identity "Olay-2026-11-04"
# Sonuç sayısını doğruladıktan sonra
New-ComplianceSearchAction -SearchName "Olay-2026-11-04" -Purge -PurgeType SoftDelete

New-TenantAllowBlockListItems -ListType Sender -Block -Entries "odeme.birimi@example.org"

Temizleme eylemini çalıştırmadan önce arama sonucundaki öğe sayısına ve örnek iletilere bakın. Sorgu fazla geniş yazılmışsa meşru yazışmalar da silinir. Geri dönüşü zahmetlidir.

Sorun güvenlikten çok posta akışıyla ilgiliyse, örneğin iletinin neden geciktiği veya neden reddedildiği soruluyorsa, Exchange Online posta akışı sorun giderme rehberi ileti izleme ve NDR analizini ayrıntılı anlatır.

İnceleme kontrol listesi

• Ham başlıklar ve özgün ileti (.eml veya .msg) delil olarak saklandı.
• Kendi sınır sunucunuzun Received satırı ve bağlanan IP belirlendi.
• Kendi sunucunuzun Authentication-Results satırı okundu; DMARC ve compauth sonucu not edildi.
• From, Return-Path, Reply-To ve Message-ID alan adları karşılaştırıldı.
• İçerikteki URL ve ekler izole ortamda veya tehdit istihbaratı servisinde kontrol edildi.
• Diğer alıcılar bulundu; tıklayan veya yanıtlayan kullanıcılar tespit edildi.
• İletiler temizlendi, gönderen ve URL engellendi.
• Kimlik bilgisi girildiyse parola sıfırlama, oturum iptali ve posta kutusu kural kontrolü yapıldı.

Son madde atlanırsa olay kapanmaz. Saldırganın posta kutusuna kurduğu yönlendirme kuralı parola değişikliğinden sonra da çalışmaya devam eder. Bildirilen iletilerin bu adımlarla düzenli işlenmesini olay müdahale sürecine yazın; rol dağılımı ve tatbikat için siber olay müdahale hazırlığı sayfasına bakabilirsiniz. Filtre politikalarının bu tür iletileri baştan yakalaması için gereken ayarlar Defender for Office 365 yapılandırma rehberinde. Başlık alanının resmi tanımı için RFC 8601’e bakın.

Sık sorulan sorular

Başlıkları ekran görüntüsünden incelemek yeterli olur mu?

Olmaz. Ekran görüntüsü yalnız görünen adı ve konuyu gösterir; Received zinciri, Authentication-Results ve Reply-To ancak ham başlıklarda görülür. Kullanıcıdan iletiyi ek olarak iletmesini veya Rapor düğmesiyle bildirmesini isteyin; düz iletme bazı başlıkları kaybettirir.

SPF pass görünen bir ileti güvenilir sayılabilir mi?

Tek başına sayılamaz. SPF zarf gönderen (Return-Path) alan adını doğrular, kullanıcının gördüğü From alan adını değil. Saldırgan kendi alan adıyla SPF pass alıp From alanına başka bir ad yazabilir. Belirleyici olan, From alan adıyla hizalı SPF veya DKIM sonucunu gösteren DMARC değerlendirmesidir.

Received zincirindeki tüm satırlara güvenilir mi?

Hayır. Her sunucu kendi satırını en üste ekler ve gönderen taraf zincirin altına sahte satır koyabilir. Güvenilir başlangıç noktası, kendi sınır sunucunuzun (örneğin Exchange Online Protection) eklediği ve bağlantıyı kuran IP’yi kaydettiği satırdır; altındaki satırlar yalnız bilgi amaçlıdır.

Benzer iletileri kullanıcı kutularından nasıl silebilirim?

Defender for Office 365 Plan 2 varsa Threat Explorer’dan iletileri seçip yumuşak veya kalıcı silme eylemi başlatın. Plan 2 yoksa Purview içerik araması oluşturup sonuç üzerinde temizleme (purge) eylemi çalıştırın. İki yöntemde de önce aramanın yalnız hedef iletileri bulduğunu doğrulayın.