[ Başlıklar ve teslimat hataları ]

Gönderen günlüklerini, alıcı teşhislerini ve DMARC raporlarını karşılaştırın

Gönderen işlemlerini, güvenilir alıcı kanıtlarını ve DMARC toplu raporlarını aşamalarını, popülasyonlarını veya zaman damgalarını karıştırmadan uzlaştırın.

EmailAuth araştırma ekibi tarafından · 8 dakikalık okuma

[ Anahtar noktalar ]

  • Gönderenin kabulü, kimlik doğrulaması ve gelen kutusu yerleştirme farklı sonuçlardır.
  • Toplu raporlar, mesaj başına tam izlemeler değildir.
  • Raporun alınmasını ve ayrıştırılmasını ayrı bir teslimat yolu olarak izleyin.
Bu sayfada

Gözlemleri aynı aşamada ve zamanda karşılaştırın

Gönderen günlükleri, alıcı tanılamaları ve DMARC toplu raporlar posta yolunun farklı bölümlerini tanımlayın. Herhangi bir kaynağın yanlış olmasına gerek kalmadan aynı fikirde olamazlar. Gönderen, bir sonraki atlama noktasına göre kabulü kaydedebilir, alıcı daha sonraki bir politikayı uygulayabilir ve bir DMARC raporu, bir raporlama aralığı boyunca kimlik doğrulamayı özetleyebilir. Bunları tek bir teslim edildi veya başarısız oldu etiketine zorlamak yerine, her kaynak için olayı, gözlemciyi ve zaman esasını adlandırarak başlayın.

Bu makalede, 8 Kasım 2026'da muhafaza edilen birincil SMTP , DSN, kimlik doğrulama ve toplu raporlama özellikleri kullanılmaktadır. Gerçek günlüklerin veya raporların analizi değil, önerilen bir mutabakat iş akışı sağlanmaktadır. Katalog, yayınlanan istekten posta kutusu makbuzuna ve ayrıştırılmış gözleme kadar bir rapor teslim takibi gerektirir. Burada böyle bir operasyonel zincir sağlanmadı veya yürütülmedi.

Gönderen günlüğünün gerçekte neyi belirlediğini belirtin

Gönderen sistemi, kuyruk tanımlayıcıyı, alıcıyı, deneme süresini, hedef ana bilgisayarı ve tam SMTP yanıtını kaydedin. Geçici ret ile kalıcı ret ve kabul edilen transfer arasında ayrım yapın. SMTP kabulü bir aktarım aşaması gözlemidir; alıcının mesajı okuduğunu veya mesajın gelen kutusunda göründüğünü tespit etmez. Daha sonraki kuyruk ve teslimat durumu olaylarını ayrı ayrı koruyun. RFC 5321

Birden fazla alıcıya sahip bir mesajın farklı sonuçları olabilir. RFC 3464 Eylem, Durum ve Tanılama Kodu dahil olmak üzere alıcı başına DSN bilgilerini tanımlar. Tek bir reddi mesajın veya kampanyanın tamamına kopyalamak yerine bu alanları doğru alıcıyla ilişkili tutun. Ayrıca raporlama sistemini tanılamada belirtilen uzak sunucudan ayırın. RFC 3464

Alıcı kanıtlarını güven sınırları dahilinde okuyun

Alıcı teşhisi, politika kararlarını, kabul edilen mesaj başlıklarını veya idari izleri içerebilir. Kanıtı hangi sistemin ürettiğini ve aynı mesaj ve yolla ilgili olup olmadığını belirleyin. İletilen bir kopya, orijinal teslimat yolundan farklı kimlik doğrulama sonuçlarına sahip olabilir. Doğrudan yol geçişini iletilmiş yol reddi ile birleştirmeyin ve rota anlaşılıncaya kadar farkı rastgele olarak adlandırmayın.

Authentication-Results iddialar güvenilir bir üretim bağlamı gerektirir. Bu sınırın dışına eklenen rastgele bir başlık herhangi bir sonucu iddia edebilir. Bir olayı uzlaştırmak için üstbilgileri kullanırken doğrulayıcı kimliğini ve orijinal ileti ilişkisini koruyun. Gönderen orijinal kabul edilen mesajı hiç almamışsa, SMTP metninden bir sonuç uydurmak yerine alıcı tarafındaki kanıtın mevcut olmadığını işaretleyin. RFC 8601

