Güvenlik·
4 Nisan 2026
E-posta altyapınız her gün binlerce kayıt üretir. Bu kayıtların büyük çoğunluğu rutin trafiği yansıtır; ancak aralarına gizlenmiş birkaç satır, hesap ele geçirme girişiminden kimlik avı kampanyasına, yetkisiz veri aktarımından açık relay istismarına kadar ciddi güvenlik olaylarının habercisi olabilir. Peki logları nasıl okur, hangi kalıplara dikkat edersiniz?
Postfix, Exim veya Sendmail gibi yaygın MTA yazılımları her iletim girişimi için standart bir kayıt satırı oluşturur. Bu satır genellikle şu alanları içerir: zaman damgası, kuyruk kimliği (queue ID), gönderen adresi, alıcı adresi, bağlantı IP'si, iletim durumu kodu (RFC 5321'de tanımlanan SMTP yanıt kodları) ve varsa hata mesajı. Bunların yanı sıra modern e-posta altyapıları IMAP/POP3 erişim logları, webmail oturum kayıtları ve kimlik doğrulama (SASL) hataları da üretir.
RFC 5321 (SMTP), RFC 5322 (İnternet Mesaj Biçimi) ve RFC 6591 (ARF — Abuse Reporting Format) bu kayıt yapılarının temel standartlarını tanımlar. Günümüzde yaygınlaşan DMARC mekanizması ise RFC 7489 ile tanımlanmış olup etki alanı sahiplerine XML formatında toplu raporlar (aggregate reports) iletir.
Aşağıdaki tablo, sık karşılaşılan log kalıplarını, olası güvenlik anlamlarını ve önerilen tepkileri özetlemektedir:
| Log Kalıbı / Gösterge | Olası Güvenlik Anlamı | Önerilen Tepki |
|---|---|---|
| Kısa sürede aynı IP'den çok sayıda SASL authentication failed | Kaba kuvvet (brute-force) parola saldırısı | IP'yi geçici engelle (fail2ban vb.), hesap kilitleme politikasını gözden geçir |
| Bilinmeyen veya yurt dışı IP'den başarılı oturum açma | Kimlik bilgisi çalınmış olabilir (credential stuffing) | Hesabı askıya al, kullanıcıya bildir, aktif oturumları sonlandır |
| SPF: fail, DKIM: fail, DMARC: fail aynı mesajda | Alan adı sahteciliği (domain spoofing) veya kimlik avı (phishing) | Mesajı karantinaya al, DMARC politikasını p=reject'e yükselt |
| Relay erişimi izin verilmemiş IP'ye açıksa "Relay access denied" yerine iletim başarısı | Açık relay (open relay) yapılandırma hatası veya istismarı | MTA relay kısıtlamalarını derhal kontrol et, kötüye kullanım raporları (ARF) incele |
| Gece yarısı veya çalışma saatleri dışında toplu gönderim kuyruğu | Spam botnet veya ele geçirilmiş hesaptan toplu gönderim | Saatlik/günlük gönderim kotası uygula, anormallik uyarısı kur |
| Başlıkta Received zincirinde döngü (loop) veya 30'dan fazla atlama | Yanlış yapılandırma veya kasıtlı başlık manipülasyonu | MTA yapılandırmasını denetle; RFC 5321 §4.4 gereği maksimum 100 atlamada mesaj silinmeli |
| Bounce (geri dönen mesaj) oranının aniden %5'i aşması | Liste temizlenmemiş spam gönderimi veya hesap güvenlik ihlali | Gönderim geçici durdur, liste hijyenini denetle, kara liste kontrolü yap |
DMARC (Domain-based Message Authentication, Reporting and Conformance — Alan Adı Tabanlı Mesaj Kimlik Doğrulama, Raporlama ve Uyumluluk) RFC 7489 kapsamında, etki alanı sahibine alan adını kimin ve nasıl kullandığına dair kapsamlı raporlar sunar. Bu XML raporlar iki türdür:
Bir rua raporunda kendi IP aralığınız dışında kaynaklardan gönderim girişimi görüyorsanız bu, alan adınızın aktif olarak sahtekarlık amacıyla kullanıldığına işaret eder. DMARC politikanızı p=none'dan p=quarantine'e, ardından p=reject'e yükseltmek bu tehdidi büyük ölçüde engeller; ancak geçiş sürecinde meşru gönderim kaynaklarınızı (ESP, CRM, destek sistemleri) eksiksiz kaydetmeniz zorunludur.
6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesi, veri sorumlularına kişisel verilerin hukuka aykırı olarak işlenmesini önlemeye ve verilere yetkisiz erişimi engellemeye yönelik teknik tedbirleri alma yükümlülüğü getirir. E-posta logları; alıcı adresleri, gönderim süreleri, IP adresleri gibi kişisel veri niteliğinde bilgiler içerebileceğinden bu logların işlenmesi ve saklanması da KVKK kapsamında değerlendirilir.
Kişisel Verileri Koruma Kurulu'nun 2019/10 sayılı kararı (Veri Güvenliği Rehberi) loglama altyapısının kurulmasını ve düzenli güvenlik testleri yapılmasını önermektedir. Aynı rehber, yetkisiz erişim girişimlerinin kayıt altına alınmasını ve bu kayıtların belirli bir süre saklanmasını tavsiye etmektedir; ticari ilişkinin sona ermesinden itibaren 3 yıllık zamanaşımı süreci temel referans alınmaktadır.
6563 sayılı Ticari İletişim ve Ticari Elektronik İleti Hakkında Kanun (ETK) açısından ise hizmet sağlayıcıların ticari elektronik iletilere ilişkin kayıtları en az 1 yıl boyunca saklama zorunluluğu bulunmaktadır (ETK Uygulama Yönetmeliği, Madde 12). Bu yükümlülük, onay kayıtlarının yanı sıra gönderim loglarını da kapsar.
Log analizi için ölçeklenebilir bir yapı kurmak isterseniz şu katmanlı yaklaşım iyi bir başlangıç noktasıdır:
Bir güvenlik olayı sonrasında bireysel mesaj başlıkları kritik kanıt niteliği taşır. RFC 5322'ye göre her Received başlığı mesajın geçtiği bir MTA'yı temsil eder; bu zinciri en alttan yukarı doğru okuyarak mesajın gerçek kaynağına ulaşabilirsiniz. Dikkat edilmesi gereken başlıklar şunlardır:
X-Originating-IP veya X-Forwarded-For: Webmail üzerinden gönderilmişse son kullanıcı IP'sini taşıyabilir; saldırı kaynağını belirlemede yararlıdır.Authentication-Results: SPF, DKIM ve DMARC doğrulama sonuçlarını tek bir başlıkta özetler (RFC 7601).DKIM-Signature: İmzalayan etki alanı (d=) ile From başlığındaki etki alanının eşleşip eşleşmediğini kontrol edin.Return-Path: Geri dönüş adresi farklıysa bu, e-postanın farklı bir altyapıdan gönderildiğine işaret edebilir.Received başlığı arasında saatler hatta günler fark varsa bu, mesajın kuyruğa alındığına ya da başlıkların değiştirildiğine işaret edebilir.Türk mevzuatında 6563 sayılı ETK Uygulama Yönetmeliği'nin 12. maddesi ticari elektronik iletilere ait kayıtların en az 1 yıl saklanmasını zorunlu kılmaktadır. KVKK kapsamında ise amaç ve ilgili zamanaşımı süreleri dikkate alındığında güvenlik loglarının 3 yıla kadar saklanması yaygın ve savunulabilir bir yaklaşımdır. Sektörel düzenlemeler (bankacılık, sağlık) farklı saklama süreleri gerektirebilir.
DMARC başarısı için SPF veya DKIM'in doğrulanması yeterli değildir; doğrulama sonucunun From başlığındaki etki alanıyla "hizalanması" (alignment) gerekir. SPF envelope from'i doğrular, DMARC ise header From'i kontrol eder. İkisi farklı etki alanlarına ait olduğunda SPF geçse bile DMARC başarısız olabilir.
Fail2ban tek IP bazında çalışır; dağıtık saldırılarda (botnet) etkisi sınırlıdır. Bu durumda SMTP kimlik doğrulaması için oran sınırlama (rate limiting), CAPTCHA destekli webmail girişi veya çok faktörlü kimlik doğrulama (MFA) katmanları eklemek daha etkili bir savunma sağlar.
Her yüksek bounce oranı bir güvenlik olayına işaret etmez; liste hijyeni sorunları veya eski veritabanı kayıtları da benzer sonuçlara yol açar. Ancak bounce oranının aniden (önceki baseline'a göre 2-3 katına) artması, özellikle gece yarısı gerçekleşen gönderimlerle birliktelik gösteriyorsa, hesap ele geçirme veya yetkisiz toplu gönderim ihtimalini araştırmanız gerekir.
dmarcian, Valimail Monitor (ücretsiz katmanı mevcuttur), Google Postmaster Tools ve Mimecast DMARC Analyzer yaygın kullanılan araçlar arasındadır. Kendi altyapınızda çalıştırmak istiyorsanız açık kaynaklı parsedmarc (Python) veya dmarc-report-converter araçlarına bakabilirsiniz.
Kişisel Verileri Koruma Kurulu'na yönelik ihlal bildirimi yükümlülüğü, olayın öğrenilmesinden itibaren 72 saat içinde yapılmasını gerektirmektedir (KVKK Madde 12/5 ve Kişisel Veri İhlali Bildirimi Hakkında Rehber). Bu süreyi karşılayabilmek için gerçek zamanlı uyarı sistemleri olayı fark etme sürenizi birkaç dakikaya indirmelidir.
Loglar kişisel veri içerdiğinden erişim, iş gerekçesi olan personelle sınırlı tutulmalı ve her erişim denetim izi (audit trail) oluşturmalıdır. KVKK Madde 12 kapsamında "veri minimizasyonu" ilkesi gereği, güvenlik incelemesi dışında logların kişisel ayrıntıları maskelenmiş (anonimleştirilmiş) kopyalar üzerinden çalışılması önerilir.
MX Toolbox (mxtoolbox.com), SMTP Diag Tool gibi çevrimiçi araçlar sunucunuzun açık relay olup olmadığını test edebilir. Kendi altyapınızda test için swaks (Swiss Army Knife SMTP) aracını kullanabilirsiniz. Açık relay, spam gönderimcilerin altyapınızı kötüye kullanmasına ve IP'nizin kara listelere girmesine yol açar.
Kural tabanlı sistemler basit ve şeffaftır; anomali tespiti için yeterli olabilir. Büyük hacimlerde ise davranışsal analiz modelleri (User and Entity Behavior Analytics — UEBA) yanlış pozitif oranını düşürür. Splunk UEBA, Microsoft Sentinel veya açık kaynak Wazuh bu kategoride değerlendirilebilir. Yapay zeka çözümleri faydalıdır ancak kör bağımlılık yerine kural tabanlı bir temel üzerine eklenti olarak konumlandırılmalıdır.
SMTP protokolü RFC 5321 ile standartlaştırılmış olsa da log formatları MTA'dan MTA'ya farklılık gösterir. Postfix, Exim, Sendmail ve Exchange birbirinden farklı satır yapıları kullanır. Bu nedenle merkezi log yönetimi için her MTA'nın çıktısını ortak bir şemaya dönüştüren (parse eden) ayrıştırıcılara ihtiyaç duyulur; Logstash ve Graylog'un hazır Postfix/Exim ayrıştırıcıları mevcuttur.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.