Kurumsal E-posta Güvenliği: SPF, DKIM ve DMARC Denetim Rehberi

Kurumsal e-posta güvenliği konuşmaları genellikle bir ürünle başlıyor, oysa bir sayıyla başlaması gerekiyor. FBI İnternet Suç Şikayet Merkezi'nin 2025 raporunda tek bir suç türü olarak 24.768 iş e-postası ele geçirme (BEC) şikayeti ve 3,046 milyar dolar bildirilmiş zarar var; şikayet hacmi üç yıldır aynı bantta dururken para tarafı yükselmeye devam ediyor. Kimlik taklidi ucuz, başarısızlığı pahalı. Buna karşılık korumanın büyük bölümü raflardaki cihazlarda değil, DNS'teki kayıtlarda duruyor.

Bu, bir işletme için kullanışlı bir çerçeve: e-posta, korumanın önemli bir kısmının dışarıdan doğrulanabildiği tek büyük saldırı yüzeyi. Herkes bir alan adının SPF, DKIM ve DMARC kayıtlarını sorgulayabilir, MTA-STS politikasını ve TLS raporlama adresini okuyabilir ve bir öğleden sonra içinde savunulabilir bir sonuca varabilir. Dışarıdan görülemeyen kısım ise kutunun içinde: yönlendirme kuralları, tam yetki erişimler, uygulama izinleri ve gelen filtresinin gerçekte neyi engellediği. Riskin geri kalanı tam orada duruyor ve o yarısı işbirliği istiyor, DNS sorgusu değil.

Bu rehber iki yarıyı da bir denetim artefaktı olarak kuruyor: hangi kayıt neyi kanıtlıyor, hangi aritmetik neyi gösteriyor, hangi belge denetimde masaya konuyor. Türkçe kaynaklarda bu konunun tipik hâli ya bir barındırma firmasının teslim edilebilirlik kontrol listesi ya da bir hukuk bürosunun madde özeti. İkisi de doğru ama ikisi de eksik: birincisi kaydı pazarlama başarısı gibi anlatıyor, ikincisi 12. maddeyi yazıyor ve teknik karşılığını yazmıyor. Aradaki boşluk tam olarak bu metnin konusu.

Neden hâlâ görünen gönderici satırıyla başlıyoruz

E-posta, birbirine güvenen sistemler arasında mesaj taşımak için tasarlandı ve alıcının gördüğü adres protokolün içinde hiçbir zaman doğrulanmadı. SPF, DKIM, DMARC, ARC ve MTA-STS'in tamamı bu boşluğun etrafına sonradan yerleştirilmiş bir yamadır. Yama tamamlandığında çalışıyor, kısmi kaldığında ise öngörülebilir bir biçimde çöküyor: yalnızca izleme modundaki bir alan adı kendini korunuyor hissedebilir, oysa bir yabancı onun finans müdürü adına e-posta gönderebilir.

Ölçüm sorunu artık kamuya açık ve yayımlanmış sayılar işin yapılması gerektiğinin en iyi kanıtı. Valimail'in 2026 DMARC raporu farkındalığı yüzde 78, uygulamayı yüzde 42 olarak ölçüyor; yani standardı bilen kurumlarla, alıcı sunuculardan kaydına uymasını isteyen kurumlar arasında 36 puanlık bir boşluk var. SimpleDMARC'in Haziran 2026'da Fortune Global 500 üzerinde yaptığı tarama yüzde 63 quarantine veya reject uygulandığını, yüzde 48 tam reject, yüzde 16,4 yalnızca izleme modu ve yüzde 20,6 hiç kayıt olmadığını buluyor. DMARCguard'ın Şubat 2026'da Tranco listesindeki 5.499.028 alan adı üzerindeki sayımı ise kayıt yayımlayanların yüzde 30,4, uygulayanların yüzde 12,8 olduğunu gösteriyor.

Üçünü birlikte okuduğunuzda ortaya çıkan tablo kimsenin yapmadığı değil. En büyük ve en iyi kaynaklı kurumlar büyük ölçüde yapıyor, uzun kuyruk büyük ölçüde yapmıyor, orta segment ise bir posta kutusu sağlayıcısının toplu gönderim kuralını karşılayan ama alan adını taklit etmeye karşı hiçbir şey yapmayan bir kayıt yayımlıyor. Yalnızca izleme modundaki bir kayıt, korumaya giden yolun yarısı değil; o bir raporlama mekanizması ve hiçbir şeyi engellemiyor.

Bu boşluğun ticari bir nedeni var. İzleme modundaki bir kayıt ucuz, yönetim kuruluna görünmez ve kaydın var olup olmadığını soran soruyu geçiyor. Reject'e ulaşmak ise şirket adına posta gönderen her uygulamayı bulmayı, her birine bir sahip atamayı ve hizalaması bozuk olanları düzeltmeyi gerektiriyor. Bu iş küçük bir ekibe düşer ve görünür hiçbir özellik üretmez. Bitişi gören kurumlar, bu işi tarihli bir projeye yazanlardır; takılanlar ise kimseye özellikle atanmadığı için takılır.

Mesajdaki dört kimlik ve kullanıcının gördüğü tek şey

