DMARC toplu raporları nasıl okunur?

Toplu raporlar nedir?

DMARC kaydınız rua=mailto:... etiketini içerdiğinde, raporlamayı destekleyen alıcılar From başlığında sizin alan adınızı kullanan postaya ilişkin düzenli bir özet gönderir. Biçim, RFC 7489'un Ek C bölümünde tanımlanmış olan XML'dir ve alışılmış aralık bir gündür. Her rapor tek bir alıcıdan, örneğin büyük bir posta kutusu sağlayıcısından gelir ve yalnızca o alıcıya teslim edilen postayı kapsar; dolayısıyla tek bir rapor gönderdiğiniz postanın tamamını değil, yalnızca bir kesitini anlatır.

Raporlar sayıları, IP adreslerini, alan adlarını ve kimlik doğrulama sonuçlarını içerir. İleti içeriği, konu başlıkları veya alıcı adresleri yer almaz; büyük sağlayıcıların çoğunun bu raporları göndermesinin nedeni de tam olarak budur. Hata raporları (ruf) bundan farklı bir şeydir ve çok nadiren gönderilir.

Dosya ve yapısı

Raporlar ek olarak, genellikle gzip veya zip ile sıkıştırılmış halde gelir. RFC 7489 §7.2.1.1, dosya adını alıcı alan adı, politika alan adı ve raporlama döneminin başlangıcı ile bitişi Unix zaman damgası olarak, aralarında ! işaretiyle tanımlar. Bu ayrıntı küçük görünse de işinizi kolaylaştırır: dosyaları hiç açmadan önce tarihe ve alıcıya göre sıralayabilirsiniz.

<feedback>
  <report_metadata>
    <org_name>receiver.example.net</org_name>
    <email>noreply-dmarc@receiver.example.net</email>
    <report_id>1234567890</report_id>
    <date_range><begin>1789430400</begin><end>1789516799</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>none</p><sp>none</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.25</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><selector>s1</selector><result>pass</result></dkim>
      <spf><domain>bounces.esp.example.net</domain><scope>mfrom</scope><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

policy_evaluated ile auth_results karşılaştırması

Kafa karıştıran satırların büyük bölümü bu ayrımla açıklanır. Yukarıdaki örnekte auth_results/spf alanı pass diyor, ama policy_evaluated/spf alanı fail diyor. SPF, example.com ile hizalı olmayan bounces.esp.example.net alan adı için geçmiştir; dolayısıyla DMARC açısından bakıldığında SPF'nin bu iletiye hiçbir katkısı olmamıştır.

Aynı satırdaki DKIM ise hizalı olan example.com için geçmiştir; bu yüzden policy_evaluated/dkim alanı pass değerini alır ve ileti DMARC doğrulamasını geçer. Hizalı sonuçlardan herhangi biri geçtiğinde ileti de geçmiş sayılır. Bu gönderici sorunsuzdur, ancak özel bir bounce alan adı tanımlayıp SPF hizalamasını da düzeltmek ikinci bir güvenlik katmanı eklerdi.

Satırları dört gruba ayırmak

1. Kendi göndericileriniz, geçenler

Posta kutusu sağlayıcınızın, pazarlama aracınızın ya da kendi sunucularınızın hizalı bir DKIM veya SPF geçişine sahip IP adresleri. Bunlar ulaşmak istediğiniz hedef durumdur ve herhangi bir işlem gerektirmez. Yapılacak tek şey, hacimlerin gerçekten gönderdiğiniz posta miktarına kıyasla makul görünüp görünmediğini doğrulamaktır.

2. Kendi göndericileriniz, başarısız olanlar

Tanıdığınız ya da kullandığınız bir hizmete ait olan, hizalı sonuçların ikisinin birden başarısız olduğu adresler. Tipik nedenler şunlardır: kendi alan adıyla imzalayan bir hizmet, kimsenin yapılandırmadığı yeni bir araç veya süresi dolmuş bir DKIM anahtarı. Zorlamaya geçmeden önce bunları düzeltin: p=reject politikasının engelleyeceği posta tam olarak bu gruptur.

3. Yönlendirme

Çoğu zaman üniversitelere, şirketlere veya posta kutusu sağlayıcılarına ait olan, SPF'si başarısız ama DKIM'i hizalı biçimde geçen tanımadığınız IP'ler. Bu satırların arkasında genellikle postanızı başka bir adrese ileten bir alıcı vardır ve yönlendirmeyi yapan sunucu doğal olarak SPF kaydınızda yer almaz. DKIM geçtiği sürece DMARC de geçer ve yapılacak hiçbir şey yoktur.