Toplu raporları mesaj izlerinden ayrı tutun

RFC 9990 Rapor meta verileri, politika bağlamı ve gruplandırılmış gözlemler dahil olmak üzere DMARC toplu raporlamayı tanımlar. Böyle bir rapor, mesaj başına tam bir teslim günlüğü değildir. Sayımları ve aralığı, bir kimlik doğrulama modelinin belirlenmesine yardımcı olabilir, ancak belirli bir iş mesajını otomatik olarak tanımlamaz, gelen kutusu yerleşimini kanıtlamaz veya her alıcıyı kapsamaz. Raporun kendi zaman aralığını ve tanımlayıcılarını ayrıştırılan verilerin yanında tutun. RFC 9990

DMARC uyumlu kimlik doğrulamayı ve politikayı kendi protokol kuralları kapsamında değerlendirir. Kimlik doğrulama başarısını gösteren bir rapor, içerik veya alıcı politikası reddiyle bir arada bulunabilir. Tersine, bir alıcı, yerel politikaya veya diğer kanıtlara göre bir kimlik doğrulama hatasını ele alabilir. Mutabakat, bir DMARC sonucunun nihai dağıtım düzenlemesi olduğunu varsaymak yerine, farklı soruları korumalıdır. RFC 9989

Raporlamayı ayrı bir dağıtım yolu olarak izleme

Eksik bir toplu raporun kendi incelemesine ihtiyacı vardır. Önerilen zincir, yayınlanan raporlama talebiyle ve geçerli herhangi bir harici hedef yetkilendirmesiyle başlar, rapor oluşturma ve taşıma yoluyla devam eder, ardından toplama posta kutusuna veya hizmetine ve ayrıştırıcısına ulaşır. Doğru bir talep, koleksiyoncunun kullanılabilir bir rapor aldığını kanıtlamaz. Alınan bir ek, kontrol panelinin onu doğru şekilde ayrıştırdığını ve ilişkilendirdiğini kanıtlamaz. RFC 9990 rapor keşfi ve teslimi

Orijinal rapor dosyasını, alındı ​​meta verilerini ve ayrıştırıcı sonucunu uygun erişim kontrolleri altında saklayın. Alma, sıkıştırmayı açma, şema işleme, veri tekilleştirme veya etki alanı ilişkilendirme sırasında bir hatanın oluşup oluşmadığını kaydedin. Bunlar, belirli bir koleksiyoncuya ilişkin bulgular değil, önerilen araştırma aşamalarıdır. Bir kontrol paneli boş olduğu için raporlamanın evrensel olarak bozulduğu veya bir rapor geldiği için evrensel olarak tamamlandığı sonucunu çıkarmayın.

Kanıtları yok etmeden zamanı ve tanımlayıcıları normalleştirin

Her kaynağın orijinal zaman damgasını ve aralığını korurken karşılaştırma için ortak bir saat dilimi seçin. Günlük toplam aralık ve yerel zamanlı kuyruk günlüğü farklı tarihlere denk gelebilir. Dönüşümleri açıkça kaydedin. Mesaj tanımlayıcılarını, kuyruk tanımlayıcılarını ve rapor tanımlayıcılarını ayrı tutun; farklı sistemlere aittirler ve değiştirilebilir anahtarlar olarak değerlendirilmemelidirler.

Doğrudan korelasyonun mümkün olmadığı durumlarda çıkarım düzeyini belirtin. Gönderen IP, etki alanı ve aralık, bire bir mesaj eşleşmesini kanıtlamadan popülasyon düzeyinde bir karşılaştırmayı destekleyebilir. Benzer konu satırlarından veya sayılardan eşleşme üretmeyin. Bir tedarikçinin kesin tanımlayıcılara ihtiyacı varsa, gerekli açıklamayı onaylayın ve redakte edilmiş bir kopya hazırlamadan önce, el değmemiş dahili orijinali saklayın.

Orijinal mutabakat çalışma sayfası