Her mesaj kendini kimin gönderdiğine dair birkaç iddia taşır ve bunları karıştırmak yanlış yapılandırmaların çoğunun kökü. Başlık From gelen kutusunda görünen adrestir ve DMARC hizalamayı bu adres üzerinden değerlendirir. Zarf gönderici (MAIL FROM) SPF'in doğruladığı ve geri dönen mesajların seyahat ettiği adrestir. DKIM alan adı mesajı imzalayan alan adıdır; sizin olabilir, pazarlama platformunuzun olabilir, ortak bir imza servisinin olabilir. HELO alan adı gönderen sunucunun adıdır ve esas olarak itibar ile taşıma politikası kontrolleri için önemlidir.

Kimlik	Nerede duruyor	Hangi kontrol doğruluyor	Kullanıcı görür mü
Başlık From	Mesaj başlığı	DMARC hizalaması	Evet, gelen kutusunda
Zarf gönderici (MAIL FROM)	SMTP zarfı	SPF	Hayır, yalnızca ham başlıkta
DKIM imza alan adı (d=)	DKIM-Signature başlığı	DKIM	Bazı istemcilerde "via" satırı olarak
HELO / EHLO	SMTP el sıkışması	İtibar ve taşıma politikası	Hayır
Return-Path	Alıcı sunucunun eklediği başlık	SPF değerlendirmesinin izi	Hayır

Buradan iki kural çıkıyor ve ikisi de düzenli olarak atlanıyor. Birincisi, bir mesaj alıcının hiç görmediği bir alan adında SPF'ten geçebilir ve görünen göndericiyle ilgisi olmayan bir alan adında DKIM'den geçebilir; geçmek hizalanmak değildir. İkincisi, revizyon SPF değerlendirmesinin hangi kimliğe uygulandığına dokundu: RFC 9989 SPF doğrulamasını MAIL FROM ile sınırlandırıyor, bu eski bir belirsizliği kaldırıyor ama farklı bir kimliğin kontrol edildiğine güvenen bir ortamın geçişten sonra hizalamanın hâlâ tuttuğunu doğrulaması gerekiyor.

Uygulanabilir test şu: gerçek bir mesajı alın, ham başlıkları açın ve dört değeri yan yana yazın. Görünen From alan adı ile DKIM imza alan adı farklıysa mesaj yine de meşru olabilir, çünkü sizin adınıza kendi alan adıyla imza atan bir toplu gönderici normaldir; ama hizalama DMARC'ın bunu size yazıp yazmayacağına karar verir. İşletmenin kullandığı her gönderim platformundan birkaç gerçek başlık almayan bir denetim bu ölçümü hiç yapmıyor demektir.

Hizalama matrisi: sekiz kombinasyonun hangisi DMARC'ı geçirir

Hizalama kulağa teknik bir ayrıntı gibi geliyor ama pratikte bütün denetimin omurgası. Aşağıdaki matris, örnek alan adı ornek.com.tr için sekiz gerçekçi durumu gösteriyor. Satırların hiçbiri varsayımsal değil; hepsi saha denetimlerinde çıkan yapılandırma hataları.

From alan adı	SPF sonucu	DKIM d= değeri	DMARC sonucu	Neden
ornek.com.tr	pass (MAIL FROM ornek.com.tr)	yok	pass	SPF hizalı
ornek.com.tr	pass (MAIL FROM gonderim.partner.com)	d=partner.com	fail	İki kontrol de hizasız: kimlik doğrulandı, alan adı doğrulanmadı
ornek.com.tr	fail	d=ornek.com.tr	pass	DKIM hizalı; tek geçen yeter
ornek.com.tr	permerror (12 lookup)	yok	fail	SPF kaydı bozuk, DKIM yok: DMARC'ın dayanağı kalmadı
mail.ornek.com.tr	pass (MAIL FROM ornek.com.tr)	yok	relaxed pass, strict fail	Organizasyon alan adı aynı; strict'te tam eşleşme gerekir
mail.ornek.com.tr	yok	d=ornek.com.tr	relaxed pass, strict fail	adkim=s ise alt alan adı yetmez
ornek.com.tr	pass (MAIL FROM ornek.com.tr.evil.net)	yok	fail	Farklı organizasyon alan adı; benzer görünmek hizalama değil
ornek.com.tr	fail	d=ornek.com.tr, l= etiketli	pass, ama gövde korunmuyor	İmza yalnızca ilk N baytı kapsıyor; sonrası serbest

Matrisin en çok işe yarayan satırı ikincisi. Bir Türk şirketinin pazarlama platformu genellikle kendi alan adıyla imza atar ve SPF'i kendi zarf adresinden geçer; iki kontrol de başarılıdır, DMARC yine de fail verir. Bu, satıcının hatası değil, alıcı tarafın sizin alan adınızı görmek istemesidir. Çözüm ya platformun kendi alan adınızda bir DKIM seçicisi yayımlamasına izin vermek ya da gönderimi kendi alt alan adınıza taşımaktır.

SPF: on sorgu bütçesi ve 255 karakter sınırı

SPF bir alan adı adına posta göndermeye yetkili sistemleri yayımlar ve alıcı sunucu bunu zarf göndericiye karşı değerlendirir. Mekanizma basit, operasyonel tuzak ise aritmetikte. Bir kaydın değerlendirilmesi DNS sorgusu gerektirebilir ve şartname bu sayıyı ona sabitler. include, a, mx, ptr, exists ve redirect terimlerinin her biri en az bir sorgu harcar ve bir include, adlandırdığı alan adının iç içe kaydının tamamını içeri çeker. CRM, pazarlama platformu, çağrı merkezi, bordro sağlayıcısı ve web formu işleyicisi biriktiren bir işletme on sayıya fark etmeden ulaşabilir; sonuç, alıcıların SPF yokmuş gibi davrandığı kalıcı bir hatadır.

