Raport operacyjny klienta powinien wyjaśniać, na czym polegała usługa, co obejmują dowody i na jaką następną decyzję klient musi zdecydować. Agent może sporządzić raport, ale nie powinien zamieniać niekompletnych obserwacji w gwarancję ani wnioskować o zgodzie na przesłanie raportu z zgody na jego sporządzenie.
Zdefiniuj umowę raportowania
Podaj klienta, zakres domeny, okres, obowiązki związane z usługą i znane wyłączenia. Zidentyfikuj, kto jest właścicielem zatwierdzenia DNS , decyzji dotyczących własności nadawcy, reakcji na incydenty i podpisania raportu. Oddziel prace monitorujące dostawcy od systemów i odbiorników znajdujących się poza jego kontrolą.
RFC 9990 raporty zbiorcze podsumować obserwacje uczestniczącego odbiorcy. Zgłoś problem zamiast twierdzić, że cała poczta klientów została zauważona. Użyj zatwierdzonego rejestru usług jako mianownika zasięgu usług i wypisz osobno ciche i nietestowane usługi. Pokazuj wyniki uwierzytelniania niezależnie od wyników dostarczania.
Przenieś cykl życia do raportu
Proponowany cykl życia raportowania może obejmować przyjęcie, inwentaryzację domeny i usługi, zatwierdzenie wdrożenia, weryfikację, monitorowanie, eskalację, raportowanie okresowe i zakończenie. Dla każdego etapu określ odpowiedzialną rolę, przedstawione dowody i warunki ukończenia. Jest to zalecana lista kontrolna, a nie dostarczony element Runbook, umowny cel usługi lub wykonana operacja klienta.
Przy odbiorze właściciel klienta potwierdza zakres. Podczas implementacji nazwana osoba zatwierdzająca DNS akceptuje dokładną różnicę. Podczas monitoringu operator rejestruje dzienny stan poboru i przypisuje awarie materiałowe. Przy wyjściu upoważnieni operatorzy uzgadniają zatrzymane zapisy, eksportują uzgodnione dowody i cofają dostęp w ramach zatwierdzonego planu. Nie usuwaj automatycznie współużytkowanych zależności DNS po zakończeniu.
Oblicz metryki z widocznymi mianownikami
Załóżmy, że hipotetyczny raport obejmuje cztery zarejestrowane usługi w jednym zadeklarowanym przedziale czasu. Trzy z nich zawierają przydatne obserwacje, a jeden zgłaszający incydent zachowuje milczenie, co zapewnia pokrycie obserwowanych usług na poziomie 3/4 lub 75%. W populacji deduplikowanych odebranych raportów w tym samym przedziale załóżmy, że 200 obserwacji komunikatów, z których osiem zakończyło się niepowodzeniem DMARC: obserwowany wskaźnik awaryjności wynosi 8/200 lub 4%. Nie jest to miara wszystkich wysłanych wiadomości, liczby unikalnych klientów ani dostaw biznesowych.
Cicha obsługa pozostaje nieznana, niezdrowa. Poproś właściciela o zaplanowaną czynność lub autoryzowany test trasy. Oczekująca zmiana DNS należy do decyzji oczekujących na zatwierdzenie, a nie do zakończenia pracy. Są to określone dane wejściowe i ręcznie wykonana arytmetyka, a nie wygenerowany raport lub przeprowadzona kontrola kompletności. Przed udostępnieniem rzeczywistego raportu sprawdź metadane okresu, właścicieli akcji i limity każdego mianownika.
Przejrzyj przed udostępnieniem
Poproś operatora o weryfikację twierdzeń opartych na faktach i zobowiązań właściciela mających kontakt z klientem. Określ luki w dowodach, wyjątki związane z wiekiem i potrzebne decyzje, używając prostego języka. Nie należy wyciągać wniosku, że przelotny, zgodny podpis oznacza aprobatę biznesową; RFC 9989wynik uwierzytelnienia służy innemu celowi.
Nie uwzględniaj w raporcie poufnych treści wiadomości i danych uwierzytelniających. Udostępnij tylko za pośrednictwem autoryzowanego odbiorcy i zakresu dostępu. W tym artykule przedstawiono wzorzec raportowania, a nie zaakceptowany element Runbook klienta ani zmierzoną wydajność usługi. Nie zawiera żadnych roszczeń dotyczących właściwości produktu i nie zezwala na dostawę do żadnego odbiorcy zewnętrznego.
Raport końcowy powinien ułatwić kolejne działanie, nie wyolbrzymiając tego, co usługa może kontrolować.
Podstawowe czytanie: Raportowanie zbiorcze RFC 9990 DMARC, RFC 9989 DMARC, OWASP LLM06 2025 Nadmierna agencja.