DMARC toplu raporları nasıl okunur

Raporları nasıl alırsınız

DMARC kaydınıza mailto adresi içeren bir rua etiketi ekleyin. Raporlamayı destekleyen alıcı sunucular bundan sonra, her raporlayan kuruluş için günde bir rapor gönderir. Rapor, o dönemde domaininizden gördükleri e-postayı kapsar. Raporlar genellikle kayıt yayınlandıktan sonraki bir iki gün içinde gelmeye başlar.

Rapor adresi, hakkında rapor verilen domainden farklı bir domaindeyse, o diğer domainin bir yetkilendirme kaydı yayınlaması gerekir. Aksi halde alıcı sunucular raporları göndermez.

Bir raporun içinde ne var

Her raporun üç bölümü vardır. Üst veri, raporlayan kuruluşu ve tarih aralığını belirtir. Yayınlanan politika bölümü, alıcı sunucunun gördüğü DMARC kaydını yineler. Kayıtlar bölümü işe yarayan kısımdır: gönderen IP adresi ile kimlik doğrulama sonucunun her bileşimi için bir satır içerir.

1. source_ip: e-postanın geldiği adres.
2. count: o satırın kaç iletiyi temsil ettiği.
3. policy_evaluated: uygulanan işlem (none, quarantine ya da reject) ve DKIM ile SPF'nin hizalı olarak geçip geçmediği.
4. header_from: görünen From adresindeki domain.
5. auth_results: hangi domainin imzaladığı ya da denetlendiği dahil, ham DKIM ve SPF sonuçları.

Bir satırı okumak

Önce policy_evaluated bölümünü okuyun. DKIM ya da SPF'den biri geçmişse ve From domainiyle hizalıysa ileti DMARC'tan geçer. İkisinin de başarısız olması, iletinin DMARC'tan geçemediği anlamına gelir.

Ardından nedenini görmek için auth_results bölümünü kullanın. Sık rastlanan bir örüntü, auth_results içinde DKIM pass, policy_evaluated içinde ise DKIM fail görünmesidir: ileti imzalanmıştır, ama sizin domaininizle değil sağlayıcının domainiyle, dolayısıyla hizalı değildir. Bu, sağlayıcı tarafında yapılacak bir yapılandırma işidir ve genellikle özel bir imzalama domaininin etkinleştirilmesi anlamına gelir.

Her göndereni bulmak

Satırları kaynağa göre gruplayın ve hacme bakın. Tanıdığınız ve doğrulamadan geçen kaynaklar için yapılacak bir şey yoktur. Tanıdığınız ama başarısız olan kaynaklar iş listenizdir: her biri, uygulayan bir politika altında engellenecek meşru bir sistemdir.

Tanımadığınız kaynaklar kendiliğinden kötüye kullanım anlamına gelmez. İletme SPF'yi bozar ve çoğu zaman ilgisiz bir posta sunucusundan gelen başarısız e-posta olarak görünür. Unutulmuş bir iç sistem de tıpkı bilinmeyen bir gönderen gibi görünür. Denetleyene kadar bilinmeyeni bilinmeyen olarak ele alın.

Raporlar size neyi söyleyemez

Toplu raporlar ileti içeriği, konu satırı ya da alıcı adresi içermez. Yalnızca rapor gönderen alıcı sunucuları kapsarlar, dolayısıyla toplamlar e-postanızın tamamı değil, bir örneklemdir. Ayrıca bir gün ya da daha fazla gecikmeyle gelirler.

ruf etiketiyle istenen hata raporları tek tek iletileri içerirdi, ancak büyük alıcı sunucuların çoğu gizlilik nedeniyle artık bunları göndermiyor.

Raporları politikayı sıkılaştırmak için kullanmak

p=none politikasından quarantine ya da reject politikasına geçme kararı raporlara dayanmalıdır. Geriye kalan başarısız satırlar yalnızca yetkilendirmemeye karar verdiğiniz kaynaklardan oluşuyorsa politika sıkılaştırılabilir. CloudSpex raporları alır, kaynağa göre gruplar ve ölçülen iletilerden kaçının daha sıkı bir politikadan etkilenmiş olacağını gösterebilir. Bunu yaparken değişikliğin güvenli olduğunu iddia etmez.