Kanıtları, yorumları ve eksik bağlantıları ayırt etmek için önerilen bu çalışma sayfasını kullanın. Gerçek bir mesaj veya raporla doldurulmamıştır.

  • Gönderen olayı: kuyruk tanımlayıcısı, alıcı, rota, zaman damgası ve tam yanıt.
  • Alıcı olayı: güvenilir üretici, mesaj referansı, politika sonucu ve gözlem süresi.
  • Toplu olay: raporlama organizasyonu, rapor tanımlayıcı, aralık, politika alanı ve gruplandırılmış sayımlar.
  • Raporlama talebi: yayınlanan konum, gözlemlenen değer ve geçerli varış yeri yetkilendirme kanıtı.
  • Toplama izlemesi: posta kutusu veya uç nokta alındısı, tutulan dosya ve aktarım meta verileri.
  • Ayrıştırma izi: şema sonucu, tekilleştirme, ilişkilendirme ve kontrol paneli içe aktarma durumu.
  • Korelasyon: tam eşleşme, popülasyon düzeyinde çıkarım veya çözülmemiş ilişki.
  • Sonuç: desteklenen başarısızlık aşaması, sonraki sahibi ve bulgunun sınırları.

Yararlı bir mutabakat, gelen kutusu yerleşimi bilinmezken gönderenin kabulü ve toplu kimlik doğrulama başarısının sağlandığı sonucuna varabilir. Bir diğeri, gönderen alanın kimlik doğrulamasını suçlamadan toplayıcı ayrıştırma sorununu tanımlayabilir. Bu daha dar ifadeler, tek bir kırmızı veya yeşil teslimat etiketinden daha eyleme geçirilebilir.

Kurgusal örnek: rapor geliyor ancak grafik boş kalıyor

Fictional Lantern Ledger, başarılı gönderen aktarım günlüklerini görüyor ve DMARC kontrol panelinin doldurulmasını bekliyor. İcat edilen uygulamada, toplama posta kutusunun bir rapor eki vardır, ancak önerilen ayrıştırıcı incelemesi bunun içe aktarılıp aktarılmadığını henüz belirlememiştir. Ekip, yalnızca grafik boş olduğu için DNS değiştirmemelidir; eksik bağlantı, alım ile ayrıştırılmış gözlem arasında olabilir.

Planlanan soruşturma, eki koruyacak, rapor tanımlayıcısını ve aralığını kaydedecek ve yetkili toplayıcının işlem sonucunu denetleyecektir. Ayrıca orijinal iş mesajı teslimi sorununu rapor aktarımından ayrı tutacaktır. Lantern Ledger kurgusaldır: hiçbir posta kutusuna, günlüğe, eke veya ayrıştırıcıya erişilmemiştir ve hiçbir hata doğrulanmamıştır.

Kesin kanıt zincirini kapatın

Gerçekten yetkili bir düzeltmeden sonra, önceki başarısız aşamada yeni bir gözlemi koruyun. Ayrıştırıcı artık bir raporu içe aktarırsa, bu, tüm teslimat veya kimlik doğrulama sorunlarını değil, gözlemlenen dosyanın ayrıştırma sorununu kapatır. Daha sonraki bir SMTP denemesi başarılı olursa, rapor toplama veya alıcı okuma işlemi gerçekleşmez. Her sonucu kendi kanıtlarına ve kapsamına bağlı tutun.

Gerekli rapor teslim takibi açık kalır. İnsan KOBİ'si, kaynak uygulanabilirliği, üretim yolları, görsel erişilebilirlik ve sahibinin serbest bırakılması da açık kalır ve yayına hazır olma durumu yanlıştır. Bu makale operasyonel kanıt veya evrensel bir teslim edilebilirlik sonucundan ziyade yapılandırılmış bir karşılaştırma yöntemi sunmaktadır.

[ Götürmek ]

Her kaynağın gözlemcisini, olayını ve aralığını koruyun, ardından yalnızca gerçekte gösterilen kanıt zincirini kapatın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Gözlemlenen aşamaları uzlaştırın

Bir kuyruk günlüğü ve bir rapor farklı olayları tanımlayabilir.

Sonraki adımlar

  1. Kesin yanıtları ve zaman damgalarını saklayın.
  2. Rapor ve mesaj tanımlayıcılarını ayrı tutun.
  3. Ayrıştırma yoluyla koleksiyonu izleyin.

CISO / SecOps

Kanıt güveni oluşturun

Kopyalanan başlıklar ve dönüştürülen raporların kaynağına ihtiyaç vardır.

Sonraki adımlar

  1. Güvenilir doğrulayıcıları belirleyin.
  2. Onaylı orijinalleri koruyun.
  3. Korelasyon iddialarını desteklenen ilişkilerle sınırlandırın.

