compauth=fail: Wyjaśnienie działania uwierzytelniania kompozytowego Microsoftu

Skonfigurowałeś już SPF, DKIM i DMARC, a Twoje wiadomości e-mail wciąż trafiają do folderu wiadomości-śmieci w programie Outlook. Przyczyną tego stanu rzeczy jest często komunikat „compauth=fail” – specyficzna dla Microsoftu warstwa uwierzytelniania, wykraczająca poza standardowe protokoły globalne. Zrozumienie, co oznacza ten komunikat diagnostyczny, czym różni się od DMARC oraz dlaczego po aktualizacjach z maja 2025 r. ma on większe znaczenie niż kiedykolwiek, ma kluczowe znaczenie dla utrzymania dostarczalności firmowej poczty elektronicznej.

Czym jest uwierzytelnianie złożone (compauth)?

Uwierzytelnianie złożone (compauth) to autorski system oceny uwierzytelniania firmy Microsoft, wykorzystywany przez usługę Exchange Online Protection (EOP) w usłudze Microsoft 365 oraz w programie Outlook.

W odróżnieniu od standardowych mechanizmów SPF, DKIM i DMARC, które działają jako wyraźne, oparte na standardach mechanizmy weryfikacyjne, compauth funkcjonuje jako złożony wskaźnik oceny ryzyka. Łączy on wyniki jawnego uwierzytelniania z zaawansowanymi sygnałami niejawnymi, takimi jak reputacja nadawcy, historyczne wzorce interakcji, wewnętrzne dane Microsoftu dotyczące fałszowania adresów oraz analiza behawioralna.

Ostateczny wynik oceny jest umieszczany w nagłówku „Authentication-Results” każdej wiadomości przychodzącej przetwarzanej przez Microsoft 365. W zależności od tego, jak wiadomość e-mail wypadnie w tej hybrydowej kontroli, w nagłówku pojawi się jedna z czterech możliwych wartości:

• compauth=pass: Komunikat przeszedł zarówno jawne kontrole uwierzytelniające, jak i niejawne oceny bezpieczeństwa.
• compauth=fail: Komunikat nie spełnił kryteriów uwierzytelniania złożonego firmy Microsoft i został oznaczony jako wysoce podejrzany.
• compauth=softpass: Komunikat został przekazany za pomocą sygnałów domyślnych lub opartych na reputacji, mimo braku solidnego, jawnego uwierzytelnienia.
• compauth=none: Nie przeprowadzono oceny uwierzytelniania złożonego dla tej wiadomości.

Aby uzyskać więcej informacji na temat konfiguracji uwierzytelniania wiadomości e-mail w usłudze Microsoft 365, zapoznaj się z naszym przewodnikiem dotyczącym protokołu DMARC dla usługi Office 365.

compauth a DMARC: jaka jest różnica?

Częstym źródłem niejasności dla administratorów systemów jest sytuacja, w której wiadomość e-mail przechodzi standardową weryfikację DMARC, a jednocześnie generuje status „compauth=fail”.

Z powodu tych różnic wiadomość może z łatwością przejść bezpośrednią weryfikację DMARC, a mimo to otrzymać status „compauth=fail”, jeśli modele uczenia maszynowego firmy Microsoft oznaczają ją jako nietypową (np. nowo zarejestrowana domena, nagły wzrost liczby wiadomości lub domena działająca zgodnie z pasywną polityką monitorowania p=none).

Z drugiej strony, wiadomość może nie przejść bezpośrednich testów SPF lub DKIM, ale uzyskać wynik „compauth=pass”, jeśli jej autentyczność zostanie potwierdzona przez system Microsoftu do wykrywania fałszerstw lub lokalną historię bezpiecznych nadawców (np. z kodem „reason=130” w wyniku nadpisania ARC lub „reason=201” w przypadku wewnętrznie zaufanych nadawców z usługi M365).

Czym są kody przyczyn w systemie Compauth?