Eksiksiz bir kayıt, açıklamalı

Raporlar, konusu raporlayan kuruluşu ve domaininizi belirten bir e-postaya eklenmiş, genellikle sıkıştırılmış bir XML dosyası olarak gelir. İçinde okumaya değer kısım record öğelerinin listesidir. Aşağıda bir kayıt gösterilmiştir. Devamındaki yöntemde anlatılan her şey bu alanlara atıfta bulunur.

<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>mailer.example.net</domain><selector>k1</selector><result>pass</result></dkim>
    <spf><domain>example.com</domain><result>pass</result></spf>
  </auth_results>
</record>

O kaydı okumak

203.0.113.25 adresinden, example.com'dan geldiğini öne süren kırk iki ileti gelmiştir. policy_evaluated bloğu DMARC kararıdır: SPF hizalı olarak geçmiş, DKIM geçmemiştir. Hizalı tek bir geçiş yeterli olduğundan bu iletiler DMARC'tan geçmiştir ve uygulanan işlem none olmuştur.

auth_results bloğu DKIM satırını açıklar. İletiler imzalanmış ve imza doğrulanmıştır, ancak imzalama domaini example.com değil mailer.example.net olmuştur. İmza geçerlidir ama hizalı değildir. Bu gönderen şu anda yalnızca SPF'ye bağlıdır. E-postalarından biri iletilirse SPF başarısız olur ve DMARC'tan geçecek hiçbir şey kalmaz. Yapılacak iş, o serviste özel bir DKIM domaini etkinleştirmektir.

Göreceğiniz beş örüntü

Bir rapordaki hemen her satır az sayıdaki örüntüden birine girer ve her birinin standart bir karşılığı vardır.

1. İkisi de hizalı olarak geçiyor: doğru yapılandırılmış bir gönderen. Yapılacak bir şey yok.
2. SPF hizalı, DKIM başka bir domainle imzalanmış: çalışır ama kırılgandır. Serviste özel DKIM imzalamayı etkinleştirin.
3. DKIM hizalı, SPF başarısız ya da hizalı değil: DMARC açısından sorun yok. Servis kendi dönüş yolunu kullanıyor, bu normaldir.
4. İkisi de başarısız, tanıdığınız bir kaynaktan: uygulayan bir politika altında engellenecek meşru bir sistem. Sıkılaştırmadan önce düzeltin.
5. İkisi de başarısız, tanımadığınız bir kaynaktan, az sayıda: genellikle iletme ya da sahtecilik. Karar vermeden önce kaynağı belirleyin.

Bilinmeyen bir kaynağı belirlemek

Rapor bir şirket adı değil, bir IP adresi verir. Göndereni genellikle üç sorgu ortaya çıkarır. Adresin ters DNS adı çoğu zaman sağlayıcıyı doğrudan belirtir. Bir WHOIS sorgusuyla bulunan adres aralığının sahibi ağı belirtir. auth_results içindeki domainler de iletilerin hangi SPF domainini ve DKIM imzalama domainini taşıdığını gösterir. Bu, adres göstermese bile çoğu zaman servisi ortaya koyar.

Satırdaki DKIM domaini büyük bir e-posta sağlayıcısına aitse ve SPF başarısız olmuşsa, ileti büyük olasılıkla iletilmiştir: biri e-postanızı bir adreste alıyor ve başka bir adrese iletiyordur. Bu meşrudur ve e-postanızın iletmeden sağ çıkması için DKIM ile imzalandığından emin olmak dışında yapabileceğiniz bir şey yoktur.

dig -x 203.0.113.25 +short
whois 203.0.113.25 | grep -i -E 'orgname|netname|descr'

Haftalık gözden geçirme

Raporlar tek tek dosya olarak değil, eğilim olarak işe yarar. Çoğu domain için kısa bir haftalık gözden geçirme yeterlidir.