Kurucu / Teknik Olmayan

Kesin bir sonuç isteyin

Tek bir yeşil ölçüm her teslimat aşamasını kanıtlamaz.

Sonraki adımlar

  1. İş makbuzunu nakliyeden ayırın.
  2. Koleksiyon ve ayrıştırıcı sahiplerini atayın.
  3. Geriye kalan bilinmeyenleri görünür tutun.

[ SSS ]

Sık sorulan sorular

SMTP kabul edilmesi alıcının mesajı okuduğunu kanıtlar mı?

Hayır. Bu, aktarım aşamasındaki bir gözlemdir, gelen kutusunun yerleştirildiğinin veya okunduğunun kanıtı değildir.

RFC 5321 : Basit Posta Aktarım Protokolü

Bir mesajın farklı alıcı sonuçları olabilir mi?

Evet. DSN'ler alıcı başına teslimat bilgilerini içerir.

RFC 3464 : Teslimat Durumu Bildirimleri için Genişletilebilir Mesaj Formatı

DMARC toplu raporu tam bir ileti günlüğü müdür?

Hayır. Kimlik doğrulama gözlemlerini bir raporlama aralığı boyunca gruplandırır.

RFC 9990 : DMARC Toplu Raporlama

Rastgele bir Kimlik Authentication-Results başlığına güvenilebilir mi?

Hayır. Üretim sistemini ve güven sınırını oluşturun.

RFC 8601: Authentication-Results

Yayınlanan bir raporlama talebi toplamanın işe yaradığını kanıtlar mı?

Hayır. Keşif, varış yeri yetkilendirmesi, taşıma, teslim alma ve işleme farklı bağımlılıklardır.

RFC 9990 : DMARC Toplu Raporlama

Boş bir tablo, hiçbir raporun gelmediğini kanıtlar mı?

Hayır. Alındı ​​ve ayrıştırıcı niteliği ayrı ayrı araştırılmalıdır.

Sayımlar tek başına bire bir mesaj eşleşmesi sağlayabilir mi?

Mutlaka değil. Popülasyon düzeyindeki çıkarımı tam korelasyondan ayrı olarak etiketleyin.

Burada rapor teslim takibi tamamlandı mı?

Hayır. Gerekli operasyonel zincir açık kalır.

[ Kaynaklar ]

Kaynaklar

  1. RFC 9989: DMARC

    Bölümler §2.4 Kapsam Dışı · §4.1 DMARC Temelleri · §4.3 Kimlik Doğrulama Mekanizmaları · §4.4 Tanımlayıcı Hizalamasının Açıklaması

  2. RFC 8601: Authentication-Results

    Bölümler §1.2 Güven Sınırı · §1.6 Güven Ortamı · §7.1 Sahte Başlıklar

  3. RFC 3464 : Teslimat Durumu Bildirimleri için Genişletilebilir Mesaj Formatı

    Bölümler §2.2 Mesaj Başına DSN Alanları · §2.3 Alıcı Başına DSN Alanları

  4. RFC 5321 : Basit Posta Aktarım Protokolü

    Bölümler §4.2.1 Yanıt Kodu Önem Dereceleri ve Teorisi · § 4.5.4.1 Gönderme Stratejisi · §6.1 Güvenilir Teslimat ve E-postayla Yanıtlar

  5. RFC 9990 : DMARC Toplu Raporlama

    Bölümler §3.1 Toplu Raporlar · §3.4 Rapor Talebi Keşfi · §3.5 Rapor Teslimi · §4 Dış Hedefleri Doğrulama · §8 Güvenlik Hususları · §9 Operasyonel Hususlar

[ Sözlük ]

Sözlük

Raporlama aralığı
Toplu bir raporla temsil edilen zaman aralığı.

RFC 9990 : DMARC Toplu Raporlama

Teşhis Kodu
Bir DSN'deki protokole özgü tanılama bilgileri.

RFC 3464 : Teslimat Durumu Bildirimleri için Genişletilebilir Mesaj Formatı

Korelasyon düzeyi
Kanıtların tam bir eşleşmeyi, nüfus çıkarımını veya kurulu bir ilişkinin olmadığını destekleyip desteklemediği.
Ayrıştırılmış gözlem
Veriler, ham alımdan farklı olarak bir toplayıcı tarafından başarıyla yorumlanır ve ilişkilendirilir.

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası