DMARC raporu okuma ve gönderici sahteciliğini tespit etme rehberi

Haftalık e-posta noreply@dmarcreport.com adresinden geliyor ve ekinde açtığında sadece iç içe birkaç etiket ve yüzlerce IP satırı gördüğün bir XML dosyası var. Gerçek soru şu: bu IP'lerden hangisi bize ait ve hangisi bizim alan adımız adına e-posta gönderiyor? Bu sorunun cevabını bilmiyorsan, p=none'dan asla ileri gidemezsin.

DMARC raporu tam olarak sana ne söylüyor

rua=mailto:dmarc@example.com ile yapılandırılmış her _dmarc kaydı, Gmail ve Outlook gibi büyük alıcıların sana günde bir veya birkaç kez bir XML dosyası göndermesini sağlar. Bu dosyanın iki bölümü vardır: raporu hangi sunucunun ve hangi zaman aralığında oluşturduğunu söyleyen <report_metadata> ve her "gönderici IP + From alan adı" kombinasyonu için ayrı bir blok oluşturan <record>.

Her <record> içinde üç önemli şey vardır. Birincisi gönderici adresi olan <source_ip>. İkincisi o aralıktaki mesaj sayısını veren <count>. Üçüncüsü SPF ve DKIM değerlendirme sonucunu <spf>pass</spf> veya <dkim>fail</dkim> ile gösteren <policy_evaluated>. Eğer her ikisi de fail ise, o kayıt sahte bir mesajdır.

Ham XML'i ağır araçlar olmadan nasıl okuruz

Önce bir grafik panel kurman gerekmez. Çoğu dağıtımda bulunan xmllint ile birkaç saniyede cevaba ulaşırsın. Dosyayı e-postadan ayırdığını ve adının report.xml olduğunu varsayalım:

xmllint --xpath '//record[policy_evaluated/spf="fail" and policy_evaluated/dkim="fail"]/row/source_ip/text()' report.xml

Bu komut yalnızca hem SPF hem de DKIM'i reddeden IP'leri yazdırır. Çıktı boşsa, bu iyi haberdir. Birkaç IP dönerse, gerçek şüpheliler onlardır. Her birinin mesaj sayısını görmek için:

xmllint --xpath '//record/row[source_ip="203.0.113.45"]/count/text()' report.xml

Pratik bir not: raporlar genellikle gzip'lenmiştir. Önce gunzip report.xml.gz ve sonra yukarıdaki komutu çalıştır. Günde birkaç rapor alıyorsan, klasör üzerinde basit bir döngü çalıştır ve çıktıyı tek bir dosyada topla; XML'i elle açmak sadece ilk seferde işe yarar.

Yetkili göndericiyi sahteden ayırt etme

Ölçüt basittir ve tahmine ihtiyaç duymaz. Raporda spf=pass ve dkim=pass ile görünen her IP yetkili göndericidir; yani ya kendi e-posta sunucundur ya da SPF ve DKIM'ini yapılandırdığın e-posta pazarlama gibi bir işlemsel hizmettir. Her ikisini de fail veren her IP sahteciliktir. Belirsiz durum, birinin pass diğerinin fail olduğu durumdur; örneğin SPF geçmiş ama DKIM geçmemiş. Burada genellikle mesajı yeniden ileten ve DKIM imzasını bozan bir forwarder veya e-posta listesi aradadır.

Yetkili IP'nin gerçekten sana ait olduğundan emin olmak için tersini sorgula:

dig -x 203.0.113.45 +short

Çıktı kendi e-posta hizmetinin alan adına işaret ediyorsa, yetkilidir. Bilinmeyen bir host veya yabancı bir ISP'ye işaret ediyorsa, sahtekar odur. Kendi SPF ve DKIM kayıtlarını kontrol etmek için de kayıtların doğru yayımlandığından emin olmak amacıyla DNS ve ağ kontrol araçlarını kullanabilirsin.

Burada hata yapıyorlar

Gördüğüm en yaygın hata şudur: site yöneticisi raporu görür, birkaç bilinmeyen IP bulur ve hemen politikayı p=none'dan p=reject'e çeker. İki hafta sonra sitenin iletişim formunun e-posta göndermediği ve müşterilerin hiçbir şey almadığı şikayeti gelir.

