A DMARC Geri alma, ne olduğunu açıklamak için gereken kanıtları korurken amaçlanan iletişimi kurtarmalıdır. Kaydı düzenlemek bu işin yalnızca bir kısmıdır. Ekibin ayrıca hangi meşru hizmetin başarısız olduğunu, alıcının hangi politikayı görmüş olabileceğini ve neyin başka bir girişimi haklı çıkaracağını bilmesi gerekiyor.
Değişiklikten önce bu kurtarma yolunu hazırlayın. Bir olay gerçekleştiğinde, önceki bir değer, adlandırılmış sahip ve test edilmiş onay rotası, ekran görüntüleri aracılığıyla doğaçlama bir arama yapmaktan daha faydalıdır.
Restorasyona ihtiyaç duyabilecek durumu kaydedin
Kayıt kümesinin tamamını, TTL'si, yetkili sunucuları ve toplama süresiyle birlikte, etkilenen DNS sahibi adına kaydedin. Keşif açısından önemli olduklarında geçerli üst ve alt alan adı politikalarını koruyun. Kopyalanan bir p değeri tek başına raporlama adreslerini veya hizalama Aynı anda değiştirilen ayarlar.
Onaylanan değişikliği okunabilir bir fark olarak saklayın. Değiştirilen her etiketin amacını ve önceki yapılandırmayı geri yükleyebilecek yetkili kişiyi tanımlayın. Gözden geçirmek alt alan adı politikası keşfi Bir ebeveyn kaydını düzenlemenin her çocuğun değerlendirmesini değiştirdiğini varsaymadan önce.
DNS yönetimi kanıtlarını hassas mesaj örneklerinden ayrı olarak saklayın. Her ikisinin de uygun erişime ihtiyacı vardır, ancak olay kaydının müşterinin gizli içeriğini yeniden üretmesi gerekmez.
Başarısızlığı şüpheden ayıran bir tetikleyici tanımlayın
Değişiklik için somut geri alma kriterlerini seçin: örneğin, yeni politikaya atfedilebilen kritik bir meşru akışın doğrulanmış reddi ve bu akışın, kararlaştırılan yanıt penceresi içinde onarılamaması.
Destek şikayeti tek başına soruşturma başlatır; DMARC neden olarak belirlemez. Döndürülen SMTP metninin tamamını, hizmeti ve hesabı, zamanı, alıcı etki alanını, görünür Kimden etki alanını ve mevcut gönderme günlüklerini yakalayın. Teslim edilen postalar için temsili orijinal mesajı ve güvenilir alıcı kimlik doğrulama sonuçlarını şu adreste saklayın: RFC 8601 §7.1.
Tek başına düşük bir toplam geçiş oranı da bağlama ihtiyaç duyar. Sağlıklı bir dağıtım sırasında yetkisiz trafik başarısız olabilir. Politikayı zayıflatmadan önce hangi meşru iş yolunun etkilendiğini sorun.
Gönderici onarımını ilke geri yüklemesinden ayırın
Bir uygulamanın imza kimliği yanlışsa, desteklenen bir uygulama düzeltmesi uygun kurtarma yöntemi olabilir. Geniş politika değişikliği sonuçsal etkiye neden oluyorsa, uygulama incelenirken onaylanmış önceki politikayı geri yükleyin.
Değiştirmekten kaçının SPF, DKIM, DMARC ve gönderen platforma, olay gerektirmediği sürece tek seferde gönderilir ve her değişiklik kaydedilir. Eş zamanlı yapılan birkaç düzenleme, iyileştirme veya başarısızlığın atfedilmesini zorlaştırır.
İlkeyi geri yüklemek, temeldeki kimlik doğrulama veya hizalama kusurunu onarmaz. Bu kusuru bir sahip, kanıt ve yeniden test gereksinimi ile açık tutun.
Kontrollü bir geri yükleme provası yapın
Bu kurgusal alıştırma, gerçek bir üretim testini değil, kayıt tutmayı göstermektedir:
- Zaman: 10:00 UTC; Etkinlik: Onaylanan politikada hiçbir değişiklikten karantinaya geçiş; Saklanan kanıtlar: Eski ve yeni kayıt kümelerini, TTL'yi ve onayı tamamlayın
- Zaman: 10:08 UTC; Olay: Fatura iş akışı politikayla ilgili bir ret alır; Saklanan kanıtlar: Geri gönderilen yanıt, gönderen hesap ve mesaj tanımlayıcıları
- Zaman: 10:13 UTC; Olay: Olay sahibi planlanan geri yüklemeye izin verir; Saklanan kanıtlar: Karar ve etkilenen kapsam
- Zaman: 10:16 UTC; Etkinlik: Daha önce tamamlanmış DMARC değeri aynı sahibi adına geri yüklendi; Saklanan kanıtlar: Yetkili DNS yanıtı ve değişiklik bilgisi
- Zaman: 10:26 UTC; Olay: Test alıcısında kontrollü fatura yeniden denemesi kabul edilir; Saklanan kanıtlar: Yeni SMTP sonucu ve alınan kimlik doğrulama kanıtı
Son satır, o rotadaki belirli yeniden denemeyi gösterir. Bu, her alıcının daha önce önbelleğe alınmış bir yanıtı attığını veya tüm müşteri mesajlarının kurtarıldığını kanıtlamaz.
Prova sırasında uygun bir test ortamında gerçek yönetim ve onay yolunu uygulayın. Değişikliği kimin yapabileceğini ve bu kişi ya da DNS sağlayıcısı kullanılamadığında ne olacağını kaydedin.
DNS görünümlerinin ve rapor dönemlerinin çakışmasını bekleyin
Çözümleyici daha önceki bir DNS yanıtını saklayabilir; RFC 8767 §4 TTL'nin sona ermesinden sonra nitelikli eski yanıt kullanımına izin verir, bu nedenle TTL, garantili bir küresel kaldırma son tarihi değildir. Bir çözümleyicinin daha erken, daha uzun ömürlü bir yanıtı önbelleğe almasının ardından TTL'yi düşürmek, o yanıtın kalan önbellek ömrünü geriye dönük olarak kısaltmaz.
Kaydı geri yükledikten sonra yetkili sunucuları ve ilgili özyinelemeli görünümleri sorgulayın, ardından etkilenen posta yolunu yeniden test edin. Yeni ve yetkili bir yanıt, bölgenin mevcut verilerini kanıtlıyor; her uzak alıcının şu anda ne kullandığını kanıtlamaz.
Uygun olduğunda raporlamayı aktif tutun. RFC 9990 §3.3 bir raporlama dönemindeki bir politika değişikliğinin, farklı politika versiyonları kapsamındaki tasarrufları birleştiren bir rapor üretebileceğini açıklıyor. Bazı uygulamalar bunun yerine birden fazla rapor üretebilir. Tek bir politika alanını, o dönemdeki her mesajın tam olarak bu sürümü kullandığının kanıtı olarak ele almak yerine olay zaman çizelgesine açıklama ekleyin.
Tam ve geçerli bir yapılandırmayı geri yükleyin
Tam olarak amaçlanan sahibin adını kullanın ve mevcut kayıt kümesini uzlaştırın. Altında RFC 9989 §4.10, geçersiz kılmak amacıyla ilk DMARC politikasının yanına ikinci bir DMARC politikası eklemeyin. Onaylanmış raporlama hedeflerini ve gerekli tüm harici hedef izinlerini aşağıdaki koşullar altında saklayın: RFC 9990 §4 kurtarma işlemi bunları açıkça değiştirmediği sürece.
İstenmeyen değişiklikler için ortaya çıkan politikanın tamamını kontrol edin. Hizalamayı veya alt alan kapsamını sessizce değiştiren bir geri yükleme, yalnızca kurtarma değil, yeni bir politika kararıdır.
Kullanmak kayıt iş akışı yayınlanmak üzere ve raporlama kılavuzu sonraki kanıtların yorumlanması için.
Kurtarma ve düzeltmeyi ayrı ayrı kapatın
Tanımlanan etkilenen iş akışları üzerinde anlaşılan testleri karşıladığında ve yapılandırma bilinen sınırlar dahilinde doğrulandığında kurtarma sağlanır. Düzeltme yalnızca neden anlaşıldığında ve gönderme yolu düzeltildiğinde veya amaçlanan politika yeniden değerlendirildiğinde sona erer.
Bir sonraki değişiklik, ilk girişimin başarısız olmasına neden olan eksik kanıtları içermelidir. Birlikte çalışabilirlik kılavuzu RFC 9989 §7.4 aynı zamanda reddetmenin genel amaçlı çalışan alanı için uygunsuz olabileceği anlamına da gelir. Başarısız bir değişiklik, önerilen politikanın kendisinin farklı bir karara ihtiyaç duyduğunu ortaya çıkarabilir.
Orijinal kanıtları, başarısız sonucu, düzeltme kararını ve başarılı yeniden testi bir arada tutun. Bu iz bir sonraki onayın daha hızlı alınmasını sağlar çünkü neyin değiştiğini, neyin düzeldiğini ve neyin çözülmeden kaldığını açıklar.
Bir sonraki eylemi spesifik tutun
Kurgusal zaman çizelgesinde, 10:26'daki kabul, bir kurtarma gözlemidir, kimlik doğrulama kusurunun onarıldığına dair bir kanıt değildir. Gönderen düzeltme öğesini açık tutun ve gerçek yeni yöntem sonuçlarını ayrı ayrı karşılaştırın. 26 dakikalık zaman çizelgesi bir iyileşme vaadi veya tavsiye edilen bir bekleme aralığı değildir. Bu makale için hiçbir DNS geri yüklemesi, yetkilendirme veya ileti yeniden denemesi gerçekleşmedi.