SPF, DKIM, DMARC Nedir? E-posta Başlığından Sahte Maili Anlamak

SPF, DKIM ve DMARC nedir sorusunun kısa cevabı şu: bir e-postanın gerçekten göründüğü alan adından gelip gelmediğini kontrol eden üç DNS kaydı. SPF gönderen sunucunun yetkili olup olmadığına, DKIM iletinin imzasına bakar. DMARC bu iki sonucu e-posta programında gördüğün gönderen adresine bağlar. Bu yazıda üçünü sahte bir ödeme e-postasının başlığında satır satır okuyacaksın.

SPF, DKIM ve DMARC nedir, birlikte nasıl çalışır?

Üçü de alan adının DNS'inde yayınlanan TXT kayıtlarıdır ve alıcı posta sunucusu iletiyi kabul ederken bunlara bakar. Neden üç kayıt gerektiğini anlamak için bir e-postadaki iki gönderen adresini bilmen gerekir:

• Zarf adresi (MAIL FROM): Sunucular arasındaki teslimatta kullanılır. Teslim edilen iletide Return-Path satırı olarak görünür.
• Görünen adres (From): E-posta programında "Kimden" alanında okuduğun adrestir.

Gönderen bu iki adresi farklı yazabilir. SPF zarf adresinin alan adını, DKIM imzayı atan alan adını doğrular. İkisi de From satırını denetlemez. DMARC bu boşluğu kapatır: From'daki alan adının, geçen SPF ya da DKIM sonucundaki alan adıyla eşleşmesini ister. Buna hizalama (alignment) denir.

E-posta başlığı nasıl okunur?

E-posta başlığını okumak için iletinin ham hâlini açar, Authentication-Results, Return-Path, Received ve From satırlarını birbiriyle karşılaştırırsın. Bu işe mail header analizi de denir. Gmail'de bunu bilgisayardan yaparsın: iletiyi aç, Yanıtla düğmesinin yanındaki Diğer (üç nokta) menüsünden "Orijinali göster" seçeneğini seç. Açılan sayfanın üstünde üç denetimin özeti, altında başlığın tamamı vardır. Outlook'ta iletinin menüsündeki ileti ayrıntılarını gösteren seçeneği kullanırsın. Menü adları sürüme göre değişir. Diğer istemciler için Google'ın başlık rehberine bak.

Aşağıdaki başlık, kurgu bir şirkete (firma.example) gelen sahte bir ödeme talebinden kısaltıldı:

Return-Path: <[email protected]>
Received: from smtp.firma-odeme.example (smtp.firma-odeme.example [203.0.113.77])
        by mx.firma.example with ESMTPS; Tue, 3 Nov 2026 09:14:05 +0300
Authentication-Results: mx.firma.example;
        spf=pass smtp.mailfrom=firma-odeme.example;
        dkim=pass header.d=firma-odeme.example header.s=s1;
        dmarc=fail (p=none) header.from=firma.example
DKIM-Signature: v=1; a=rsa-sha256; d=firma-odeme.example; s=s1; ...
From: "Genel Müdür" <[email protected]>
Reply-To: <[email protected]>
To: [email protected]
Subject: Acil: bugün yapılması gereken ödeme

Satırları şu sırayla oku:

1. Authentication-Results: İlk bakacağın satır, bunu şirketin kendi sunucusu mx.firma.example yazdı. SPF ve DKIM geçmiş, ama ikisi de firma-odeme.example için. DMARC başarısız, çünkü From'daki firma.example bu alan adıyla hizalı değil.
2. Return-Path: Zarf adresi. SPF'in kontrol ettiği alan adı burada görünür, şirketinki değil.
3. Received: Köşeli parantezdeki 203.0.113.77, bağlantıyı kuran sunucunun adresidir ve bunu alıcı sunucu yazar. Birden fazla Received satırı varsa en üstteki en son eklenendir. Yolculuğu baştan izlemek için aşağıdan yukarı okursun.
4. From: "Genel Müdür" yalnız görünen addır, herkes istediğini yazabilir. Adres şirketin alan adında, ama doğrulama sonuçları onu desteklemiyor.
5. Reply-To: Yanıt bambaşka bir adrese gider. Ödeme talebiyle birlikte güçlü bir dolandırıcılık işaretidir.

DMARC başarısızken ileti neden gelen kutusuna düştü? Çünkü firma.example politikası p=none. Bu ayar, başarısız iletiler için bir tercih bildirilmediği anlamına gelir. p=reject olsaydı ileti büyük olasılıkla reddedilirdi.

