SPF, DKIM, DMARC (ve Bonus: BIMI) — Sıfırdan Kurulum, Sık Yapılan Hatalar ve Doğrusu

Bu yazıyı tek bir gözlem doğurdu: Yıllardır yüzlerce kurumun DNS kayıtlarını inceliyoruz ve en sık gördüğümüz manzara şu — SPF var ama 10 lookup sınırını aşmış; DKIM "kurulmuş" ama tek seçiciyle unutulmuş; DMARC kaydında ise rua=mailto:[email protected] yazıyor. Yani kurum, hem raporları kimsenin bakmadığı bir kutuya akıtıyor hem de en kritik yönetici adresini tüm dünyaya ilan ediyor.

Bu yazı, Mail Teknolojileri Serimizin ilk yazısı. Amacımız internette bolca bulunan "SPF nedir?" tanım yazılarından farklı bir şey yapmak: hiç bilmeyen bir BT yöneticisinin bile okuyup uygulayabileceği, sık yapılan hataları ve doğrusunu gösteren, sahadan beslenen bir kurulum rehberi. Sonunda bonus olarak BIMI var — markanızın logosunu gelen kutusunda doğrulatan standart.

1. Üç Kayıt, Tek Amaç: "Bu Maili Gerçekten Siz mi Gönderdiniz?"

Teknik detaya girmeden önce üçünün işbölümünü tek paragrafta netleştirelim. SPF, alan adınız adına hangi sunucuların mail gönderebileceğini ilan eder ("bizim adımıza sadece şu sunucular konuşur"). DKIM, gönderilen maile kriptografik bir imza ekler ("bu mail yolda değiştirilmedi ve gerçekten bizden çıktı"). DMARC ise ikisinin sonucuna bakıp karar verir ("SPF ya da DKIM tutmuyorsa maili reddet/karantinaya al ve bana raporla"). Üçü birlikte, alan adınızın taklit edilmesini engelleyen kimlik katmanını oluşturur.

2. SPF — Nasıl Kurulur?

Adım adım

1. Envanter çıkarın: Alan adınızdan mail gönderen her şeyi listeleyin — mail sunucunuz (Microsoft 365 / Google Workspace), CRM, toplu e-posta aracı, muhasebe yazılımı, web sitenizin form mailleri.

2. TXT kaydını yazın: DNS yönetiminizde kök alan adına bir TXT kaydı ekleyin. Microsoft 365 için tipik başlangıç: 

   v=spf1 include:spf.protection.outlook.com -all

3. Diğer gönderenleri ekleyin: Her meşru gönderen servis için bir include: ekleyin.
4. -all ile bitirin: "Listede olmayan herkes reddedilsin" demektir. Yumuşak ~all yalnızca geçiş dönemi içindir; orada unutulmamalıdır.

Sık yapılan hatalar → doğrusu

• Hata: 10 lookup sınırını aşmak. SPF standardı en fazla 10 DNS sorgusuna izin verir; her include: zinciri bu sayacı yer. Aşarsanız SPF "permerror" verir ve koruma fiilen çöker. Doğrusu: Kullanılmayan include'ları temizlemek ve mümkünse yönetilen SPF (aşağıda) kullanmak.
• Hata: Birden fazla SPF kaydı. Bir alan adında yalnızca tek SPF TXT kaydı olabilir; ikincisi tüm yapıyı geçersiz kılar. Doğrusu: Tüm gönderenleri tek kayıtta birleştirmek.
• Hata: Tüm gönderen altyapısını dünyaya ilan etmek. Klasik SPF kaydı, hangi CRM'i, hangi pazarlama aracını, hangi sunucuları kullandığınızı herkese okutur — saldırgan için hazır keşif raporu. Doğrusu: Yönetilen SPF / SPF flattening.

Bir üst seviye: Yönetilen SPF (kendi domainimizden canlı örnek)

Kendi alan adımız kinetikbilisim.net üzerinden gösterelim — kayıt kamuya açık, herkes sorgulayabilir:

v=spf1 include:25nfc2tit.spf.checkpoint-spf.com -all

Dikkat edin: kayıtta Microsoft görünmüyor, CRM görünmüyor, hiçbir gönderen altyapısı görünmüyor. Tek bir yönetilen include var. Check Point'in SPF Management hizmeti, tüm meşru gönderenlerimizi kendi tarafında dinamik olarak yönetiyor; biz yeni bir gönderen servis eklediğimizde DNS'e dokunmuyoruz bile. Sonuç: lookup sayımız 10 sınırının çok altında (2/10), sıfır hata — ve gönderen altyapımız dışarıdan tamamen gizli. Güvenlik, "doğru SPF yazmak"tan bir kademe yukarı çıkıyor: saldırganın keşif yüzeyi de kapanıyor.

