DMARC nedir? Politikayı güvenle devreye alma

DMARC, görünen gönderici alan adının SPF veya DKIM doğrulamasıyla uyumunu değerlendirir ve başarısız mesajlara yönelik bir politika bildirir. Doğru kurulmadığında gerçek işletme mesajlarının da etkilenmesi mümkündür. Bu nedenle başlangıçta hangi sistemlerin alan adınızla e-posta gönderdiğini belirlemek, doğrudan en katı politikayı uygulamaktan daha sağlıklı bir yaklaşımdır.

Hizalama neden önemlidir?

Bir iletide SPF’nin başarılı olması, ekranda görünen From alan adının mutlaka doğrulandığı anlamına gelmez. Benzer şekilde DKIM imzası başka bir hizmetin alan adıyla başarılı olabilir. DMARC, bu doğrulamaların görünen gönderici alan adıyla belirli kurallar çerçevesinde hizalanmasını ister. Uygun biçimde hizalanmış SPF veya DKIM’den en az birinin başarılı olması temel değerlendirmede yeterli olabilir; ikisinin mutlaka aynı anda başarılı olması gerektiğini varsaymayın.

Bu ayrım özellikle pazarlama platformu, CRM ve işlem e-postası hizmeti kullanan işletmelerde önem taşır. Her sistemin kurulum ekranında “doğrulandı” yazması tek başına tüm mesajların DMARC’den geçtiğini göstermeyebilir. Gerçek gönderilen iletilerin başlıkları ve raporlar birlikte incelenmelidir.

Politika seçeneklerini anlayın

p=none, izleme odaklı bir başlangıç politikasıdır. quarantine, başarısız iletilerin daha sıkı değerlendirilmesini ister; reject ise reddetme talebini bildirir. Alıcı sistemlerin kendi politikaları da devrededir. Bu değerleri yalnız daha güvenli görünen kelimeye göre seçmeyin. Hazır olmayan bir gönderim akışını katı politika altında bırakmak meşru mesajların teslimini etkileyebilir.

Aşamalı uygulama planı

1. Gönderim kaynaklarını çıkarın. Personel postası, formlar, bildirimler, bültenler ve dış uygulamalar için ayrı satır oluşturun. Unutulan bir hizmet, politika sıkılaştırıldığında ilk etkilenen kaynak olabilir.
2. SPF ve DKIM’i doğrulayın. Her hizmetten test mesajı gönderin. Sonucu ve kullanılan alan adlarını inceleyerek hizalama sorunlarını belirleyin.
3. Rapor kabul edecek adresi hazırlayın. Toplu raporlar teknik veriler içerir ve yüksek hacimde gelebilir. Gerçekten yönettiğiniz bir rapor adresi veya yetkilendirilmiş hizmet kullanın.
4. İzlemeyle başlayın. DNS’te _dmarc adı altındaki politikayı sağlayıcınızın önerisine göre yayınlayın. Aynı ad altında birbiriyle çelişen birden fazla politika oluşturmamaya dikkat edin.
5. Raporlara göre sıkılaştırın. Meşru gönderimlerin durumunu gördükten sonra karantina veya ret politikasını planlayın. Değişikliğin etkisini zaman damgalı testlerle takip edin.

Örnek kayıt nasıl okunur?

v=DMARC1; p=none; rua=mailto:[email protected] yalnız açıklama amaçlı bir örnektir. Canlı kullanımda kendi alan adınızı ve gerçekten rapor kabul eden adresinizi kullanmanız gerekir. Harici bir rapor alan adına gönderim yapılacaksa ek yetkilendirme gerekebilir. Örneği anlamadan doğrudan yayınlamayın ve mevcut çalışan kaydın üzerine plansız yazmayın.

Raporlarda gördüğünüz her yabancı IP mutlaka kötüye kullanım değildir; unutulmuş bir hizmet veya yönlendirme akışı da olabilir. Kaynağı tanımlamadan izin kapsamını genişletmeyin. Amaç bütün trafiği başarılı göstermek değil, meşru kaynakları doğru doğrulamak ve yetkisiz kullanımı ayırt etmektir.

Sık sorulan sorular

DMARC spam sorununu tek başına çözer mi? Hayır. Kimlik doğrulamasını güçlendirir; içerik, itibar ve alıcı davranışları da teslimatı etkiler.

Rapor geldiyse kurulum tamam mı? Rapor almak, mesaj akışlarının doğru hizalandığını göstermez. İçeriği ve gerçek test mesajlarını değerlendirin.

Politikayı ne zaman reject yapmalıyım? Bütün meşru gönderim kaynaklarını doğruladığınız ve etkisini izleyebildiğiniz bir geçiş planına göre karar verin; evrensel bir süre varsaymayın.

İlgili teknik kaynak

• Google Workspace: Önerilen DMARC geçişi