Yalnız kendi posta sunucunun adını taşıyan Authentication-Results satırına güven. RFC 8601, alıcı sunucunun kendi adıyla dışarıdan gelen satırları silmesini ister. Başka adla gelen satırı gönderen de ekleyebilir. Senin sunucunun eklediklerinin altında kalan Received satırları da uydurulmuş olabilir.

Bunu tarayıcıda dene: Saha'daki Genel Müdürden Gelen Acil Talep görevinde sahte bir fatura e-postasının başlığını cat ve grep ile okur, bulguları vaka defterine işlersin. Görev tarayıcıda açılan bir terminalde çalışır, kurulum gerektirmez ve ücretsizdir.

SPF kaydı nedir, neyi kontrol eder?

SPF kaydı, bir alan adının "benim adıma yalnız şu sunucular posta gönderir" listesidir. Alıcı sunucu, bağlanan sunucunun IP'sini bu listeyle karşılaştırır:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -all"

v=spf1 kaydın türünü, ip4 yetkili adres aralığını söyler. include kullandığın posta hizmetinin listesini ekler. Sondaki ifade, listede olmayan sunucunun sonucunu belirler:

RFC 7208'deki iki kural en sık hatalara karşılık gelir. Bir alan adında yalnız bir SPF kaydı olabilir, ikincisi sonucu permerror yapar. include, a, mx, ptr, exists ve redirect gibi DNS sorgusu gerektiren ifadelerin toplamı 10'u geçemez. Her posta hizmeti bir include eklediği için bu sınır kolay aşılır, sonuç yine permerror olur.

SPF From satırına bakmaz ve yönlendirmede zayıftır. İletiyi başka adrese ileten sunucu artık son gönderendir, bu yüzden yönlendirilen ileti çoğu zaman SPF'ten geçemez.

DKIM imzası neyi kanıtlar?

DKIM imzası, iletinin d= alanındaki alan adının özel anahtarıyla imzalandığını ve imzalanan başlıkların ve gövdenin yolda değişmediğini kanıtlar. İmza, iletinin başlığına eklenir:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;
        h=from:to:subject:date; bh=...; b=...

• d=: İmzanın sorumluluğunu üstlenen alan adı.
• s=: Seçici. Alıcı açık anahtarı s1._domainkey.example.com TXT kaydında arar.
• h=: İmzaya dahil edilen başlıklar.
• bh= ve b=: Gövdenin özeti ve imzanın kendisi.

Seçici sayesinde alan adı birden fazla anahtar kullanır ve anahtarı kesintisiz yeniler. Anahtarı çoğu zaman posta hizmetin üretir, sen verdiği kaydı DNS'e eklersin. Gmail, kişisel Gmail hesaplarına gönderilen iletilerde en az 1024 bitlik DKIM anahtarı istiyor.

DKIM'in sınırını RFC 6376 açıkça yazar: imzalayan alan adının From'daki adresle eşleşmesi gerekmez. Yukarıdaki sahte iletide imza geçerliydi, ama saldırganın kendi alan adına aitti.

DMARC nedir, p=none, quarantine ve reject ne demek?

DMARC, From alan adının sahibinin yayınladığı bir politikadır. İletinin DMARC'tan geçmesi için SPF ya da DKIM'den en az birinin geçmesi ve geçen alan adının From ile hizalı olması gerekir. Örnek:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Varsayılan hizalama gevşektir: bulten.example.com ile example.com aynı kurumsal alan adını paylaştığı için hizalı sayılır. Sıkı modda (adkim=s, aspf=s) iki alan adı birebir aynı olmalıdır.

Politika bir istektir. RFC 9989'a göre alıcı sunucu uymak zorunda değildir ve kendi kurallarını uygular. rua etiketi toplu raporların gideceği adresi verir. Raporlar alan adın adına hangi sunucuların posta gönderdiğini gösterir.

Kasım 2026 itibarıyla güncel standart, Mayıs 2026'da yayımlanan RFC 9989'dur. RFC 7489'un yerini aldı ve DMARC'ı önerilen standart düzeyine taşıdı. Kayıtlar yine v=DMARC1 ile başlar. Yüzde belirten pct etiketi kaldırıldı, işlevini kısmen t=y test modu üstlendi: alıcıdan politikayı bir basamak yumuşak uygulamasını ister. Var olmayan alt alan adları için np etiketi eklendi.

Kendi alan adında DMARC'a güvenli geçiş sırası:

1. SPF ve DKIM'i bütün meşru göndericiler için kur: posta hizmeti, bülten aracı, fatura sistemi.
2. p=none ve bir rua adresiyle başla, raporları bir süre oku.
3. Raporlarda hizalanmamış meşru gönderici kalmayınca p=quarantine politikasına geç.
4. Sorun çıkmazsa p=reject ile bitir.