4. Sahtecilik ve gürültü

Hem SPF hem de DKIM'in başarısız olduğu, çoğu zaman birçok farklı ağdan küçük sayılarla gelen bilinmeyen IP'ler. Bu, sizmiş gibi görünmeye çalışan postadır; arada bir de kimsenin size haber vermediği meşru bir sistem çıkabilir. Zorlamaya geçmeden önce bu ikinci ihtimali ağ sahibiyle doğrulayın; ondan sonrası için bu grubu durduran şey tam olarak zorlamanın kendisidir.

Bir IP'yi tanımlamak için ters DNS kaydını DNS Sorgulama ile, ait olduğu ağı da IP Bilgisi ile sorgulayın. mail-out.esp.example.net gibi bir PTR adı ya da bilinen bir sağlayıcıya ait bir ASN numarası, satırların büyük bölümünü saniyeler içinde açıklığa kavuşturur.

Raporları tarayıcıda açmak

Ham XML'i elle okumak zordur ve alışılmış çözüm, dosyaları üçüncü taraf bir hizmete teslim etmektir. DMARC Rapor Analizi aynı işi yükleme yapmadan görür: .xml, .xml.gz veya .zip eklerini geldikleri haliyle bırakın, araç bunları sayfanın içinde ayrıştırır. Raporlar bilgisayarınızda kalır; bu da önemlidir, çünkü raporlar alan adınız adına gönderim yapan her sistemin IP adresini tek tek yazar.

Birden çok dosya tek bir görünümde birleştirilir; böylece dört alıcıdan gelen bir haftalık rapor, yirmi sekiz ek yerine tek bir tablo olarak okunur. Her satır tek bir kaynağı gösterir: hacmi, DMARC kararı ve hizalamalarıyla birlikte SPF ile DKIM sonuçları. Günlük hacim grafiği de yeni bir göndericiyi ya da ani bir başarısızlık dalgasını fark etmeyi kolaylaştırır. Tablo CSV, ayrıştırılmış satırlar JSON olarak dışa aktarılır.

Bir kaynağı tanımlamak yine de bir sorgu gerektirdiği için IP başına sorgu isteğe bağlıdır: tek bir adresi sorduğunuzda XGM sunucusuna yalnızca o adres gider, raporun kendisi hiçbir zaman yüklenmez. Araca güvenmeden önce bilmeniz gereken iki sınır var. Raporları posta kutunuzdan toplamaz, yani ekleri yine siz indirirsiniz; hata (ruf) raporlarını da okumaz.

Raporları bir betikle özetlemek

Küçük bir alan adı için kaynak IP ve sonuç başına ileti toplamlarını hesaplayan basit bir betik fazlasıyla yeterlidir. Aşağıdaki örnek yalnızca Python standart kütüphanesini kullanır ve içinde .xml, .xml.gz ile .zip dosyaları bulunan bir klasörü okur. Önce DMARC doğrulamasını geçemeyen satırları yazdırır, çünkü ilgilenmeniz gereken satırlar bunlardır.

import gzip, sys, zipfile
from collections import Counter
from pathlib import Path
import xml.etree.ElementTree as ET

def open_report(path):
    if path.suffix == ".gz":
        return gzip.open(path).read()
    if path.suffix == ".zip":
        with zipfile.ZipFile(path) as archive:
            return archive.read(archive.namelist()[0])
    return path.read_bytes()

totals = Counter()
for path in Path(sys.argv[1]).iterdir():
    root = ET.fromstring(open_report(path))
    org = root.findtext("report_metadata/org_name")
    for record in root.iter("record"):
        ip = record.findtext("row/source_ip")
        count = int(record.findtext("row/count") or 0)
        dkim = record.findtext("row/policy_evaluated/dkim")
        spf = record.findtext("row/policy_evaluated/spf")
        passed = "pass" in (dkim, spf)
        totals[(passed, ip, dkim, spf, org)] += count

for (passed, ip, dkim, spf, org), count in sorted(totals.items()):
    print(f"{'PASS' if passed else 'FAIL'} {ip:<39} dkim={dkim:<4} spf={spf:<4} {count:>6}  {org}")

Yalnızca kendi rapor adresinize gelen raporları ayrıştırın ve bu dosyaları her zaman güvenilmeyen girdi olarak değerlendirin. Standart kütüphanedeki ayrıştırıcı dış varlıkları getirmez, ama bilinmeyen göndericilerden gelen çok büyük veya bozuk biçimli dosyalar yine de körlemesine işlenmek yerine atlanmalıdır.