Bunun nedeni, o bilinmeyen IP'nin şirketin kendi e-posta sunucusu olması ve bir alt alan adından veya bir bulut hizmetinden gönderim yapması ve birinin onun için SPF'i güncellemeyi unutmuş olmasıdır. Belirtisi de tam olarak budur: kurum içinden gönderim kesilir, ancak dış hizmetlerden gönderim sağlam kalır. Herhangi bir değişiklikten önce, yetkili IP listesini sadece raporla değil, altyapı ekibiyle kontrol et.

p=reject ne zaman konulabilir

Sayısal bir ölçütü vardır, hissi değil. En az iki haftalık bir dönemde, raporlanan mesajların yüzde 99'undan fazlası SPF ve DKIM ile geçiyorsa ve geçen tüm IP'ler senin yetkili listendeyse, zamanı gelmiştir. Güvenli yol şudur: veri toplamak için p=none, sonra bir süre pct=25 ile p=quarantine ve son olarak p=reject.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1"

pct parametresini hafife alma. pct=25 ile sahte mesajların yalnızca dörtte biri karantinaya alınır ve bir hata yaptıysan, sağlıklı trafiğinin dörtte üçü hâlâ reddedilmez. Bu gerçek bir can simidi, bir formalite değil.

Kabul etmen gereken maliyet: p=reject o anda geri döndürülemez. Yarın gönderim için yeni bir hizmet eklersen ve SPF'i güncellemezsen, e-postaları sessizce reddedilir ve bunu yalnızca kullanıcı şikayetinden anlarsın. Bu yüzden e-posta altyapısındaki her değişiklik, eşzamanlı DMARC kaydı değişikliğiyle birlikte olmalıdır.

Raporları nerede saklayalım

Ham XML'i atma. Raporlar, bir ihlalin nereden başladığını anlamak istediğinde tek tarihsel belgendir. Onları diğer loglarını sakladığın yerde sakla ve dokunulmadan kaldıklarından emin ol; çalışma yöntemi Denetim logu nedir ve nasıl dokunulmadan saklanır? başlığında açıklanmıştır. Sunucunu kaybedersen ve raporlar da aynı sunucudaysa, hiçbir kanıtın olmaz.

Sık sorulan sorular

DMARC raporunu nereden alırım?

Alan adının _dmarc.example.com içindeki TXT kaydına rua=mailto:adres ekleyerek. Gmail ve Outlook gibi büyük alıcılar raporu kendileri o adrese gönderir ve bir yere kaydolman gerekmez. Sadece o posta kutusunu gerçekten okumalısın, yoksa raporlar işe yaramaz şekilde depolar.

SPF, DKIM ve DMARC arasındaki fark nedir?

SPF hangi IP'lerin gönderim yapmaya izinli olduğunu söyler ve SMTP zarfı üzerinde kontrol edilir. DKIM başlıklara kriptografik bir imza koyar ve mesajın yolda değiştirilmediğini kanıtlar. DMARC bu ikisinin üstüne oturur ve her ikisi de başarısız olursa alıcının ne yapacağını belirler: hiçbir şey, karantina veya reddetme.

p=reject sonrası neden kendi e-postalarım reddediliyor?

Neredeyse her zaman gözden kaçan bir yetkili gönderici vardır. Ya SPF yeni bir hizmet için güncellenmemiştir ya da DKIM alt alan adında doğru yapılandırılmamıştır. Önce ruf raporlarını oku, reddedilen IP'yi dig -x ile kontrol et ve sonra sorun çözülene kadar politikayı geçici olarak p=quarantine'e geri döndür.

Raporları ne sıklıkla kontrol etmeliyim?

İlk haftalarda haftalık, politika oturduktan sonra ayda bir yeterlidir. Ancak e-posta altyapın her değiştiğinde, o hafta raporu tekrar kontrol et. Rapor kontrolü olmadan gönderim hizmetini değiştirmek, işlemsel e-postaların kesilmesinin en yaygın nedenidir.

Hâlâ p=none'da kaldıysan ve nereden başlayacağını bilmiyorsan, önce bir hafta rapor topla, geçen IP'leri bir dosyada listele ve sonra politika değişikliğine geç. E-posta altyapını ve alan adı güvenliğini başka bir ekibe bırakmayı tercih ediyorsan, ServerNet güvenlik hizmetleri aynı yolu kapsar. Ancak her durumda, yetkili IP listene yazılı olarak sahip olana kadar p=reject'e dokunma.