Üçü de geçtiyse e-posta güvenli midir?

Hayır. pass yalnız iletinin o alan adından geldiğini gösterir. Alan adının senin sandığın kurum olduğunu ya da isteğin meşru olduğunu göstermez. Şu üç durumda doğrulama yine geçer:

• Benzer alan adı: Saldırgan firma-odeme.example gibi bir alan adı alır, üç kaydı da kendisi kurar. From adresi bu alan adındaysa SPF, DKIM ve DMARC'ın üçü de geçer.
• Ele geçirilmiş gerçek hesap: Tedarikçinin posta hesabı ele geçirildiyse ileti gerçek altyapıdan çıkabilir. İş e-postası dolandırıcılığının (BEC) en zor yakalanan biçimi budur.
• Görünen ad hilesi: "Genel Müdür" adı, ücretsiz bir posta hizmetindeki adresin önüne yazılır. Doğrulama geçer, çünkü adres gerçekten o hizmete aittir.

Bu durumlarda bağlama bakarsın: alan adı ne zaman alınmış, istek olağan mı, ödeme bilgisi neden değişiyor? İstihbarat Masası'ndaki tedarikçi faturası vakasında IBAN değişikliği isteyen ileti gerçek tedarikçi adresinden görünür ve alan adı sahte değildir. Başlık bilgilerini, gönderen IP'nin itibarını, sandbox özetini ve pasif DNS kaydını birleştirip kurumun etkilenip etkilenmediğine karar verirsin. İstihbarat Masası giriş yapmadan da açılır ve taslağın tarayıcında saklanır.

Oltalamayı tanımanın genel ipuçları için phishing nedir yazısına, aciliyet ve otorite baskısının nasıl kurulduğu için sosyal mühendislik yazısına bak.

Kendi alan adının kayıtlarını nasıl kontrol edersin?

Üç kaydı terminalden dig ile okursun. Kayıtların nasıl çözüldüğünü DNS nedir yazısında görebilirsin.

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s1._domainkey.example.com

Windows'ta aynı sorguyu nslookup -type=TXT _dmarc.example.com ile yaparsın. DKIM seçicisini bilmiyorsan kendine bir e-posta gönder ve başlıktaki DKIM-Signature satırında s= değerine bak. Sonra şunları kontrol et:

1. Alan adında yalnız bir v=spf1 kaydı var mı?
2. SPF kaydı -all ya da ~all ile bitiyor mu, +all kullanılmamış mı?
3. Posta gönderen bütün hizmetler (bülten, destek, fatura) SPF'e eklenmiş ve DKIM ile imzalıyor mu?
4. _dmarc kaydı var mı, rua raporlarını okuyan biri var mı?
5. Hiç posta göndermeyen bir alan adın varsa ona v=spf1 -all ve p=reject yayınladın mı?

Kasım 2026 itibarıyla büyük sağlayıcılar bu kayıtları şart koşuyor:

Gmail kurallara uymayan iletiyi spam olarak işaretleyebilir ya da 5.7.26 hatasıyla reddedebilir. Microsoft'un duyurusuna göre kurallara uymayan iletiler 550 5.7.515 hatasıyla reddedilir.

Şüpheli bir e-posta aldıysan ne yaparsın?

Doğrulama sonucu ne olursa olsun, para ya da parola isteyen e-postayı başka kanaldan teyit edersin:

1. Bağlantıya tıklama, eki açma, iletiyi yanıtlama.
2. Ödeme ya da IBAN değişikliği talebini, karşı tarafın önceden bildiğin numarasını arayarak doğrula. E-postadaki numarayı kullanma.
3. Bir kurumda çalışıyorsan iletiyi başlığıyla birlikte BT ya da güvenlik ekibine bildir. Başlık, incelemenin ana kanıtıdır.
4. Oltalama sitesini USOM'a bildir. Nasıl yapılacağını USOM nedir yazısında bulursun.
5. Para çıktıysa önce bankanı resmî müşteri hizmetleri numarasından ara, kartı ya da hesabı kapattır ve işleme itiraz et. Ardından en yakın polis merkezine, jandarmaya ya da Cumhuriyet Başsavcılığına şikâyette bulun. Kayıtları ve ekran görüntülerini sakla.

Kaynaklar

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) imzaları
• RFC 9989: DMARC, Mayıs 2026 sürümü
• Google: Gmail'e e-posta gönderenler için kurallar
• Microsoft: Outlook'un yüksek hacimli gönderen kuralları