Kurumsal e-posta güvenliği
Mail Güvenliği, Spam ve Phishing Koruması
Kurumsal mail güvenliği yalnız spam oranını düşürmek değildir. Alan adının doğru doğrulanması, kullanıcı ve tedarikçi taklidinin ayırt edilmesi, şüpheli bağlantı ve eklerin incelenmesi, hesapların korunması ve olay çıktığında kimin ne yapacağının bilinmesi gerekir. Antalya’da yerinde keşif; Türkiye genelinde uzaktan denetim, kurulum ve operasyon desteği sunuyoruz.
Alan adınızı ve riskli kullanıcı gruplarını birlikte inceleyelim
E-posta platformunu, kullanıcı sayısını, gönderim yapan servisleri, mevcut lisansları ve yaşadığınız teslimat veya phishing sorununu paylaşın. İlk görüşmede denetim, pilot ve destek sınırını netleştirelim.
Tehdidi doğru adlandırmak
Spam, phishing ve BEC aynı olay değildir
Politika, yalnız ileti içeriğine göre değil; gönderen kimliği, alan adı, kullanıcı ilişkisi, istenen işlem ve hesabın oturum davranışı birlikte değerlendirilerek kurulur.
Spam ve toplu ileti
İstenmeyen reklam, düşük itibarlı gönderim ve kullanıcı için değer taşımayan yüksek hacimli iletilerdir. Teslimat ve yanlış pozitif dengesi izlenir.
Phishing ve zararlı içerik
Kullanıcıyı sahte giriş sayfasına, zararlı eke veya riskli işleme yönlendiren iletilerdir. URL, ek, kimlik ve davranış sinyalleri birlikte ele alınır.
BEC ve taklit
Yönetici, finans, tedarikçi veya gerçek hesap görünümüyle ödeme ve bilgi talep eden iş e-postası dolandırıcılığıdır. Her zaman zararlı bağlantı içermeyebilir.
Teknik sınır: Tek bir filtre, DNS kaydı veya kullanıcı eğitimi bütün senaryoları durdurmaz. Alan adı doğrulaması, kimlik güvenliği, içerik analizi, kullanıcı bildirimi ve olay müdahalesi birbirini tamamlayan katmanlardır.
Doğrudan yanıt
E-posta güvenliği, ileti gelmeden önce başlar ve olay kapandıktan sonra ölçülür
Gönderim kaynakları ile alan adı kayıtları doğru kurulmadan teslimat güveni oluşmaz; hesap ve oturumlar korunmadan ele geçirilmiş kullanıcı riski azalmaz; karantina ile olay devri işletilmeden de filtre çıktısı yönetilebilir bir güvenlik sürecine dönüşmez.
Kimlik ve erişim
Yönetici, finans ve hassas rollerde güçlü MFA, riskli oturum kontrolü, eski protokoller ve uygulama izinleri değerlendirilir.
Alan adı doğrulaması
SPF, DKIM ve DMARC; gerçek gönderim kaynakları, hizalama, raporlar, yönlendirme ve alt alan adlarıyla birlikte doğrulanır.
İleti ve taklit koruması
Spam, phishing, zararlı yazılım, URL, ek, görünen ad, kullanıcı ve alan adı taklidi için ayrı politika ve eylem belirlenir.
Operasyon ve müdahale
Karantina yetkisi, kullanıcı bildirimi, benzer ileti arama, hesap kontrolü, ticket devri ve kapanış kaydı tanımlanır.
Keşif ve uygulama
Politika değişmeden önce gerçek mail akışı çıkarılır
Kullanıcı sayısı başlangıç bilgisidir; asıl kapsam hangi alan adının, uygulamanın ve iş sürecinin nasıl ileti gönderip aldığıyla belirlenir.
- Microsoft 365, Google Workspace, yerel veya hibrit e-posta mimarisi
- Kabul edilen alan adları, alt alan adları ve tüm gönderim kaynakları
- CRM, ERP, bülten, web formu, yazıcı, uygulama ve SMTP röleleri
- Yönetici, finans, insan kaynakları, satın alma ve paylaşılan posta kutuları
- Konektörler, yönlendirme, izin listeleri, karantina ve mevcut politikalar
- MFA, oturum kayıtları, kullanıcı bildirimi, SIEM ve ticket gereksinimi
- 01
Alan adı ve mail akışı envanteri
Gelen ve giden ileti yolları, MX kayıtları, konektörler, üçüncü taraf göndericiler, uygulamalar, yönlendirme ve röle noktaları kaydedilir.
- 02
Kullanıcı ve iş riski profili
Yönetici, finans, satın alma, insan kaynakları, destek ve dış paydaşlarla yoğun ileti kuran hesaplar için taklit ve hesap ele geçirme etkisi belirlenir.
- 03
SPF, DKIM ve DMARC doğrulaması
Kayıt sözdizimi kadar gerçek iletilerde geçme ve hizalanma sonuçları incelenir; raporlarla meşru kaynaklar tamamlanmadan yaptırım sıkılaştırılmaz.
- 04
Politika ve karantina pilotu
Spam, phishing, taklit, zararlı ek ve URL eylemleri temsilî kullanıcı grubunda gözlenir; yanlış pozitifler dar istisnalarla düzeltilir.
- 05
Kimlik ve kullanıcı bildirim yolu
MFA, riskli oturum, eski kimlik doğrulama ve şüpheli ileti bildirim düğmesi kontrol edilir; bildirimin ulaşacağı ekip ve ticket akışı tanımlanır.
- 06
Olay müdahalesi ve devir
İleti arama ve temizleme, hesap oturumlarını sonlandırma, parola ve MFA kontrolü, yönlendirme kuralları, endpoint incelemesi ve iletişim adımları runbook hâline getirilir.
- 07
Doğrulama ve sürekli ayar
Test iletileri, kimlik doğrulama raporları, karantina örnekleri, kullanıcı bildirimleri, yanlış pozitifler ve olay süreleri düzenli gözden geçirilir.
Gönderen doğrulaması
SPF, DKIM ve DMARC birlikte çalışır; aynı şeyi ölçmez
Doğru kurulum, yalnız TXT kayıtlarının bulunması değildir. Meşru gönderim kaynaklarının yetkili olması, iletinin imzasının doğrulanması ve kullanıcıya görünen From alan adıyla hizalanması gerekir.
- SPF
- MAIL FROM alan adı adına gönderebilecek kaynakları DNS üzerinden tanımlar. Görünen From alanını tek başına doğrulamaz ve yönlendirmede bozulabilir.
- DKIM
- İleti başlığındaki dijital imzayı yayınlanan anahtarla doğrular. İmzalayan alan adı görünen From alanıyla aynı değilse tek başına taklidi kanıtlamaz.
- DMARC
- Görünen From alanı ile SPF veya DKIM tarafından doğrulanan alanın hizalanmasını kontrol eder; none, quarantine veya reject politikası ve raporlama sağlar.
- Yönlendirme ve ARC
- İleti yönlendirme veya ara servislerle değiştiğinde SPF/DKIM/DMARC etkilenebilir. Akış ve desteklenen ARC davranışı gerçek örneklerle incelenir.
- Gönderim itibarı
- PTR, TLS, gönderim hacmi, şikâyet oranı, liste hijyeni ve alıcı gereksinimleri teslim edilebilirliği etkiler; DNS doğrulaması tek başına yeterli değildir.
- Politika geçişi
- Raporlar ve meşru kaynaklar doğrulandıktan sonra none seviyesinden karantina veya reddetmeye kontrollü geçilir; değişiklik sonrası teslimat izlenir.
Önemli: SPF, DKIM ve DMARC; korunan alan adının yetkisiz kullanımını azaltır. Benzer yazımlı alan adları, ele geçirilmiş gerçek hesaplar ve görüntü adı taklidi için ek kontroller gerekir.
İki somut doğrulama noktası
Alan adı sağlığı ve olay devri ayrı ayrı test edilir
Karantinadan olay kapanışına
Şüpheli ileti yalnız silinmez; etkisi araştırılır
Olayın kapsamı, kullanıcının iletiyle ne yaptığı ve aynı kampanyanın başka posta kutularına ulaşıp ulaşmadığı doğrulanır.
İletiyi doğrula
Gönderen başlıkları, kimlik doğrulama sonuçları, URL, ek, benzer iletiler, hedef kullanıcı ve istenen işlem incelenir.
Etkilenmeyi sınırla
İleti karantinaya alınır; gerekiyorsa benzer kopyalar aranır, bağlantı ve gösterge engellenir, hesap oturumları ile yönlendirme kuralları kontrol edilir.
Kanıtla ve iyileştir
Karar, uygulanan eylem, etkilenen kullanıcı, zaman çizelgesi ve kapanış sonucu kaydedilir; politika veya eğitim ihtiyacı geri beslenir.
Proje teslimi
Ayarlar, işletilebilir kayıtlara dönüştürülür
Yönetici ekranında etkin görünen özellik teslim kanıtı değildir. Envanter, politika, test ve müdahale sorumlulukları yazılı olarak devredilir.
Alan adı ve akış envanteriDomain, kaynak, konektör, röle ve yönlendirme
Doğrulama raporuSPF, DKIM, DMARC, hizalama ve geçiş notu
Politika matrisiKapsam, öncelik, eylem, istisna ve karantina
Pilot ve test kaydıÖrnek ileti, sonuç, yanlış pozitif ve düzeltme
Olay müdahale akışıBildirim, triyaj, temizleme, hesap kontrolü ve devir
Yönetici teslimiRoller, raporlama, bakım ve değişiklik sınırları
İşletme ölçeğine göre uygulama
Aynı tehdit, farklı operasyon ihtiyacı doğurur
- Mikro işletme
- Öncelik; yönetici ve finans hesaplarında MFA, alan adı doğrulaması, güvenli varsayılan politikalar, basit bildirim yolu ve gerektiğinde ulaşılabilir teknik destektir.
- Küçük işletme
- Paylaşılan kutular, web formu ve uygulama gönderimleri, tedarikçi taklidi, karantina sorumlusu, kullanıcı bildirimi ve temel olay kaydı eklenir.
- Orta ölçekli kurum
- Departman ve risk grupları, ayrı politika öncelikleri, SIEM veya ticket entegrasyonu, aylık metrikler, kontrollü simülasyon ve düzenli politika gözden geçirmesi gerekir.
- Büyük ve çok lokasyonlu yapı
- Çoklu alan adı ve tenant, birleşme/tedarikçi akışları, yetki ayrımı, 7/24 eskalasyon, gelişmiş araştırma, saklama ve değişiklik yönetimi birlikte planlanır.
Operasyon ölçümü
Başarı, yalnız engellenen ileti sayısıyla ölçülmez
Hacim tek başına kalite göstergesi değildir. Teslimat, doğrulama, kullanıcı davranışı ve olay yanıtı birlikte değerlendirilir.
- Kimlik doğrulama sağlığı
- SPF/DKIM geçme, DMARC hizalanma, bilinmeyen gönderim kaynağı ve politika hatası eğilimi.
- Yanlış pozitif davranışı
- Meşru iletinin karantinaya düşmesi, serbest bırakma süresi, tekrar eden gönderen ve istisna gerekçesi.
- Kullanıcı bildirimi
- Şüpheli ileti bildirim hacmi, doğruluk oranı, geri bildirim süresi ve aynı kampanyanın erken bulunmasına katkı.
- Olay triyajı
- Bildirimin alınması, doğrulama, kapsam araması, kullanıcı teması ve ilk sınırlama adımları arasındaki süre.
- Kimlik riski
- MFA kapsamı, riskli oturum, eski protokol, yetkili uygulama ve şüpheli yönlendirme kuralı bulguları.
- Politika değişikliği
- Değişiklik nedeni, etkilenen grup, test sonucu, geri dönüş planı ve sonrasında oluşan teslimat etkisi.
Ölçüm notu: Tanımlar ve hedefler kurumun platformuna, lisansına ve destek sözleşmesine göre belirlenir. Sayfadaki örnekler tek başına hizmet seviyesi taahhüdü oluşturmaz.
Sık sorulan sorular
Mail güvenliği ve phishing koruması hakkında merak edilenler
Spam filtresi kurumsal e-posta güvenliği için tek başına yeterli midir?
Hayır. Spam filtresi istenmeyen ve bilinen kötü niyetli iletilerin bir bölümünü azaltır; ancak hesap ele geçirme, yönetici veya tedarikçi taklidi, güvenli görünen bağlantılar, meşru bulut servisleri üzerinden gönderilen dosyalar ve iş e-postası dolandırıcılığı için kimlik güvenliği, MFA, gönderen doğrulaması, taklit koruması, URL ve ek analizi, kullanıcı bildirimi ile olay müdahalesi birlikte gerekir.
SPF, DKIM ve DMARC arasındaki fark nedir?
SPF, alan adı adına posta göndermesine izin verilen kaynakları tanımlar. DKIM, iletinin belirli bölümlerini alan adıyla ilişkili dijital imza üzerinden doğrular. DMARC ise görünen From alanındaki alan adı ile SPF veya DKIM tarafından doğrulanan alan adının hizalanmasını kontrol eder, başarısız iletiler için politika bildirir ve rapor toplamaya imkân verir. Üçü birlikte planlanmalı, gerçek mail akışında test edilmelidir.
DMARC kaydı doğrudan p=reject olarak yayınlanmalı mıdır?
Genellikle hayır. Önce tüm meşru gönderim kaynakları, alt alan adları, CRM, ERP, bülten, yazıcı, uygulama ve üçüncü taraf servisleri envantere alınır. İzleme politikası ve raporlar üzerinden SPF/DKIM hizalaması doğrulanır; hatalar giderildikten sonra karantina ve reddetme politikasına kontrollü geçilir. Hazırlıksız p=reject geçişi gerçek iletilerin teslimini bozabilir.
DMARC phishing ve BEC saldırılarının tamamını engeller mi?
Hayır. DMARC, korunan alan adının yetkisiz biçimde görünen gönderen olarak kullanılmasını azaltır; benzer yazımlı yeni alan adları, ele geçirilmiş gerçek hesaplar, görüntü adı taklidi ve kullanıcıyı telefon ya da farklı kanala yönlendiren BEC senaryolarını tek başına durdurmaz. Taklit koruması, MFA, oturum riski, kullanıcı bildirimi ve olay müdahalesi ayrıca gerekir.
Microsoft 365 veya Google Workspace yerleşik koruması yeterli olur mu?
Yerleşik koruma önemli bir başlangıçtır; yeterlilik lisans seviyesine, etkin politikalara, alan adı doğrulamasına, kullanıcı ve domain taklit korumasına, URL ve ek incelemesine, karantina yetkilerine, log saklamaya ve operasyon ekibine bağlıdır. Platform adı tek başına koruma seviyesini göstermez. Mevcut lisans ile aktif kontroller ayrı ayrı doğrulanır.
Karantinadaki iletileri kullanıcılar serbest bırakabilmeli midir?
Yetki, ileti türüne ve riske göre ayrılmalıdır. Düşük riskli toplu ileti ve olası spam için kontrollü kullanıcı talebi uygulanabilir; phishing, zararlı yazılım, taklit veya yüksek güvenli tehdit sınıflarında serbest bırakma güvenlik ekibi onayına bağlanmalıdır. İzin listeleri mümkün olduğunca dar, süreli ve gerekçeli tutulur.
Teslim edilmiş şüpheli e-posta sonradan temizlenebilir mi?
Platform ve lisans destekliyorsa benzer iletiler diğer posta kutularında aranabilir, karantinaya taşınabilir veya silinebilir. Buna rağmen yalnız iletiyi kaldırmak yeterli değildir; kullanıcı bağlantıya tıkladıysa oturum, MFA değişikliği, yönlendirme kuralı, uygulama izni, parola ve endpoint bulguları da kontrol edilmelidir. Müdahale adımları önceden yetkilendirilir.
Phishing farkındalık eğitimi teknik kontrollerin yerini tutar mı?
Hayır. Eğitim ve kontrollü simülasyon, kullanıcıların şüpheli iletiyi tanıma ve doğru kanaldan bildirme davranışını geliştirir; ancak saldırıyı yalnız kullanıcı dikkatine bırakamaz. Teknik filtreler, kimlik güvenliği, kolay raporlama, hızlı triyaj ve geri bildirim döngüsüyle birlikte uygulanmalıdır. Sonuçlar cezalandırma yerine risk azaltma amacıyla değerlendirilir.
Mail güvenliği teklifi için hangi bilgiler gerekir?
Kullanıcı ve posta kutusu sayısı, Microsoft 365, Google Workspace veya yerel sunucu bilgisi; kabul edilen ve gönderim yapan alan adları, üçüncü taraf göndericiler, mevcut lisanslar, MFA durumu, yönetici ve finans gibi riskli kullanıcı grupları, mail akış konektörleri, karantina modeli, log ve SIEM ihtiyacı, destek saatleri ile son dönemde yaşanan teslimat veya phishing sorunları ilk kapsam için yeterlidir.
Teknik kaynaklar: CISA Phishing Guidance, CISA MFA rehberi, Microsoft e-posta doğrulaması, Microsoft anti-phishing politikaları, Google e-posta gönderici gereksinimleri, IETF DMARC standardı RFC 9989 ve NIST Phish Scale.
Teknik içerik 20 Temmuz 2026 tarihinde resmî kaynaklar ve ürün-bağımsız işletim ilkeleri dikkate alınarak gözden geçirilmiştir. Özellik, lisans, karantina, saklama, geriye dönük temizleme ve entegrasyon kapsamı seçilen platformun güncel dokümanı ile teklif üzerinden doğrulanır. Sayfa tek başına güvenlik sonucu veya teslimat başarısı taahhüdü oluşturmaz.
Ön değerlendirme
Mail akışını güvenli, görünür ve yönetilebilir hâle getirelim
Alan adı, kullanıcı, gönderim kaynakları ve mevcut lisanslardan başlayarak ihtiyacınıza uygun denetim, kurulum ve destek kapsamını çıkaralım.