Przeczytaj uwierzytelnianie złożone jako wynik Microsoft
Pole compauth firmy Microsoft nie jest inną pisownią DMARC. Jest to ocena złożona, wykorzystująca uwierzytelnianie i inne sygnały komunikatu, a jej interpretacja podlega udokumentowanemu przetwarzaniu przez firmę Microsoft. Wiadomość może zatem zawierać różnie wyglądające wyniki DMARC i złożone, a nagłówek nie będzie z natury sprzeczny. Prawidłowym zadaniem jest przeczytanie każdego pola, jego kontekstu tożsamości i powiązanego kodu przyczyny przed podjęciem decyzji, co ustali wynik.
W tym artykule wykorzystano podstawową dokumentację firmy Microsoft przechowywaną 8 listopada 2026 r. Na stronie nagłówka modułu antyspamowego widnieje aktualizacja z 27 lipca 2026 r. Nie dostarczono żadnej oryginalnej wiadomości ani śladu dzierżawcy, a poniższy przykład jest wyraźnie fikcyjny, a nie zredagowany nagłówek. Katalog wymaga prawdziwego przykładu oryginalnej wiadomości, zanim będzie można wydać wnioski operacyjne.
Zadbaj o widoczność tożsamości
Microsoft definiuje header.from jako widoczną domenę From, smtp.mailfrom jako kopertę POCZTA OD domena i nagłówek.d jako DKIM domenę podpisującą, jeśli jest obecna. Pola te mogą się różnić. Zachowaj ich związek podczas odczytywania wyników: SPF przepustka na jedną domenę nie jest ustanawiana automatycznie wyrównanie z widocznym nadawcą, a przepustka DKIM musi być powiązana z podpisem i domeną, którą opisuje. Pola nagłówka uwierzytelniania Microsoft
Decyzja dotycząca protokołu DMARC dotyczy dostosowania do widocznej domeny From zgodnie z jej zasadami. Złożone uwierzytelnianie Microsoft wykorzystuje domenę From jako podstawę podczas łączenia SPF , DKIM , DMARC i innych informacji. Nie zastępuj oddzielnego wyniku DMARC danymi obliczeniowymi w oświadczeniu o zgodności lub wnioskach dotyczących rozwiązywania problemów DNS . Odpowiadają na powiązane, ale nieidentyczne pytania. RFC 9989 Pola złożone Microsoftu
Zinterpretuj wynik i przyczynę razem
Wartości obliczeniowe dokumentów firmy Microsoft są pozytywne, negatywne, miękkie i żadne, z trzycyfrowym powodem. Zachowaj pełną parę. Kod przyczyny nie jest kodem odpowiedzi SMTP , nawet jeśli jego cyfry przypominają inny kod diagnostyczny. Nie dekoduj reason=130 przy użyciu ogólnej tabeli SMTP ani nie wnioskuj o warunku obejmującym całą dzierżawę na podstawie wartości jednej wiadomości. Użyj bieżącej tabeli Microsoft dla obserwowanego kontekstu. Uwierzytelnianie złożone Microsoft
Odniesienie do nagłówka opisuje przyczynę 000 jako jawny błąd uwierzytelnienia z niepowodzeniem DMARC i zasadą kwarantanny lub odrzucenia, podczas gdy 001 dotyczy ukrytego niepowodzenia uwierzytelnienia w udokumentowanych okolicznościach słabych zasad lub braku zasad. Opisuje 109 jako przypadek, w którym nie Rekord DMARC istnieje, ale w przeciwnym razie wiadomość zostałaby przekazana. Są to definicje dostawców o określonym zakresie, a nie instrukcje dotyczące tworzenia nagłówka lub dowodu, że taki komunikat został tutaj zaobserwowany. Kody przyczyn firmy Microsoft
Zrozum bestguesspass bez powoływania się na opublikowane zasady
Etykieta dmarc=bestguesspass firmy Microsoft oznacza, że nie ma DMARC Rekord TXT istnieje, ale wiadomość zostałaby przekazana, gdyby domena ją posiadała. Nie należy zgłaszać jako dowodu, że domena opublikowała ważną politykę DMARC lub że rzeczywista standardowa ocena DMARC została zwrócona pozytywnie. Zachowaj dosłownie etykietę dostawcy i wyjaśnij jej ograniczone znaczenie. Wartości pól Microsoft DMARC
Nadawca przeglądający taki wynik powinien mimo to zweryfikować faktyczny porządek publiczny i zamierzoną konfigurację uwierzytelniania. Nie zakładaj, że złożony sukces eliminuje potrzebę wyraźnej polityki domeny lub gwarantuje, że inni odbiorcy dokonają takiej samej oceny. Heurystyka lub wnioskowanie specyficzne dla odbiorcy nie jest przenośnym zamiennikiem opublikowanych kontrolek domeny.
Sygnały ARC i ukryte nie przepisują podstawowych faktów
Firma Microsoft dokumentuje powód 130 jako zaufany ARC wynik uszczelniacza zastępuje błąd DMARC . Może to wyjaśniać złożony wynik w ścieżce przekazanej lub zapośredniczonej, ale nie oznacza to, że podstawowa awaria DMARC powinna zostać wymazana z dokumentacji dowodowej. Zachowaj rozpoznawalność oryginalnego wyniku, kontekstu ARC , przyczyny i ostatecznej obsługi. Nie twórz, że dowolny dowolny nagłówek ARC jest wystarczający; udokumentowany przypadek dotyczy zaufanego uszczelniacza. Powód Microsoftu 130
Podobnie firma Microsoft opisuje inne ukryte sygnały i zauważa, że awaria złożona nie powoduje bezpośrednio zablokowania. Ogólna ocena może pozwolić na przesłanie wiadomości pomimo tej awarii, podczas gdy inne technologie ochrony mogą zidentyfikować ryzyko w uwierzytelnionej poczcie. W związku z tym compauth=pass nie gwarantuje umieszczenia w skrzynce odbiorczej ani bezpieczeństwa treści, a compauth=fail nie jest sam w sobie dowodem odrzucenia. Wyjaśnienie obsługi firmy Microsoft
Ustal granicę zaufania nagłówka
Uzyskaj autoryzowaną oryginalną wiadomość od odpowiedniego odbiorcy i zidentyfikuj, który zaufany system wygenerował wyniki. RFC 8601 wyjaśnia dlaczego Authentication-Results asercje wymagają granicy zaufania. W ścieżce wiadomości może pojawić się wiele nagłówków, a niezaufany nadawca może wstawić tekst, który wygląda na wiarygodny. Nie wybieraj wystąpienia, które najlepiej pasuje do żądanego wniosku, bez śledzenia pochodzenia. RFC 8601
Zachowaj nienaruszony oryginał do wewnętrznej weryfikacji i oddzielną, zredagowaną kopię wyjaśniającą. Zmiana adresów lub podpisanej treści może uniemożliwić niezależną ponowną weryfikację kryptograficzną, dlatego należy odpowiednio oznaczyć kopię. Adnotacja może zachować relacje tożsamości do dyskusji, ale nie jest to oryginalna wiadomość, którą można na nowo zweryfikować. Jeśli odbiorca potrzebuje mocniejszych dowodów, zastosuj zatwierdzony proces bezpiecznego przekazywania, zamiast po cichu poszerzać zakres ujawnień.
Oryginalny arkusz z wynikami złożonymi
Poniższy proponowany arkusz umożliwia powtarzalność interpretacji pola. Nie jest on wypełniony prawdziwym komunikatem i nie należy go traktować jako zakończonej analizy uwierzytelniającej.
- Pochodzenie dowodu: odniesienie do otrzymanej wiadomości, odbiorca, znacznik czasu i zaufany weryfikator.
- Widoczna tożsamość: header.from i jego związek z nadawcą biznesowym.
- SPF : dokładny wynik, smtp.mailfrom i obserwowany kontekst źródłowy.
- DKIM : wynik dla każdego odpowiedniego podpisu i odpowiedniego nagłówka.d.
- DMARC : dokładna wartość pola dostawcy i oddzielnie zweryfikowany kontekst polityki.
- Złożone: wartość obliczeniowa, trzycyfrowy powód i cytowana definicja Microsoftu.
- Mediacja: spedycja, zaufany ARC lub inny faktycznie dostępny dowód trasy.
- Wynik: zaobserwowane postępowanie, niepoparte wnioski i potrzebne kolejne dowody.
Nie łącz wyników z różnych komunikatów w celu utworzenia syntetycznego rekordu all-pass. Próbka udanej dostawy bezpośredniej i próbka przesłanej niepowodzenia mogą ujawnić różnicę w trasach, ale każda z nich wymaga własnej tożsamości i sygnatury czasowej. Zachowaj niewiadome, gdy pole lub oryginalna wiadomość są niedostępne.
Fikcyjny przykład: wywnioskowany sukces jest mylony z wdrożeniem zasad
Fikcyjne biuro Seabright Desk widzi hipotetyczny raport zawierający dmarc=bestguesspass i compauth=pass reason=109. W proponowanym przeglądzie wyjaśniono, że udokumentowane znaczenie nie ustanawia opublikowanego rekordu DMARC . Właściciel poczty nadal sprawdzałby rzeczywiste zasady i potwierdzał zamierzone wdrożenie, zamiast oznaczać domenę jako ukończoną na podstawie samego złożonego wyniku.
W tej pracy nie istnieje nagłówek Seabright Desk, odpowiedź DNS ani wynik dzierżawy. Wartości służą wyłącznie do zilustrowania udokumentowanej interpretacji firmy Microsoft, a nie jako sfabrykowany dowód weryfikacji. Prawdziwa analiza wymaga oryginalnego przekazu i zaufanego kontekstu źródłowego.
Katalog wymaga aktualnych definicji pól firmy Microsoft i zredagowanego przykładu oryginalnej wiadomości. Definicje opierają się na źródle, ale brakuje dowodów na pierwotny przekaz. Oryginalne dowody, ludzkie MŚP, zastosowanie źródła, trasy produkcji, dostępność wizualna i zezwolenie właściciela pozostają otwarte. Niniejszy projekt stanowi przewodnik interpretacyjny, a nie zweryfikowaną ocenę najemcy.