Kurumsal E-posta ve Domain Güveni: SPF, DKIM ve Phishing’e Karşı Kapsamlı Rehber

Kurumsal e-posta (ör. ad@firma.com) bugün sadece “profesyonel görünmek” için değil, satış, teklif, fatura, destek ve insan kaynakları gibi kritik süreçleri güvenle yürütmek için temel bir altyapı. Ancak aynı zamanda saldırganların en sık hedeflediği kanallardan biri. Çünkü bir kez domain güvenliği zedelenirse; müşterileriniz sahte e-postalara kanabilir, gerçek e-postalarınız spam’a düşebilir, hatta marka itibarınız uzun süre toparlanamayacak şekilde zarar görebilir.

Bu noktada “kurumsal mail kurulumu” sadece posta kutusu açmak anlamına gelmez. DNS tarafında doğru SPF kaydı, DKIM doğrulama ve ideal olarak DMARC politikası olmadan, e-posta kimlik doğrulama eksik kalır. Üstelik phishing (oltalama) saldırıları da yalnızca teknik ayarla bitmez: kullanıcı farkındalığı, süreçler ve izleme birlikte düşünülmelidir. Bu rehberde “spf dkim nedir” sorusundan başlayıp, DMARC ile alignment mantığına, en sık görülen kurulum hatalarına ve kurumsal e-postada phishing/BEC senaryolarına kadar uçtan uca, pratik bir yol haritası bulacaksınız.

Kurumsal e-posta neden “domain güveni” ile birlikte düşünülmeli?

Kurumsal e-posta, şirketinizin dijital kimliğinin en görünür parçalarından biridir. Bir müşteriye gönderdiğiniz teklif e-postası, bir tedarikçiye ilettiğiniz ödeme bilgisi veya bir adayla yaptığınız yazışma; hepsi e-posta üzerinden ilerler. Bu yüzden e-posta güvenliği iki temel eksende ele alınmalı:

1. Teslim edilebilirlik (deliverability) ve itibar:
   E-postalarınızın gelen kutusuna düşmesi, büyük ölçüde domain ve gönderim altyapınızın itibarına bağlıdır. SPF/DKIM/DMARC eksikliği, yanlış DNS kayıtları, tutarsız gönderim kaynakları veya kötüye kullanım; “mail spam’a düşüyor” şikayetlerini artırır.

2. Kimlik sahteciliği (spoofing) ve phishing riski:
   Saldırganlar, sizin domain’inizi taklit ederek (domain spoofing) “Muhasebe’den ödeme talebi” ya da “CEO’dan acil havale” gibi içeriklerle çalışanlarınızı hedefleyebilir. Burada kritik nokta şudur: SPF ve DKIM tek başına her zaman yeterli olmaz; DMARC ile “From” alanı üzerinden kurumsal kimliğinizi doğrulamak gerekir.

Kurumsal ölçekte doğru yaklaşım; e-posta altyapısını (Microsoft 365 kurumsal mail, Google Workspace kurumsal mail, mail hosting/cPanel/Plesk vb.) kurarken DNS doğrulamalarını, yetkilendirmeyi ve güvenlik süreçlerini en baştan planlamaktır. Özellikle birden fazla sistemden e-posta gönderiyorsanız (CRM, form bildirimleri, e-bülten, ticket sistemi), “tek bir doğru SPF kaydı” ve düzenli denetim şarttır.

SPF nedir? SPF kaydı nedir, neyi doğrular neyi doğrulamaz?

“SPF nedir?” sorusunun kısa cevabı: SPF (Sender Policy Framework), bir domain adına e-posta göndermeye yetkili sunucuları DNS üzerinden ilan eden bir standarttır. Pratikte bu, alıcı mail sunucusunun “Bu e-postayı gönderen IP/host, bu domain için yetkili mi?” diye kontrol yapması demektir.

SPF’in kritik detayı: From’u değil, zarf göndereni doğrular