3. DKIM — Nasıl Kurulur?

Adım adım

1. Mail platformunuzda DKIM'i etkinleştirin: Microsoft 365'te Defender portalından (Email authentication settings), Google Workspace'te Admin konsolundan anahtar üretilir.
2. Seçici (selector) kayıtlarını DNS'e ekleyin: Platform size selector1._domainkey ve selector2._domainkey gibi CNAME/TXT kayıtları verir; bunları DNS'e girersiniz.
3. İmzalamayı açın ve doğrulayın: Test maili gönderin, başlıkta DKIM=pass görün.

Sık yapılan hatalar → doğrusu

• Hata: Anahtarı kurup yıllarca unutmak. Aynı DKIM anahtarı yıllarca dönmezse (rotate edilmezse), sızması halinde tüm geçmiş ve gelecek trafik risklenir. Doğrusu: Periyodik anahtar rotasyonu — ideali bunu otomatik yapan bir yönetim katmanı.
• Hata: Üçüncü parti gönderenleri imzasız bırakmak. CRM ve pazarlama araçları kendi DKIM'ini ister; kurulmazsa o mailler DMARC hizasından düşer. Doğrusu: Her gönderen servis için kendi seçicisini kurmak.
• Hata: 1024-bit zayıf anahtar kullanmak. Doğrusu: 2048-bit anahtar.

Bir üst seviye: Yönetilen DKIM (yine kendi domainimizden)

kinetikbilisim.net'in DNS'ine bakan biri şunu görür: _domainkey.kinetikbilisim.net alt alanı, NS kayıtlarıyla yönetilen bir DNS bölgesine devredilmiş durumda. Bu, Check Point DKIM Management'ın yaklaşımı: tüm DKIM seçicileri bizim adımıza yönetilen bölgede tutulur; anahtar üretimi, rotasyon ve yeni servis eklemeleri otomatik yürür. Biz her seferinde DNS kaydı girip çıkarmayız; unutulan seçici, süresi geçmiş anahtar, kopyala-yapıştır hatası diye bir şey kalmaz. DKIM'in en büyük operasyonel riski olan "insan unutkanlığı" denklemden çıkar.

4. DMARC — Nasıl Kurulur? (Ve En Kritik Hata Burada)

Adım adım

1. Monitor modunda başlayın: _dmarc alt alanına TXT kaydı: v=DMARC1; p=none; rua=mailto:... — p=none hiçbir maili engellemez, yalnızca rapor toplar.
2. Raporları 2–4 hafta izleyin: Hangi meşru gönderenlerin SPF/DKIM hizasından düştüğünü tespit edip düzeltin.
3. Kademeli sıkılaştırın: p=quarantine (önce pct=25 gibi kısmi), sonra p=reject. Hedef her zaman reject'tir; p=none'da yıllarca kalmak, alarm kurup sesini kapatmak gibidir.

Sık yapılan hatalar → doğrusu

• Hata: Sadece ruf ekleyip rua eklememek. DMARC'ın asıl değeri olan toplu raporları rua taşır; ruf (adli raporlar) ise gizlilik gerekçesiyle Gmail dahil büyük sağlayıcıların çoğu tarafından artık gönderilmez. Yalnızca ruf tanımlayan kurum, hiç rapor almadan "DMARC kurdum" sanır — alarm var ama kablosu takılı değil. Doğrusu: rua her zaman tanımlı olmalı; ruf opsiyoneldir.
• Hata: Ön tanımlı değişkenleri boş yere kayda eklemek. pct=100, ri=86400, adkim=r, aspf=r gibi etiketler zaten varsayılan değerlerdir; kayda yazmak hiçbir şey kazandırmaz. Kaydı uzatır, okunabilirliği düşürür ve elle düzenlemelerde hata riskini artırır. Doğrusu: Yalnızca varsayılandan sapan etiketleri yazmak. Kısa kayıt, temiz kayıttır.
• Hata: Çift DMARC kaydı girmek. SPF'teki çift kayıt hatasının DMARC versiyonu: _dmarc altında birden fazla TXT kaydı varsa alıcı sunucular kaydı geçersiz sayar ve DMARC hiç yokmuş gibi davranır. Genellikle iki farklı aracın/ajansın birbirinden habersiz kayıt eklemesiyle oluşur. Doğrusu: Tek kayıt; yeni kayıt eklemeden önce mevcut _dmarc TXT'si mutlaka sorgulanmalı.
• Hata: Kurulumdan sonra test etmemek. SPF, DKIM ve DMARC çalışması bitince doğrulama yapılmazsa; yazım hatası, eksik seçici ya da hizalama sorunu haftalarca fark edilmez — üstelik her şey "kurulu" görünürken. Doğrusu: Aşağıdaki 5 dakikalık doğrulamayı kurulumun standart son adımı yapmak.

