A DMARC wynikiem jest kategoria diagnozy, a nie instrukcja zmiany opublikowanej polityki. ponieść porażkę, nic, temperror I permerror wskazują na różne badania. Traktowanie ich jako wymiennych może pozostawić prawdziwą usterkę nierozwiązaną i niepotrzebnie osłabić ochronę.
Zacznij od zaufanych dowodów systemu odbierającego. Jakiś Nagłówek Authentication-Results rejestruje potwierdzenie systemu; sama jego obecność nie dowodzi, że twierdzenie jest wiarygodne. Zidentyfikuj, która usługa odbierająca go wygenerowała i którym nagłówkom ta usługa ufa. Granicę tę wyjaśniono w RFC 8601 §1.2 I RFC 8601 §7.1.
Przeczytaj metodę i wynik razem
W nagłówku zawierającym spf=pass; dkim=pass; dmarc=fail, trzy słowa wynikowe należą do różnych metod. The SPF I DKIM przepustki mogą uwierzytelniać domeny, które nie są zgodne z widoczną domeną Od. I odwrotnie, przejście DMARC może współistnieć z niepowodzeniem jednej podstawowej metody, jeśli inna ścieżka przechodząca jest zgodna.
Skorzystaj z poniższej mapy diagnostycznej. Znaczenia wynikowe pochodzą z RFC 9989 , sekcja 9.2; kolejne działania to zalecenia operacyjne.
- Wynik:
dmarc=none; Interpretacja: nie znaleziono odpowiednich zasad dla domeny autora; Pierwsza przydatna akcja: Zrekonstruuj wykrywanie zasad dla rzeczywistej domeny From - Wynik:
dmarc=pass; Interpretacja: istnieje odpowiednia polityka i dopasowuje się przekazywana uwierzytelniona tożsamość; Pierwsza przydatna akcja: Zidentyfikuj pomyślną ścieżkę i zbadaj każdy oddzielny problem z dostawą - Wynik:
dmarc=fail; Interpretacja: istnieje odpowiednia polityka, ale nie ustalono żadnej zgodnej tożsamości; Pierwsza przydatna akcja: porównaj SPF i wszystkie istotne wyniki DKIM z From - Wynik:
dmarc=temperror; Interpretacja: W ocenie napotkano pozornie przejściowy błąd; Pierwsza przydatna akcja: przechwyć błąd DNS lub usługi i porównaj późniejszą kontrolowaną próbę - Wynik:
dmarc=permerror; Interpretacja: Podczas oceny napotkano błąd, którego nie da się rozwiązać jedynie poprzez ponowną próbę; Pierwsza przydatna akcja: Sprawdź dokładne dane zasad i diagnostykę odbiornika pod kątem utrzymującego się problemu z konfiguracją
Nie wnioskuj o przyczynie na podstawie samego słowa wynikowego. Tymczasowa awaria DNS i źle sformułowana polityka mogą uniemożliwić normalne zakończenie, ale wymagają różnych właścicieli i różnych prac naprawczych. Zachowaj wszelkie komentarze diagnostyczne, zamiast ograniczać dowody do koloru deski rozdzielczej.
Oddziel dmarc=none od p=none
dmarc=none jest raportowanym wynikiem oceny. p=none jest wartością w opublikowanej polityce. Ważna polityka monitorowania może nadal skutkować jednym i drugim dmarc=pass Lub dmarc=fail w indywidualnych wiadomościach.
Rozważmy dwa syntetyczne przypadki. w pierwszym example.com publikuje ważny zapis monitorowania, a komunikat ma wyrównany przebieg Podpis DKIM. Oczekiwana ocena DMARC jest pozytywna, mimo że polityka nie mówi nic. W drugim przypadku nie można znaleźć żadnych zasad mających zastosowanie dla domeny autora wiadomości. Odbiorca może zgłosić dmarc=none; z tego słowa nie można wnioskować żadnej obietnicy dotyczącej polityki monitorowania.
Jeśli kolega powie „ DMARC jest ustawiony na brak”, zapytaj, czy ma na myśli politykę DNS , wynik wiadomości czy ostateczną dyspozycję. Nagraj wszystkie trzy osobno. To krótkie wyjaśnienie często uniemożliwia zmianę DNS mającą na celu niewłaściwy problem.
Zbadaj niepowodzenie poprzez tożsamość
Uzyskaj oryginalną otrzymaną wiadomość. Zapisz widoczną domenę From, tożsamość i wynik SPF oraz plik d= domenę i wynik dla każdego odpowiedniego podpisu DKIM . Zastosuj skonfigurowane wyrównanie tryb przekazywania tożsamości. A selektor to lokalizator kluczy, a nie domena używana do dostosowania DKIM .
Jeśli SPF przejdzie do domeny dostawcy, a DKIM przejdzie do domeny innego dostawcy, żadna z nich nie może być zgodna z Twoją domeną Od. Edycja roota Rekord SPF nie jest automatycznie rozwiązaniem. Ustal, jaką tożsamość faktycznie ocenia usługa i jakie opcje uwierzytelniania w domenie klienta obsługuje. The przewodnik po błędach wyrównania przechodzi przez to porównanie.
Sprawdzaj błędy bez zgadywania
Dla temperror, zapisz czas wiadomości, odbiorcę, zapytaną nazwę, błąd i kontekst mechanizmu rozpoznawania nazw, jeśli jest dostępny. Porównaj wiarygodne wyniki DNS i wyniki rekurencyjne. Późniejsze pomyślne wyszukiwanie potwierdza przejściowe wyjaśnienie, ale nie dowodzi tego, co odbiorca widział wcześniej. Jeśli to rozróżnienie ma znaczenie, poproś operatora odbierającego o logi.
Dla permerror, pobierz cały odpowiedni plik Rekord TXT ustawić. Sprawdź nazwę publikacji, umiejscowienie wersji, zduplikowane zapisy zasad i zniekształcone wartości. Nie obiecuj, że każdy zniekształcony rekord będzie miał tę samą etykietę: bieżący DMARC in RFC 9989 §4.10 I RFC 9989 §4.10.1 definiuje specyficzne przywracanie i domyślne zachowanie w przypadku niektórych problemów ze składnią i wartością zasad, a implementacje mogą się różnić. Dopasuj diagnostykę do obowiązującej reguły przed jej zmianą.
Zachowaj próbkę przed i po. Jeśli nowa próba się powiedzie, zachowaj razem dokładną naprawę i pomyślny wynik. Unikaj zamykania incydentu tylko dlatego, że publiczne sprawdzanie daje teraz zielony wynik.
Oddziel ocenę od dostawy
Pod RFC 9989 §5.4, odbiorca może dostarczyć wiadomość, która nie spełnia wymagań DMARC, zgodnie z lokalnymi zasadami obsługi i może zablokować przekazaną wiadomość ze względu na spam, złośliwe oprogramowanie lub z innych powodów. Zbierz odpowiedź SMTP lub dyspozycję doręczenia oddzielnie od wyniku uwierzytelnienia.
Końcowa notatka o zdarzeniu powinna zawierać informację, co zostało ocenione, który zaufany odbiorca, kiedy, dlaczego nastąpił wynik i co się zmieniło. Dokładny wniosek, taki jak „usługa rozliczeniowa generuje teraz wyrównany przepust DKIM na swojej trasie produkcyjnej”, jest bardziej przydatny niż „naprawiono DMARC ”. W przypadku braku polisy kontynuuj Nie znaleziono rekordu DMARC.
Podejmij następną decyzję jasno
W osprzęcie zasad monitorowania zapisz p=none, dmarc=pass i rzeczywista dyspozycja w trzech oddzielnych polach. Jeśli istnieje prawidłowa zasada, ale obie tożsamości mechanizmów przekazywania nie są wyrównane, ukończenie oceny kończy się niepowodzeniem. Jeśli wymagane zapytania DNS nie zostaną zakończone, RFC 9989 §5.3.6 zapobiega normalnemu stwierdzeniu pozytywnego/negatywnego wyniku. Są to klasyfikacje analityczne, a nie logi odbiornika.