SPF çoğu kişinin sandığı gibi doğrudan görünen From: alanını doğrulamaz. SPF kontrolü genellikle “envelope sender” denen Return-Path / MAIL FROM üzerinden çalışır. Bu yüzden SPF “pass” olsa bile, kötü niyetli bir e-posta görünen From alanında markanızı taklit etmeye çalışabilir. İşte burada DMARC devreye girer (alignment).

SPF kaydı örneği (TXT)

Basit bir SPF kaydı örneği:

v=spf1 include:_spf.google.com ~all

• include:_spf.google.com: Google Workspace üzerinden gönderime izin verirsiniz.
• ~all (softfail): Yetkisiz kaynakları “şüpheli” olarak işaretler; kademeli geçişte faydalıdır.
• Zamanla daha sıkı politikaya geçmek için -all (fail) tercih edilebilir; fakat önce tüm gönderim kaynaklarınızın doğru olduğundan emin olmalısınız.

En sık SPF hataları (ve hızlı çözümler)

• Birden fazla SPF kaydı eklemek: Aynı domain için birden fazla TXT SPF kaydı olursa doğrulama bozulur. Çözüm: Tek bir SPF kaydında birleştirin.
• SPF 10 DNS lookup limiti: SPF değerlendirmesinde include, a, mx, redirect gibi mekanizmalar toplamda 10 DNS sorgusunu aşarsa permerror oluşabilir. Çözüm: include zincirini sadeleştirin, gereksiz yönlendirmeleri kaldırın, gerekiyorsa gönderim kaynaklarını konsolide edin.
• Yanlış include / eski servisler: Kullanmadığınız e-bülten sağlayıcısının include’u kayıtta kalırsa hem karmaşa hem risk yaratır. Çözüm: Gönderim envanteri çıkarıp SPF’i güncelleyin.
• Softfail’de takılı kalmak: Sürekli ~all kullanmak, sahteciliği tamamen engellemez. Çözüm: DMARC ile birlikte kademeli olarak sıkılaştırın.

Bu bölüm “spf kaydı nedir”, “spf kaydı örneği”, “spf include nedir”, “spf fail ne demek” gibi aramaları da doğal biçimde karşılar. Ancak SPF’in tek başına phishing’i bitirmediğini akılda tutmak gerekir.

DKIM nedir? DKIM doğrulama, selector ve key rotation ile güveni artırın

“DKIM nedir?” sorusunun cevabı: DKIM (DomainKeys Identified Mail), e-postanın içeriğinin ve bazı başlıklarının kriptografik olarak imzalanmasını sağlar. Alıcı taraf, DNS’te yayınlanan public key ile bu imzayı doğrular ve e-postanın yolda değiştirilmediğini (ve ilgili domain adına imzalandığını) kontrol eder.

DKIM nasıl çalışır? (Basit anlatım)

• Gönderici sistem, e-postayı bir private key ile imzalar.
• DNS’te selector._domainkey altında public key yayınlanır.
• Alıcı, imzayı doğrular ve “DKIM pass/fail” sonucu üretir.

DKIM DNS kaydı örneği

Genellikle şöyle görünür (örnek format):

selector1._domainkey.firma.com  TXT  "v=DKIM1; k=rsa; p=PUBLICKEY..."

Buradaki selector, birden fazla anahtar yönetebilmenizi sağlar. Bu da “key rotation” (anahtar yenileme) için kritiktir.

DKIM’de sık görülen problemler

• Yanlış selector kullanımı: Servis panelinde seçilen selector ile DNS’teki kayıt uyuşmaz. Sonuç: dkim=fail.
• 1024-bit anahtarlar: Bazı eski kurulumlarda 1024-bit anahtarlar hâlâ kullanılır; modern beklenti çoğu senaryoda 2048-bit anahtardır.
• Key rotation yapılmaması: Uzun süre aynı anahtarı kullanmak risklidir. Çözüm: Yılda en az bir kez (veya politika gereği) selector değiştirerek anahtar yenileyin.
• “DKIM pass ama yine de spam”: DKIM tek başına teslim edilebilirliği garanti etmez. İçerik kalitesi, gönderim hacmi, domain reputation ve DMARC politikası da etkilidir.