Kurulumdan sonra: 5 dakikalık doğrulama

En basit test: Kendi domaininizden bir Gmail adresine test maili gönderin. Gelen mesajı açın → sağ üstteki üç nokta → "Orijinali göster" (Show original). Gmail; SPF, DKIM ve DMARC sonuçlarını tek ekranda gösterir — üçünde de PASS görmelisiniz. Birinde FAIL varsa aynı ekrandaki başlıklar sorunun hangi katmanda olduğunu söyler.

Online doğrulama araçları: Daha ayrıntılı analiz için şu araçlara test maili gönderebilir ya da domain sorgusu yapabilirsiniz:

• learndmarc.com — size verdiği adrese test maili atarsınız; SPF/DKIM/DMARC değerlendirmesini adım adım, görsel bir akışla gösterir. Konuyu yeni öğrenen ekipler için özellikle değerli.
• mail-tester.com — test mailinize 10 üzerinden puan verir; kimlik doğrulamanın yanında spam skorunu ve içerik sorunlarını da raporlar.
• MXToolbox (Domain Health) ve Google Admin Toolbox CheckMX — mail göndermeden, DNS tarafındaki SPF/DMARC kayıtlarınızı ve genel sağlığı tek sorguda kontrol eder.

Sahada en sık gördüğümüz hata: rua/ruf adresleri

DMARC kaydındaki rua (toplu raporlar) ve ruf (adli/hata raporları) adresleri, herkese açık DNS'te yayınlanır. Ve sahada en sık gördüğümüz manzara şu:

rua=mailto:[email protected]  ya da  rua=mailto:[email protected]

Bu tek satır, iki zafiyeti aynı anda üretir. Birincisi: Kurumun en yetkili posta kutusunu ya da gerçek bir çalışanın adres formatını tüm dünyaya ilan edersiniz — hedefli phishing ve parola denemeleri için hazır hedef. İkincisi ve daha yaygını: O kutuya günde onlarca sıkıştırılmış XML raporu düşer ve kimse açmaz. Açan da tek tek XML'lerden büyük resmi göremez: "Bu hafta alan adımı taklit ederek Vietnam'dan 4.000 mail gönderilmiş" bilgisi, yüzlerce dosyanın içinde görünmez kalır.

Doğrusu: Raporları işi bu olan bir servise yönlendirin

rua/ruf adresleri; kişisel kutulara, kendi alan adınızdaki yönetici hesaplarına ya da kim olduğu belirsiz ücretsiz üçüncü parti servislere değil, hâlihazırda çalıştığınız siber güvenlik üreticisinin DMARC yönetim hizmetine yönlendirilmelidir. Ölçek ve ihtiyaca göre iki iyi örnek:

• Cloudflare DMARC Management (ücretsiz): DNS'iniz Cloudflare'deyse, raporlar Cloudflare'in ürettiği özel bir adrese akar; panelde kaynak/geçiş oranı grafikleriyle özetlenir. Küçük ve orta ölçek için sıfır maliyetle "büyük resmi görme" sağlar.
• Check Point DMARC Management (profesyonel): Harmony Email & Collaboration'ın parçası olarak; rapor toplama-görselleştirmenin ötesinde, yukarıda anlattığımız SPF Management ve DKIM Management ile aynı çatı altında uçtan uca yönetim sunar. Raporlar sizin adınıza toplanır, kaynaklar otomatik sınıflanır, reject'e geçiş yol haritası panelden yürütülür.

Kural basit: XML'i insana değil, sisteme okutun. DMARC'ın değeri raporda değil, raporun görünür kılınmasında.

Küçük ama önemli bir teknik ayrıntı: raporları kendi domaininiz dışındaki bir adrese yönlendirdiğinizde, DMARC standardı karşı tarafın "bu domain adına rapor kabul ediyorum" anlamına gelen bir harici hedef doğrulama kaydı yayınlamasını şart koşar — yoksa birçok sağlayıcı rapor göndermez. Elle kurulumda sık atlanan bu adım, yönetilen servislerde otomatik kurulur; "raporlar neden gelmiyor?" sorusunun en yaygın cevaplarından biri de budur.

5. Bonus: BIMI — Logonuz Gelen Kutusunda

BIMI (Brand Indicators for Message Identification), DMARC'ı reject/quarantine seviyesine taşımış kurumlara verilen görünür ödüldür: doğrulanmış marka logonuz, Gmail ve destekleyen diğer istemcilerde mailin yanında görüntülenir. Kurulumu üç parçadır: 