Uygulamalı bir örnek

Aşağıda, p=none yayımlayan ve bir posta kutusu sağlayıcısı, bir bülten hizmeti ile bir uygulama sunucusu kullanan example.com alan adı için bir haftalık raporların özeti yer alıyor. Adresler RFC 5737'de belgeleme amacıyla ayrılmış aralıklardan geldiği için gerçek ağların yerine geçer. Her satır, farklı alıcılardan gelen toplam ileti sayısıyla birlikte tek bir kaynak IP'yi gösterir.

İlk satır ulaşmak istediğiniz hedef durumdur. Bülten hizmeti yalnızca DKIM üzerinden geçiyor ve bu da DMARC için yeterlidir; özel bir bounce alan adı tanımlamak SPF hizalamasını da eklerdi, ama zorunlu değildir. Üniversiteye ait satır bir yönlendirmedir ve DKIM imzası bu yolculuktan sağ çıktığı için hiçbir işlem gerektirmez.

Geriye karar bekleyen iki satır kalıyor. Uygulama sunucusu SPF'yi geçiyor ama DKIM'i geçmiyor; bu yüzden gönderdiği makbuzlar, bir müşteri onları başka bir adrese yönlendirir yönlendirmez DMARC doğrulamasını kaybedecek, dolayısıyla kullandığı aktarıcıda DKIM imzalamayı etkinleştirmeniz gerekir. Son satır ise kimsenin tanımadığı bir ağdan her iki kontrolü de başarısız geçiyor; bu tipik bir sahteciliktir ve zorlamanın duracağı yer tam olarak burasıdır.

Raporlar gelmediğinde

Sessizlik iyi bir işaret değildir. Büyük sağlayıcılara posta gönderen bir alan adı, rua etiketini yayımladıktan sonraki bir iki gün içinde ilk raporlarını görmeye başlamalıdır. Hiçbir şey gelmiyorsa aşağıdaki olası nedenleri, kaydın kendisinden başlayarak sırayla gözden geçirin.

1. _dmarc.example.com adresinde tam olarak tek bir DMARC kaydı bulunduğunu ve bu kaydın sorunsuz ayrıştırıldığını kontrol edin; ikinci bir kayıt, alıcıların ikisini birden yok saymasına yol açar.
2. rua söz dizimini kontrol edin: her adresin başında mailto: öneki bulunmalıdır ve birden çok adres virgülle ayrılır.
3. Adres başka bir alan adındaysa, o alan adının example.com._report._dmarc.<o alan adı> kaydını v=DMARC1 değeriyle yayımladığını doğrulayın.
4. Posta kutusunun büyük sıkıştırılmış ekleri kabul ettiğini ve rapor postalarını istenmeyen posta olarak filtrelemediğini doğrulayın.
5. Alıcıların yalnızca kendilerine ulaşan posta hakkında rapor verdiğini unutmayın: bir sağlayıcıya hiç posta göndermemiş bir alan adı o sağlayıcıdan hiçbir rapor almaz.

E-posta Güvenliği aracı, dış yetkilendirme sorgusu da dahil olmak üzere ilk üç maddeyi tek bir çalıştırmada kapsar. Dördüncü madde için rapor adresine büyük ekli bir test iletisi gönderin ve iletinin gerçekten ulaştığını doğrulayın.

Tarayıcı aracı, kendi betiğiniz ya da rapor hizmeti

Üç yaklaşım da aynı XML dosyalarını okur; dolayısıyla seçim aslında hacim ve emek meselesidir. Birkaç göndericisi olan küçük bir alan adı için analiz aracı ya da haftada bir çalıştırılan bir betik fazlasıyla yeterli olur. Çok sayıda tedarikçisi, birden fazla markası ya da sıkı uyumluluk gereksinimleri olan bir alan adı ise geçmişi saklayan, IP sahiplerini çözen ve değişiklik olduğunda uyaran bir hizmetten belirgin fayda görür.

Hangisini seçerseniz seçin, ham raporları bir süre saklayın. Bir hizmet bir kaynağı yanlış sınıflandırdığında ya da yazdığınız betikte bir hata olduğunda geri dönüp bakacağınız tek kanıt XML dosyalarının kendisidir.

Alt alan adları, birden çok alan adı ve zaman aralıkları

Bir rapor, üretildiği politika alan adını kapsar, ama içindeki satırlar o politikayı devralan alt alan adlarından gelen postayı da içerebilir. identifiers/header_from alanı her satır için tam From alan adını gösterdiğinden, yalnızca news.example.com kaynaklı satırları görmek istediğinizde bu alana göre filtreleyin. Kendi DMARC kaydı ve kendi rua adresi olan alt alan adları ise ayrı raporlar alır.

