DMARC, görünür From alan adının SPF veya DKIM ile doğrulanan alan adıyla uyumunu değerlendirir ve alıcıya başarısız mesajlar için yayımlanmış politikayı bildirir. Amaç, alan adınızın taklit edilmesini azaltırken meşru gönderim akışını korumaktır. Bir kayıt ekleyip hemen p=reject kullanmak, unutulmuş fatura veya web formu mesajlarının reddedilmesine yol açabilir. Bu nedenle DMARC geçişini tek DNS değişikliği olarak değil, gönderim envanteri ve rapor incelemesiyle ilerleyen bir çalışma olarak planlayın.
Önce SPF ve DKIM'i doğrulayın
İş kutuları dışında mesaj gönderen muhasebe, destek, CRM ve pazarlama sistemlerini listeleyin. Her kaynaktan gerçek bir test göndererek SPF ve DKIM sonuçlarını inceleyin. Yalnızca bir imzanın geçmesi yeterli olmayabilir; doğrulanan alan adının görünür gönderici alan adıyla uyumlu olması gerekir. Başkasına ait varsayılan imza alan adı üzerinden DKIM geçmesi, işletmenizin From alan adıyla otomatik uyum sağladığı anlamına gelmez. Yönlendirme ve liste hizmetlerini ayrıca test edin.
Kademeli uygulama planı
- Alan adının yetkili DNS sağlayıcısında mevcut
_dmarckaydını kontrol edin ve varsa kopyasını saklayın. Aynı ad için çakışan politikalar oluşturmayın. İlk aşamada uygulama zorlamayanp=nonepolitikasıyla rapor toplanabilir. Örnek olarakv=DMARC1; p=none; rua=mailto:[email protected]biçimi kullanılır; bu adresi gerçek, yönetilen rapor adresinizle değiştirin. Örnek metin doğrudan herkes için doğru nihai politika değildir. - Rapor alacak adresin çalıştığını ve raporları işleyecek kişinin belirlendiğini doğrulayın. Raporlar çoğunlukla makine tarafından okunacak XML verileri taşır ve gönderen IP ile doğrulama özetleri içerebilir. Raporları rastgele dış servise iletmeden kuruluşunuzun veri işleme tercihlerini değerlendirin. Farklı alan adına rapor gönderilecekse gerekli dış hedef yetkilendirmesini sağlayıcınızın belgelerinden kontrol edin. Rapor gelmemesi her kaynağın başarılı olduğu anlamına gelmez.
- Normal iş günlerini ve seyrek kullanılan araçları kapsayacak şekilde gözlem yapın. Haftalık bülten veya aylık fatura akışı bir günlük testte görünmeyebilir. Hatalı kaynakların gerçekten kurumunuza ait olup olmadığını ayırın; meşru bir sistemi düzeltmek ile taklit göndericiye izin vermek farklıdır. Her kaynak için görünür From, SPF alan adı, DKIM alan adı ve gönderim hizmetini eşleştirin. Değişiklikleri sorumlu kişi ve tarihle kaydedin.
- Meşru akışlarda sorun kalmadığında karantina veya reddetme politikasına kontrollü geçin. Sağlayıcının desteklediği kademeli uygulama seçenekleri değerlendirilebilir; ancak her alıcının politikayı aynı biçimde uygulayacağını varsaymayın. Politika değiştikten sonra yeni testler yapın, raporları ve kullanıcıların teslim şikâyetlerini izleyin. Son aşamada daha katı uygulama hedeflenirken geri dönüş planınız ve önceki kayıt değeriniz hazır bulunmalıdır.
Değişiklik sonrası doğrulama
DNS'te doğru politikayı sorgulayın ve her gönderim kaynağından alınan yeni iletinin özgün başlıklarını kontrol edin. dmarc=pass sonucunu hangi doğrulama yolunun sağladığını not edin. Yalnızca e-posta istemcisindeki gelen kutusuna bakmak yeterli değildir; alıcı kendi spam ve itibar politikalarını da uygular. Başarılı bir DMARC sonucu tüm iletilerin teslim garantisi değildir. Raporlarda başarısız görünen kaynağı bulduğunuzda tek bir alan adının kaydını gevşetmek yerine gerçek kimlik uyumunu düzeltin.
Hatalı politika risklerini ayırın
From alan adıyla ilgisiz DKIM imzası, unutulmuş üçüncü taraf gönderici veya aktarım sırasında değiştirilen mesajlar farklı hata nedenleridir. Bir kaynağın yetkili olduğuna yalnızca alan adınıza benzer görünmesinden karar vermeyin. Alt alanların kendi DMARC kayıtları ve ana alan politikasından etkilenme biçimi de tasarımda önemlidir. Teslim sorunu başladıysa önce hangi değişiklikten sonra hangi kaynakların etkilendiğini belirleyin; parolaları değiştirmek DNS politikasındaki sorunu çözmez.
p=none alan adı taklidini engeller mi?
Bu politika alıcıya zorunlu karantina veya reddetme talimatı vermez; gözlem ve rapor toplama aşaması için kullanılır. Taklit riskini azaltmak için meşru kaynaklar düzeltildikten sonra uygun uygulama politikasına geçiş değerlendirilir.
SPF ve DKIM'in ikisi de geçmek zorunda mı?
DMARC açısından uyumlu SPF veya uyumlu DKIM yolunun başarılı olması yeterli olabilir. Buna rağmen iki yöntemi de düzgün kurmak aktarım senaryolarında dayanıklılık sağlar. Doğrulama sonucu ile alan adı uyumunu ayrı kontrol edin.
Resmi kaynaklar
Süreç özeti
DMARC politikasını kademeli devreye alma
| Adım | Kontrol |
|---|---|
| 1 | Gönderim envanteri |
| 2 | Uyumlu SPF/DKIM |
| 3 | Rapor izleme |
| 4 | Kontrollü politika |