Przewodnik po operacjach zabezpieczeń dotyczący uwierzytelniania poczty e-mail na platformie Microsoft 365

Email uwierzytelnianie jest kluczowym składnikiem zabezpieczania komunikacji w organizacji. Po odebraniu wiadomości e-mail w usłudze Microsoft 365 usługa dodaje nagłówek Authentication-Results . Ten nagłówek przedstawia wyniki różnych testów uwierzytelniania poczty e-mail, w tym SPF, DKIM, DMARC i uwierzytelniania złożonego (compauth).

W tym przewodniku wyjaśniono typowe scenariusze, które mogą wystąpić z następującymi wynikami:

• Dlaczego wiadomość została przekazana lub nie powiodło się uwierzytelnianie za pośrednictwem poczty e-mail.
• Czy źródło wiadomości e-mail lub miejsce docelowe wiadomości e-mail jest odpowiedzialne za wynik.
• Jakie akcje (jeśli istnieją) zalecamy ulepszanie wyników uwierzytelniania poczty e-mail.

Ale najpierw kilka definicji zgodnie z opisem w poniższej tabeli:

Email scenariusze z przekazywaniem uwierzytelniania

W tych scenariuszach opisano komunikaty, które przeszły testy uwierzytelniania poczty e-mail lub zostały zaakceptowane (czasami z powodu określonych konfiguracji). Ogólnie rzecz biorąc, po przejściu uwierzytelniania poczty e-mail nie jest wymagana żadna akcja naprawcza. Jednak niektóre scenariusze zawierają ostrzeżenia, w których zalecamy ulepszenia konfiguracji w celu zwiększenia bezpieczeństwa.

Nadawca odwołuje się do administratorów w organizacji źródłowej. Adresat odwołuje się do administratorów w organizacji docelowej.

Wszystkie zakończone testy uwierzytelniania

• Przykład nagłówka: dmarc=pass (i zazwyczaj spf=pass i dkim=pass).
• Co to oznacza: wszystkie testy uwierzytelniania poczty e-mail (SPF, DKIM i DMARC) zakończyły się pomyślnie. Ten wynik wskazuje, że komunikat jest w pełni uwierzytelniony zgodnie ze standardowymi protokołami uwierzytelniania poczty e-mail.
• Kto jest odpowiedzialny: nadawca.
• Zalecana akcja: Brak. uwierzytelnianie Email jest poprawnie skonfigurowane i działa zgodnie z oczekiwaniami. Adresat może zaufać domenie nadawcy, który prawidłowo uwierzytelnił tę wiadomość.

Pomyślnie przekazano uwierzytelnianie złożone

• Przykład nagłówka: compauth=pass (podanie uwierzytelniania złożonego).

• Co to oznacza: Komunikat przeszedł uwierzytelnianie złożone platformy Microsoft 365:

  • Wymagania DMARC zostały spełnione: przekazano protokół SPF lub DKIM , a adresy MAIL FROM i From są wyrównane.

    Lub

  • Niejawna logika zaufania firmy Microsoft zidentyfikowała komunikat jako uzasadniony. Na przykład komunikat może przekazywać uwierzytelnianie złożone na podstawie historii bezpiecznych nadawców firmy Microsoft lub fałszywych danych wywiadowczych wskazujących, że nadawca jest zaufany.

• Kto jest odpowiedzialny: nadawca.

• Zalecana akcja: Brak. Testy uwierzytelniania zakończyły się pomyślnie, a system nie wykrył żadnych problemów. W tym scenariuszu nie są potrzebne żadne zmiany dotyczące SPF ani DKIM.

Przekazywanie DMARC bez zasad DMARC (bez rekordu DMARC)

• Przykład nagłówka: dmarc=bestguesspass action=none
• Co to znaczy: komunikat domyślnie przeszedł DMARC, ponieważ domena nadawcy nie ma opublikowanego rekordu DMARC. Jeśli domena nie ma zasad DMARC, docelowe serwery poczty e-mail nie mogą zakończyć się niepowodzeniem komunikatu w usłudze DMARC. W praktyce sprawdzanie DMARC nie ma zastosowania. DMARC=bestguesspass action=none oznacza, że jeśli domena ma prawidłowy rekord DMARC, sprawdzanie DMARC dla komunikatu zostanie przekazane.
• Kto jest odpowiedzialny: nadawca.
• Zalecana akcja: nadawca powinien opublikować rekord DMARC dla swojej domeny. Mimo że komunikat został zaakceptowany, brak zasad DMARC nie jest dobrym znakiem. Zalecamy, aby właściciel domeny skonfigurował rekord DMARC TXT w celu wymuszenia zasad DMARC (p=quarantine lub p=reject) dla komunikatów, które nie walidują DMARC. Aby uzyskać więcej informacji, zobacz Składnia rekordów TXT DMARC.

Weryfikowane przez usługę ARC (złożone scenariusze routingu)

• Przykład nagłówka: compauth=pass reason=130 (uwierzytelnianie złożone zostało przekazane z powodu usługi ARC).
• Co to znaczy: komunikat przeszedł uwierzytelnianie z powodu zastąpienia uwierzytelnionego łańcucha odebranych odebranych (ARC ). Ten wynik zazwyczaj występuje w złożonych scenariuszach routingu poczty e-mail lub przekazywania wiadomości e-mail. Jeśli pośredni serwer poczty modyfikuje wiadomość i powoduje niepowodzenie SPF lub DKIM, zaufany sygnatura ARC informuje firmę Microsoft 365, że oryginalne uwierzytelnianie jest prawidłowe. W takim przypadku system zaakceptował komunikat na podstawie prawidłowego łańcucha ARC, mimo że bezpośrednie kontrole SPF lub DKIM mogą zakończyć się niepowodzeniem.
• Kto jest odpowiedzialny: Nadawca (oryginalny nadawca lub pośrednik). Nie ma błędnej konfiguracji. Pośrednik korzystający z usługi ARC przetworzył komunikat.
• Zalecana akcja: jeśli ten scenariusz jest oczekiwany, nie jest wymagana żadna akcja bezpośrednia (na przykład komunikat został przetworzony przez znaną usługę implementującego usługę ARC). Jeśli korzystasz z usługi pośredniczącej innej niż Microsoft, dodaj nagłówki USŁUGI ARC i sprawdź, czy serwery odbierające (takie jak Microsoft 365) ufają sygnaturom usługi ARC. Ta konfiguracja umożliwia komunikatom przychodzącym przekazywanie kompauth za pośrednictwem usługi ARC.

Komunikat dostarczony z powodu zezwalania na wpisy dla sfałszowanych nadawców na liście dozwolonych/zablokowanych dzierżaw

• Co to znaczy: komunikat pominął normalne akcje niepowodzenia uwierzytelniania, ponieważ zezwalaj na wpisy dla sfałszowanych nadawców istnieją na liście dozwolonych/zablokowanych dzierżaw. W usłudze Microsoft 365 wpis dozwolony dla sfałszowanych nadawców może zastąpić błędy. Nawet jeśli sprawdzanie uwierzytelniania poczty e-mail zwykle kończy się niepowodzeniem, komunikat jest dozwolony z powodu tej jawnej konfiguracji zaufania.

• Przykład nagłówka: compauth=fail reason=000 (ale zasady organizacji zezwalają na komunikat: Dozwolone fałszowanie zezwalania na dzierżawę/listy zablokowanych).

• Kto jest odpowiedzialny: adresat. Administratorzy w organizacji adresata skonfigurowali wpis zezwalający na fałszowanie na liście Zezwalanie/blokowanie dzierżawy dla tej konkretnej pary domen. Nadawca powinien rozwiązać problemy z uwierzytelnianiem, aby uniknąć problemów z dostarczaniem z innymi adresatami.

• Zalecana akcja: Administratorzy adresatów mogą sprawdzić sekcję Wszystkie przesłonięcia na stronie jednostki Email, aby sprawdzić, czy dotyczy to przesłonięcia listy dozwolonych/zablokowanych dzierżaw. Te komunikaty zawierają dozwolone przez zasady organizacji: Dozwolone fałszowanie listy dozwolonych/dozwolonych na liście blokad.

  Ogólnie rzecz biorąc, nie ma natychmiastowej akcji dla tych komunikatów, ponieważ są one celowo dozwolone. Jednak dobrym rozwiązaniem dla administratorów jest okresowe przeglądanie wpisów dozwolonych dla sfałszowanych nadawców , aby upewnić się, że dozwolone są tylko niezbędne nadawcy. Nadmierne użycie listy dozwolonych/zablokowanych dzierżawy umożliwia dostarczanie (prawdopodobnie złośliwych) komunikatów, które normalnie kończyłyby się niepowodzeniem sprawdzania uwierzytelniania.

Uwierzytelnione za pośrednictwem wyrównania PTR (odwrotny system DNS)

• Przykład nagłówka: compauth=pass z kodami takimi jak reason=116 lub reason=111 , aby wskazać użycie rekordu PTR.
• Co to znaczy: komunikat przeszedł uwierzytelnianie na podstawie weryfikacji PTR (reverse DNS) jako rezerwowy. W niektórych przypadkach, gdy testy SPF i DKIM nie dają jednoznacznego przebiegu, platforma Microsoft 365 może przyjrzeć się rekordowi PTR nadawcy. Jeśli adres IP serwera wysyłającego ma rekord PTR (odwrotny dns), który jest zgodny z domeną w komunikacie Z adresu, system może traktować komunikat jako uwierzytelniony.
• Kto jest odpowiedzialny: nadawca. Serwer poczty e-mail nadawcy został zweryfikowany za pośrednictwem rekordu PTR w systemie DNS. Ten wynik zwykle oznacza, że SPF i DKIM nie zostały poprawnie skonfigurowane, a system uciekał się do wyszukiwania PTR.
• Zalecana akcja: nadawca powinien upewnić się, że SPF i DKIM są prawidłowo skonfigurowane dla swojej domeny. Prawidłowy odwrotny rekord DNS (PTR), który mapuje domenę wysyłającą na wysyłany adres IP, jest dobry, ale nie zastępuje wyrównania DMARC. Nadawcy muszą traktować przekazywanie PTR jako wskaźnik, aby ulepszyć konfigurację SPF i DKIM. Nie ma żadnej akcji dla odbiorcy, poza powiadomieniem nadawców, gdy zauważą ten wynik.

scenariusze błędów uwierzytelniania Email

Te scenariusze obejmują nieudane testy uwierzytelniania lub inne warunki, w których komunikat jest oznaczony jako nieu uwierzytelniony. Niepowodzenie sprawdzania uwierzytelniania nie zawsze oznacza, że komunikat został odrzucony. Niektóre błędy powodują, że komunikat jest poddawany kwarantannie lub dostarczany z ostrzeżeniami. W poniższych scenariuszach opisano, dlaczego wystąpił błąd, kto musi go rozwiązać i jak rozwiązać podstawowy problem.

Nadawca odwołuje się do administratorów w organizacji źródłowej. Adresat odwołuje się do administratorów w organizacji docelowej.

Błąd DMARC (komunikat odrzucony lub poddany kwarantannie)

• Przykład nagłówka: dmarc=fail action=quarantine (lub action=reject); często towarzyszy mu compauth=fail kod (na przykład reason=000, reason=001lub reason=601).

• Co to znaczy: weryfikacja DMARC nie powiodła się dla komunikatu. Ten wynik oznacza:

  • SPF lub DKIM nie zostały przekazane z wyrównaniem dla domeny Z adresu.

    I

  • Rekord DMARC domeny Z adresu zawiera p=quarantine zasady lub p=reject .

  W rezultacie platforma Microsoft 365 oznaczyła komunikat dla określonej akcji zasad: dostarczenie do folderu Email śmieci, kwarantanna lub odrzucenie.

• Kto jest odpowiedzialny: nadawca lub adresat. Awaria jest spowodowana tym, że domena nadawcy nie przekazuje DMARC lub złożonej konfiguracji routingu poczty adresata, która spowodowała niepowodzenie DMARC.

  Podczas gdy nadawcy są odpowiedzialni za prawidłowe konfigurowanie SPF, DKIM i DMARC dla swojej domeny, błędy uwierzytelniania mogą czasami wynikać z problemów w organizacji adresata. Przykład:

  • Organizacja adresata korzysta z usługi filtrowania innej firmy niż Microsoft między internetem Microsoft 365 bez konfigurowania rozszerzonego filtrowania łączników. Weryfikacja SPF może zakończyć się niepowodzeniem, gdy platforma Microsoft 365 otrzyma komunikat.
  • Jeśli usługa filtrowania innych niż Microsoft modyfikuje komunikat przed dostarczeniem, program DKIM może zakończyć się niepowodzeniem, nawet jeśli rekord DKIM nadawcy jest poprawnie skonfigurowany.

  Dlatego ważne jest rozróżnienie między werdyktem w punkcie początkowego odbioru (rekord MX) a werdyktem, gdy wiadomość dotrze do skrzynki pocztowej odbiorcy.

• Zalecana akcja:

  • Nadawca musi naprawić konfigurację uwierzytelniania poczty e-mail. W szczególności nadawca musi wykonać następujące czynności:

    • Upewnij się , że rekord SPF zawiera wszystkie uzasadnione źródłowe adresy IP dla poczty e-mail z domeny.
    • Skonfiguruj usługę DKIM dla domeny i sprawdź, czy podpisy są prawidłowo stosowane do poczty wychodzącej.
    • Sprawdź, czy protokół SPF lub DKIM (lub oba) są przekazywane i są również zgodne z domeną Z adresu zgodnie z wymaganiami DMARC.
    • Sprawdź składnię rekordu DMARC i zasady DMARC. Na przykład p=quarantine lub p=reject.

  • Adresat musi naprawić złożoną konfigurację routingu poczty. W szczególności odbiorca musi wykonać następujące czynności:

    • Konfigurowanie rozszerzonego filtrowania dla łączników
    • Jeśli są dostępne, skonfiguruj zaufane uszczelnienia ARC w celu zastąpienia błędów spowodowanych modyfikacją komunikatów podczas przesyłania.
    • Rozważ użycie platformy Microsoft 365 do zastosowania modyfikacji komunikatów (stopek, zrzeczenia się odpowiedzialności, tematu itp.) zamiast usług innych niż Microsoft.

Sprawdzanie SPF nie powiodło się

• Przykład nagłówka: spf=fail lub spf=softfail. Zwróć uwagę na spf=temperror wskazywanie przejściowych problemów z systemem DNS lub spf=permerror wskazywanie problemów z konfiguracją SPF.

• Co to oznacza: Jedna z następujących możliwości:

  • Adres IP serwera wysyłającego nie jest autoryzowany przez rekord SPF domeny, więc zwrócony SPF kończy się niepowodzeniem.
  • Sprawdzanie SPF nie mogło przeprowadzić prawidłowo. Na przykład problem z wyszukiwaniem DNS (spf=temperror) lub zbyt wiele przekierowań (spf=permerror).

  Niepowodzenie SPF bez przekazania DMARC powoduje również niepowodzenie DMARC.

• Kto jest odpowiedzialny: nadawca. Problem dotyczy konfiguracji rekordu SPF domeny nadawcy lub konfiguracji serwera wysyłającego.

• Zalecana akcja: nadawca powinien zaktualizować i naprawić rekord SPF domeny:

  • Sprawdź , czy wszystkie prawidłowe źródłowe adresy IP domeny są uwzględnione w rekordzie SPF.
  • Jeśli program DMARC ulegnie awarii z powodu niezgodności domeny (domena adresu MAIL FROM różni się od domeny adresowej From), możesz rozwiązać ten problem, wykonując jedną lub obie następujące czynności:
    • Wyrównaj domeny używane w adresach MAIL FROM i From.
    • Skonfiguruj podpisywanie komunikatów wychodzących przez moduł DKIM przy użyciu domeny zgodnej z domeną Z adresu. DMARC wymaga weryfikacji SPF lub DKIM, a nie obu.
  • spf=temperror ogólnie wskazuje, że adresat miał problem z rozwiązaniem rekordu SPF (na przykład przejściowe problemy z systemem DNS). Nadawca powinien sprawdzić, czy serwery DNS dla ich domeny są w dobrej kondycji i osiągalne. Jeśli wartość czasu wygaśnięcia (TTL) jest zbyt niska i powoduje częste przekroczenia limitu czasu, rozważ zwiększenie czasu wygaśnięcia do co najmniej jednej godziny.
  • spf=permerror zazwyczaj wskazuje na problem z samym rekordem SPF, w tym wymaga więcej niż 10 wyszukiwań DNS. Uprościć rekord SPF, usuwając niepotrzebne include: instrukcje i poprawiając wszelkie błędy składni.

Rozwiązywanie problemów z filtrem SPF oznacza, że komunikaty częściej przechodzą uwierzytelnianie DMARC. Adresaci powinni powiadamiać nadawców o błędach SPF i zalecanych akcjach w celu rozwiązania problemów.

Sprawdzanie DKIM nie powiodło się (brak klucza do sygnatury)

• Przykład nagłówka: dkim=fail (brak klucza do sygnatury), jeśli brakuje klucza publicznego.

• Co to oznacza: Jedna z następujących możliwości:

  • Był podpis DKIM, ale adresat nie mógł znaleźć pasującego klucza publicznego w systemie DNS (bez klucza).

    Lub

  • Klucz nie jest zgodny z podpisem (nie można zweryfikować podpisu).

• Kto jest odpowiedzialny: nadawca. Domena nadawcy ma uszkodzoną konfigurację DKIM:

  • Klucz publiczny nie jest obecny w rekordzie CNAME lub TXT DKIM w systemie DNS.

    Lub

  • Występuje problem z systemem DNS po stronie nadawcy lub odbiorcy.

• Zalecana akcja: nadawca powinien poprawić konfigurację DKIM dla swojej domeny , wykonując następujące kroki:

  • Opublikuj klucz publiczny DKIM w systemie DNS. Sprawdź, selector._domainkey.contoso.comczy rekord CNAME lub TXT DKIM zawiera prawidłowy selektor (na przykład ), który jest zgodny z kluczem prywatnym używanym do podpisywania komunikatów.
  • Jeśli klucz zostanie opublikowany, prawdopodobnie wystąpił limit czasu, gdy platforma Microsoft 365 próbowała wykonać zapytanie dotyczące rekordu. Sprawdź, czy wartość czasu wygaśnięcia (TTL) jest ustawiona na co najmniej jedną godzinę.

Po prawidłowym skonfigurowaniu i wyrównaniu modułu DKIM adresaci zobaczą dkim=pass Komunikaty, co pomaga również przekazywać komunikaty DMARC.

DKIM nie powiodło się po modyfikacji (sygnatura nie została zweryfikowana)

• Przykład nagłówka: dkim=fail (Podpis nie został zweryfikowany).
• Co to znaczy: Komunikat zawierał prawidłowy podpis DKIM, ale weryfikacja DKIM nie powiodła się, ponieważ nagłówek zawarty w podpisie DKIM został zmodyfikowany podczas przesyłania po podpisaniu. Ta modyfikacja zazwyczaj występuje, gdy pośrednik (na przykład lista wysyłkowa, usługa przesyłania dalej lub urządzenie zabezpieczające) zmienia podpisany nagłówek (na przykład Subject:, From:lub To:) po pierwotnym zastosowaniu podpisu DKIM. Wartość h= w pliku DKIM-Signature identyfikuje nagłówki zawarte w oryginalnym skrótie. Modyfikowanie dowolnego z tych nagłówków powoduje błąd DKIM.
• Kto jest odpowiedzialny: nadawca lub pośrednik , który zmienił nagłówki wiadomości. Oryginalny nadawca poprawnie DKIM podpisał komunikat, ale pośrednik może być odpowiedzialny za uszkodzony podpis DKIM.
• Zalecana akcja: nie wprowadzaj zmian w nagłówkach po podpisaniu komunikatu przez moduł DKIM:
  • Nadawcy: sprawdź, czy podpisane nagłówki pozostają niezmienione od momentu, gdy komunikat jest podpisany przez moduł DKIM do momentu opuszczenia środowiska.
  • Pośrednicy: zezwalaj klientom na skonfigurowanie usługi jako zaufanego uszczelniacza ARC w celu zastąpienia błędów DKIM spowodowanych modyfikacją komunikatów podczas przesyłania.

Maszyna DKIM nie powiodła się po modyfikacji (skrót treści nie powiódł się)

• Przykład nagłówka: dkim=fail (skrót treści kończy się niepowodzeniem).
• Co to znaczy: komunikat zawierał prawidłowy podpis DKIM, ale weryfikacja DKIM nie powiodła się, ponieważ treść komunikatu została zmodyfikowana podczas przesyłania po podpisaniu. Ta modyfikacja zazwyczaj ma miejsce, gdy pośrednik (na przykład lista wysyłkowa, usługa przesyłania dalej lub urządzenie zabezpieczające) zmienia zawartość treści wiadomości po pierwotnie zastosowanym podpisie DKIM. Wynikiem jest wartość skrótu obliczona przez odbierający system poczty e-mail nie jest zgodna z skrótem w podpisie DKIM, więc sprawdzanie DKIM kończy się niepowodzeniem.
• Kto jest odpowiedzialny: nadawca lub pośrednik , który zmienił wiadomość. Oryginalny nadawca poprawnie DKIM podpisał komunikat, ale pośrednik może być odpowiedzialny za uszkodzony podpis DKIM.
• Zalecana akcja: Upewnij się, że po podpisaniu nie wprowadzono niezamierzonych zmian w zawartości wiadomości e-mail:
  • Nadawcy: Wykonaj następujące kroki:
    • Sprawdź, czy podpisane nagłówki pozostają niezmienione od momentu, gdy komunikat jest podpisany przez moduł DKIM do momentu opuszczenia środowiska.
    • Rozważ użycie platformy Microsoft 365 do zastosowania modyfikacji komunikatów (stopek, zrzeczenia się odpowiedzialności, tematu itp.) zamiast usług innych niż Microsoft.
  • Pośrednicy: zezwalaj klientom na skonfigurowanie usługi jako zaufanego uszczelniacza ARC w celu zastąpienia błędów DKIM spowodowanych modyfikacją komunikatów podczas przesyłania.

Tabela szybkich odwołań

Ta sekcja zawiera uproszczoną tabelę, która podsumowuje scenariusze, zalecane rozwiązania i linki do odpowiednich artykułów do dalszego czytania.

Nadawca odwołuje się do administratorów domeny wysyłającej. Adresat odwołuje się do administratorów organizacji odbierającej.

Najlepsze rozwiązania i porady

• Zaimplementuj SPF, DKIM i DMARC: te technologie wzajemnie się uzupełniają i zapewniają kompleksową ochronę. Nic mniej pozostawia luki w ochronie.

• Utrzymywanie rekordów DNS: aktualizuj rekordy SPF ze wszystkimi źródłami poczty e-mail. W razie potrzeby obracaj klucze DKIM i zarządzaj nimi oraz monitoruj raporty DMARC, aby zidentyfikować błędy uwierzytelniania.

• Monitorowanie wyników uwierzytelniania: regularnie sprawdzaj nagłówki Authentication-Results lub używaj narzędzi/raportów (na przykład analizy analizy fałszowania platformy Microsoft 365), aby zobaczyć, jak działają przychodzące komunikaty. To działanie może ujawnić partnerów, którzy nie skonfigurowali SPF/DKIM lub jeśli twój własny komunikat kończy się niepowodzeniem uwierzytelniania.

• Korzystanie z usługi ARC w scenariuszach przekazywania: jeśli organizacja przekazuje pocztę lub korzysta z usług innych niż Microsoft, które modyfikują komunikaty, rozważ skonfigurowanie zaufanych uszczelniaczy ARC na platformie Microsoft 365. Usługa ARC może pomóc zachować uwierzytelnianie i uniknąć fałszywych błędów podczas przesyłania komunikatów za pośrednictwem pośredników.

• Zachowaj ostrożność w przypadku list dozwolonych: polegaj na wynikach uwierzytelniania standardowego zawsze, gdy jest to możliwe, zamiast zezwalać na wpisy w organizacji. Wpisy zezwalania powinny być wyjątkami i powinny być okresowo sprawdzane w celu usunięcia niepotrzebnych wpisów.

• Bądź na bieżąco: postępuj zgodnie z następującymi zasobami:

  • blog Ochrona usługi Office 365 w usłudze Microsoft Defender
  • Blog zespołu programu Exchange
  • Co nowego w ochronie usługi Office 365 w usłudze Microsoft Defender?
  • Centrum komunikatów platformy Microsoft 365.