Birden çok alan adı yönetiyorsanız hepsini aynı rapor adresine yönlendirin ve satırları policy_published/domain alanına göre gruplayın. Tutarlı tek bir ayrıştırıcıya sahip tek bir posta kutusunu çalışır durumda tutmak, her alan adı için ayrı bir süreç işletmekten çok daha kolaydır. Buna karşılık her dış adresin, kendisini kullanan her alan adı için ayrı bir yetkilendirme kaydına yine de ihtiyacı vardır.

date_range değerleri UTC'ye göre Unix zaman damgalarıdır ve alıcıların çoğu tam bir UTC gününü kapsar. Raporları kendi gönderim kayıtlarınızla karşılaştırırken önce ikisini de UTC'ye çevirin. UTC'nin ilerisindeki bir saat diliminde akşam geç saatte gönderilen bir kampanya bir önceki günün raporunda görünür; görünürdeki uyuşmazlıkların büyük bölümü çoğu zaman bununla açıklanır.

Gizlilik, hacim ve saklama

Toplu raporlar, gönderim yapan sunucuların IP adreslerini ve bazen zarf alıcısının alan adını listeler. Bunlar genellikle tek tek alıcılara ilişkin kişisel veri sayılmaz, ama yine de denetimli bir posta kutusunda tutmanız gereken operasyonel veridir. Bu raporları ne kadar süre saklayacağınıza baştan karar verin; eğilimleri fark etmek için birkaç aylık geçmiş genellikle yeterli olur.

Yoğun bir alan adı, günde birçok farklı alıcıdan çok sayıda rapor alır. Kimsenin okumadığı bir posta kutusu kısa sürede bir yüke dönüşür; bu yüzden ya özeti otomatikleştirin ya da bir rapor hizmeti kullanın. Hizmet başka bir alan adı üzerinde çalışıyorsa, raporlarınıza izin verip vermediğini E-posta Güvenliği aracıyla kontrol edin.

• rua için kişisel bir gelen kutusu değil, yalnızca bu işe ayrılmış bir adres kullanın.
• Bu posta kutusunu pazarlama ve destek talebi sistemlerinin dışında tutun.
• Rapor hacmindeki ani düşüşlere dikkat edin: bozuk bir rua adresi ya da bir DNS yazım hatası akışı sessizce durdurur.
• Her DNS değişikliğinden sonra raporlardaki policy_published değerini kendi kaydınızla karşılaştırın.

Sık karşılaşılan sürprizler

• Kendi sağlayıcınızın IP'leri başarısız oluyor: sağlayıcının yönetim panelinde alan adınız için DKIM imzalama etkinleştirilmemiştir, bu yüzden iletide yalnızca sağlayıcının kendi imzası bulunur.
• Hiç göndermediğiniz posta DMARC'ı geçiyor: eski bir hizmetin alan adınız için hâlâ geçerli bir DKIM anahtarı ya da SPF include'u vardır; artık kullanmadığınız her şeyi iptal edin.
• Sayılar gönderdiğinizden çok daha düşük: raporlar yalnızca rapor veren alıcılardan ve yalnızca onlara gerçekten teslim edilen posta için gelir.
• Aynı IP farklı sonuçlarla görünüyor: tek bir sunucudan çıkan farklı iletiler, doğrudan teslim ve yönlendirme gibi farklı yollar izlemiştir.
• Zorlayıcı bir politika altında `none` değerinde bir `disposition`: alıcı, örneğin bilinen bir posta listesi için yerel bir geçersiz kılma uygulamıştır ve bunu reason öğesinde açıkça belirtir.

Bunların hiçbiri panik yapmayı gerektirmez, ama her biri notlarınızda bir satırı hak eder. Hafta be hafta tekrarlayan örüntüler, gerçekten düzeltmeye değer olanlardır.

Raporları eyleme dönüştürmek

İkinci grup tam bir raporlama dönemi boyunca boş kaldığında zorlamaya geçmeye hazırsınız demektir. p=none'dan p=reject'e plan rehberi bu geçişin aşamalarını ve geri alma yolunu ayrıntılı olarak anlatır.

SSS

Kaynaklar

• RFC 7489: DMARC, §7 Raporlama ve Ek C (XML şeması)
• RFC 7208: SPF
• RFC 6376: DKIM imzaları
• IETF taslağı: DMARC toplu raporlama (DMARCbis)
• Python belgeleri: xml.etree.ElementTree