Aşağıdaki tablo, orta ölçekli bir Türk şirketinin gerçekçi kaydını sayıyor. Sayılan şey etiket değil, her terimin harcadığı sorgu.

Terim	Neden sorgu harcıyor	Sorgu	Kümülatif
mx	İki MX kaydı, her biri bir A sorgusu	2	2
include:_spf.google.com	İç kaydı netblocks ve başka bir include çağırıyor	3	5
include:spf.protection.outlook.com	Tek katman	1	6
include:servers.mcsv.net	Tek katman	1	7
include:spf.eposta-saglayici.com.tr	Üç iç include ve bir a terimi	4	11
a:mail.ornek.com.tr	Sonradan eklenmiş tek satır	1	12
ip4, ip6, all	Sorgu harcamıyor	0	12

Kümülatif 12, sınırın iki üstünde ve sonuç permerror. Buradaki tehlike sessizlik: hata, kaydın içinde duran bazı göndericilerin postasının geçmeye devam etmesine izin verir, çünkü değerlendirme hata verene kadar okunan terimler geçerli sayılır. Yani kayıt bazen çalışan bir kayıttır ve test edildiği gün çalıştığı için sorun görünmez.

İkinci sınır boyut. Tek bir TXT metni 255 karakterle sınırlı, çözümleyici birden fazla metni birleştiriyor ve pratik kural kaydın tamamını rahatça 512 oktet içinde tutmak. 2048 bitlik bir DKIM açık anahtarı tek başına 255 karakterlik dilime sığmıyor; bu yüzden DKIM kayıtları iki veya üç parçaya bölünmüş TXT metni olarak yayımlanır ve bir parçanın tırnakları bozulduğunda imza doğrulaması sessizce düşer. Sınırı aşan bir kayıt kısmen dikkate alınmaz; başarısız olur.

SPF flattening: çözüm değil, takas

Flattening, yani include'ları literal IP adreslerine çözmek, bu sorunun en yaygın cevabı ve bir takas. Sorgu maliyetini kaldırır, bakımı yapılan bir üçüncü taraf kaydını, sağlayıcı bir adres eklediğinde veya kaldırdığında bayatlayan bir fotoğrafa çevirir. Büyük bir bulut göndericisi bunu haber vermeden yapar ve sizin meşru postanız sessizce düşmeye başlar. Düzleştirilmiş kayıt ayrıca hızla boyut sınırını aşar, çünkü bir sağlayıcının onlarca adresi tek metin içinde birikir.

Alternatifler üç: postayı daha az gönderim alan adı üzerinden yönlendirmek, yüksek hacimli platformlara kendi alt alan adını ve kendi SPF ile DKIM kaydını vermek, ya da yönetilen bir flattening hizmetini kabul edip bayatlamayı izlemek. İkinci yol hizalamayı üst alan adında tutmaya devam eder ve ek bir fayda sağlar: kampanya gönderiminin itibarı kurumsal posta itibarını yutmaz. Seçenek olmayan şey bozuk kaydı yerinde bırakmak, çünkü başarısızlık sessiz.

Alt alan adları ayrı bir cümleyi hak ediyor. SPF miras alınmaz: kendi kaydı olmayan bir alt alan adının, joker kayıt veya organizasyon alan adı yapılandırması devreye girmediği sürece SPF'i yoktur; DMARC politikası ise miras alınır. Bu asimetri, üst alan adı reject'te dururken mail. veya info. alt alan adından gerçek trafik taşınmasının nedenidir.

DKIM: seçici envanteri, anahtar boyu ve l= etiketi

DKIM mesajı, açık yarısı DNS'te bir seçici adresinde duran bir anahtarla imzalar ve alıcı sunucular gövdenin ve seçilmiş başlıkların yolda değişmediğini doğrular. Yönlendirmeden sağ çıkan kontrol budur; bu yüzden postası aktarılan her kurum için DKIM hizalaması SPF hizalamasından daha önemli.

İlk kontrol edilecek şey seçicilerinizin gerçekte ne yayımladığı. 1024 bitlik anahtar 2026'da yeterli değil; yeni her şey için taban 2048 bit RSA olmalı ve anahtar gönderim servisi başına ayrılmalı ki tek bir ele geçirme bütün akışları lekelemesin. Seçiciler ayrıca birikir: emekliye ayrılmış sağlayıcılar, eski pazarlama araçları ve unutulmuş test alan adları, ilişki bittikten yıllar sonra bile alan adı için imza atabilen geçerli anahtarlar bırakır.

Seçici	Anahtar	Son imza	Sahip	Karar
google._domainkey	2048 RSA	2026-11-07	Workspace	Kalır, hizalama doğrulanır
selector1._domainkey	2048 RSA	2026-11-07	Microsoft 365	Kalır
mail._domainkey	2048 RSA	2026-11-05	Yerel SMTP	Kalır, From ile hizalı mı bakılır
k1._domainkey	1024 RSA	2025-03-11	Eski bülten aracı	Kaldırılır: zayıf anahtar, sahipsiz
default._domainkey	1024 RSA	Hiç imza görülmedi	Bilinmiyor	Kaldırılır: kim yayımladığı belirsiz
s2._domainkey	2048 RSA, l= etiketli	2026-11-07	Bilet sistemi	l= kaldırılır veya akış ayrılır