1. Haftanın bütün raporlarında kaynak başına iletileri toplayın.
2. Hacme göre sıralayın ve önce en büyük başarısız kaynaklara bakın.
3. Her kaynağı size ait, bilinen üçüncü taraf, iletme ya da bilinmeyen olarak işaretleyin.
4. Başarısız olan her meşru kaynak için, o serviste SPF ya da DKIM hizalamasını düzeltecek bir görev açın.
5. Bu hafta yeni olan her kaynağı not edin.
6. Genel geçme oranını geçen haftayla karşılaştırın. Ani bir düşüş genellikle bozuk bir kayıt ya da yenilenmiş bir anahtar anlamına gelir.

Toplamlar neden kendi rakamlarınızla hiç örtüşmez

Raporlardaki ileti sayıları, gönderdiğiniz ileti sayısına eşit olmaz. Yalnızca raporlamayı destekleyen alıcı sunucular rapor gönderir, her biri yalnızca kendi aldığı e-postayı raporlar, daha küçük sağlayıcılar ve kurumsal posta sistemleri ise çoğu zaman hiç rapor göndermez. Raporlar, büyük e-posta sağlayıcılarına doğru ağırlıklı geniş bir örneklemdir.

Sayılar ayrıca raporlayan kuruluşun kendi saat dilimine göre gün bazında gruplanır ve raporlar bir iki gün geç gelebilir. Bu yüzden bir haftalık rapor, takvim haftasıyla tam olarak örtüşmez. Raporları hacim denetimi olarak değil, kaynakları karşılaştırmak ve eğilimleri izlemek için kullanın.

Raporları başka bir domaine göndermek

rua adresi, hakkında rapor verilen domainden farklı bir domaindeyse, örneğin bir izleme servisinde ya da birkaç domain için ortak bir posta kutusundaysa, alıcı domainin raporları kabul ettiğini belirten bir kayıt yayınlaması gerekir. Bu kayıt olmadan raporlayan kuruluşların raporları göndermemesi beklenir ve sonuç, hiç rapor üretmeyen geçerli bir DMARC kaydı olur.

Kayıt, hedef domainde bulunan ve hakkında rapor verilen domainin adını taşıyan bir TXT kaydıdır. Joker karakter, herhangi bir domain için raporları yetkilendirebilir.

_dmarc.example.com.                       TXT  "v=DMARC1; p=none; rua=mailto:reports@example.net"
example.com._report._dmarc.example.net.   TXT  "v=DMARC1"

Hacim sorunu

Orta düzeyde e-posta hacmi olan bir domain günde onlarca rapor alır ve her biri farklı bir biçim tuhaflığı taşıyan sıkıştırılmış bir XML dosyasıdır. Bunları elle okumak bir hafta işe yarar. Sonra posta kutusu dolar, kimse açmaz ve kimse sıkılaştıracak kadar emin olmadığı için domain süresiz olarak p=none politikasında kalır.

Raporları, onları ayrıştıran bir araca göndermenin pratik nedeni budur. İşe yarayan çıktı tek tek raporlar değil, bütündür: hacim, geçme oranları ve ilk görülme tarihiyle birlikte bir kaynak listesi. Her durumda rua için ayrılmış bir posta kutusu ya da adres kullanın, asla bir kişinin gelen kutusunu değil.

Raporlardan karara

Raporların yanıtlamak için var olduğu soru, politikayı sıkılaştırmanın meşru e-postayı engelleyip engellemeyeceğidir. Bu soru doğrudan yanıtlanabilir: dönem içinde DMARC'tan geçemeyen iletileri alın ve hangi kaynaklardan geldiklerine bakın. Başarısız olan her kaynak düzeltilmişse, bilerek yetkilendirilmemişse ya da kabul ettiğiniz düzeyde bir iletmeyse politika yükseltilebilir.

Bir çekinceyi göz önünde tutun. Raporlar, rapor gönderen alıcı sunucuların o dönemde gördüğü e-postayı anlatır. Üç ayda bir çalışan ya da yalnızca rapor göndermeyen sağlayıcılardaki alıcılara e-posta atan bir gönderen raporlarda görünmez. CloudSpex ölçülen iletileri kaynağa göre gruplar ve kaçının daha sıkı bir politikadan etkilenmiş olacağını gösterir. Bunun gözlemlenen e-postanın bir sayımı olduğunu, görmediği e-posta hakkında bir güvence olmadığını da belirtir.