E-posta Spoofing (Sahteciliği) Nasıl Önlenir?

E-posta protokolünün kalbindeki SMTP, 1980'lerin sonunda tasarlandı ve o dönemde kimsenin aklına "gönderen kim, gerçekten o mu?" sorusu gelmedi. Bunun sonucu bugün hâlâ yaşadığımız temel bir güvenlik açığı: bir e-postanın "Kimden" satırına yazan adres ile o e-postayı gerçekten gönderen sunucu arasında protokol düzeyinde hiçbir zorunlu bağ yoktur. Yani ben bir SMTP sunucusuna bağlanıp "Bu mektup [email protected] adresinden geliyor" diyebilirim ve sizin alan adınızla hiçbir ilişkim olmadığı hâlde mesaj çoğu zaman alıcının gelen kutusuna düşer. İşte e-posta spoofing dediğimiz sahtecilik tam olarak budur.

Bu makalede, gönderen adresinin neden bu kadar kolay taklit edilebildiğini teknik olarak açacak, bunun phishing saldırılarıyla ve marka itibarınızla olan doğrudan ilişkisini kuracağız. Ardından SPF, DKIM ve DMARC üçlüsünün birbirini nasıl tamamladığını, kritik olan p=none politikasından p=rejecte kademeli geçiş sürecini ve DMARC raporlarını nasıl okuyacağınızı gerçek örneklerle göstereceğiz. Amaç, "alan adım adına birileri spam gönderiyor" cümlesini bir daha kurmak zorunda kalmayacağınız bir yapılandırmaya ulaşmanız.

E-posta Spoofing Tam Olarak Nedir?#

Spoofing, bir e-postanın gerçek kaynağını gizleyerek onu güvenilir bir kişiden veya kurumdan geliyormuş gibi göstermektir. Burada dikkat edilmesi gereken önemli bir ayrım vardır. Bir e-postanın aslında iki farklı "gönderen" adresi bulunur:

• Envelope From (zarf adresi / Return-Path): SMTP oturumu sırasında MAIL FROM komutuyla belirtilir. Teslim edilemeyen mesajların geri döndüğü adrestir ve kullanıcı normalde görmez.
• Header From (başlık adresi): Mesajın içindeki From: başlığıdır. Alıcının e-posta istemcisinde "Kimden" olarak görünen adrestir.

Saldırganların işi kolaylaştıran şey, bu iki alanın birbirinden bağımsız ayarlanabilmesidir. Aşağıdaki gibi ham bir SMTP diyaloğu, bir saldırganın sizin alan adınızı nasıl taklit ettiğini net gösterir:

$ telnet mail.hedef-alici.com 25
220 mail.hedef-alici.com ESMTP
HELO saldirgan-sunucu.net
250 Merhaba
MAIL FROM:<[email protected]>
250 OK
RCPT TO:<[email protected]>
250 OK
DATA
354 Mesaj gövdesini girin
From: "Muhasebe Müdürü" <[email protected]>
Subject: Acil ödeme talebi
To: [email protected]

Merhaba, ekteki IBAN'a bugün ödeme yapılması gerekiyor.
.
250 OK: mesaj kuyruğa alındı

Görüldüğü gibi saldırganın sirketiniz.com üzerinde hiçbir yetkisi yok; sadece From: başlığına o adresi yazması yeterli oldu. Kimlik doğrulama mekanizmaları devrede değilse, alıcı sunucu bu mesajı kabul eder ve kullanıcı "Muhasebe Müdürü"nden geldiğini sanır. Spoofing'in tehlikesi bu basitlikte yatar.

Neden Bu Kadar Tehlikeli? Phishing ve Marka İtibarı#

Spoofing tek başına bir "gösteri" değildir; neredeyse her zaman daha büyük bir saldırının ilk adımıdır. En yaygın kullanım senaryoları şunlardır:

• Hedefli oltalama (spear phishing / BEC): Saldırgan CEO, muhasebe veya İK gibi güvenilir bir iç adresi taklit ederek çalışanı sahte havale, gizli belge paylaşımı veya kimlik bilgisi girişine ikna eder. İş E-postası Ele Geçirme (BEC) saldırıları, dünya genelinde en yüksek maddi kayba yol açan siber suç kategorilerinden biridir.
• Müşteri dolandırıcılığı: Alan adınız @markaniz.com müşterilerinize sahte fatura veya kampanya maili göndermek için kullanılır. Zarar gören müşteri olsa bile itibar kaybı sizin markanıza yazılır.
• Kara listeye düşme: Alan adınız adına toplu spam gönderilirse, IP ve alan adı itibarınız çöker; bir süre sonra kendi meşru e-postalarınız bile spam klasörüne düşmeye başlar.