DKIM, SPF’e göre phishing’e karşı daha güçlü bir sinyal üretir; çünkü içerik imzası üzerinden doğrulama yapar. Yine de “From” alanının güveni için DMARC ile alignment şarttır.

Bu noktada web sitenizden giden otomatik e-postalar (form bildirimleri, teklif talepleri, CRM bildirimleri) ayrı bir risk alanıdır. Özellikle lead toplama ve form akışları kullanıyorsanız, e-posta kimlik doğrulama ayarlarını doğru yapmak teslim edilebilirlik için kritiktir. İlgili bir okuma: Web Sitesinden Lead: Form, CRM ve Ölçümleme Zinciri

DMARC, alignment ve domain spoofing: SPF/DKIM’i gerçek “domain güvenliği”ne çevirin

SPF ve DKIM “geçti” diye her şey tamam sanmak, kurumsal e-posta güvenliğinde en yaygın yanılgılardan biridir. Çünkü saldırganlar, görünen From alanında sizin domain’inizi yazıp, teknik olarak farklı bir zarf gönderen veya farklı imzalama alanı kullanabilir. DMARC (Domain-based Message Authentication, Reporting & Conformance) burada devreye girer.

DMARC nedir ve alignment ne demek?

DMARC, alıcıya şunu söyler:

• SPF ve/veya DKIM sonuçlarına bak,
• ama en önemlisi From domain’i ile SPF/DKIM domain’i “uyumlu” (aligned) mi? kontrol et,
• uyumsuzsa ne yapacağını (none/quarantine/reject) politikayla belirle.

Bu sayede “spf pass ama from taklit” gibi senaryolar büyük ölçüde engellenir. İşte bu, domain spoofing riskini azaltmanın en etkili yollarından biridir.

DMARC politikası: none → quarantine → reject geçiş planı

DMARC’ı bir anda p=reject yapmak, bazı meşru e-postalarınızı da engelleyebilir. Daha sağlıklı yaklaşım:

1. Başlangıç (p=none):
   Rapor toplayın, kimlerin sizin adınıza mail gönderdiğini görün.
2. Temizlik:
   CRM, e-bülten, helpdesk, web formu, ERP gibi tüm gönderim kaynaklarını SPF/DKIM ile düzeltin.
3. Kademeli sıkılaştırma (p=quarantine + yüzde):
   Örn. belirli bir yüzdeyle karantinaya alma.
4. Tam koruma (p=reject):
   Yetkisiz gönderimleri reddet.

DMARC raporları (rua/ruf) ne işe yarar?

DMARC raporları, sizin domain’iniz adına kimlerin e-posta göndermeye çalıştığını gösterir. Bu raporlar sayesinde:

• Yetkili olmayan kaynakları fark edebilir,
• SPF 10 DNS lookup limit gibi karmaşık hataları daha hızlı teşhis edebilir,
• “Kurumsal mail kurulumu” sonrası doğrulama adımlarını somut veriye dayandırabilirsiniz.

DMARC aynı zamanda teslim edilebilirlikte de ciddi fark yaratır; çünkü büyük e-posta sağlayıcıları (Gmail, Outlook vb.) kimlik doğrulaması düzgün domain’lere daha fazla güvenir. Bu güven, özellikle düzenli müşteri iletişimi yapan şirketler için kritik bir avantajdır.

Phishing nedir? Kurumsal e-postada en yaygın senaryolar ve korunma yöntemleri

“Phishing nedir?” en basit haliyle, kullanıcıyı kandırarak şifre, ödeme, erişim veya hassas bilgi elde etmeye yönelik saldırıların genel adıdır. Kurumsal dünyada phishing çoğu zaman daha hedefli biçimde gelir:

Phishing, spoofing ve BEC farkı