İkinci kontrol l= etiketi, yani gövde uzunluğu sınırı: doğrulayıcıya gövdenin yalnızca ilk N baytını özetlemesini söyler. Bazı e-posta listesi ve bilet yazılımlarında alt bilgi eklenmesiyle bozulan imzalar için çözüm olarak görünür ve saldırgana hediye edilmiş bir yetkidir: imzalanmış önekin arkasına her şey eklenebilir ve imza yine doğrulanır. Uzunluk etiketi taşıyan bir alan adı, mesajı değil bir başlık iddiasını imzalıyor demektir.

Üçüncü kontrol, seçicilerin gerçekten kullanılıp kullanılmadığı: son 30 günün imza başlıklarını toplayın, hangi seçicilerin göründüğünü sayın ve envanterdeki listeyle karşılaştırın. Envanterde olup hiç görünmeyen her seçici ya kaldırılacak bir kalıntı ya da kimsenin bilmediği bir gönderim yoludur; ikisi de bilinmesi gereken bir bilgidir.

DMARC merdiveni: none, quarantine, reject ve t= etiketi

DMARC alıcı sunucudan tek bir şey ister: kimlik doğrulama sonuçlarını görünen From alan adıyla karşılaştırmak ve hizalanmadığında alan adı sahibinin yayımladığı politikayı uygulamak. Politikanın üç kullanışlı değeri var. none yalnızca rapor ister, başka bir şey istemez. quarantine mesajın şüpheli sayılmasını ister ki çoğu sağlayıcıda karşılığı spam klasörüdür. reject mesajın hiç teslim edilmemesini ister.

Kayıt	Alıcı ne yapar	Neyi engeller	t=y eklendiğinde
p=none	Yalnızca rapor üretir	Hiçbir şey	Etkisi yok: none zaten en alt kademe
p=quarantine	Hizasız mesajı şüpheli işaretler	Gelen kutusuna ulaşmayı	none gibi davranılır
p=reject	Hizasız mesajı reddeder	Teslimi	quarantine gibi davranılır
sp= alt alan adı politikası	Alt alan adları için ayrı hüküm	sp yoksa alt alanlar p'yi miras alır	p ile birlikte yorumlanır
np= var olmayan alt alan adı	Hiç var olmayan alt alanlara uygulanır	Uydurulmuş alt alan adıyla gönderimi	p ile birlikte yorumlanır

Neredeyse her alan adı none ile başlar ve bu doğrudur: kurumun bütün meşru göndericilerini bilmeden yayımlanan bir reject politikası gerçek postayı engeller. Faturalar, aday takip sistemi, kimsenin belgelemediği bordro platformu, web sitesi iletişim formu. Geçiş, DNS değişikliği gibi görünen bir keşif çalışmasıdır: rua adresiyle yeterince uzun çalışın, her kaynağı görün, her birini adı belli bir iş sahibiyle eşleştirin, hizalanmayanları düzeltin, sonra quarantine ve en sonunda reject'e geçin. Kurumlar none'da takılır çünkü son adım teknik olarak zor değil, kimse eşleştirme işine atanmadı.

Politikanın anlam taşıyıp taşımadığını iki ayar belirler. Alt alan adı politikası (sp) alt alanlardan gelen postayı kontrol eder; yoksa alt alanlar organizasyon politikasını miras alır, ki bu ya istediğiniz şeydir ya da kaç alt alanın posta gönderdiğini kimsenin bilmemesine bağlı bir sürpriz. Hizalama (adkim, aspf) bir alt alan adının sizinkine sayılıp sayılmayacağını belirler: relaxed, organizasyon alan adının aynı olmasını yeterli görür; strict tam eşleşme ister.

Toplu raporlama kaydın diğer yarısı ve kurumların en çok görmezden geldiği kısım. rua adresi, katılan sağlayıcılardan günlük XML raporları alır: neyin görüldüğü, neyin başarısız olduğu. Raporlama hedefi olmayan bir kayıt, geri bildirimi olmayan bir politikadır ve reject'e geçiş tahmine dönüşür. Raporlar mesaj içeriğini değil gönderim adreslerini ve sayıları taşır, ama yine de trafiğe dair kayıtlardır; bu kutunun sahibi varsayılanla değil, veri sorumlusuyla birlikte belirlenmeli.

En yanlış anlaşılan özelliği açıkça yazmak gerekiyor: DMARC markayı değil alan adını korur. Bir yabancının ornek.com.tr adına posta göndermesini engeller. Bir harfi değiştirilmiş benzeri, tireyle türetilmiş alternatifi ya da kendi alan adı üzerinden sizin görünen adınızı kullanan bir saldırgan hakkında hiçbir şey yapmaz. Gelen kutusuna en sık ulaşan teknikler tam olarak bunlar, çünkü reject yayımlayan bir alan adını taklit etmeye çalışmaktan daha ucuza geliyor.

Mayıs 2026: RFC 9989 neyi değiştirdi

On yıl süren taslaklardan sonra revize şartname Mayıs 2026'da üç belge olarak yayımlandı: çekirdek politika için RFC 9989, toplu raporlama için RFC 9990 ve hata raporlaması için RFC 9991. RFC 7489'u ve eklentisini geçersiz kılıyorlar; bir işletme için önemli olan nokta hiçbir şeyin hemen yeniden yayımlanması gerekmediği, çünkü v=DMARC1 sürüm dizesi değişmedi ve mevcut kayıtlar geçerli.