Marka açısından en sinsi nokta şudur: müşteri sahte bir mail aldığında teknik ayrıntıyı bilmez, sadece "bu firmadan dolandırıcılık maili geldi" diye hatırlar. Bu yüzden e-posta kimlik doğrulaması yalnızca bir BT konusu değil, aynı zamanda bir güven ve pazarlama meselesidir. Konunun oltalama tarafını derinlemesine ele aldığımız phishing saldırılarından korunma rehberimizi de okumanızı öneririz.

Çözümün Üç Ayağı: SPF, DKIM ve DMARC#

Modern e-posta kimlik doğrulaması tek bir sihirli kayıtla değil, birbirini tamamlayan üç mekanizmayla çalışır. Bunların üçünü DNS bölgenize eklersiniz ve alıcı sunucular gelen her mesajı bu kayıtlara göre denetler. Aşağıdaki tablo, her birinin hangi soruyu yanıtladığını özetliyor:

Kritik nokta şudur: DMARC, SPF veya DKIM'in "alignment" (hizalama) ile başarılı olmasını şart koşar. Yani sadece SPF geçmesi yetmez; SPF'in doğruladığı alan adı ile kullanıcının gördüğü From: alan adının aynı organizasyona ait olması gerekir. İşte spoofing'i asıl durduran mantık budur. Üç kaydın nasıl birlikte çalıştığını uçtan uca ele aldığımız SPF, DKIM ve DMARC yapılandırma rehberimiz daha ayrıntılı bir referans sunar; burada özellikle spoofing'i durdurmaya odaklanacağız.

SPF Kaydını Doğru Kurmak#

SPF (Sender Policy Framework), alan adınız adına hangi sunucuların mail gönderebileceğini DNS'te ilan eder. Alan adınızın kök seviyesine tek bir TXT kaydı olarak eklenir:

sirketiniz.com.   IN   TXT   "v=spf1 include:_spf.google.com include:sirketiniz-mailserver.com ip4:203.0.113.10 -all"

Bu kaydın parçalarını açalım:

• v=spf1 — SPF sürüm etiketi, her kayıt bununla başlar.
• include:... — Google Workspace, bülten servisi veya hosting sağlayıcınız gibi sizin adınıza mail gönderen üçüncü taraf sistemleri yetkilendirir.
• ip4:203.0.113.10 — kendi posta sunucunuzun sabit IP adresi.
• -all — bu kayıtta listelenmeyen tüm kaynakları reddet anlamına gelir. En güvenli seçenektir.

Sondaki niteleyici hayati önemdedir ve sık yapılan hataların kaynağıdır:

SPF'te uyulması gereken iki teknik sınır vardır. Birincisi, bir alan adı başına yalnızca tek bir SPF TXT kaydı olabilir; iki tane koyarsanız bazı sunucular ikisini de geçersiz sayar. İkincisi, include ve a/mx gibi mekanizmalar en fazla 10 DNS sorgusuyla çözülebilmelidir; bu sınırı aşarsanız SPF permerror verir ve koruma çöker. Kaydınızı Linux üzerinden hızlıca doğrulayabilirsiniz:

dig +short TXT sirketiniz.com | grep spf1
# Beklenen çıktı:
# "v=spf1 include:_spf.google.com ip4:203.0.113.10 -all"

SPF'in en büyük zayıflığı, e-posta bir aracı sunucudan yönlendirildiğinde (forwarding) gönderen IP'nin değişmesi ve kaydın kırılmasıdır. Bu boşluğu DKIM kapatır.

DKIM ile Mesajı Kriptografik Olarak İmzalamak#

DKIM (DomainKeys Identified Mail), giden her mesaja alan adınıza ait özel anahtarla dijital bir imza ekler. Alıcı sunucu, DNS'te yayınladığınız açık anahtarı çekerek bu imzayı doğrular. İmza geçerliyse iki şey kanıtlanmış olur: mesaj gerçekten sizin alanınızdan çıkmıştır ve yolda içeriği değiştirilmemiştir. SPF'ten farklı olarak DKIM, IP değişse bile bozulmaz; bu yüzden yönlendirme senaryolarında çok daha dayanıklıdır.

Önce bir anahtar çifti üretirsiniz. OpenDKIM ile örnek:

opendkim-genkey -b 2048 -d sirketiniz.com -s mail2026
# mail2026.private  → sunucuda gizli tutulur
# mail2026.txt      → DNS'e eklenecek açık anahtar

Üretilen açık anahtarı bir "selector" (burada mail2026) altında DNS TXT kaydı olarak yayınlarsınız:

mail2026._domainkey.sirketiniz.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB"

Sunucu tarafında (örneğin Postfix + OpenDKIM) imzalama devreye alınır:

# /etc/opendkim.conf
Domain                  sirketiniz.com
Selector                mail2026
KeyFile                 /etc/opendkim/keys/mail2026.private
Canonicalization        relaxed/simple
Mode                    sv

Doğru çalıştığında giden mesajın başlıklarında şuna benzer bir imza görürsünüz:

DKIM-Signature: v=1; a=rsa-sha256; d=sirketiniz.com; s=mail2026;
    h=from:to:subject:date; bh=...; b=...

Pratik iki öneri: anahtar uzunluğunu en az 2048 bit tutun (1024 bit artık zayıf kabul ediliyor) ve anahtarları yılda bir "selector" değiştirerek döndürün; böylece bir anahtar sızarsa etkisi sınırlı kalır. Yönetimli bir e-posta altyapısı istiyorsanız kurumsal e-posta hizmetimiz SPF ve DKIM'i sizin için hazır getirir.

DMARC ile Politikayı Belirlemek ve Sahteciliği Durdurmak#

SPF ve DKIM tek başlarına "başarısız olursa ne yapılacağını" söylemez; işte DMARC (Domain-based Message Authentication, Reporting and Conformance) tam bu boşluğu doldurur. DMARC üç şey yapar: bir politika ilan eder (kabul et, karantinaya al, reddet), SPF/DKIM hizalamasını denetler ve size ne olup bittiğine dair raporlar gönderir. Bir DMARC kaydı _dmarc alt alanında yayınlanır:

_dmarc.sirketiniz.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100"

Etiketleri açalım:

• p=none | quarantine | reject — başarısız mesajlara uygulanacak politika.
• rua= — toplu (aggregate) raporların gönderileceği adres. Günlük özet XML'leri buraya gelir.
• ruf= — adli (forensic) raporların adresi; başarısız tek tek mesajların ayrıntısı.
• adkim / aspf — hizalama modu; s (strict) tam eşleşme, r (relaxed) alt alan toleransı sağlar.
• pct=100 — politikanın mesajların yüzde kaçına uygulanacağı; kademeli geçişte çok işe yarar.

Bir mesajın DMARC'ı geçmesi için, SPF veya DKIM'den en az birinin başarılı olması ve o başarılı mekanizmanın alan adının kullanıcıya görünen From: alan adıyla hizalı olması gerekir. Bu "hizalama" şartı spoofing'i imkânsıza yakın hâle getirir; çünkü saldırgan From: alanına sizin adınızı yazsa bile, ne sizin SPF'inizi geçebilir ne de sizin özel anahtarınızla DKIM imzası atabilir.

p=none'dan p=reject'e Kademeli Geçiş#

DMARC'ı doğrudan p=reject ile başlatmak cazip görünse de tehlikelidir; farkında olmadığınız meşru bir gönderici (bülten servisi, CRM, fatura sistemi) düzgün hizalanmamışsa o mesajlar anında reddedilir. Doğru yaklaşım, üç aşamalı bir olgunlaşma sürecidir:

Süreç şöyle işler. Önce p=none ile yayına geçer, DMARC raporlarını toplamaya başlarsınız. Bu aşamada hiçbir mesaj engellenmez; sadece gözlem yaparsınız. Raporlarda "kaç mesaj SPF/DKIM'i geçti, hangi IP'lerden geliyor" bilgisini görürsünüz. Meşru gönderdiğiniz halde başarısız olan sistemleri bulup onların SPF/DKIM ayarlarını düzeltirsiniz.

Meşru trafiğin yüzde 95'inden fazlası temiz geçmeye başladığında karantinaya geçersiniz. Riski azaltmak için pct ile başlarsınız:

# 1. hafta: mesajların sadece %25'ine karantina uygula
_dmarc.sirketiniz.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"

# 2. hafta sorunsuzsa %100'e çıkar
_dmarc.sirketiniz.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"

Karantina aşamasında da rapor akışı temizse son adıma, tam zorlamaya geçersiniz:

_dmarc.sirketiniz.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

Bu noktadan sonra sizin adınıza gönderilen tüm sahte mesajlar alıcı sunucular tarafından reddedilir; spoofing pratikte durur. Bu geçişi aceleye getirmeyin, ama yarım da bırakmayın: p=noneda takılı kalan bir DMARC koruma değil, sadece bir gözlemci konumundadır.

DMARC Raporlarını Okumak#

DMARC raporları, alan adınızın "kimlik doğrulama sağlığının" günlük röntgenidir. Alıcı sağlayıcılar (Google, Microsoft, Yahoo vb.) her gün size sıkıştırılmış XML dosyaları gönderir. Ham hâlleri okunması zordur, ama yapı basittir. Tek bir kaydın özü şuna benzer:

source_ip: 203.0.113.10
count: 128
disposition: none
dkim: pass
spf: pass
header_from: sirketiniz.com

Burada count, o IP'den kaç mesaj geldiğini; dkim/spf, sonuçlarını; disposition ise uygulanan politikayı gösterir. Raporlarda üç tip kaynak görürsünüz: (1) sizin meşru sunucularınız — hepsi pass olmalı; (2) yetkilendirmeyi unuttuğunuz meşru üçüncü taraf sistemler — bunları SPF/DKIM'e ekleyip düzeltirsiniz; (3) sizi taklit eden saldırgan IP'ler — p=rejecte geçtikten sonra bunların etkisi sıfırlanır.

Bu XML'leri elle okumak yorucudur, bu yüzden bir DMARC rapor toplayıcı kullanmak akıllıca olur. Ham raporları hızlıca özetlemek için basit bir SQL sorgusu bile işe yarar:

SELECT source_ip,
       SUM(message_count) AS toplam,
       spf_result,
       dkim_result
FROM dmarc_kayitlari
WHERE header_from = 'sirketiniz.com'
GROUP BY source_ip, spf_result, dkim_result
ORDER BY toplam DESC;

Raporları düzenli takip etmek, hem sahtecilik girişimlerini erkenden görmenizi hem de yeni eklediğiniz meşru bir servisin (örneğin bir e-fatura entegrasyonu) yanlışlıkla engellenmesini önlemenizi sağlar. Kısacası DMARC raporu bir "kur ve unut" belgesi değil, sürekli bakılması gereken bir gösterge tablosudur.

Ek Katman: BIMI, MTA-STS ve Altyapı Hijyeni#

SPF, DKIM ve DMARC üçlüsü işin bel kemiğidir, ancak birkaç tamamlayıcı önlem korumanızı güçlendirir. p=reject seviyesine ulaştığınızda BIMI'yi (Brand Indicators for Message Identification) devreye alabilirsiniz; bu, doğrulanmış markaların logosunun alıcının gelen kutusunda görünmesini sağlar ve hem güven hem de görünürlük katar. MTA-STS ve TLS-RPT ise sunucular arası trafiğin şifreli kanaldan gitmesini zorunlu kılarak araya girme (man-in-the-middle) risklerini azaltır.

Bunların dışında birkaç temel hijyen kuralı vardır. Kullanmadığınız alt alanlar için bile boş bir SPF ve p=rejectli DMARC yayınlayın; saldırganlar çoğu zaman ana alan yerine korunmasız alt alanları hedefler:

# Hiç mail göndermeyen bir alt alan adı için "kilit" kaydı
pazarlama.sirketiniz.com.        IN TXT "v=spf1 -all"
_dmarc.pazarlama.sirketiniz.com. IN TXT "v=DMARC1; p=reject;"

Ayrıca posta sunucunuzu, web uygulamalarınızı ve DNS bölgenizi güncel tutmak, güçlü kimlik doğrulama kullanmak ve giden mail hacmini izlemek de resmin parçasıdır. Alan adı ve DNS yönetiminizi güvenilir bir sağlayıcıda toplamak bu kayıtları yönetmeyi kolaylaştırır; alan adı hizmetlerimiz ile DNS bölgenizi tek panelden yönetip bu kayıtları dakikalar içinde ekleyebilirsiniz. Sunucu tarafındaki sertleştirme için sunucu yönetimi hizmetimize göz atabilirsiniz.

Sıkça Sorulan Sorular#

SPF kurdum ama hâlâ adıma spam geliyor, neden?#

Tek başına SPF, kullanıcının gördüğü From: başlığını değil, arka plandaki zarf adresini doğrular; bu yüzden saldırgan farklı bir zarf adresi kullanıp sizin adınızı sadece From: satırına yazarak SPF'i atlatabilir. Bu boşluğu kapatan şey DMARC'ın "hizalama" şartıdır. SPF'i mutlaka -all ile bitirin ve üzerine p=reject seviyesinde bir DMARC ekleyin; asıl sahteciliği durduran kombinasyon budur.