• Spoofing (domain taklidi): E-posta, sizin domain’inizden geliyormuş gibi gösterilir. DMARC burada kritik rol oynar.
• Phishing (oltalama): Sahte giriş sayfaları, sahte dosyalar, linkler üzerinden kimlik bilgisi çalınır.
• BEC (Business Email Compromise): “CEO fraud”, “sahte fatura dolandırıcılığı”, “acil ödeme talimatı” gibi senaryolarla finansal kayıp hedeflenir. BEC saldırıları çoğu zaman teknikten çok süreç zafiyetlerinden faydalanır.

Kurumsal phishing’e karşı teknik + süreç önlemleri

• MFA ve koşullu erişim: Özellikle Microsoft 365 kurumsal mail ve Google Workspace kurumsal mail ortamlarında MFA zorunlu olmalı.
• Şüpheli e-posta bildirim süreci: Çalışanların tek tıkla güvenlik ekibine iletebileceği bir akış oluşturun.
• Eğitim ve simülasyon: “Phishing nasıl anlaşılır?” eğitimleri düzenli tekrarlanmalı; simülasyonlarla ölçülmeli.
• Lookalike domain / typosquatting takibi: Saldırganlar benzer alan adları alabilir (firmaadi.com yerine firrnaadi.com gibi). Marka ve domain güvenliği için izleme/koruma planı oluşturun.
• DNS ve registrar güvenliği: Domain panelinde 2FA, registrar lock, yetki matrisi ve değişiklik takibi; “domain güvenliği”nin en kritik ama en çok unutulan kısmıdır.

Kurumsal güven sinyalleri sadece e-postada değil web tarafında da önemlidir. Özellikle KVKK, güven ve iletişim süreçleri açısından benzer yaklaşımı web varlıklarınıza da taşımak isterseniz: Avukatlar İçin Web Sitesi ve KVKK / Güven Sinyalleri

Kurumsal mail kurulumu için güvenlik ve doğrulama kontrol listesi (Pratik)

Kurumsal mail kurulumu yaparken (veya mevcut sistemi denetlerken) aşağıdaki liste, hem e-posta güvenliği hem de teslim edilebilirlik açısından iyi bir temel sağlar:

• SPF

  • Tek bir SPF TXT kaydı var mı?
  • Kullanılan tüm gönderim kaynakları (CRM, e-bülten, web sitesi SMTP, helpdesk) SPF’e dahil mi?
  • spf 10 dns lookup limit aşımı var mı?
  • Geçiş planı: ~all → (sorunlar çözülünce) -all

• DKIM

  • DKIM imzalama aktif mi?
  • 2048-bit anahtar kullanılıyor mu?
  • Selector yönetimi doğru mu?
  • Düzenli DKIM key rotation planı var mı?

• DMARC

  • DMARC kaydı var mı?
  • p=none ile rapor toplanıyor mu?
  • Alignment kontrolleri sağlanıyor mu?
  • Kademeli olarak quarantine/reject aşamasına geçiş planlandı mı?

• DNS/Domain yönetimi

  • Registrar ve DNS panelinde 2FA açık mı?
  • Yetkiler rol bazlı mı? (Kim TXT kaydı ekleyebilir?)
  • Değişiklikler loglanıyor mu?

• Operasyonel süreç

  • Şüpheli e-posta bildirim akışı var mı?
  • Finansal işlem onaylarında ikinci kanal doğrulama (telefon/IM) zorunlu mu?
  • Düzenli denetim: “mail spam’a düşüyor” gibi şikayetlerde header analizi yapılabiliyor mu?

Bu kontrol listesini uygulamak, hem “kurumsal e-posta” altyapınızı sağlamlaştırır hem de büyüdükçe artan otomasyon ve entegrasyonların (CRM, formlar, kampanyalar) riskini yönetilebilir kılar. Daha geniş dijital planlama perspektifi için şu içerik de yol gösterici olabilir: SEO ve GEO Birlikte Nasıl Planlanır?

İç Bağlantı Önerileri

• SEO ve GEO Birlikte Nasıl Planlanır?
• Web Sitesinden Lead: Form, CRM ve Ölçümleme Zinciri
• Avukatlar İçin Web Sitesi ve KVKK / Güven Sinyalleri