Önümüze gelen sorular genellikle şöyledir: bu fatura e-postası gerçekten tedarikçimizden mi geldi, karşı tarafın dosyaya koyduğu e-posta sonradan mı üretildi, ileti iddia edilen tarihte gönderildi mi? Cevap tek bir satırda değil, iletideki izlerle sunucu kayıtlarının birlikte okunmasındadır. Ödeme bilgisi değiştirilmiş bir faturayla karşılaştıysanız önce sahte IBAN e-postasında ilk 24 saatte yapılacaklara bakın: o durumda ilk iş bankayı aramaktır.
"Sahte e-posta" iddiaları hangi türlerde çıkar?
"Sahte e-posta" dediğimiz şey teknik olarak beş ayrı durumdur ve her birinde bakılacak kayıt değişir.
| Durum | Ne olmuştur | İncelemede bakılan | Dikkat |
|---|---|---|---|
| Gönderici taklidi (spoofing) | From alanına başkasının adresi yazılmıştır. SMTP bunu kendiliğinden engellemez (RFC 5321 §7.1). | Alıcı sunucunun Authentication-Results satırı, DMARC hizalaması, Received zinciri | DMARC politikası yoksa taklit ileti gelen kutusuna düşebilir. |
| Benzer alan adı | Saldırgan gerçeğine benzeyen kendi alan adından yazar (harf değişikliği, sona "-tr", "-fatura" eklenmesi). | Alan adının kayıt tarihi, ilk TLS sertifikasının tarihi, gösterilen ad ile gerçek adres farkı | SPF/DKIM/DMARC çoğu zaman pass döner, çünkü alan adı saldırganındır. |
| Ele geçirilmiş gerçek hesap | İleti gerçekten o hesaptan ve o kurumun sunucusundan çıkmıştır. | Oturum açma kayıtları, posta kutusu kuralları, ileti izleme kayıtları | Başlık tek başına yetmez; hesap kayıtları gerekir (hesap ele geçirme incelemesi). |
| Sonradan üretilmiş ya da düzenlenmiş ileti | Metni değiştirilmiş .eml, düzenlenmiş ekran görüntüsü, gönderilmemiş taslak. | DKIM gövde özeti (bh=), Message-ID'nin sunucu kayıtlarındaki karşılığı, karşı taraftaki kopya | Elde yalnızca ekran görüntüsü varsa sonuç çoğu zaman "belirlenemedi" olur. |
| Gönderim ve teslim uyuşmazlığı | "Gönderdim" ve "almadım" beyanları çelişir. | Received zamanları, sunucunun teslim kaydı, gönderilmiş öğeler kopyası | Teslim kaydı iletinin okunduğunu göstermez. |
Neden ekran görüntüsü değil, orijinal .eml dosyası?
Ekran görüntüsü, e-posta programının iletiyi nasıl gösterdiğinin resmidir. Gösterilen ad ("Muhasebe") gerçek adresi gizleyebilir; Received satırları, DKIM imzası ve doğrulama sonuçları görüntüde yoktur. Bu yüzden ekran görüntüsünden iletinin nereden geldiğine dair teknik sonuç çıkarılamaz (bkz. ekran görüntüsünün delil değeri). Normal iletme (forward) de yetmez: ileti yeni başlıklarla çıkar, asıl başlıklardan geriye çoğu zaman gövdeye alıntılanmış üç dört satır (kimden, tarih, konu) kalır. İletiyi birine aktarmak zorunluysa "ek olarak ilet" seçeneği iletinin kendisini dosya olarak ekler.
- Tek tek iletiler: webmail'de iletinin menüsünden indirilen
.eml, Outlook masaüstünden kaydedilen.msg..emlbaşlığı ve gövdeyi, ekler dahil, RFC 5322 biçiminde ham olarak taşır. - Kurumsal posta kutusu: yöneticinin dışa aktarma veya eDiscovery aracıyla aldığı
.pstya da.mbox, aynı döneme ait ileti izleme ve oturum açma kayıtlarıyla. - Kendi sunucusunu işletenler: posta kutusu ve loglar, değiştirilmeden.
Dosyayı açıp yeniden kaydetmeyin. Teslim aldığımız her dosyanın SHA-256 değerini kaydederiz; aynı değeri tarayıcıda çalışan hash hesaplama aracıyla siz de hesaplayabilirsiniz. Hash, elimizdeki kopyanın teslimden sonra değişmediğini gösterir, iletinin özgün olduğunu değil. Aynı ileti iki farklı programdan indirilirse hash'ler farklı çıkabilir; bu çelişki sayılmaz.
Başlık analizinde neye bakıyoruz?
Başlık analizi, iletinin geçtiği sunucuları, zamanları ve doğrulama sonuçlarını satır satır çıkarıp birbiriyle sınamaktır. Aşağıdaki başlık kurgusaldır, adresler dokümantasyon aralıklarından alınmıştır.
Örnek:
Return-Path: <fatura@example.com> Received: from mx.example.com (mx.example.com [192.0.2.10]) by mx.example.org (Postfix) with ESMTPS id 4dW3Kx1Z2Qz9sQ for <muhasebe@example.org>; Thu, 12 Mar 2026 10:21:07 +0300 Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com header.s=s1; dmarc=pass header.from=example.com DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; h=from:to:subject:date:message-id:reply-to; bh=…; b=… Received: from [10.0.0.23] (unknown [203.0.113.45]) by mx.example.com (Postfix) with ESMTPSA id 7C1E2A1B3 for <muhasebe@example.org>; Thu, 12 Mar 2026 07:21:05 +0000 From: "Tedarikçi A.Ş. Muhasebe" <fatura@example.com> Reply-To: <odeme@example.net> Date: Thu, 12 Mar 2026 10:21:04 +0300 Message-ID: <20260312072104.9F2A@mx.example.com> Subject: Güncel IBAN bilgimiz
Başlık aşağıdan yukarı okunur, çünkü her sunucu kendi Received satırını en üste ekler ve öncekileri değiştiremez (RFC 5321 §4.4). Bu örnekten çıkanlar:
- En alttaki
Received, gönderen sunucunun iletiyi 203.0.113.45 adresindeki istemciden kimlik doğrulamalı oturumla (ESMTPSA) aldığını söyler. EHLO'daki[10.0.0.23]istemcinin beyanıdır, parantezdeki adres bağlantıdan gelir. Satırı gönderen taraf yazmıştır; doğrulanması gereken bir beyandır. - Üstteki
ReceivedveAuthentication-Resultssatırlarını alıcının kendi sunucusu eklemiştir. Güven sınırı burasıdır. Alıcı sunucu, kendi adını taşıyan ama güvendiği bir sunucudan gelmemiş sonuç satırlarını silmekle yükümlüdür (RFC 8601 §5); başka bir ada ait sonuçlara itibar etmeyiz. id 4dW3Kx1Z2Qz9sQ, alıcı sunucunun logundaki kuyruk kimliğidir. Sunucu kayıtlarına bu anahtarla geçilir.- İki halkanın saatleri farklı dilimlerde yazılmış. UTC'ye çevrilince 07:21:05 ve 07:21:07 olur: sıra doğru, aralık iki saniye. Karşılaştırmayı hep UTC'de yaparız.
Dategönderenin cihaz saatidir, taşıma zamanı değildir (RFC 5322 §3.6.1).Reply-Tobaşka bir alan adına gidiyor. Tek başına sahtelik kanıtı değildir, ama ödeme değişikliği bildiren bir iletide ilk not ettiğimiz şeydir. İmza geçerli ve DKIMh=listesindereply-tovarsa bu alan imza anında vardı; aynı alandan iki tane varsa hangisinin imzalandığına bakarız.- Message-ID her ileti için tekil olmalıdır (RFC 5322 §3.6.4). Sağ tarafı gönderen altyapıyla tutarlı; sol taraftaki
20260312072104da Date'in UTC karşılığıyla örtüşüyor. Bazı sistemler kimliği zamandan üretir, ama bu bir kural değildir; asıl sınama, aynı kimliğin sunucu kayıtlarında bulunmasıdır.
Örnekte her şey pass ve tutarlı. Bu, iletinin example.com'un yetkili altyapısından çıktığını gösterir; fatura@example.com hesabının o anda kimin elinde olduğunu göstermez. Bundan sonrası hesap kayıtlarının işidir, başlığın değil. Başlığı kendiniz okumak isterseniz e-posta başlığının nasıl bulunup okunduğunu anlatan rehber ve tarayıcıda çalışan, hiçbir şey yüklemeyen e-posta başlık analizi aracı işinizi görür.
SPF, DKIM ve DMARC ne kanıtlar, ne kanıtlamaz?
Üçü de alan adını doğrular, kişiyi değil. Farkları, neyi denetledikleri ve hangi durumda yanlış alarm verdikleridir:
| Mekanizma | Neyi denetler | Neyi göstermez | İncelemede dikkat |
|---|---|---|---|
| SPF (RFC 7208) | Zarftaki MAIL FROM (ve HELO) alan adı için, bağlanan IP'nin DNS'te yetkilendirilmiş olup olmadığını | Ekranda görünen From adresini doğrudan denetlemez | Yönlendirilen iletilerde SPF bozulabilir; fail her zaman sahtelik değildir. |
| DKIM (RFC 6376) | h= listesindeki başlıkların ve gövdenin imzadan sonra değişmediğini; imzanın d= alan adının anahtarıyla atıldığını | İletiyi hangi kişinin yazdığını; imzalanmamış başlıkları; l= sınırından sonra eklenen gövdeyi | Anahtar DNS'ten kaldırıldıysa aylar sonra doğrulama başarısız olur (RFC 6376 §6); bu tek başına sahtelik göstermez. |
| DMARC (RFC 9989) | From alanındaki alan adının, SPF veya DKIM ile doğrulanmış bir alan adıyla hizalı olup olmadığını | Adresin kullanıcı kısmını (fatura@) | Politika kaydının iletinin gönderildiği tarihteki hâli ayrıca araştırılır. |
DMARC'ı bugün Mayıs 2026'da yayımlanan RFC 9989 tanımlıyor; RFC 7489'un yerini aldı. pct etiketi kalktı, np, psd ve t etiketleri geldi. İnternetteki Türkçe anlatımların çoğu hâlâ eski metne dayanıyor, raporda hangi sürüme göre değerlendirme yaptığımızı yazarız.
DKIM imzası, HMK m.205/2'nin senet hükmü tanıdığı güvenli elektronik imza değildir; bir alan adına bağlıdır, kişiye değil.
Sunucu kayıtları iletinin geçişini nasıl doğrular?
İletinin kendisi tek taraflı bir kayıttır; sunucu logları, iletinin gerçekten o sunucudan geçip geçmediğini bağımsız olarak gösterir. SMTP kayıtlarında aynı iletiye ait satırlar kuyruk kimliğiyle birbirine, Message-ID ile de başlığa bağlanır.
Örnek (alıcı tarafta Postfix logu):
Mar 12 10:21:07 mx postfix/smtpd[21877]: 4dW3Kx1Z2Qz9sQ: client=mx.example.com[192.0.2.10] Mar 12 10:21:07 mx postfix/cleanup[21880]: 4dW3Kx1Z2Qz9sQ: message-id=<20260312072104.9F2A@mx.example.com> Mar 12 10:21:08 mx postfix/qmgr[1022]: 4dW3Kx1Z2Qz9sQ: from=<fatura@example.com>, size=48213, nrcpt=1 (queue active) Mar 12 10:21:08 mx postfix/local[21885]: 4dW3Kx1Z2Qz9sQ: to=<muhasebe@example.org>, relay=local, status=sent (delivered to mailbox)
Satırlarda yıl ve saat dilimi yok; klasik syslog biçimi bunları yazmaz. İkisini sunucu yapılandırmasından belirler, raporda varsayım olarak yazarız.
- Exchange Server: ileti izleme varsayılan olarak açıktır ve 30 günden eski kayıtları döngüsel siler. Satırlarda UTC zamanı,
client-ip,message-id, zarftaki gönderen (return-path) veRECEIVE,DELIVER,FAILgibi olay türleri bulunur. İleti içeriği tutulmaz, konu satırı tutulur. - Exchange Online: ileti izleme verisi 90 gün tutulur, süre değiştirilemez. İzdeki "gönderen", başlıktaki From değil zarftaki MAIL FROM'dur.
- Postfix: varsayılan olarak syslog'a yazar; saklama süresini log rotasyonu belirler.
Bcc alıcıları diğer alıcıların kopyasında görünmez; iletinin gerçekte kimlere gittiği gönderen sunucunun kaydından (Exchange'de recipient-status alanı To, Cc, Bcc ayrımını taşıyabilir) ya da "Gönderilmiş Öğeler" kopyasından anlaşılır.
Ek dosyalar ve metadata
Ekler .eml dosyasının içinde MIME parçaları olarak durur; onları çıkarır, hash değerlerini alır ve metadata'larını ayrıca inceleriz. Sahte IBAN'lı fatura şüphesinde PDF'in Creator ve Producer alanları, CreationDate/ModDate ve sona eklenmiş güncellemeler (birden fazla %%EOF) aynı göndericinin önceki faturalarıyla karşılaştırılır. Bu alanlar da değiştirilebilir; tek başına hüküm kurmayız. Ayrıntı: doküman ve metadata incelemesi.
İnceleme nasıl ilerler?
- Kapsam. Hangi iletiler, hangi iddia, hangi posta kutularına hukuka uygun olarak erişilebildiği.
- Teslim. Orijinal dosyalar SHA-256 değerleriyle kayda geçer; çalışma kopya üzerinde yapılır.
- Başlık tablosu. Her
Receivedsatırı için sunucu, IP, protokol ve UTC zamanı; güven sınırı işaretlenir. - Kimlik doğrulama. Alındığı andaki
Authentication-Resultsokunur, DNS kayıtlarının bugünkü hâli sorgulanır, DKIM yeniden doğrulanır. - Alan adı. Benzer alan adında kayıt tarihi RDAP'tan (.tr için TRABİS'ten), ilk TLS sertifikası sertifika şeffaflığı (Certificate Transparency) kayıtlarından bulunur. Olaydan birkaç gün önce kaydedilmiş alan adı güçlü bir işarettir.
- Sunucu ve hesap kayıtları. İleti izleme, oturum açma ve posta kutusu kuralı kayıtları iletiyle eşleştirilir.
- Zaman çizelgesi ve rapor. Olaylar UTC ve Türkiye saatiyle tek çizelgede birleşir.
Raporda neler yer alır?
- İncelenen dosyaların listesi, SHA-256 değerleri ve teslim bilgisi
- Yöntem ve araçlar, sürümleriyle
- Başlık tablosu: her halka için sunucu, IP, zaman (UTC ve yerel) ve satırı hangi tarafın eklediği
- Kimlik doğrulama sonuçları ve DNS kayıtlarının inceleme tarihindeki hâli
- Sunucu kayıtlarıyla eşleştirme
- Her soru için bulgu: "uyumludur", "uyumlu değildir" ya da "mevcut materyalle belirlenemedi", dayandığı kayıtla birlikte
- Sınırlar ve sonucu güçlendirebilecek ek kayıtlar
Rapor, avukatınız tarafından dosyaya uzman görüşü (HMK m.293) ya da ceza dosyasında bilimsel mütalaa olarak sunulabilir. Mahkemeyi bağlamaz; hâkim onu diğer delillerle birlikte değerlendirir. Hukuki nitelendirme yapmayız: "sahtecilik yapılmıştır" değil, "ileti şu kayıtlarla uyumsuzdur" deriz.
Bu inceleme neyi gösteremez?
E-posta incelemesi klavyenin başındaki kişiyi göstermez; en iyi ihtimalle hesabı, sunucuyu ve bağlantıyı gösterir. Sunucu kayıtları silinmişse iletinin geçişi yalnızca kendi başlıklarından değerlendirilir. Elde yalnızca ekran görüntüsü varsa görüntünün iç tutarlılığına bakılabilir, o kadar. Bizce o durumda ilk iş, orijinal iletinin alıcıda ya da gönderende hâlâ durup durmadığını öğrenmektir.