DMARC kaydını ayarladınız, raporlar da geliyor, ancak p=none neden hiçbir e-postayı durdurmuyor ya da p=reject ile sitenizin iletişim formu neden aniden e-posta göndermiyor, bilmiyorsunuz. Sorun neredeyse her zaman bir etiketin değerinde, tüm kayıtta değil. Bu metin her etiket için kısa bir referanstır: izin verilen değer, gerçek etki ve e-postayı bozmadan geçilebilecek kombinasyon.
DMARC kaydı _dmarc.example.com üzerinde bir TXT kaydıdır ve v=DMARC1 ile başlar. Etiketlerin sırası önemli değildir, ancak v ilk olmalıdır. dig ile kontrol ediyorsanız:
dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"Çıktı boşsa, kayıt yoktur veya yanlış ada kaydedilmiştir. Yaygın bir hata, _dmarc.example.com yerine example.com üzerine kaydetmektir; hiçbir araç bunu görmez.
p etiketi: gerçekten uygulanan politika
Üç izin verilen değeri vardır: none, quarantine, reject. Bu etiket, alıcının hem SPF hem de DKIM'in başarısız olduğu bir e-postayla ne yapacağını belirler. none yalnızca rapor ver ve hiçbir şey yapma demektir; quarantine spam'e gönder demektir; reject hiç teslim etme demektir.
Daha az söylenen nokta: DMARC politikayı yalnızca her iki mekanizma da başarısız olduğunda uygular. SPF geçerse, DKIM başarısız olsa bile mesaj geçer. Yani p=reject, SPF doğru olduğu sürece sanıldığı kadar tehlikeli değildir.
Pratik geçiş sırası: iki ila dört hafta p=none üzerinde kalın, raporları okuyun, izin verilen kaynakları SPF ve DKIM'de sağlamlaştırın, sonra p=quarantine ve nihayet p=reject. E-postaların neden spam'e gittiğini bilmek istiyorsanız, spam sorununu giderme tam kılavuzu tam da bu zinciri açıyor.
rua ve ruf etiketleri: raporlar nereye gider
rua toplu rapor adresidir (günlük XML) ve ruf forensic rapordur (başarısız mesaj örneği). Her ikisi de mailto: ile başlar ve virgülle ayrılır. Pratik sınırlama: Gmail dahil birçok büyük alıcı ruf raporu göndermez. Yalnızca ruf'a güvenirseniz, kutunuz boş kalır ve kaydın çalışmadığını düşünürsünüz.
rua rapor hacmini hafife almayın. Günde birkaç bin e-posta alan bir alan adı için günlük XML dosyası birkaç megabayta ulaşır ve adresi kişisel kutuya koyarsanız, kutu kotası birkaç gün içinde dolar. E-posta kotası yönetimi, kutu dolduğunda ne olduğunu ve bunu nasıl önleyeceğinizi açıklar. Doğru yol, özel bir kutu veya bir DMARC analiz hizmetidir.
Burada hata yapıyorlar
rua adresini, DMARC'in kendisi için ayarlandığı alan adına koyuyorlar, o kutunun var olduğundan emin olmadan. Sonuç: raporlar sessizce çöpe atılır, hiçbir hata da görünmez. Belirtisi şudur: haftalarca rapor bekler ve asla gelmez, oysa kayıt tamamen geçerlidir.
pct, fo ve rf etiketleri
pct, politikanın uygulandığı mesajların yüzdesidir; izin verilen değer 0 ile 100 arasındadır. Varsayılan 100'dür. pct=25 koyarsanız, başarısız e-postaların yalnızca dörtte biri politikaya göre işlenir. Bu etiket kademeli geçiş için tasarlanmıştır, ancak pratikte güvenlikten çok kafa karışıklığına neden olur. Benim önerim: pct kullanmayın ve bunun yerine doğrudan p=none'dan p=reject'e geçin.
fo, forensic raporun hangi koşullarda gönderileceğini belirler: 0 (her ikisi başarısız), 1 (herhangi biri başarısız), d (DKIM başarısız), s (SPF başarısız). 1 değeri en çok raporu verir ve sorun giderme için faydalıdır. rf rapor biçimidir ve bugün yalnızca afrf anlam taşır; koymak isteğe bağlıdır.
adkim ve aspf etiketleri: katı mod
Her ikisi de r (relaxed, varsayılan) veya s (strict) değerini alır. adkim DKIM için ve aspf SPF içindir. Fark alan adı hizalamasındadır: relaxed modda alt alan adları da kabul edilir; strict modda yalnızca tam alan adı.
| Etiket | İzin verilen değer | Varsayılan | Pratik etki |
|---|---|---|---|
v | DMARC1 | Zorunlu | Kayıt sürümü; ilk olmalıdır |
p | none / quarantine / reject | — | Ana alan adı için politika |
sp | Aynı p değerleri | p ile aynı | Alt alan adları için ayrı politika |
rua | mailto: listesi | — | Günlük toplu rapor |
ruf | mailto: listesi | — | Forensic rapor; sınırlı destek |
pct | 0–100 | 100 | Politika uygulama yüzdesi |
adkim | r / s | r | DKIM hizalaması |
aspf | r / s | r | SPF hizalaması |
fo | 0 / 1 / d / s | 0 | Forensic rapor gönderme koşulu |
Strict modu yalnızca tüm gönderim kaynakları üzerinde tam kontrole sahip olduğunuzda seçin. Alt alan adı üzerinden gönderim yapan bir işlemsel e-posta hizmeti kullanıyorsanız, aspf=s e-postalarınızı sebepsiz yere reddeder. İşlemsel e-posta kılavuzu, paylaşımlı hosting'den göndermenin neden sorun yarattığını ve doğru alternatifin ne olduğunu açıklar.
sp etiketi ve alt alan adları yönetimi
sp koymazsanız, p değeri alt alan adları için de uygulanır. Bu varsayılan birçok kuruluşta felakettir: hiç e-posta göndermeyen bir alt alan adı aniden p=reject ile karşılaşır ve biri ondan gönderirse sessizce reddedilir.
İki yolunuz var. Ya sp=quarantine koyun ki alt alan adları daha yumuşak davransın, ya da kullanılmayan alt alan adları için p=reject ile ayrı kayıt koyun. İkinci yol daha güvenlidir ve unutulmuş alt alan adlarından sahtecilik yapılmasını engeller.
Güvenli başlangıç için kombinasyon
Bugün kaydı koyup yarın pişman olmak istemiyorsanız, bu satırı _dmarc.example.com üzerine kaydedin:
v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; adkim=r; aspf=rİki hafta raporları okuyun. Raporda fail olarak görünen her kaynak ya SPF'e eklenmeli ya da DKIM'i doğru almalıdır. Sonra p'yi quarantine ve nihayet reject olarak değiştirin. Tüm süreç genellikle bir ay sürer ve acele ederseniz, sitenin iletişim formu veya parola sıfırlama e-postası ilk kurban olur.
Araçlarla ilgili bir nokta: her değişiklikten önce MX ve SPF kaydını MX kaydı kontrolü ile kontrol edin ki gönderimin doğru yerden yapıldığından emin olun. Paylaşımlı hosting'de çalışıyorsanız ve kayıtlar üzerinde tam kontrolünüz yoksa, DNS'e tam erişimli Linux hosting bu yolu kolaylaştıran tam da o şeydir. Daha fazla teknik dokümantasyon da ServerNet bilgi bankası'nda mevcuttur.
p=reject'ten sonra dahili e-postaların bir kısmının reddedildiğini fark ederseniz, önce DMARC'i değil SPF'i kontrol edin. Yüz vakadan doksan dokuzunda sorun oradadır.
Sık sorulan sorular
DMARC kaydında p ile sp arasındaki fark nedir?
p ana alan adının politikasını belirler ve sp alt alan adlarının politikasını. sp koymazsanız, p değeri otomatik olarak alt alan adları için de uygulanır ki bu birçok durumda istenmeyen bir sonuçtur.
pct=50 güvenliği yarıya mı indirir?
Evet, tam olarak bunu yapar. pct=50 ile başarısız e-postaların yalnızca yarısı politikaya göre işlenir ve geri kalanı geçer. Kademeli geçiş için tasarlanmıştır, ancak pratikte önerilmez; doğrudan none'dan reject'e geçmek daha iyidir.
rua raporu neden gelmiyor?
Üç yaygın neden: kutu adresi yok, kayıt yanlış ada kaydedilmiş veya alıcı toplu rapor göndermiyor. Önce dig +short TXT _dmarc.example.com ile kaydın varlığını doğrulayın, sonra hedef kutunun varlığını.
DMARC, SPF ve DKIM'in yerini alır mı?
Hayır. DMARC, SPF ve DKIM üzerine biner ve onlar olmadan hiçbir şey yapmaz. SPF doğru ayarlanmamışsa, p=reject yalnızca sağlam e-postalarınızı da reddeder.