Kısaca
DMARC, SPF ve DKIM, bir alan adı adına kimlerin e-posta gönderebileceğini tanımlayan ve sahte gönderimlerin alıcı tarafında reddedilmesini sağlayan DNS tabanlı e-posta kimlik doğrulama standartlarıdır. Şirket alan adı kullanan her işletme için gereklidir. CybUp tüm gönderim kaynaklarını bulur, kayıtları kurar ve DMARC’ı raporlara bakarak p=none’dan p=reject’e aşamalı taşır.
SPF, DKIM ve DMARC nedir, nasıl birlikte çalışır?
SPF, alan adınız adına hangi sunucuların e-posta gönderebileceğini DNS’te listeleyen kayıttır (RFC 7208). DKIM, giden her e-postaya alan adınıza ait bir anahtarla dijital imza ekler; alıcı imzayı DNS’teki açık anahtarla doğrular ve mesajın yolda değiştirilmediğini anlar (RFC 6376).
İkisinin de bir boşluğu var: kullanıcının ekranda gördüğü “Kimden” adresini korumazlar. Saldırgan kendi alan adıyla geçerli SPF ve DKIM üretip, görünen adrese sizin alan adınızı yazabilir. DMARC bu boşluğu kapatır: SPF ya da DKIM’den en az birinin geçmesini ve görünen “Kimden” alan adıyla hizalı olmasını şart koşar. Testi geçemeyen mesaja ne yapılacağını (hiçbir şey, karantina, ret) alan adı sahibi olarak siz belirlersiniz; alıcılar da size bu kararların raporunu gönderir.
DMARC’ın standardı 2026 Mayıs’ında güncellendi: eski RFC 7489’un yerini RFC 9989 aldı, toplu raporlar ayrı bir belgede tanımlandı. Yeni sürümde “pct” etiketi kaldırıldı, yerine test modu için “t” etiketi geldi. Kayıtlarınızı kurarken yeni standarda uygun yazıyoruz.
DMARC olmadan ne olur? CEO dolandırıcılığı senaryosu
Örneğin 50 kişilik bir ithalat firmasını düşünelim. Alan adının SPF kaydı var ama DMARC kaydı yok. Bir cuma öğleden sonra muhasebe sorumlusuna genel müdürün tam adresinden bir e-posta gelir: yurt dışındaki tedarikçinin banka hesabı değişmiş, bekleyen fatura bugün yeni hesaba ödenmeli. Görünen adres doğru, imza doğru, üslup tanıdık.
Bu e-posta genellikle bir posta sunucusuna sızılarak değil, basitçe adres taklit edilerek (spoofing) gönderilir. DMARC politikası p=reject olan bir alan adında, Gmail ve Microsoft 365 gibi büyük alıcılar bu mesajı kutuya ulaşmadan reddeder. DMARC olmayan alan adında ise kararı alıcının kendi filtresi verir ve mesaj pekâlâ gelen kutusuna düşebilir.
Bir sınırı da açıkça söyleyelim: DMARC yalnızca sizin alan adınızın birebir taklidini engeller. Saldırgan “firmaadi-tr.com” gibi benzer bir alan adı alırsa DMARC bunu durduramaz. Bu tür saldırılara karşı ödeme değişikliklerini telefonla teyit etme kuralı ve kullanıcı farkındalığı hâlâ gereklidir.
DMARC politikası p=none’dan p=reject’e nasıl taşınır?
DMARC’ı doğrudan p=reject ile yayımlamak, kendi meşru e-postalarınızı engellemenin en hızlı yoludur. Çoğu şirket, alan adı adına kimlerin e-posta gönderdiğini tam bilmez: CRM, e-bülten aracı, ERP’nin fatura gönderimi, web sitesinin iletişim formu, insan kaynakları platformu, fotokopi makinesinin taramayı e-postayla gönderme özelliği. Bu yüzden geçiş aşamalı yapılır.
- p=none ve rua adresiyle başlangıç: hiçbir e-posta etkilenmez, raporlar toplanır.
- Raporlardan tüm gönderim kaynaklarının çıkarılması ve her birine SPF/DKIM hizalamasının yapılması.
- p=quarantine: testi geçemeyen mesajlar alıcıda spam klasörüne gider; gerekirse önce t=y test bayrağıyla.
- p=reject: sahte mesajlar alıcı tarafından reddedilir.
- Alt alan adları ve kullanılmayan alan adları için sp ve np politikalarının belirlenmesi.
“The reason for starting at "p=none" is to ensure that nothing’s been missed in the initial SPF and DKIM deployments. In all but the most trivial setups, a Domain Owner can overlook a server here or be unaware of a third-party sending agreement there.”
“p=none” ile başlamanın nedeni, ilk SPF ve DKIM kurulumlarında hiçbir şeyin gözden kaçmadığından emin olmaktır. En basit yapılar dışında alan adı sahibi bir yerde bir sunucuyu atlayabilir ya da başka bir yerde üçüncü taraf bir gönderim anlaşmasından habersiz olabilir.
DMARC raporları nasıl okunur?
Gmail, Microsoft ve Yahoo gibi alıcılar, rua etiketinde belirttiğiniz adrese günlük XML formatında toplu rapor gönderir. Raporda hangi IP’nin alan adınız adına kaç e-posta gönderdiği, SPF ve DKIM’in geçip geçmediği ve hizalama sonucu yer alır. Ham XML’i okumak zahmetlidir; raporları bir analiz aracına toplayıp anlaşılır hâle getiriyoruz.
İlk haftalarda raporlar genellikle sürpriz içerir. Kimsenin hatırlamadığı bir pazarlama aracı, eski bir web sunucusu ya da alan adınızı kullanan bir bayi çıkar. Her kaynak için karar verilir: meşruysa yetkilendirilir ve DKIM imzası açılır, değilse engellenmeye bırakılır.
Google ve Yahoo toplu gönderici kuralları ne istiyor?
Google’ın e-posta gönderici kuralları, 2024 Şubat’ından beri kişisel Gmail hesaplarına e-posta gönderen herkesten en az SPF ya da DKIM ister. Günde 5.000 ya da daha fazla mesaj gönderenlerden ise SPF, DKIM ve DMARC’ın üçünü birden, “Kimden” alan adının hizalanmasını ve pazarlama e-postalarında tek tıkla abonelikten çıkmayı bekler; DMARC politikası bu kurallar için p=none olabilir.
Yahoo’nun toplu gönderici kuralları da benzer: SPF ve DKIM birlikte, en az p=none olan geçerli bir DMARC kaydı ve hizalama. Kurallara uymayan gönderimler spam klasörüne düşebilir ya da reddedilebilir. Bülten ya da toplu bildirim gönderen şirketler için DMARC artık teslim edilebilirlik meselesidir.
Kurulumda sık karşılaşılan hatalar nelerdir?
En yaygın hata, SPF kaydının DNS sorgu sınırını aşmasıdır. RFC 7208’e göre SPF değerlendirmesinde include gibi DNS sorgusu gerektiren mekanizmaların toplamı 10’u geçemez; her yeni servis için bir include eklenen kayıtlar bir noktada geçersiz hâle gelir ve SPF tamamen başarısız olur. Bir alan adında birden fazla SPF kaydı bulunması da kaydı geçersiz kılar.
İkinci sık hata, üçüncü taraf servislerin DKIM’i kendi alan adlarıyla imzalamasıdır. Bu durumda DKIM geçer ama hizalanmaz; DMARC açısından işe yaramaz. Servisin panelinden kendi alan adınızla imzalama (özel DKIM) açılmalıdır. Microsoft 365 kullanıyorsanız varsayılan onmicrosoft.com imzası yerine alan adınız için DKIM’i etkinleştirmek gerekir. Exchange’den Microsoft 365’e geçiş yapıyorsanız bu kayıtları geçiş planına dahil etmek en temiz yoldur.
“SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".”
SPF uygulamaları, DNS üzerinde makul olmayan bir yük oluşmaması için SPF değerlendirmesi sırasında bu terimlerin toplam sayısını 10 ile sınırlamak zorundadır. Bu sınır aşılırsa uygulama “permerror” sonucunu döndürmek zorundadır.
Teslim ettiklerimiz
- Alan adı adına e-posta gönderen tüm kaynakların envanteri
- Düzenlenmiş, sorgu sınırı içinde tek SPF kaydı
- Tüm meşru kaynaklar için hizalı DKIM imzası
- Aşamalı DMARC politikası: none, quarantine, reject
- Alt alan adları ve kullanılmayan alan adları için koruyucu kayıtlar
- DMARC rapor analizi ve dönem sonu özet raporu
Nasıl çalışıyoruz
- 1
Ücretsiz inceleme
Alan adlarınızın mevcut SPF, DKIM ve DMARC kayıtlarını kontrol eder, eksikleri ve riskleri yazılı olarak iletiriz.
- 2
İzleme modu
DMARC p=none ve raporlama adresiyle yayımlanır; e-posta akışı etkilenmeden raporlar toplanır.
- 3
Kaynakların düzeltilmesi
Raporlarda görülen her meşru gönderim kaynağı için SPF ve hizalı DKIM ayarlanır, gereksiz kaynaklar kayıttan çıkarılır.
- 4
Kademeli sıkılaştırma
Raporlar temiz geldikçe politika quarantine’e, ardından reject’e taşınır.
- 5
Takip
Yeni bir servis eklendiğinde kayıtlar güncellenir, raporlar belirli aralıklarla gözden geçirilir.
Sıkça sorulan sorular
DMARC kurulumu e-posta akışımızı keser mi?
Aşamalı yapıldığında hayır. İlk aşama p=none’dur ve hiçbir e-postayı etkilemez. Politikayı ancak raporlarda tüm meşru kaynakların geçtiğini gördükten sonra sıkılaştırıyoruz.
p=reject’e ulaşmak ne kadar sürer?
Gönderim kaynaklarının sayısına bağlıdır. Yalnızca Microsoft 365 ya da Google Workspace kullanan bir şirkette birkaç hafta yeterli olabilir. Birçok üçüncü taraf servisi olan şirketlerde süreç birkaç ay sürebilir.
Microsoft 365 ve Google Workspace ile uyumlu mu?
Evet. İki platform da SPF, DKIM ve DMARC’ı destekler. Kurulum, DNS kayıtlarının eklenmesi ve platform tarafında kendi alan adınızla DKIM imzalamanın açılmasından oluşur.
DMARC kimlik avı e-postalarını tamamen durdurur mu?
Hayır. Sizin alan adınızın birebir taklidini durdurur; benzer alan adlarından ya da ele geçirilmiş gerçek hesaplardan gelen e-postaları durdurmaz. Bu yüzden ödeme değişikliklerinin telefonla teyidi gibi süreç kontrolleri de gerekir.
Hiç e-posta göndermediğimiz alan adlarımız için ne yapmalıyız?
Bu alan adları saldırganlar için cazip hedeftir. Gönderim olmadığını belirten bir SPF kaydı ve p=reject politikalı bir DMARC kaydı yayımlıyoruz; böylece bu alan adlarıyla sahte gönderim yapılamaz.
DNS’imiz başka bir firmada, sorun olur mu?
Olmaz. DNS yönetim panelinize erişim verirseniz kayıtları biz ekleriz; erişim veremiyorsanız eklenecek kayıtları hazırlayıp DNS sağlayıcınıza ileteceğiniz biçimde teslim ederiz.
KVKK açısından e-posta güvenliği neden önemli?
KVKK’nın veri güvenliği rehberi, kişisel verilerin e-posta ile aktarımında yeterli tedbir alınmasını bekler. Sahte e-postayla kişisel veri ya da ödeme bilgisi talep edilmesi, sık karşılaşılan ihlal yollarından biridir. DMARC bu riski azaltan teknik tedbirlerden biridir.
Ücret nasıl belirleniyor?
Alan adı sayısına, gönderim kaynaklarının çeşitliliğine ve rapor takibinin süresine göre değişir. Mevcut kayıtlarınızı inceledikten sonra yazılı teklif veriyoruz; inceleme ücretsiz.
Kaynaklar ve resmi dokümanlar
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), Mayıs 2026
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- Google Workspace: Email sender guidelines
- Yahoo Sender Hub: Sender Best Practices
- Microsoft Learn: Set up DKIM to sign mail from your Microsoft 365 domain