1. DMARC en az p=quarantine (ideali reject)
2. logonuzun SVG Tiny-PS formatında hazırlanması,
3. default._bimi TXT kaydı + Gmail için VMC (Verified Mark Certificate — logonuzun tescilli markanız olduğunu doğrulayan sertifika).

Bu arada, DMARC'ınızı reject/quarantine seviyesine taşıdıysanız muhtemelen fark etmişsinizdir: MXToolbox'ta domaininizi sorguladığınızda araç artık [SUPPLEMENTAL] Brand Logo not appearing in inboxes uyarısı göstermeye başlar. Bu bir hata değil, bir davettir — MXToolbox size "kimlik doğrulaman logo göstermeye hazır ama BIMI kaydın yok" demektedir. Uyarıyı gördüyseniz, BIMI için ön koşulları zaten tamamlamışsınız demektir.

BIMI'nin asıl değeri estetik değil: logonun görünmesi, alıcıya "bu alan adı kimlik doğrulamasını tam yapmış" sinyali verir ve phishing maillerinin (logosuz) ayırt edilmesini kolaylaştırır. Türkiye'de BIMI'yi tamamlamış kurum sayısı hâlâ çok az — erken davrananlar için gelen kutusunda gerçek bir farklılaşma alanı.

Sıkça Sorulan Sorular

Domainimin mevcut durumunu hızlıca nasıl kontrol ederim?

Üç kaydı da birkaç dakikada kontrol edebilirsiniz: SPF ve DMARC için alan adınıza TXT sorgusu (DMARC için _dmarc.alanadiniz.com), DKIM için platformunuzun seçicisiyle sorgu. MXToolbox gibi araçlar bunu tek ekranda yapar. Dilerseniz ücretsiz saha denetimi kapsamında üç kaydın karnesini look-alike domain riskiyle birlikte biz çıkarırız.

p=none'da kalmak gerçekten sorun mu? Hiç DMARC olmamasından iyi değil mi?

Rapor toplamak için evet, hiç yoktan iyidir — ama koruma açısından p=none, taklit edilen maillerinizin teslim edilmesine izin verir. p=none bir varış noktası değil, en fazla birkaç haftalık bir geçiş istasyonudur.

SPF -all yaptım, bazı meşru maillerimiz spam'e düşmeye başladı. Ne yaptım?

Büyük olasılıkla envanterde unutulan bir gönderen servis var (web formu, muhasebe yazılımı, eski bir CRM). DMARC raporları tam bu yüzden vardır: reject'e geçmeden önce raporlarda tüm meşru kaynakları görüp SPF/DKIM hizasına almak. Yönetilen SPF kullanıyorsanız yeni servisi panele eklemek yeterlidir; DNS'e dokunmazsınız.

Bunların hepsi kurulunca phishing biter mi?

Hayır — ve bunu netlikle söylemek gerekir. SPF/DKIM/DMARC, sizin alan adınızın taklit edilmesini durdurur. Look-alike domain (kinetlkbilisim.net gibi), display name spoofing ve ele geçirilmiş gerçek hesaplardan gelen BEC saldırıları bu protokollerin kapsamı dışındadır. Bu katmanın üstüne davranışsal analiz gerekir; ayrıntısı BEC yazımızda.

Şimdi Ne Yapmalı?

Beş dakikanız varsa: alan adınızın SPF kaydına bakın (lookup sayısı? -all mi?), _dmarc kaydınıza bakın (p=none'da mı? rua kime gidiyor?). Cevaplardan biri sizi rahatsız ettiyse:

1. Ücretsiz Saha Denetimi: SPF/DKIM/DMARC/BIMI karneniz, lookup analizi, rua/ruf zafiyeti ve look-alike domain riskiyle birlikte raporlanır.
2. Yönetilen geçiş: SPF Management, DKIM Management ve DMARC Management'ın kurumunuza kurulumu; p=none'dan reject'e kademeli yol haritasıyla.

Tanışma toplantısı planlayın

Bu yazı hakkında: Mail Teknolojileri Serimizin ilk yazısıdır; bir sonraki yazı S/MIME ve PGP ile e-posta şifrelemeyi ele alacak. Kinetik Bilişim, Check Point Software Technologies'in Advanced Partner 2026 seviyesindeki Türkiye iş ortağıdır; Email, Endpoint & Browser, Mobile ve SASE Solution Specialization akreditasyonlarına sahiptir. Yazar Kemal Özleyen, Check Point Workspace Security Expert sertifikalı bir siber güvenlik mühendisidir. Yazıdaki kinetikbilisim.net örnekleri kamuya açık DNS kayıtlarıdır.