Podczas analizy nagłówków wiadomości e-mail po ciągu znaków „compauth=fail” lub „compauth=pass” pojawia się konkretny trzycyfrowy kod przyczyny. Kod ten dokładnie wskazuje, dlaczego silnik filtrujący firmy Microsoft podjął taką decyzję.

Uwaga: Wszystkie kody błędów pochodzą bezpośrednio z oficjalnej dokumentacji technicznej firmy Microsoft. Aby szybko zdiagnozować problem z wysyłanymi wiadomościami, skopiuj surowe nagłówki wiadomości e-mail i wklej je do internetowego narzędzia Microsoft Message Header Analyzer.

Dlaczego parametr „compauth=fail” będzie miał większe znaczenie po maju 2025 r.

Skutki operacyjne wyniku „compauth=fail” stały się znacznie poważniejsze po wprowadzeniu przez firmę Microsoft 5 maja 2025 r. nowych zasad egzekwowania. Wymagania dotyczące nadawców określone przez firmę Microsoft wprowadziły rygorystyczne, zautomatyzowane zasady uwierzytelniania wiadomości e-mail skierowane do nadawców wysyłających duże ilości wiadomości (co najmniej 5000 wiadomości dziennie) do punktów końcowych użytkowników końcowych, takich jak Outlook.com, Hotmail i Live.com.

W ramach tych zaktualizowanych mechanizmów egzekwowania klasyfikacja „compauth=fail” oznacza bezpośrednio agresywne przenoszenie wiadomości do folderu ze spamem lub całkowite odrzucenie wiadomości na poziomie bramy. Filtracja firmy Microsoft traktuje obecnie politykę DMARC typu „p=none” jako główny czynnik wywołujący kod „reason=001”, nawet jeśli testy SPF i DKIM zakończą się pozytywnie. Nadawcy, których wiadomości były wcześniej akceptowane w trybie pasywnego monitorowania, muszą się teraz liczyć z nagłym i znacząco zakłócającym działanie spadkiem dostarczalności we wszystkich środowiskach zarządzanych przez Microsoft.

Co powoduje błąd „compauth=fail”?

Aby rozwiązać problemy z dostawą, należy dopasować konkretny kod błędu znajdujący się w nagłówku „Authentication-Results” do jego rzeczywistej przyczyny:

• reason=000: Domena nadawcy stosuje rygorystyczną politykę DMARC typu p=reject lub p=quarantine, a wiadomość nie przeszła weryfikacji ani SPF, ani DKIM. Szczegółowe instrukcje dotyczące rozwiązywania problemów z uwierzytelnianiem znajdziesz w naszym przewodniku wyjaśniającym przyczyny niepowodzeń DMARC.
• reason=001 (Standard): Jest to najczęściej występujący kod błędu. Wskazuje on na domenę stosującą pasywną politykę monitorowania p=none, całkowity brak rekordu DMARC, niezoptymalizowany miękki błąd SPF (~all) lub niezgodność domen identyfikatorów.
• reason=001 i reason=601 (nadawcy zewnętrzni): Sytuacja ta ma miejsce, gdy zewnętrzny dostawca usług pocztowych (ESP) lub system CRM wysyła wiadomości w imieniu Twojej marki, ale podpisuje je przy użyciu domen należących do własnej infrastruktury. Ponieważ widoczna domena w nagłówku „From” nie zgadza się z domenami śledzącymi używanymi przez dostawcę, uruchamiany jest krytyczny błąd niezgodności.
• powód=010: System wykrywania fałszywych wiadomości firmy Microsoft zidentyfikował zachowanie nadawcy jako podejrzane, wskazujące na phishing lub podszywanie się pod domenę.

Jak naprawić błąd „compauth=fail”

Naprawienie błędu uwierzytelniania złożonego wymaga wprowadzenia ukierunkowanych zmian w konfiguracji, dostosowanych do konkretnej sytuacji, która spowodowała ten błąd.

Rozwiązanie 1: Zaktualizuj swoją politykę DMARC, rezygnując z ustawienia p=none

Ponieważ polityka monitorowania pasywnego (p=none) jest traktowana jako domyślna porażka uwierzytelnienia (reason=001), należy stopniowo dostosowywać swoją domenę do trybu egzekwowania. Należy bezpiecznie przejść do polityki p=quarantine lub p=reject. Odejście od podejścia opartego wyłącznie na monitorowaniu eliminuje lukę, która powoduje uruchamianie reguł domyślnej porażki. Jeśli obawiasz się, że podczas tego przejścia mogą zostać zablokowane uzasadnione strumienie danych pochodzących ze starszych systemów, zapoznaj się z naszymi strategiami zarządzania nadpisywaniem polityki DMARC.

Rozwiązanie 2: Zapewnienie dokładnej zgodności DKIM

Skonfiguruj swoje główne serwery pocztowe tak, aby podpisywały wszystkie wychodzące wiadomości przy użyciu unikalnego klucza kryptograficznego DKIM. Upewnij się, że parametr domeny podpisującej (d=) w nagłówku DKIM idealnie pokrywa się z domeną główną wyświetlaną w widocznym nagłówku „Od:”. Ta ścisła zgodność kryptograficzna stanowi najsilniejszy możliwy sygnał potwierdzający dla silnika CompAuth firmy Microsoft.

Rozwiązanie 3: Skonfiguruj niestandardowe ścieżki zwrotne dla zewnętrznych dostawców usług e-mailowych

Korzystając z platform zewnętrznych (takich jak narzędzia marketingowe lub systemy obsługi klienta), nie należy polegać na ich domyślnych, ogólnych ustawieniach. Należy skonfigurować niestandardową domenę MAIL FROM lub Return-Path, wykorzystującą własną nazwę domeny firmy, albo upewnić się, że dostawca posiada pełne uprawnienia do kryptograficznego podpisywania wiadomości przy użyciu kluczy DKIM należących do tej domeny. Rozwiązuje to problem niezgodności identyfikatorów i eliminuje błędy typu „reason=601”.

Poprawka nr 4 i przyszłość przekazywania wiadomości (przejście z ARC na DKIM2)

W przeszłości, jeśli przepływ poczty w organizacji rutynowo przechodził przez listy mailingowe lub automatyczne łańcuchy przekazywania wiadomości, standardowe podpisy DKIM ulegały uszkodzeniu. Aby rozwiązać ten problem, należy wdrożyć Authenticated Received Chain (ARC) . Gdy serwer pośredniczący weryfikuje przychodzącą wiadomość i plombuje ją za pomocą zaufanego pieczęci kryptograficznej, Microsoft 365 odczytuje łańcuch nadzoru, ignorując lokalne awarie i generując wynik pomyślny compauth=pass reason=130.

Sytuacja w zakresie uwierzytelniania poczty elektronicznej ulega jednak dynamicznym zmianom. 22 kwietnia 2026 r. w projekcie grupy roboczej IETF ds. DMARC (draft-ietf-dmarc-arc-to-historic-00) zaproponowano przeklasyfikowanie protokołu ARC jako standardu historycznego. Jest to roboczy projekt internetowy grupy roboczej, a nie ostateczny dokument RFC; protokół ARC (RFC 8617) pozostaje protokołem aktywnym.

Wnioski wyciągnięte z projektu ARC są w naturalny sposób włączane do powstającej specyfikacji DKIM2, która rozwiązuje problem uszkodzonych podpisów podczas przekazywania wiadomości oraz ataków typu DKIM replay. Zgodnie z najnowszym projektem IETF z 17 maja 2026 r. (draft-ietf-dkim-dkim2-spec-02) każdy system, który ma kontakt z wiadomością, rejestruje zmiany i dołącza swój własny podpis do nieprzerwanego łańcucha kontroli.

Co to oznacza dla Ciebie w tej chwili:

• Na razie pozostaw funkcję ARC włączoną: firma Microsoft nadal wykorzystuje parametr reason=130 (zastąpienie ARC) do przekazywania wiadomości e-mail, więc nie usuwaj jeszcze konfiguracji certyfikatu Microsoft Trusted ARC Seal.
• Przygotuj się na DKIM2: Niektórzy główni dostawcy usług pocztowych mogą rozpocząć wdrażanie tej technologii pod koniec 2026 roku, choć specyfikacja pozostaje na wczesnym etapie opracowywania. Ponieważ klucze DKIM2 będą wykorzystywać istniejącą strukturę rekordów DNS, najlepszym zabezpieczeniem przed przyszłymi błędami uwierzytelniania jest zapewnienie, by obecna infrastruktura DKIM działała bez zarzutu. Usuń zbędne selektory i zadbaj o prawidłową rotację kluczy.

Rozwiązanie 5: Wykorzystaj funkcję „Spoof Intelligence” w usłudze M365, aby zezwolić na dostęp

W przypadku aplikacji wewnętrznych, starszych urządzeń lokalnych lub wysoce wyspecjalizowanych profili legalnych nadawców, które powodują automatyczne fałszywe alarmy generowane przez system uczenia maszynowego (kod przyczyny = 010), administratorzy usługi Microsoft 365 mogą ręcznie zastąpić działanie algorytmu. Należy przejść do portalu Microsoft 365 Defender, otworzyć konsolę analizy Spoof Intelligence i dodać wpis wyraźnie zezwalający do listy zezwoleń/blokad dzierżawcy dla tego konkretnego profilu nadawcy.

Jak odczytywać pole „compauth” w nagłówkach wiadomości e-mail

Aby zlokalizować i zidentyfikować te wartości, konieczne jest wyodrębnienie surowych nagłówków routingu internetowego z danej wiadomości.

1. Wyodrębnij nagłówki: W komputerowej wersji programu Outlook otwórz docelową wiadomość e-mail w osobnym oknie i przejdź do menu Plik > Właściwości > Nagłówki internetowe. Alternatywnie, jeśli jesteś administratorem zajmującym się rozwiązywaniem szerszego problemu z dostarczaniem wiadomości, poproś użytkowników lub skorzystaj z dzienników administracyjnych, aby skopiować surowy tekst nagłówka i wkleić go bezpośrednio do narzędzia Microsoft Message Header Analyzer (MHA) pod adresem mha.azurewebsites.net, gdzie uzyskasz przejrzysty, przeanalizowany widok.
2. Wyszukaj odpowiedni wiersz: Przejrzyj przeanalizowany tekst w poszukiwaniu konkretnego bloku oznaczonego jako „Authentication-Results”. Zwróć szczególną uwagę na frazę „compauth=”, po której bezpośrednio następuje status oceny (pass, fail lub softpass) oraz odpowiadający mu kod reason=.
3. Porównaj dane: Nie należy rozpatrywać zbiorczego wyniku uwierzytelniania w oderwaniu od kontekstu. Należy sprawdzić sąsiednie parametry w tej samej linii nagłówka, zwracając szczególną uwagę na poszczególne wyniki spf=, dkim= i dmarc=. Porównanie tych konkretnych wartości z kodem przyczyny compauth pozwala dokładnie ustalić, która kontrola zakończyła się niepowodzeniem lub który sygnał pośredni spowodował przekierowanie wiadomości do folderu ze spamem.

Jak na stałe zapobiec błędom typu „compauth=fail”?

Ręczna analiza nagłówków i koordynacja ich ujednolicenia w przypadku kilkunastu zewnętrznych dostawców może stanowić ogromne obciążenie dla wewnętrznych zespołów IT. PowerDMARC upraszcza ten proces, zapewniając pełny wgląd w dane oraz narzędzia do automatycznego zarządzania, pomagając w usuwaniu błędów typu „compauth=fail” i utrzymywaniu porządku w rejestrach uwierzytelniania poczty elektronicznej.

Rozpocznij bezpłatny okres próbny usługi DMARC już dziś, aby uzyskać pełny wgląd w procesy dostarczania wiadomości w usłudze Microsoft 365, wyeliminować błędy w konfiguracji i bezpiecznie przestawić swoją domenę na obowiązkową politykę DMARC.

Najczęściej zadawane pytania

Co oznacza wpis „compauth=fail” w nagłówkach wiadomości e-mail?

Oznacza to, że system Exchange Online Protection firmy Microsoft przeanalizował przychodzącą wiadomość i odrzucił ją na podstawie połączenia jawnych protokołów uwierzytelniających (SPF, DKIM, DMARC) oraz niejawnych sygnałów dotyczących zagrożeń (reputacja nadawcy, dane o fałszowaniu adresów, historia).

Jaka jest różnica między Compauth a DMARC?

DMARC to otwarty, globalny protokół internetowy wykorzystywany przez wszystkich dostawców usług pocztowych do sprawdzania zgodności identyfikatorów. compauth to zastrzeżona, dostępna wyłącznie w systemie Microsoft warstwa analityczna, która wykorzystuje standardowe wyniki DMARC oraz uwzględnia dodatkowe wskaźniki reputacji i zachowań w czasie rzeczywistym.

Dlaczego weryfikacja Compauth kończy się niepowodzeniem, mimo że SPF i DKIM przeszły pomyślnie?

Sytuacja ta zdarza się często, gdy domena jest skonfigurowana z pasywną polityką DMARC (p=none), którą zaktualizowany system Microsoftu traktuje jako zagrożenie dla dostarczalności. Błąd może również wystąpić, jeśli wewnętrzny system Microsoftu do wykrywania fałszywych adresów (spoof intelligence) zidentyfikuje zachowanie transakcyjne nadawcy lub historię wysyłek jako nietypowe.

Co oznacza komunikat o błędzie „compauth fail reason=001”?

Kod błędu 001 oznacza, że wiadomość nie spełniła kryteriów uwierzytelniania domyślnego firmy Microsoft. Przyczyną tego stanu rzeczy jest zazwyczaj brak rekordów DMARC lub SPF, niezgodność identyfikatorów lub stosowanie pasywnej polityki DMARC (p=none) zamiast przejścia do etapu egzekwowania.

Jak naprawić błąd „compauth=fail” w usłudze Microsoft 365?

Upewnij się, że domeny SPF i DKIM są dokładnie zgodne z widocznym nagłówkiem „From”, zmień ustawienia polityki DMARC z p=none na tryb egzekwowania, np. p=quarantine lub p=reject, oraz skonfiguruj zaufane pieczęcie ARC, jeśli w obiegu poczty występuje automatyczne przekazywanie wiadomości.

Czy ustawienie „compauth=fail” powoduje, że wiadomości e-mail trafiają do folderu „Spam” w programie Outlook?

Tak. Zgodnie z rygorystycznymi zasadami bezpieczeństwa status „compauth=fail” powoduje, że moduł filtrujący EOP kieruje przychodzące wiadomości bezpośrednio do folderu ze spamem lub odrzuca je całkowicie na granicy sieci.

• O
• Latest Posts

Yunes Tarada

Ekspert ds. bezpieczeństwa domen i poczty e-mail w PowerDMARC

Yunes jest liderem zespołu operacyjnego w PowerDMARC z wiedzą ekspercką w zakresie uwierzytelniania i bezpieczeństwa poczty elektronicznej. Yunes jest certyfikowanym przez Microsoft Azure Administrator Associate z certyfikatami CompTIA A+ i wieloma innymi.

Najnowsze posty autorstwa Yunes Tarada (zobacz wszystkie)

• Jak podzielić rekord DKIM - 5 czerwca 2026 r.
• compauth=fail: Wyjaśnienie uwierzytelniania kompozytowego Microsoftu - 1 czerwca 2026 r.
• Czy program Windows Defender wystarczy do zapewnienia bezpieczeństwa w małej firmie? - 14 maja 2026 r.