DMARC'ı açtınız. Bir rehber söylediği için kayda bir rua= etiketi koydunuz. Ve şimdi, her gün, gelen kutunuz Google, Microsoft, Yahoo'dan ve hiç duymadığınız değişken bir sağlayıcı grubundan küçük bir yığın e-posta alıyor, her biri google.com!yourdomain.com!1736899200!1736985600!17482910384.xml.gz gibi bir dosya adına sahip gzip'li bir XML eki taşıyor.
Kimse bunları açmıyor. DMARC benimsemesinin dürüst gerçeği bu — çok sayıda alan adı yıllarca p=none'da oturmuş, kimsenin hiç okumadığı raporları itaatkâr bir şekilde alıyor, bu da tam olarak sıfır fayda ve tüm gürültüyü aldıkları anlamına geliyor.
Raporlar aslında okunması zor değil. Sadece bakması nahoş. İşte içinde ne olduğu, gerçekte neyin önemli olduğu ve birinden yaklaşık on dakikada gerçek bir yanıt nasıl alınacağı.
Bir DMARC raporu nedir, ve ne değildir
Bir DMARC toplu raporu, alıcı bir posta sağlayıcısının size şunu söylemesidir: "İşte bugün gördüğüm, alan adınızdan olduğunu iddia eden her mesaj, onu gönderen IP'ye göre gruplanmış, ve işte her birinin kimlik doğrulamasını geçip geçmediği."
Hepsi bu. Bir alıcının bakış açısından, sizin adınıza kimin posta gönderdiğine dair günlük bir sayım.
Kasıtlı olarak olmadığı bazı şeyler:
- Mesaj başına değildir. Mesajlar gruplanır ve sayılır. "Bu IP'den 42 mesaj, hepsi geçti" alırsınız — 42 ayrı kayıt değil.
- Mesaj içeriği içermez. Konu yok, gövde yok, alıcı yok. Bu, gizlilik için kasıtlıdır. (Mesaj detaylarını içeren,
ruf=etiketi aracılığıyla adli raporlar adında ayrı bir mekanizma var — ama artık neredeyse kimse bunları göndermiyor, yine gizlilik nedenleriyle.ruf=ayarlarsanız ve hiçbir şey almazsanız, nedeni budur. Beklemeyin.) - Bir teslimat raporu değildir. Postanın gelen kutusuna mı yoksa spam'e mi düştüğünü söylemez. Sadece kimlik doğrulama hakkında bilgi verir.
- Tek bir alıcının görüşüdür. Google'ın raporu Gmail adreslerine gönderilen postayı kapsar. Microsoft'unki Outlook'u kapsar. Tüm resmi görmek için birkaçını okumanız gerekir, ve hacim aralarında büyük ölçüde değişir.
Raporlar varsayılan olarak günlük gelir — aralık, DMARC kaydınızdaki ri= etiketiyle kontrol edilir, ve 86400 saniye (bir gün) hem varsayılan hem de, gerçekçi olarak, herkesin uyduğu tek değerdir.
XML'in anatomisi
Birini açın ve üç anlamlı bölüm bulacaksınız. Gerisini atlayın.
<report_metadata> — raporu kim gönderdi ve hangi zaman aralığını kapsıyor. Sadece yönelim için yararlı. Hangi bakış açısını okuduğunuzu bilmek için org_name'e dikkat edin.
<policy_published> — bu, alıcının anladığı şekliyle sizin kendi DMARC kaydınızdır. Bir bakışa değer, çünkü gerçekte neyin yayında olduğunu doğrular:
<policy_published>
<domain>yourdomain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>p politikanızdır (none, quarantine veya reject). sp alt alan adları için politikadır. pct, başarısız postanın gerçekte yüzde kaçının politikaya tabi olduğudur — aşamalı devreye almalar için yararlıdır ve "neden sadece bir kısmı karantinaya alındı" sorusunun yaygın bir kaynağıdır.
adkim ve aspf hizalama modlarıdır, ve göründüklerinden daha önemlidirler. r gevşek anlamına gelir: bir alt alan adı organizasyonel alan adıyla hizalı sayılır, bu yüzden bounce.yourdomain.com, yourdomain.com ile hizalanır. s katı anlamına gelir: tam olarak eşleşmelidir, ve aynı alt alan adı artık başarısız olur. Birisi bunu anlamadan hizalamayı katı olarak ayarladıysa, genellikle postanın başarısız olmaya başlamasının tüm nedeni budur.
<record> — gerçek veri, gönderme kaynağı başına bir blok. Burada olmanızın nedeni budur.
Tüm rapordaki en önemli şey
Her <record>, aynı mesaj hakkında iki farklı karar içerir, ve bunları karıştırmak bu raporları yanlış okumanın bir numaralı nedenidir.
<record>
<row>
<source_ip>203.0.113.5</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>yourdomain.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>mailservice.example</domain>
<selector>s1</selector>
<r>pass</r>
</dkim>
<spf>
<domain>bounce.mailservice.example</domain>
<r>pass</r>
</spf>
</auth_results>
</record>Dikkatlice okuyun. auth_results SPF'nin geçtiğini ve DKIM'in geçtiğini söylüyor. policy_evaluated ikisinin de başarısız olduğunu söylüyor.
İkisi de doğru. Farklı sorulara yanıt veriyorlar.
auth_results ham sonuçtur — SPF kontrolü geçti mi, DKIM imzası doğrulandı mı. Bu durumda evet, ikisi de geçti, çünkü gönderen hizmet kendi alan adında doğru şekilde yapılandırılmış.
policy_evaluated hizalamadan sonraki sonuçtur — geçen alan adı, görünen From başlığındaki alan adıyla eşleşti mi. Burada eşleşmedi: DKIM mailservice.example olarak imzaladı, SPF bounce.mailservice.example'ı yetkilendirdi, ama mesaj yourdomain.com'dan olduğunu iddia etti. Her şey mükemmel şekilde kimlik doğrulandı -- yanlış alan adı için.
Bu klasik üçüncü taraf gönderen sorunudur. Pazarlama platformunuz, yardım masanız veya faturalama aracınız sizin "adınıza" posta gönderir, kendi alan adıyla imzalar, ve DMARC doğru bir şekilde şunu söyler: burada hiçbir şey yourdomain.com'un bunu yetkilendirdiğini kanıtlamıyor.
policy_evaluated, postanıza ne olacağına karar veren şeydir. Raporları tararken, okunacak alan budur. auth_results, neden'in bağlamıdır.
Bu özel desen için düzeltme neredeyse her zaman özel DKIM imzalamadır — üçüncü taraf hizmeti, varsayılan paylaşılan anahtarı yerine sizin alan adınız altında yayınlanan bir anahtarla, kendi DNS'inize eklediğiniz bir seçici kullanarak imzalamaya yapılandırmak. Çoğu ciddi sağlayıcı bunu destekler; genellikle ayarlarda "DKIM kimlik doğrulaması" veya "özel alan adı imzalama" olarak gizlenmiştir. Bunu yaptıktan sonra, alan adınız için yayınlanan kayıtları kontrol etmek, seçicinin gerçekten DNS'te yayında olduğunu doğrular — bu, en sık atlanan adımdır: hizmet "yapılandırıldı" der, DNS aksini söyler, ve raporlar başarısız olmaya devam eder.
Gerçekten işe yarayan on dakikalık bir iş akışı
XML'i baştan sona okumayı unutun. Bunun yerine şunu yapın:
1. Her kaydı source_ip'ye göre gruplandırın. Tüm alıcılardan gelen tüm raporlarda. Genellikle beş ile otuz arası farklı IP ile sonuçlanırsınız.
2. Her IP için tek bir soru sorun: bunu tanıyor muyum? Posta sunucunuz, Google Workspace'iniz, CRM'iniz, faturalama sisteminiz. Tanımadığınız her şeyi arayın — IP üzerinde bir WHOIS veya ASN sorgusu genellikle hizmeti hemen adlandırır, ve çoğu "gizemli" IP, şirketteki birinin kaydolduğu bir SaaS ürünü olduğu ortaya çıkar.
3. policy_evaluated ile çapraz referans verin. Dört olası kombinasyon var, ve her biri tamamen farklı bir şey ifade ediyor:
- Tanınan IP, hizalı geçiş — bu kaynak doğru yapılandırılmış. Yapılacak bir şey yok.
- Tanınan IP, başarısız — hizalı olmayan meşru bir hizmet. Bu sizin iş listenizdir. Bunların her biri
p=reject'e geçtiğiniz anda postası reddedilecektir. - Bilinmeyen IP, başarısız — neredeyse her zaman sahtecilik. Bu, DMARC işini yapıyor. Hiçbir eylem gerekmiyor; onu açmanızın nedeni bu.
- Bilinmeyen IP, hizalı geçiş — ilginç olan. Tanımadığınız bir şey, alan adınız olarak başarıyla kimlik doğrulanıyor. Bu, DNS'inizde bir yerde meşru olarak yetkilendirildiği ve unuttuğunuz anlamına gelir. Genellikle gölge BT: bir departman bir araca kaydoldu, biri iki yıl önce bir SPF include ekledi, ve hâlâ orada. Araştırmaya değer, çünkü aynı zamanda ele geçirilmiş ama yetkilendirilmiş bir gönderenin de nasıl göründüğüdür.
4. Sadece ikinci kategoriyi düzeltin. Tanınan-ama-başarısız. Sizinle zorlama arasında duran liste budur.
Sizin hatanız olmayan iki başarısızlık
İki desen raporlarınızda sorun gibi görünecek ama olağan anlamda düzeltilebilir değildir, ve bunları bilmek çok fazla boşa harcanan çabayı kurtarır.
İletme SPF'yi bozar. Birisi mesajınızı bir adresten diğerine otomatik olarak ilettiğinde, ileten sunucu gönderen olur. SPF kaydınız onu listelemez, bu yüzden SPF son varış noktasında başarısız olur. Hiçbir şey yanlış yapılandırılmamıştır — bu, iletme ve SPF'nin nasıl etkileşime girdiğidir. DKIM genellikle iletmeyi sağlam geçirir, ve çalışan DKIM'in bu kadar önemli olmasının nedeni tam olarak budur: SPF kaçınılmaz olarak başarısız olduğunda iletilen postayı kimlik doğrulamalı tutan şey budur.
Posta listeleri DKIM'i bozar. Listeler sıklıkla mesajları değiştirir — bir alt bilgi ekler, konuyu bir [Liste Adı] etiketiyle yeniden yazar. Herhangi bir gövde veya imzalı başlık değişikliği DKIM imzasını geçersiz kılar. Yukarıdaki iletme sorunuyla birleştiğinde, posta listesi trafiği genellikle her iki kontrolü de başarısız olur.
Bunu düzeltmek için tasarlanmış bir mekanizma var (ARC — Authenticated Received Chain), burada aracılar mesajı değiştirmeden önce gözlemledikleri kimlik doğrulama sonuçlarına kefil olur. Destek gerçek ama tutarsızdır. Pratikte: raporlarınızda iletme kaynaklı bir başarısızlık taban çizgisi bekleyin, bunları desene göre tanımlayın, ve onları yapılandırma hataları olarak kovalamayın.
Onları elle okumayı ne zaman bırakmalısınız
Elle okuma, ilk temizlik için gayet iyi çalışır — gönderme kaynaklarınızı bulun, hizalamayı düzeltin, temiz bir taban çizgisine ulaşın. Bu sonlu bir iştir, genellikle birkaç hafta.
Bundan sonra, değer izlemeye kayar: yeni bozulan bir kaynağı veya başlayan bir sahtecilik kampanyasını yakalamak. Bu, insanların kötü, araçların iyi olduğu sürekli, düşük sinyalli bir görevdir. Herhangi bir sayıda DMARC rapor toplayıcısı XML'i ayrıştırır, kaynağa göre gruplandırır ve değişikliklerde sizi uyarır.
Ama önce elle geçişi yapın. Bir avuç ham raporu elle okumak, kendi posta akışınızı gerçekten anlamanın en hızlı yoludur — ve var olduğunu unuttuğunuz gönderme kaynakları bulacaksınız, ki bu tek başına on dakikaya değer.
Politikayı kurarken veya ayarlarken, bir DMARC kayıt oluşturucu etiket sözdizimini halleder ve gerçekten önemli olan karara odaklanmanıza izin verir: raporlarınız, p=none'ı geçmeden önce her meşru kaynağın temiz bir şekilde hizalandığını gösteriyor mu.