A DMARC wycofanie powinno przywrócić zamierzoną komunikację, zachowując jednocześnie dowody potrzebne do wyjaśnienia, co się stało. Edycja rekordu to tylko jedna część tej pracy. Zespół musi także wiedzieć, która legalna usługa się nie powiodła, z jaką polityką mógł zapoznać się odbiorca i co uzasadnia kolejną próbę.
Przygotuj ścieżkę odzyskiwania przed zmianą. Kiedy nadejdzie incydent, poprzednia wartość, nazwany właściciel i przetestowana trasa zatwierdzenia są bardziej przydatne niż improwizowane przeszukiwanie zrzutów ekranu.
Zapisz stan, który może wymagać przywrócenia
Zapisz cały zestaw rekordów pod nazwą właściciela DNS , którego dotyczy problem, wraz z jego czasem TTL, autorytatywnymi serwerami i czasem gromadzenia danych. Zachowaj odpowiednie zasady dotyczące domeny nadrzędnej i subdomeny, jeśli mają one znaczenie przy wykrywaniu. Sama skopiowana wartość p może pominąć adresy raportowania lub wyrównanie ustawienia, które zostały zmienione w tym samym czasie.
Zachowaj zatwierdzoną zmianę jako czytelną różnicę. Określ przeznaczenie każdego zmienionego tagu i osobę upoważnioną, która może przywrócić wcześniejszą konfigurację. Recenzja odkrycie zasad subdomen zanim założysz, że edycja rekordu rodzica zmienia ocenę każdego dziecka.
Przechowuj dowody administracyjne DNS oddzielnie od poufnych próbek wiadomości. Obydwa wymagają odpowiedniego dostępu, ale zapis incydentu nie musi odzwierciedlać poufnych treści klienta.
Zdefiniuj wyzwalacz odróżniający porażkę od podejrzenia
Wybierz konkretne kryteria wycofywania zmiany: na przykład zweryfikowane odrzucenie krytycznego uzasadnionego przepływu, który można przypisać nowej polityce i niemożność naprawienia tego przepływu w uzgodnionym oknie reakcji.
Sama skarga dotycząca wsparcia rozpoczyna dochodzenie; nie ustala DMARC jako przyczyny. Przechwytuj pełny zwrócony tekst SMTP , usługę i konto, czas, domenę odbiorcy, widoczne informacje z domeny i dostępne dzienniki wysyłania. W przypadku poczty dostarczonej zachowaj reprezentatywną oryginalną wiadomość i wyniki uwierzytelnienia zaufanego odbiorcy pod RFC 8601 §7.1.
Sam niski łączny współczynnik zdawalności również wymaga kontekstu. Nieautoryzowany ruch może zakończyć się niepowodzeniem podczas prawidłowego wdrożenia. Zanim osłabisz politykę, zapytaj, na którą legalną ścieżkę biznesową ma to wpływ.
Oddziel naprawę nadawcy od przywracania zasad
Jeśli jedna aplikacja ma niepoprawną tożsamość podpisu, obsługiwana korekta aplikacji może być odpowiednim odzyskiwaniem. Jeśli ogólna zmiana zasad powoduje konsekwencje, przywróć zatwierdzoną wcześniej politykę do czasu zbadania wniosku.
Unikaj zmian SPF, DKIM, DMARC i platformę wysyłającą, chyba że incydent tego wymaga, a każda zmiana jest rejestrowana. Kilka jednoczesnych edycji utrudnia przypisanie ulepszeń lub niepowodzeń.
Przywrócenie zasad nie naprawia podstawowego defektu uwierzytelniania lub wyrównania. Pozostaw tę wadę otwartą, z właścicielem, dowodami i wymogiem ponownego przetestowania.
Przećwicz kontrolowane przywracanie
To fikcyjne ćwiczenie ilustruje prowadzenie dokumentacji, a nie rzeczywisty test produkcyjny:
- Czas: 10:00 UTC; Zdarzenie: zatwierdzone zmiany zasad z braku na kwarantannę; Zachowane dowody: Kompletne stare i nowe zestawy rekordów, TTL i zatwierdzenie
- Czas: 10:08 UTC; Zdarzenie: Obieg faktury zostaje odrzucony ze względu na zasady; Zachowane dowody: zwrócona odpowiedź, konto wysyłające i identyfikatory wiadomości
- Czas: 10:13 UTC; Zdarzenie: właściciel zdarzenia autoryzuje planowane przywracanie; Zachowane dowody: decyzja i zakres, którego to dotyczy
- Czas: 10:16 UTC; Zdarzenie: przywrócono wcześniejszą pełną wartość DMARC dla tego samego właściciela; Zachowane dowody: autorytatywna odpowiedź DNS i potwierdzenie zmiany
- Czas: 10:26 UTC; Zdarzenie: kontrolowana ponowna próba wystawienia faktury została zaakceptowana u odbiorcy testowego; Zachowane dowody: nowy wynik SMTP i otrzymany dowód uwierzytelnienia
Ostatni wiersz pokazuje tę konkretną ponowną próbę na tej trasie. Nie dowodzi to, że każdy odbiorca odrzucił wcześniej zapisaną odpowiedź w pamięci podręcznej lub że wszystkie wiadomości klientów zostały odzyskane.
Podczas próby przećwicz prawdziwą ścieżkę administrowania i zatwierdzania w odpowiednim środowisku testowym. Zapisz, kto może dokonać zmiany i co się stanie, jeśli ta osoba lub dostawca DNS będzie niedostępny.
Należy spodziewać się, że widoki DNS i okresy raportów będą się nakładać
Mechanizm rozpoznawania nazw może zachować wcześniejszą odpowiedź DNS ; RFC 8767 §4 pozwala na kwalifikujące się użycie nieaktualnych odpowiedzi po wygaśnięciu TTL, więc TTL nie jest gwarantowanym globalnym terminem usunięcia. Obniżenie TTL po tym, jak moduł rozpoznawania nazw buforował wcześniejszą, dłuższą odpowiedź, nie skraca z mocą wsteczną pozostałego czasu życia pamięci podręcznej tej odpowiedzi.
Po przywróceniu rekordu prześlij zapytanie do autorytatywnych serwerów i odpowiednich widoków rekurencyjnych, a następnie ponownie przetestuj trasę poczty, której dotyczy problem. Świeża, wiarygodna odpowiedź potwierdza aktualne dane strefy; nie dowodzi tego, czego obecnie używa każdy zdalny odbiornik.
W stosownych przypadkach utrzymuj aktywne raportowanie. RFC 9990 §3.3 wyjaśnia, że zmiana polityki w okresie sprawozdawczym może skutkować powstaniem raportu zawierającego dyspozycje w ramach różnych wersji polis. Niektóre implementacje mogą zamiast tego generować wiele raportów. Zamiast traktować pojedyncze pole zasady jako dowód, że każda wiadomość w danym okresie korzystała z tej dokładnej wersji, zanotuj oś czasu zdarzenia.
Przywróć kompletną, prawidłową konfigurację
Użyj dokładnie zamierzonej nazwy właściciela i uzgodnij istniejący zestaw rekordów. Pod RFC 9989 §4.10, nie dodawaj drugiej zasady DMARC obok pierwszej, próbując ją zastąpić. Zachowaj zatwierdzone miejsca docelowe raportowania i wszelkie niezbędne zezwolenia dotyczące miejsc docelowych na mocy RFC 9990 §4 chyba że odzyskiwanie wyraźnie je zmieni.
Sprawdź całą powstałą politykę pod kątem niezamierzonych zmian. Przywrócenie, które po cichu zmienia wyrównanie lub zakres subdomeny, to nowa decyzja polityczna, a nie tylko odzyskiwanie.
Używać przebieg procesu nagrywania do publikacji i przewodnik raportowania do interpretacji kolejnych dowodów.
Zamknij oddzielnie odzyskiwanie i naprawę
Odzyskiwanie następuje, gdy zdefiniowane przepływy pracy, których to dotyczy, spełniają uzgodnione testy, a konfiguracja jest weryfikowana w znanych granicach. Naprawa kończy się dopiero po zrozumieniu przyczyny i poprawieniu trasy wysyłki lub ponownym rozważeniu zamierzonej polityki.
Następna zmiana powinna obejmować brakujący dowód, który spowodował niepowodzenie pierwszej próby. Wytyczne dotyczące interoperacyjności w RFC 9989 §7.4 oznacza również, że odrzucenie może być nieodpowiednie dla domeny pracowniczej ogólnego przeznaczenia. Nieudana zmiana może ujawnić, że proponowana polityka sama w sobie wymaga innej decyzji.
Zachowaj razem oryginalny dowód, nieudany wynik, decyzję o przywróceniu sprawy i pomyślne ponowne badanie. Dzięki temu śladowi kolejne zatwierdzenie jest szybsze, ponieważ wyjaśnia, co się zmieniło, co odzyskano, a co pozostaje nierozwiązane.
Konkretne następne działanie
Na fikcyjnej osi czasu akceptacja o godzinie 10:26 jest jedną obserwacją dotyczącą odzyskiwania, a nie dowodem naprawienia wady uwierzytelnienia. Pozostaw element naprawy nadawcy otwarty i porównaj osobno rzeczywiste wyniki nowej metody. 26-minutowy harmonogram nie stanowi obietnicy powrotu do zdrowia ani zalecanego okresu oczekiwania. W przypadku tego artykułu nie wystąpiło żadne przywrócenie DNS , autoryzacja ani ponowna próba wysłania wiadomości.