DMARC'ı doğrudan p=reject ile başlatabilir miyim?#

Teknik olarak mümkündür ama şiddetle önerilmez. Adınıza meşru mail gönderen ama farkında olmadığınız bir sistem (bülten aracı, CRM, fatura servisi) düzgün hizalanmamışsa, o mesajlar p=reject ile anında reddedilir ve müşterilerinize ulaşmaz. Doğru yol en az iki hafta p=none ile raporları izlemek, tüm meşru göndericileri düzeltmek ve ancak ondan sonra kademeli olarak quarantine ve rejecte geçmektir.

DKIM anahtarımın kaç bit olması gerekir?#

Günümüzde standart 2048 bit RSA anahtarıdır; 1024 bit artık zayıf kabul edilir ve bazı sağlayıcılar tarafından uyarı olarak işaretlenir. Anahtarınızı opendkim-genkey -b 2048 gibi bir komutla üretin ve yılda en az bir kez "selector" değiştirerek döndürün. Anahtar döndürme, olası bir sızıntının etkisini sınırlar ve altyapınızın güvenlik hijyenini korur.

Hiç mail göndermeyen bir alan adımı da korumam gerekir mi?#

Kesinlikle evet. Saldırganlar en çok, sahibinin "zaten mail göndermiyorum" diyerek koruma eklemediği park edilmiş alan adlarını ve alt alanları hedefler. Bu tür alanlara v=spf1 -all biçiminde boş bir SPF ve v=DMARC1; p=reject; DMARC kaydı ekleyerek o alan adıyla hiçbir mesajın gönderilemeyeceğini ilan edersiniz. Böylece marka adınız sahtecilik için kullanılamaz hâle gelir.

DMARC raporlarını okuyamıyorum, ham XML çok karmaşık. Ne yapmalıyım?#

Bu tamamen normaldir; DMARC toplu raporları makineler için tasarlanmış sıkıştırılmış XML dosyalarıdır. Raporları rua adresinize toplayıp bir DMARC rapor analiz servisine ya da açık kaynak bir toplayıcıya yönlendirin; bunlar XML'leri okunabilir bir gösterge tablosuna dönüştürür. Alternatif olarak raporları bir veritabanına aktarıp basit bir SQL sorgusuyla IP başına geçen/kalan mesaj sayısını özetleyebilirsiniz. Önemli olan raporlara düzenli bakmayı bir alışkanlık hâline getirmenizdir.

SPF, DKIM ve DMARC teslim edilebilirliğimi (deliverability) artırır mı?#

Evet, doğrudan olumlu etki eder. Google ve Microsoft gibi büyük sağlayıcılar artık toplu gönderim yapan alan adlarından bu üç kaydın da düzgün yapılandırılmış olmasını beklemektedir. Kimlik doğrulaması eksik olan alan adlarının mesajları daha sık spam klasörüne düşer veya tümüyle reddedilir. Yani bu kayıtlar hem sizi taklitten korur hem de meşru e-postalarınızın gelen kutusuna ulaşma oranını yükseltir; güvenlik ve pazarlama açısından çift kazançtır.

Kapanış#

E-posta spoofing, protokolün doğasından gelen kalıcı bir açık gibi görünse de aslında bugün tamamen kapatılabilir bir sorundur. SPF ile hangi sunucuların adınıza gönderim yapabileceğini ilan eder, DKIM ile her mesajı kriptografik olarak imzalar ve DMARC ile hem politikayı belirler hem de sahteciliği görünür kılarsınız. İşin sırrı, DMARC'ı p=none gözlem aşamasında bırakmayıp raporlar temizlendikçe kararlılıkla p=reject seviyesine taşımaktır. Bu yolculuğu tamamladığınızda hem müşterileriniz sahte maillerden korunur hem de meşru e-postalarınızın teslim oranı yükselir.

Clou.TR olarak alan adı ve DNS yönetiminden yönetimli e-posta altyapısına, sunucu sertleştirmesinden WAF korumasına kadar bu zincirin her halkasını tek çatı altında sunuyoruz. SPF, DKIM ve DMARC kayıtlarınızı dakikalar içinde eklemek için alan adı ve DNS panelimizi, hazır ve doğrulanmış bir posta altyapısı için kurumsal e-posta hizmetimizi, uygulama katmanında ek koruma için de WAF çözümümüzü inceleyebilirsiniz. Alan adınızın adını korumak, markanızın itibarını korumaktır; bugün başlayın.