Bundan sonra kaydın nasıl yazılacağını etkileyen üç değişiklik var. Mesajların bir yüzdesini örnekleyen ve yaygın biçimde güvenlik kadranı sanılan pct etiketi, yerini t adlı ikili test etiketine bıraktı; kademeli geçiş için pct kullanan politikalar aynı davranmaya devam edecek diye varsayılmak yerine yeniden yazılmalı. Yeni np etiketi var olmayan alt alan adlarını kapsıyor ve saldırganların hiçbir şeyi miras almayan alt alan adları uydurarak kullandığı boşluğu kapatıyor. Keşif ise Public Suffix List sorgusundan DNS ağacı yürüyüşüne geçti; bu, organizasyon alan adı davranışını değişen bir dış listeye bağlı olmaktan çıkarıp belirlenimci hâle getiriyor ve sorgu sayısı etiket sayısından bağımsız olarak sekizle sınırlandı.

Mühendislik sonucu şu: DMARC kayıtlarını ayrıştırıp pct varsayan ya da politikanın nerede durduğuna karar vermek için son ek listesini kullanan her araç gözden geçirilmeli. Ticari sonuç daha ince: geçişi bir proje olarak satan satıcı, standardın bilinçli olarak kırıcı olmaktan çıkardığı bir işi satıyor. Sizin hangi gönderim kaynaklarınızın hâlâ hizalanmadığını gösterebilen satıcı ise reject'e hiç ulaşıp ulaşmayacağınıza karar veren şeyi satıyor.

Toplu rapor hacmi: kaç gigabayt, kim okuyacak

Toplu raporların en sık atlanan tarafı hacim. Aşağıdaki hesap, 42.000 mesaj/gün gönderen ve 380 posta kutusu olan orta ölçekli bir kurumun gerçekçi profilinden geliyor. Rapor boyutu, kaynak IP sayısı ve politika sonucu satırlarının sayısıyla büyür; mesaj sayısıyla değil.

Ölçü	Girdi	Aritmetik	Sonuç
Günlük rapor sayısı	28 raporlayıcı kuruluş	28 x 1	28 dosya/gün
Yıllık depolama	Ortalama 310 KB/dosya	28 x 310 KB x 365	3.093,9 MB, yani yaklaşık 3,02 GB/yıl
Kaynak satırı	140 farklı kaynak IP	140 x 365	51.100 satır/yıl
TLS raporları	Aynı 28 raporlayıcı	28 x 365	10.220 rapor/yıl
İnsan okuması	Haftada 45 dakika	45 x 52	39 saat/yıl
Kural dışı inceleme	Ayda 6 anomali x 20 dakika	6 x 20 x 12	24 saat/yıl

Yani reject'e geçmenin gizli maliyeti depolama değil, 63 saatlik yıllık insan zamanı ve bunun bir sahibi olması. Bu saati kimseye atamadığınızda raporlar bir posta kutusunda birikir, politika izleme modunda kalır ve kimse nedenini sormaz. Denetimde sorulan soru da tam olarak bu: raporu kim okuyor, hangi bulguyla ne yapıldı, son okuma ne zamandı.

MTA-STS, TLS raporlama ve DANE: taşıma katmanı

SPF, DKIM ve DMARC mesajın kim olduğunu söyler; taşıma katmanı ise mesajın yolda şifreli gidip gitmediğini. Üç ayrı mekanizma var ve karıştırılıyor. MTA-STS (RFC 8461) bir alan adının HTTPS üzerinden yayımladığı politika dosyasıyla alıcı sunuculara bana TLS olmadan posta göndermeyin der; max_age değeri politikanın önbellekte kalma süresidir, üst sınırı 31.557.600 saniye yani 365,25 gün, yaygın kullanım 604.800 saniye yani 7 gün. TLS raporlama (RFC 8460) aynı alan adına günlük taşıma raporları gönderir ve yukarıdaki tabloda gördüğünüz 10.220 rapor buradan gelir. DANE ise güveni DNSSEC'e bağlar ve sertifika otoritesi sistemini atlar; etkili olması için DNSSEC'in alan adında etkin ve posta servisi kayıtlarının imzalı olması gerekir.

Hangisinin gerekli olduğu sorusunun dürüst cevabı: MTA-STS bugün en düşük maliyetli kazanç, çünkü DNSSEC gerektirmiyor ve tek bir HTTPS dosyası ile bir TXT kaydından oluşuyor. DANE daha güçlü ama DNSSEC bağımlılığı Türkiye'deki birçok alan adı kayıt operatöründe ek bir yapılandırma adımı demek. İkisini de yapmamak ise şu anlama geliyor: alıcı sunucu ile aranızdaki bağlantı, aktif bir saldırganın kolayca araya girebildiği bir kanal olmaya devam ediyor ve bunun görünür hiçbir belirtisi yok.

Dışarıdan görünmeyen yarı: kurallar, yönlendirme, yetki devri

Bir alan adının DNS'teki durumu, o alan adından gönderilen postanın kimliğini kanıtlar. Kutunun kendisi hakkında hiçbir şey söylemez. Bir saldırganın posta kutusuna girmesinin en ucuz yolu kimlik bilgisi çalmak değil, bir kez girip kalıcı bir erişim mekanizması bırakmaktır. Denetimde aranan dört mekanizma:

Gelen kutusu kuralları. Bu adresten gelen mesajları arşive taşır veya konusunda fatura geçenleri siler türünde bir kural, saldırganın uyarıları görünmez kılmasının en eski yolu. Kural envanteri, kuralı kimin ne zaman kurduğuyla birlikte okunmalı; kurumsal politika dışında kurulmuş ve sahibi olmayan her kural bir bulgudur.

Otomatik yönlendirme ve gizli kopya. Dış adrese yönlendirme, verinin kurum dışına çıktığı andır ve KVKK tarafında aktarım hükmüne dokunur. Yönlendirme kuralı olan bir kutu, parolası değiştirilse bile saldırgana akmaya devam eder; bu yüzden parola sıfırlama tek başına yeterli değildir.

Tam yetki erişim. Yönetici, bir kutuyu başka bir kullanıcıya tam erişim olarak açar; bu izin çoğu zaman işten ayrılan kişi için kapatılmaz. Yönetici konsolunda tam yetki listesi tek bir ekranda okunabilir ve denetimin en hızlı bulguları buradan çıkar.

Uygulama izinleri. Üçüncü taraf bir uygulamanın posta okuma yetkisi, parola gerektirmeyen bir arka kapıdır. Kurumsal kiracıda yönetici onayı verilmiş uygulamalar listelenmeli, sahibi belli olmayan ve posta okuma kapsamı isteyen her izin gerekçelendirilmeli.

Bu dört mekanizmanın taranması pahalı değil, sadece sıkıcı: 380 posta kutusu için kutu başına 95 saniye, toplam 602 dakika, yani yaklaşık 10 saat. Bu on saat, BEC olaylarının çoğunu denetimden önce yakalayan tek çalışmadır.

Türkiye'ye özgü üç tuzak: yerel gönderim sağlayıcısı, KEP ve e-fatura taklidi

Türk şirketlerinin e-posta altyapısı genellikle iki katmanlı: kurumsal posta Microsoft 365 veya Google Workspace üzerinde, kampanya ve bildirim gönderimi ise yerel bir toplu e-posta sağlayıcısında. İlk tuzak tam bu ayrımda. Yerel sağlayıcıların çoğu, müşteri alan adı için kendi alan adlarında bir DKIM seçicisi yayımlar ve gönderimi kendi zarf adresinden yapar; iki kontrol de geçer, DMARC fail verir. Çözüm sağlayıcıya kendi alan adınızda seçici açmasını söylemek, ki çoğu bunu destekliyor ama varsayılan kapalı, ya da gönderimi campaign.ornek.com.tr gibi bir alt alan adına taşıyıp organizasyon alanı hizalamasından yararlanmaktır.

İkinci tuzak KEP. Kayıtlı Elektronik Posta hukuki bir kanaldır: gönderim ve teslim zamanı kanıtlanır, muhatap kayıtlıdır. Ama KEP bir kimlik doğrulama standardı değil. KEP hesabınızdan gönderdiğiniz posta, alıcının kutusunda hâlâ SPF, DKIM ve DMARC ile değerlendirilir; KEP sağlayıcısının kendi etki alanından çıkıyorsa sizin alan adınızla hizalanmaz. Kurul kararlarında özel nitelikli kişisel verilerin e-posta ile aktarılması gerektiğinde şifreli olarak kurumsal e-posta adresiyle veya KEP hesabı kullanılarak aktarılması isteniyor; bu bir kanal ve şifreleme şartıdır, alan adınızın kimlik doğrulama durumunu değiştirmez. İki iş ayrı ayrı yapılmalı.

Üçüncü tuzak, Türkiye'de en çok kullanılan oltalama kitaplığı: GİB e-fatura ve e-arşiv bildirimi, tebligat, icra dosyası, kargo teslim, havale bildirimi, tedarikçi IBAN değişikliği. Bu kitaplığın ortak özelliği, hepsinin sizden bir işlem yapmanızı istemesi ve hepsinin gerçek bir devlet veya banka arayüzünü taklit edebilmesi. Gönderen adresine bakın tavsiyesi bu ailede işe yaramaz, çünkü taklit sayfa gerçek portalın işaretlemesinin kopyasıdır. İşe yarayan dört kontrol: alan adının kayıt tarihi ve organizasyon alan adı, mesajdaki bağlantının gerçek hedefi, giriş sayfasının beklenen alan adında olup olmadığı ve işlemin kendi başlattığınız bir süreç olup olmadığı. Son madde en güçlüsü: siz talep etmediyseniz gelen işlem onayı postası bir uyarıdır, talimat değil.

KVKK cephesi: 12. madde hangi kanıtı istiyor

Teknik tarafla hukuki taraf burada birleşiyor. 6698 sayılı Kanun'un 12. maddesinin birinci fıkrası veri sorumlusuna, kişisel verilerin hukuka aykırı işlenmesini ve verilere hukuka aykırı erişilmesini önlemek ile verilerin muhafazasını sağlamak için uygun güvenlik düzeyini temin etmeye yönelik her türlü teknik ve idari tedbiri alma yükümlülüğü veriyor. Beşinci fıkra ihlal hâlinde bildirimi düzenliyor ve Kurul'un 24.01.2019 tarihli 2019/10 sayılı kararı, metindeki en kısa sürede ifadesini 72 saat olarak yorumluyor; yani 259.200 saniye.

