DMARC politikasını “kademeli” uygulamak neden önemlidir?
DMARC, alan adınızdan (domain) gönderildiği iddia edilen e-postaların gerçekten yetkili sistemlerden çıkıp çıkmadığını doğrulamak ve doğrulanamayanları nasıl ele alacağınıza karar vermek için kullanılan bir mekanizmadır. Birçok şirket DMARC’ı hızlıca “reject” seviyesine çekmek ister; ancak altyapıdaki gerçek gönderim kaynakları tam olarak görülmeden bu yapılırsa, meşru e-postaların teslim edilememesi gibi iş sonuçları doğurabilir.
Kademeli yaklaşımın amacı; önce görünürlük kazanmak, sonra kontrollü şekilde yaptırıma geçmek ve en sonunda sahteciliği pratikte engellerken operasyonel riskleri en aza indirmektir. Bu süreçte özellikle iki kavram çok işe yarar: p (policy) ve pct (percentage). p, politikanın seviyesini; pct ise bu politikanın ne kadarına uygulanacağını ifade eder.
DMARC politika seviyeleri: p=none, p=quarantine, p=reject
p=none: izleme ve öğrenme modu
p=none, e-posta alıcılarına “sadece raporla, engelleme/karantinaya alma uygulama” mesajı verir. Bu aşamada hedef; alan adınızdan e-posta gönderen tüm meşru kaynakları tespit etmektir. Özellikle şu tür kaynaklar gözden kaçabilir: pazarlama otomasyon araçları, CRM bildirimleri, fatura/ERP sistemleri, web sunucusu formları, helpdesk sistemleri, çok fonksiyonlu yazıcı/tarayıcılar, üçüncü taraf insan kaynakları platformları.
p=quarantine: kontrollü yaptırım
p=quarantine, DMARC doğrulamasını geçemeyen iletilerin “şüpheli” olarak işaretlenmesini önerir. Alıcı sistemler bunu spam klasörüne düşürme, uyarı ekleme veya farklı filtreleme davranışlarıyla uygulayabilir. Buradaki avantaj, “reject” kadar sert bir kesinti yaratmadan gerçek dünya etkisini görmenizi sağlamasıdır.
p=reject: sahte gönderimleri güçlü şekilde engelleme
p=reject, DMARC’ı geçemeyen iletilerin reddedilmesini önerir. Bu seviye, alan adınızın taklit edilmesini pratikte zorlaştırır. Ancak “kimin, nereden gönderdiğini” tam bilmeden reject’e geçmek, şirket içi ve dışı meşru e-postaların geri çevrilmesine yol açabilir. Bu yüzden reject genellikle en son adımdır.
pct parametresi nedir ve nasıl kullanılır?
pct, DMARC politikanızın yalnızca belirli bir yüzdelik dilime uygulanmasını sağlar. Örneğin p=quarantine; pct=20 kullanırsanız, DMARC’ı geçemeyen iletilerin yaklaşık %20’si karantinaya yönlendirilirken geri kalanları izlenmeye devam edebilir. Bu, politikayı “aniden” uygulamak yerine aşamalı yükseltmenize yardımcı olur.
pct kullanımında beklentiyi doğru ayarlamak gerekir: pct bir “garanti” değildir, her alıcı aynı şekilde uygulamayabilir ve yüzdeler yaklaşık davranış gösterir. Yine de büyük hacimli alan adlarında risk azaltmak için etkilidir.
Kademeli geçiş planı: pratik bir yol haritası
1) Envanter çıkarın: tüm gönderim kaynakları
İlk adım, şirketiniz adına e-posta gönderen tüm sistemlerin listesini çıkarmaktır. Bu liste yalnızca “kurumsal e-posta sunucusu” değildir; uygulamalar, üçüncü taraf hizmetler ve cihazlar da dahildir. Her kaynak için şu bilgileri not edin:
- Hangi domain/alt domain ile gönderiyor?
- Gönderim IP’leri veya SMTP çıkış sağlayıcısı nedir?
- From adresi hangi formatta? (ör. billing@, no-reply@, çalışan adresleri)
- SPF ve DKIM uygulanabiliyor mu?
2) p=none ile raporlama toplayın ve veriyi anlamlandırın
DMARC raporları (aggregate) size hangi kaynakların SPF/DKIM doğrulamasından geçtiğini, hangilerinin kaldığını gösterir. Bu aşamada kritik olan, “başarısız” görünen trafiğin gerçekten sahte mi yoksa yanlış yapılandırılmış meşru kaynak mı olduğunu ayırt etmektir.
Tipik sorun örnekleri: SPF kaydında eksik gönderenler, DKIM imzası olmayan üçüncü taraflar, From domain’i ile kullanılan DKIM domain’inin uyuşmaması, yönlendirmeler nedeniyle SPF’in bozulması.
3) SPF ve DKIM’i düzeltin, mümkünse iki tarafı da güçlendirin
Kademeli uygulama başarılı olacaksa, gönderim kaynaklarınızın mümkün olduğunca hem SPF hem DKIM tarafında “sağlıklı” olması gerekir. Pratik öneriler:
- SPF kaydınızı sade tutun ve gerçekten kullanılan kaynakları ekleyin.
- Üçüncü taraf bir sistem kullanıyorsanız, o sistemin önerdiği SPF mekanizmasını ve DKIM anahtarlarını uygulayın.
- DKIM anahtar yönetimini planlayın: hangi selector kullanılacak, anahtar rotasyonu nasıl yapılacak?
- Alt domain kullanımını düşünün: pazarlama trafiğini ayrı bir subdomain üzerinden yürütmek raporlama ve risk yönetimini kolaylaştırabilir.
4) p=quarantine’a geçin, pct ile başlayın
p=none aşamasında beklenmedik meşru kaynak kalmadığından emin olmaya başladığınızda, p=quarantine’a geçiş yapın. İlk aşamada düşük bir pct ile başlamak, örneğin 10–25 aralığında, gerçek dünya etkisini gözlemlemek için makuldür.
Bu aşamada izlemeniz gerekenler:
- Şikayetler: “mailim karşı tarafa düşmüyor” geri bildirimleri
- İş kritik iletiler: fatura, sipariş, parola sıfırlama, teklif gibi akışlar
- Raporlar: hâlâ DMARC fail görünen meşru kaynak var mı?
Problemleri düzelttikçe pct’yi 25 → 50 → 75 → 100 gibi aşamalarla yükseltebilirsiniz. Her yükseltmede belirli bir gözlem süresi bırakmak (örneğin birkaç gün ile birkaç hafta arası, trafik hacmine göre) daha güvenlidir.
5) p=reject’e kademeli geçin
quarantine aşamasında pct=100 seviyesinde stabil kaldıysanız ve raporlarda kalan başarısız trafiğin büyük bölümünün sahte/istenmeyen olduğundan eminseniz, p=reject’e geçiş planlanabilir. Burada da pct kullanarak önce sınırlı bir yüzdeyle başlayıp sonra artırmak, olası sürprizleri azaltır.
Geçiş sırasında sık yapılan hatalar
“Bir kaynak kaldı ama önemsiz” varsayımı
Önemsiz görünen bir kaynak, kritik bir iş akışını besliyor olabilir (ör. bir şubenin yazıcısı veya eski bir uygulama). p=reject’e geçmeden önce bu “küçük” kaynakların iş etkisini doğrulayın.
SPF’e aşırı yüklenmek
Her şeyi SPF’e eklemeye çalışmak yönetimi zorlaştırır ve teknik sınırlara yaklaşabilir. DKIM’i devreye almak ve gerekirse gönderimleri alt domain’lere ayırmak daha sürdürülebilir olabilir.
Alt domain’leri unutmak
example.com için DMARC uygulamanız, mail.example.com veya billing.example.com gibi alt domain davranışlarını ayrı değerlendirmeyi gerektirebilir. Politika tasarımını alt domain’leri de kapsayacak şekilde düşünün.
Operasyonel kontrol listesi
- Tüm gönderim kaynakları listelendi mi?
- Her kaynak için SPF ve DKIM sorumlusu belli mi?
- DMARC p=none raporları düzenli inceleniyor mu?
- Meşru kaynaklarda DMARC geçiş oranı hedefi belirlendi mi?
- p=quarantine ve pct artışı için takvim hazır mı?
- İş kritik e-posta akışları test edildi mi?
- p=reject’e geçiş için “hazır olma kriterleri” tanımlandı mı?
Sonuç: güvenlik ve teslim edilebilirliği birlikte optimize edin
DMARC’ı kademeli uygulamak, sahtecilik riskini azaltırken meşru e-postaların teslim edilebilirliğini korumanın en güvenli yollarından biridir. p=none ile görünürlük kazanıp, p=quarantine ve p=reject’e pct ile kontrollü geçiş yapmak; IT ekiplerinin raporlara dayanarak ilerlemesini sağlar.
Eğer kurumsal e-posta altyapınızı yönetirken alan adı doğrulama kayıtlarınızı (SPF, DKIM, DMARC) daha düzenli bir yapıda tutmak ve geçiş/migration dönemlerinde riskleri azaltmak istiyorsanız, MX1Mail gibi yönetilebilir bir iş e-postası platformunda DNS ve gönderim kaynaklarını envanter yaklaşımıyla ele almak işinizi kolaylaştırabilir.