Dayanak	Ne diyor	E-posta tarafındaki kanıt
6698 md.12/1	Hukuka aykırı erişimi önlemek için teknik ve idari tedbir	SPF, DKIM ve DMARC kayıt çıktısı, MFA zorunluluğu, kural ve yetki envanteri
6698 md.12/2	Veri işleyenin de aynı tedbirleri alması	Bulut posta sağlayıcısı sözleşmesi, alt işleyen listesi, son denetim raporu
6698 md.12/5 ve 2019/10	İhlali en kısa sürede, en geç 72 saatte Kurula bildirim	Olay saati kaydı, ihlal bildirim formu, gecikme gerekçesi
Kişisel Veri Güvenliği Rehberi	Ağ ve sistem güvenliği tedbirleri	Yapılandırma kanıtı: kayıt dökümü, ekran görüntüsü değil
Özel nitelikli veri kararları	E-posta ile aktarımda şifreli kurumsal adres veya KEP	Kanal tanımı, şifreleme yöntemi, KEP kullanım kaydı
6698 md.18/1-b	Yükümlülüğe aykırılıkta idari para cezası	2026 yeniden değerleme bandı: 256.357 ile 17.092.242 TL arası

Bu tablonun pratik anlamı şu: denetimde DMARC kullanıyoruz cümlesi kanıt değil. Kanıt, kaydın kendisi yani tarih damgalı sorgu çıktısı, politika seviyesi, raporların okunduğuna dair bir kayıt ve bulguların kapatıldığına dair bir iz. Bir başka deyişle teknik kontrollerin her biri bir belge üretmeli. Üretmiyorsa, var olsa bile denetimde yok sayılır.

2026/2035 İlke Kararı: log mu, içerik mi

Bu metnin en güncel ve en az bilinen kısmı. Kişisel Verileri Koruma Kurulu'nun 16.09.2026 tarihli ve 2026/2035 sayılı İlke Kararı, 8 Ekim 2026 tarihli 33.394 sayılı Resmî Gazete'de yayımlandı ve çalışanlara tahsis edilen kurumsal e-posta hesapları başta olmak üzere işin yürütülmesi amacıyla kullanılan iletişim kanallarının denetlenmesindeki usul ve esasları düzenliyor. Kararın çekirdeği, bir güvenlik ekibinin işini doğrudan biçimlendiren üç tespit:

Birincisi, kurumsal e-posta hesaplarının denetlenmesi, içeriğe erişilmeksizin yalnızca trafik ve log kayıtlarının işlenmesi hâlinde dahi başlı başına bir kişisel veri işleme faaliyeti oluşturuyor ve her hâlükârda Kanun'un işleme şartlarına, genel ilkelerine, aydınlatma ve veri güvenliği yükümlülüklerine tabi. İletişim araçlarının işverene ait olması veya işyerinde kullanılması, işverene sınırsız bir denetim yetkisi vermiyor.

İkincisi, denetimin kapsamı belirlenirken iş amaçlı kullanım ile özel amaçlı kullanım ayrımının dikkate alınması gerekiyor; işverenin özel kullanımı yasaklaması, sınırlandırması ya da bu konuda açık bir düzenleme yapmaması, denetimin hukuka uygunluk değerlendirmesinde farklı sonuçlar doğuruyor. Bunun teknik bir karşılığı var: kurumsal kullanım politikası yazılı değilse, teknik olarak yapabildiğiniz her inceleme hukuken savunulabilir olmuyor.

Üçüncüsü, özel kullanım yasağının ihlal edildiği içerik dışı unsurlardan anlaşılabiliyorsa, yazışma içeriğine ayrıca erişilmesi gerekli ve orantılı kabul edilmiyor. Bir güvenlik olayında bu cümle çok işe yarıyor: kutunun ele geçirildiğini başlık, log ve kural verisinden gösterebiliyorsanız mesaj gövdesini okumak zorunda değilsiniz ve okumamalısınız. Denetim raporunuzun bu ayrımı yapması hem KVKK tarafında hem olay incelemesi tarafında işi kolaylaştırıyor.

Bu yüzden e-posta denetimini iki katmanlı kurmak gerekiyor: kimlik doğrulama ve yapılandırma katmanı hiç içerik okumadan tamamlanır; içerik incelemesi ise yalnızca olay müdahalesi kapsamında, yazılı bir kapsam ve saat kaydıyla yapılır. Olay müdahalesi tarafının sırası ayrı bir metnin konusu ve siber olay müdahale planı rehberinde adım adım duruyor.

Beş günlük denetimin takvimi ve çıktısı

Bu işin bir hafta sürmesinin nedeni karmaşıklık değil, kanıt toplamanın sıralı olması. Aşağıdaki takvim 30 saatlik bir çalışma ve sonunda beş belge üretiyor.

Gün	Saat	Yapılan iş	Üretilen belge
1	6	Alan adı envanteri, SPF, DKIM, DMARC ve MTA-STS kayıtlarının dışarıdan ölçümü	Alan adı kimlik doğrulama tablosu
2	6	Gönderim kaynağı keşfi: toplu raporlar, faturalar, uygulama envanteri	Kaynak eşleştirme listesi, sahipleriyle
3	6	Kutu içi tarama: kurallar, yönlendirmeler, tam yetki, uygulama izinleri	Kutu yapılandırma bulguları
4	6	Gelen filtreleme ve kimlik avı simülasyonunun ölçümü, reject provası	Filtre etkinlik raporu, politika geçiş planı
5	6	Kanıt paketinin derlenmesi, KVKK eşlemesi, yönetim özeti	Denetim raporu ve 90 günlük kapatma planı

Raporun okunabilir olması için üç kural: her bulgu tek bir cümlede ölçülebilir bir durum yazmalı, örneğin on iki sorgu ve permerror ile dört hizasız kaynak; her bulgunun bir kabul testi olmalı, örneğin bu kayıt onun altına indiğinde test geçer; ve her bulgunun bir sahibi ve tarihi olmalı. Bu üç şey yoksa rapor bir görüş yazısıdır.

İlk 24 saat: kutu ele geçirilmişse sıra

Denetim sırasında ele geçirilmiş bir kutu bulmak olağan; bu durumda rapor yazma sırası değişiyor. Aşağıdaki sıra, parola değiştirmenin neden yeterli olmadığını da gösteriyor.

Saat	Adım	Neden bu sırada	Kanıt
0-1	Oturumları iptal et	Token geçerli kaldıkça parola değişikliği saldırganı çıkarmaz	Oturum iptal kaydı
1-2	Yönlendirme ve gelen kutusu kurallarını listele, kaldır	Kural, parola değişse de veri akıtır	Kural envanteri, öncesi ve sonrası
2-3	MFA kayıtlarını sıfırla ve yeniden kaydet	Kayıtlı cihaz saldırganın elinde olabilir	MFA kayıt günlüğü
3-8	Oturum açma kayıtlarını incele: IP, konum, uygulama	Kapsamı belirleyen tek veri bu	Oturum açma dışa aktarımı
8-12	Gönderilen mesajları ve alıcıları kapsamla	İhlalin kişi sayısını bu belirler	Gönderim kaydı, alıcı listesi
12-24	72 saatlik bildirim saatini başlat ve karar ver	Saat öğrenme anından işliyor	Olay zaman çizelgesi

Bu tablodaki en kritik satır ikincisi ve en çok atlananı. Parola sıfırlama, ekranda bir şey olduğu hissini verdiği için ilk adım sanılıyor; oysa kalıcı erişim kural ve token üzerinden yaşıyor. Kutu ele geçirme olaylarının ayrıntılı müdahale akışı bec şirket e-posta hesabı ele geçirildiğinde ne yapılmalı metninde; oradaki adımlar bu tablonun devamı niteliğinde.

Satın almak mı, kurmak mı

E-posta güvenliği pazarı aynı işi üç farklı ürün kategorisi altında satıyor: güvenlik geçidi, kimlik doğrulama yönetimi ve farkındalık eğitimi. Bir denetimin çıktısı hangisinin gerçekten gerekli olduğunu gösterir, çünkü üçü farklı problemleri çözüyor.

Kendi ekibinizle yapılması gerekenler: kayıt envanteri, hizalama ölçümü, kutu kuralı ve yetki taraması, kanıt paketinin derlenmesi. Bunlar lisans gerektirmiyor ve dışarıya verildiğinde kurumun kendi yapılandırmasını tanımamasına yol açıyor. Satın alınması mantıklı olanlar: yüksek hacimli raporların işlenmesi, çünkü yılda 3 GB veri ve 51.100 satır elle okunmaz; gelen filtreleme ve kimlik avı simülasyonu. Karar sorusu hangi ürün en iyi değil, hangi işi kendi ekibimiz sürdürebilir.

Farkındalık eğitiminin ölçüm tarafı ayrı bir metin: oltalama farkındalık eğitimi programı. Teknik kontrollerle birlikte okunması gerekiyor, çünkü reject politikasına geçtikten sonra kalan en büyük açık, hizalanmış ve gerçek görünen bir mesaja tıklayan kullanıcı oluyor.

Hangi noktada dışarıdan yardım gerekir

Üç durumda iç ekip yeterli olmuyor: alan adı sayısı onu geçtiğinde ve her biri farklı bir gönderim altyapısı kullandığında, reject geçişi sırasında meşru postanın kesilmesi riski ticari olarak taşınamaz hâle geldiğinde ve bir olay sonrası hangi kutulara erişildiğinin kanıtlanması gerektiğinde. Üçüncüsü en sık ihtiyaç duyulan: bir ihlalde hangi verinin çıktığı sorusunun cevabı, oturum açma kayıtları, kural değişiklikleri ve gönderim kayıtlarının birleştirilmesiyle çıkıyor ve bu birleştirme hem teknik hem hukuki bir iş.

Bu tür bir çalışma yazılı yetkilendirme ile başlar: kapsamdaki alan adları, posta kiracısı, zaman aralığı, temas kişisi ve hangi verilere erişileceği yazılı olmalı. Yetkilendirme olmadan bir kiracıda inceleme yapmak, sahibi olduğunuz sistemde bile yetkisiz erişim sayılabilir. güvenlik sertleştirme ve dijital adli inceleme hizmet tanımlarımız bu kapsam ayrımını baştan yazıyor; KVKK teknik tedbirler kanıt rehberi ise aynı kanıtların denetim tarafında nasıl okunduğunu anlatıyor.

Sık sorulan sorular

Bu dört bölümün özeti tek bir sonuca çıkıyor: e-posta güvenliğinde ölçülebilir olan her şey dışarıdan doğrulanabilir, ölçülemeyen her şey ise bir envanter sorusudur. Kayıtları on sorgunun altına indirmek, seçicileri sahipleriyle eşleştirmek, politika seviyesini tarihle birlikte belgelemek ve kutu içindeki kalıcı erişimlerin listesini tutmak bir haftalık iş; bu dört şeyi yapmamak ise her yıl aynı soruyu sormak demek.