Blazalek.com

Błędy uwierzytelniania i DNS: zdiagnozuj ścieżkę wysyłki objętą problemem

Na tej stronie

Incydenty uwierzytelniania i DNS występują, gdy system odbierający nie może potwierdzić tożsamości albo ścieżki sieciowej deklarowanej przez wiadomość. Zdiagnozuj konkretny mechanizm — autoryzację SPF, podpis DKIM, zgodność domen w DMARC albo spójność DNS w przód i wstecz — dla właściwej domeny wysyłającej i ścieżki odbiorcy.

Widoczne objawy

  • Dlaczego DMARC nie przechodzi, mimo że SPF lub DKIM na pozór przechodzi
  • Dlaczego SPF nie przechodzi dla naszej domeny wysyłkowej
  • Dlaczego DMARC nie przechodzi i którą przyczynę sprawdzić w pierwszej kolejności
  • Dlaczego poczta jest odrzucana z powodu braku reverse DNS lub rekordu PTR

Grupy przyczyn

Tożsamość domeny i zgodność domen

  • SPF może autoryzować nadawcę kopertowego, a DMARC i tak może nie przejść, gdy domena widoczna w polu From nie jest zgodna.
  • Podpis DKIM może przechodzić weryfikację kryptograficzną, ale używać domeny, która nie spełnia wymogu zgodności domen w DMARC.

Publikacja DNS i host wysyłający

  • Niepełny rekord SPF, brak rekordu selektora lub limit odwołań DNS może powodować błąd uwierzytelnienia dla jednego nadawcy.
  • IP wysyłający bez zgodnego DNS w przód i PTR może zostać odrzucony przed oceną treści wiadomości.

Interpretacja po stronie odbiorcy

  • Microsoft 365 i inni odbiorcy pokazują inną diagnostykę; zachowaj pierwotny wynik odbiorcy przed zmianą DNS.

Pierwsze bezpieczne kontrole

  1. Zachowaj Authentication-Results, odpowiedź SMTP, nadawcę kopertowego, domenę From, domenę d= DKIM, IP wysyłające oraz rekordy DNS z czasu incydentu.
  2. Oddziel wysyłkę bezpośrednią od przekierowań i ruchu przez zewnętrznego ESP; nie testuj zmiany DNS na niepowiązanej tożsamości nadawcy.
  3. Wybierz runbook według mechanizmu wskazanego w diagnostyce odbiorcy, zanim zmienisz SPF, DKIM, DMARC albo PTR.

Zasady rozwiązania

  • Wprowadź najmniejszą korektę rekordu lub konfiguracji, która usuwa potwierdzony błąd, a następnie wyślij kontrolowaną wiadomość tą samą ścieżką.
  • Potwierdź zarówno rozwiązywanie DNS, jak i wynik uwierzytelnienia lub diagnostykę SMTP po stronie odbiorcy; sama publikacja rekordu nie oznacza odzyskania działania.

Wybierz runbook

Wybierz nieudany sygnał uwierzytelnienia lub DNS. Każda ścieżka wskazuje relację domen albo rekord sieciowy do sprawdzenia w pierwszej kolejności.

Macierz diagnostyczna

ObjawObszarPierwsza kontrola
Dlaczego DMARC nie przechodzi, mimo że SPF lub DKIM na pozór przechodziZgodność DMARC domeny From i domeny uwierzytelnionejPorównaj From, envelope-from, d= DKIM i Authentication-Results w wiadomości z błędem.
Dlaczego SPF nie przechodzi dla naszej domeny wysyłkowejRekord SPF i autoryzacja nadawcy kopertowegoRozwiąż rekord SPF nadawcy kopertowego oraz zachowaj wynik SPF odbiorcy i IP wysyłające.
Dlaczego DMARC nie przechodzi i którą przyczynę sprawdzić w pierwszej kolejnościMechanizm DMARC i wynik polityki odbiorcyZachowaj wynik DMARC wraz ze zgodnymi tożsamościami SPF/DKIM oraz informacją, czy wiadomość była przekierowana.
Dlaczego poczta jest odrzucana z powodu braku reverse DNS lub rekordu PTRPotwierdzony DNS wsteczny IP wysyłającegoOdpytaj PTR IP oraz rekord A/AAAA zwróconej nazwy, zanim poprosisz hosta o zmianę PTR.
Dlaczego uwierzytelnianie poczty zawodzi w Microsoft 365 i który test — SPF, DKIM czy DMARC — się nie powiódłDiagnostyka uwierzytelnienia Microsoft 365Zachowaj nagłówki wiadomości i diagnostykę Microsoft wskazującą niespełniony test SPF, DKIM albo DMARC.

Zacznij od dokładnego objawu i dowodów, a naprawę potwierdź, zanim wznowisz ścieżkę wysyłki objętą problemem.

Dlaczego DMARC nie przechodzi, mimo że SPF lub DKIM na pozór przechodzi?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

DMARC nie przechodzi, gdy pozytywny wynik SPF lub DKIM nie jest zgodny (aligned) z domeną From wg RFC 5322. Porównaj domenę SPF MailFrom oraz każdą domenę DKIM d= z wynikiem pass z domeną From, stosując opublikowany tryb ścisły (strict) lub luźny (relaxed). Nawet poprawiony wynik pass DMARC nie gwarantuje trafienia do skrzynki odbiorczej, bo ostateczna obsługa pozostaje w gestii lokalnej polityki.

Pierwsze 15 minut

  1. Porównaj uwierzytelnioną przez SPF domenę MailFrom oraz każdą domenę DKIM d= z wynikiem pass z domeną From wg RFC 5322.
  2. Sprawdź w rekordzie DMARC tryb zgodności domen (alignment): luźny (relaxed) czy ścisły (strict).
  3. Potwierdź, że co najmniej jeden uwierzytelniony identyfikator przechodzi i jest zgodny z domeną autora.

Teraz

  • Doprowadź do zgodności co najmniej jedną uwierzytelnioną, zaliczoną domenę SPF lub DKIM z domeną autora From wg RFC 5322.

Najbliższe 24 godziny

  • Odbieraj i analizuj raporty zbiorcze DMARC, aby wskazać autoryzowane źródła i pozostałe luki w uwierzytelnianiu.

Najbliższe 7 dni

  • Popraw autoryzowane źródła, które w raportach zbiorczych wciąż wykazują luki w uwierzytelnianiu lub zgodności domen.

Kontrole techniczne

IT / DNS

  • Porównaj MailFrom oraz każdą domenę DKIM d= z wynikiem pass z domeną From wg RFC 5322, stosując wybrany tryb zgodności domen (alignment).
  • Potwierdź, że DMARC daje wynik pass tylko wtedy, gdy zgodny jest co najmniej jeden uwierzytelniony identyfikator.

Kryteria weryfikacji

  • Potwierdź, że bieżąca wiadomość dostaje wynik pass DMARC dzięki temu, że co najmniej jeden uwierzytelniony identyfikator przechodzi i jest zgodny z domeną autora.
  • Potwierdź, że raporty zbiorcze wskazują autoryzowane źródła i pokazują, czy pozostają jeszcze luki w uwierzytelnianiu.

Kryteria eskalacji

  • Eskaluj sprawę do właścicieli DNS lub zespołu ds. dostarczalności, gdy raporty zbiorcze wciąż pokazują autoryzowane źródła z lukami w uwierzytelnianiu.
  • Pozostałe problemy z trafieniem do skrzynki odbiorczej eskaluj osobno, gdy DMARC już przechodzi, bo obsługa po stronie odbiorcy nadal zależy od lokalnej polityki.

Zapobieganie

  • Utrzymuj co najmniej jedną uwierzytelnioną domenę SPF lub DKIM w zgodności z domeną From wg RFC 5322.
  • Przeglądaj raporty zbiorcze DMARC, aby autoryzowane źródła i luki w uwierzytelnianiu pozostawały widoczne.

Wpływ na biznes

  • Pozytywny, lecz niezgodny (unaligned) wynik SPF lub DKIM nie wystarcza dla DMARC, a nawet pozytywny wynik DMARC nie gwarantuje trafienia do skrzynki odbiorczej.

Otwarte pytania

  • Nie da się wskazać ścieżki, na której następuje błąd, bez wartości Authentication-Results, From, Return-Path oraz DKIM d= z rzeczywiście odebranej wiadomości.
  • Sposób postępowania odbiorcy po niepowodzeniu DMARC wynika z lokalnej polityki i może się różnić nawet przy identycznym wyniku protokołu.
  • Serwery przekazujące i pośrednicy mogą zmienić wyniki SPF lub DKIM; zanim wskażesz winnego, sprawdź rzeczywistą ścieżkę wiadomości.
Źródła (6)
  1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Introduction, paragraphs 4-5IETF RFC 9989
  2. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Introduction, paragraph 5; Identifier AlignmentIETF RFC 9989
  3. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Sections 4.4, 5.3.3 and 5.3.4IETF RFC 9989
  4. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Section 5.3.5, Determine DMARC Pass or FailIETF RFC 9989
  5. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Sections 5.1 and 5.1.3-5.1.5IETF RFC 9989
  6. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Introduction paragraph 6 and Section 5.4IETF RFC 9989

Dlaczego SPF nie przechodzi dla naszej domeny wysyłkowej?

Poziom ważności: ŚredniWstrzymanie wysyłki: Wstrzymaj warunkowo

Zacznij od tożsamości, którą SPF faktycznie ocenił: domeny MAIL FROM albo — gdy ścieżka zwrotna (Return-Path) jest pusta — domeny HELO, a nie od widocznego adresu From. Następnie odróżnij trwały błąd autoryzacji od problemu z wieloma rekordami lub składnią, od przekroczenia limitu dziesięciu zapytań DNS oraz od przejściowych błędów DNS. Uwzględnij każdego aktywnego nadawcę dla ocenianej tożsamości i potwierdź wynik w świeżo odebranej wiadomości.

Pierwsze 15 minut

  1. Zapisz adres IP nadawcy, tożsamość MAIL FROM lub zastępczą tożsamość HELO, odpowiedź DNS oraz otrzymaną wartość Authentication-Results.
  2. Sprawdź, czy nie ma wielu rekordów SPF, błędów składni, więcej niż dziesięciu elementów odpytujących DNS ani przejściowych błędów wyszukiwania DNS.
  3. Spisz wszystkie usługi, które obecnie wysyłają dla ocenianej tożsamości.

Teraz

  • Jeśli autorytatywny DNS pokazuje wiele rekordów SPF albo błąd składni, popraw ten rekord; jeśli aktywnego nadawcy brakuje w ocenianej tożsamości MAIL FROM lub HELO, dodaj jego autoryzację.

Najbliższe 24 godziny

  • Tylko jeśli ocena SPF przekracza dziesięć rekurencyjnych elementów odpytujących DNS, ogranicz ich liczbę do limitu z RFC.

Najbliższe 7 dni

  • Wprowadź kontrolę zmian przy dodawaniu nowych nadawców, aby rekord SPF był aktualizowany, gdy nowa usługa zaczyna wysyłać.

Kontrole techniczne

IT / DNS

  • Odpytaj rekord SPF TXT dla tożsamości MAIL FROM, a gdy ścieżka zwrotna jest pusta — dla tożsamości HELO.
  • Sprawdź, czy istnieje jeden poprawny składniowo rekord SPF i nie więcej niż dziesięć elementów wywołujących rekurencyjne zapytania DNS.
  • Odróżnij temperror wywołany przekroczeniem czasu DNS lub awarią serwera od trwałego błędu autoryzacji albo permerror.

Inżynieria

  • Zestaw ocenianą tożsamość i adres IP nadawcy ze wszystkimi aktywnymi usługami wysyłkowymi, które musi autoryzować rekord SPF.

Kryteria weryfikacji

  • Świeżo odebrana wiadomość pokazuje w nagłówkach działający SPF po propagacji DNS, która — jak zaznacza Google — może potrwać do 48 godzin.

Kryteria eskalacji

  • Eskaluj sprawę do zespołu DNS lub dostawcy usług wysyłkowych, gdy temperror się utrzymuje albo poprawiony rekord nadal zwraca permerror po sprawdzeniu autorytatywnych źródeł i odebranych wiadomości.

Zapobieganie

  • Utrzymuj jeden poprawny rekord SPF, który obejmuje każdego aktywnego nadawcę i mieści się w limicie dziesięciu elementów odpytujących DNS.

Wpływ na biznes

  • Poczta z pominiętej usługi wysyłkowej nie jest autoryzowana przez rekord SPF dla ocenianej tożsamości, a zmiana w DNS może propagować się nawet do 48 godzin, zanim świeżo odebrana wiadomość pokaże działający SPF.

Uwagi dostawcy

  • Google zaleca weryfikację na podstawie nagłówków i zaznacza, że zmiany w DNS mogą potrwać do 48 godzin, zanim SPF zacznie działać.

Otwarte pytania

  • Nie podano odpowiedzi DNS, rekordu SPF TXT, ocenianej domeny MAIL FROM lub HELO, adresu IP nadawcy ani otrzymanego nagłówka Authentication-Results.
  • Wynikiem może być trwały fail, permerror, temperror, none albo błąd zgodności domen DMARC (alignment) błędnie oznaczony jako SPF; trzeba zachować dokładny wynik.
  • To, jak odbiorca traktuje wyniki SPF, zależy od jego lokalnej polityki, a czas propagacji DNS różni się w zależności od dostawcy i pamięci podręcznej resolvera.
Źródła (6)
  1. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — Section 4.1, ArgumentsIETF RFC 7208
  2. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — Sections 4.5 and 4.6IETF RFC 7208
  3. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — Section 4.6.4, DNS Lookup LimitsIETF RFC 7208
  4. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — Section 4.4, Record LookupIETF RFC 7208
  5. Troubleshoot SPF issues — SPF record doesn't include all email senders for your domainGoogle Workspace
  6. Troubleshoot SPF issues — Basic troubleshooting for SPFGoogle Workspace

Dlaczego DMARC nie przechodzi i którą przyczynę sprawdzić w pierwszej kolejności?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Zacznij od nagłówka Authentication-Results wygenerowanego przez odbiorcę dla wiadomości objętej incydentem, a nie od zmian w DNS. Ustal, czy wynik pass uzyskała zgodna domena MAIL FROM uwierzytelniona przez SPF, czy zgodna, prawidłowa domena DKIM d=, a potem zbadaj drugą gałąź oraz właściwy rekord TXT _dmarc. Nie osłabiaj istniejącej polityki egzekwującej, dopóki nie zidentyfikujesz i nie naprawisz legalnych strumieni bez uwierzytelnienia lub bez zgodności domen.

Pierwsze 15 minut

  1. Zbierz z wiadomości objętej incydentem nagłówek Authentication-Results oraz domeny From (RFC 5322), MAIL FROM i DKIM d=.
  2. Sprawdź, czy domena MAIL FROM uwierzytelniona przez SPF przechodzi weryfikację i jest zgodna z domeną autora.
  3. Sprawdź, czy którakolwiek prawidłowa domena DKIM d= jest zgodna z domeną autora.
  4. Sprawdź właściwy rekord TXT _dmarc i potwierdź, że v=DMARC1 jest pierwszym tagiem.

Teraz

  • Popraw tożsamość MAIL FROM, gdy SPF przechodzi pomyślnie, ale jego uwierzytelniona domena nie jest zgodna z domeną autora.
  • Popraw tożsamość podpisującą DKIM, gdy prawidłowy podpis używa niezgodnej domeny d=.
  • Napraw brakujący, źle umieszczony lub błędnie sformatowany tag wersji DMARC we właściwym rekordzie _dmarc.

Najbliższe 24 godziny

  • Kontynuuj monitorowanie z raportowaniem zbiorczym, dopóki naprawiasz legalne strumienie bez uwierzytelnienia lub bez zgodności domen.

Najbliższe 7 dni

  • Przechodź do egzekwowania dopiero po zinwentaryzowaniu legalnych źródeł oraz naprawieniu ich luk w uwierzytelnianiu i zgodności domen.

Kontrole techniczne

Dostarczalność

  • Porównaj wygenerowane przez odbiorcę wyniki pass i zgodności domen dla SPF oraz DKIM w wiadomości objętej incydentem.

IT / DNS

  • Sprawdź lokalizację właściwego rekordu _dmarc TXT i upewnij się, że v=DMARC1 jest jego pierwszym tagiem.

Inżynieria

  • Zinwentaryzuj legalne strumienie wysyłkowe widoczne w raportach zbiorczych i wskaż brakujące lub niezgodne uwierzytelnione identyfikatory.

Kryteria weryfikacji

  • Wygenerowany przez odbiorcę nagłówek Authentication-Results w wiadomości testowej objętej incydentem daje wynik pass DMARC przez co najmniej jedną prawidłową, zgodną gałąź SPF lub DKIM.
  • Raporty zbiorcze identyfikują oczekiwane legalne źródła i nie pokazują już ich znanych brakujących lub niezgodnych identyfikatorów.

Kryteria eskalacji

  • Eskaluj sprawę do zespołu dostarczalności lub właściciela domeny, gdy raporty zbiorcze ujawniają legalne źródła, których nie da się zidentyfikować ani uwierzytelnić.
  • Wymagaj wyraźnej zgody właściciela przed osłabieniem istniejącej polityki egzekwującej w trakcie reagowania na incydent.

Zapobieganie

  • Na bieżąco inwentaryzuj legalnych nadawców na podstawie raportów zbiorczych i śledź brakujące lub niezgodne uwierzytelnione identyfikatory.
  • Zanim zaostrzysz egzekwowanie, korzystaj z trybu monitorowania (p=none) i raportowania zbiorczego, a najpierw napraw legalne strumienie.

Wpływ na biznes

  • Dopóki wiadomość objęta incydentem nie pokaże co najmniej jednej prawidłowej, zgodnej gałęzi uwierzytelniania, zespół nie może wykazać wyniku pass DMARC na poziomie wiadomości ani podjąć bezpiecznej decyzji o wysyłce.

Otwarte pytania

  • Nie dostarczono z żadnej wiadomości objętej incydentem nagłówka Authentication-Results, domeny From (RFC 5322), MAIL FROM, domen DKIM d=, wyników selektora ani aktualnej odpowiedzi DNS.
  • Nie ustalisz, która gałąź zawodzi, dopóki nie porównasz wyników pass i zgodności domen na poziomie pojedynczej wiadomości z obowiązującą polityką DMARC.
  • Zakres raportów po stronie odbiorcy, zachowanie przy pośrednim przekazywaniu (forwarding), wykrywanie domeny organizacyjnej oraz różnica między zgodnością ścisłą a luźną mogą się różnić w zależności od ścieżki wiadomości i samego odbiorcy.
Źródła (6)
  1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Sections 4.4.1 and 4.4.2 Identifier AlignmentIETF RFC 9989
  2. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Section 4.4.2 SPF-Authenticated IdentifiersIETF RFC 9989
  3. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Section 4.4.1 DKIM-Authenticated IdentifiersIETF RFC 9989
  4. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Sections 4.1 and 4.7-4.8IETF RFC 9989
  5. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Sections 5.1.3-5.1.6IETF RFC 9989
  6. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — Sections 5.1.4-5.1.6IETF RFC 9989

Dlaczego poczta jest odrzucana z powodu braku reverse DNS lub rekordu PTR?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Potraktuj to jako incydent konfiguracji odwrotnego DNS (reverse DNS) na rzeczywistym, publicznym adresie IP, z którego wysyłasz. Zanim wznowisz normalny ruch do Gmaila, sprawdź, czy jego rekord PTR wskazuje nazwę hosta, której rekord A lub AAAA prowadzi z powrotem do tego samego adresu IP. O tym, czy Gmail tymczasowo odracza pocztę (deferral), czy blokuje ją trwale, i tak decyduje dokładna odpowiedź SMTP.

Pierwsze 15 minut

  1. Zapisz rzeczywisty publiczny źródłowy adres IP i pełną odpowiedź zdalnego serwera SMTP. Następnie oddziel odroczenia 4.7.23 od blokad 5.7.25 w Gmailu.
  2. Rozwiąż źródłowy adres IP na jego nazwę hosta z rekordu PTR, a potem rozwiąż tę nazwę z powrotem przez rekord A lub AAAA i potwierdź, że prowadzi do tego samego adresu IP.

Teraz

  • Popraw rekord PTR albo rekord A lub AAAA tak, aby rzeczywisty wysyłający adres IP i jego nazwa hosta wskazywały nawzajem na siebie.

Najbliższe 24 godziny

  • Gdy tylko zmiany w DNS staną się widoczne, ponownie sprawdź mapowanie w przód i wstecz (forward-and-reverse) dla każdego aktywnego adresu IP w ścieżce wysyłki objętej problemem.

Najbliższe 7 dni

  • Udokumentuj zweryfikowane mapowanie PTR na nazwę hosta i dalej na adres IP dla każdego produkcyjnego adresu wysyłkowego i uwzględnij je w kontrolach przy zmianach infrastruktury.

Kontrole techniczne

IT / DNS

  • Odpytaj rekord PTR dla rzeczywistego, publicznego adresu IP nadawcy. Następnie odpytaj rekord A lub AAAA dla zwróconej nazwy hosta i porównaj wynik z tym adresem IP.

Dostarczalność

  • Grupuj wyniki z serwerów zdalnych według miejsca docelowego, źródłowego adresu IP i dokładnego rozszerzonego kodu statusu. Nie traktuj każdej odpowiedzi 5.7.x jako problemu z reverse DNS.

Kryteria weryfikacji

  • Świeże publiczne zapytanie DNS pokazuje, że nazwa hosta z rekordu PTR dla wysyłającego adresu IP prowadzi przez rekord A lub AAAA z powrotem do tego samego adresu IP.
  • Kontrolowane próbki wysyłane do Gmaila nie zwracają już 4.7.23 ani 5.7.25 dla objętego problemem źródłowego adresu IP.

Kryteria eskalacji

  • Eskaluj sprawę do właściciela DNS lub platformy wysyłkowej, jeśli nie da się poprawić mapowania, albo do wsparcia dostawcy, jeśli konkretna odpowiedź 5.7.25 utrzymuje się mimo zweryfikowanego mapowania.

Zapobieganie

  • Dla każdego wysyłającego adresu IP wymagaj publicznego sprawdzenia wstępnego (preflight) mapowania forward i reverse DNS, zanim go uruchomisz lub zmienisz infrastrukturę.

Wpływ na biznes

  • Objęte problemem wiadomości do Gmaila mogą być opóźniane przez odroczenia 4.7.23 lub blokowane przez 5.7.25, co przerywa pilną komunikację z klientami.

Uwagi dostawcy

  • W udokumentowanych przypadkach Gmail oznacza tymczasowe odroczenia związane z odwrotnym DNS kodem 4.7.23, a trwałe blokady kodem 5.7.25.
  • Udokumentowany dla Exchange Online przypadek 5.7.25 związany z odwrotnym DNS ogranicza się do anonimowego ruchu przychodzącego po IPv6 i nie należy go uogólniać na każdą ścieżkę firmy Microsoft.

Otwarte pytania

  • Nie udostępniono objętego problemem wysyłającego adresu IP, jego obecnych odpowiedzi PTR i forward DNS ani dokładnej odpowiedzi SMTP z Gmaila.
  • Nie znamy skali odrzuceń (rejections) w Gmailu i u innych operatorów pocztowych, dopóki wyniki SMTP nie zostaną pogrupowane według miejsca docelowego i źródłowego adresu IP.
  • Inni operatorzy pocztowi mogą stawiać inne wymagania dotyczące odwrotnego DNS i stosować inne kody odpowiedzi.
Źródła (5)
  1. Email sender guidelines — Sender requirements and guidelines; Infrastructure configuration requirements and guidelines > IP addressesGmail
  2. Email sender guidelines — Infrastructure configuration requirements and guidelines > IP addressesGmail
  3. Email sender guidelines FAQ — Sender guidelines enforcement > Temporary failure 4.7.23Gmail
  4. Email sender guidelines FAQ — Sender guidelines enforcement > Permanent failure 5.7.25Gmail
  5. Email nondelivery reports (NDRs) and SMTP errors in Exchange Online — Common NDR codes > 5.7.25Microsoft Exchange Online

Dlaczego uwierzytelnianie poczty zawodzi w Microsoft 365 i który test — SPF, DKIM czy DMARC — się nie powiódł?

Poziom ważności: WysokiWstrzymanie wysyłki: Wstrzymaj warunkowo

Zacznij od nagłówka Authentication-Results, który Microsoft 365 dodaje przy odbiorze wiadomości objętej problemem, a nie od samych rekordów DNS w oderwaniu od reszty. To ten nagłówek pokazuje wyniki SPF, DKIM, DMARC i uwierzytelniania złożonego (composite-authentication) na poziomie konkretnej wiadomości, więc pozwala wskazać, który mechanizm zawodzi. Niepowodzenie uwierzytelniania może skończyć się kwarantanną, odrzuceniem albo trafieniem do folderu Junk Email, a DMARC przechodzi tylko wtedy, gdy tożsamość SPF lub DKIM z wynikiem pass jest zgodna z widoczną domeną From.

Pierwsze 15 minut

  1. Zbierz nagłówek Authentication-Results z Microsoft 365 dla jednej wiadomości objętej problemem i odczytaj z tej samej wiadomości wyniki SPF, DKIM, DMARC oraz compauth.
  2. Zapisz razem wyniki SPF, DKIM, DMARC oraz compauth z tego nagłówka odbiorczego, na poziomie tej właśnie wiadomości.

Teraz

  • Popraw tylko ten mechanizm, który wskazała wiadomość objęta problemem: rekord SPF albo autoryzowany adres IP, podpisywanie lub selektor DKIM, albo ścieżkę zgodności DMARC.

Najbliższe 24 godziny

  • Wyślij kontrolowaną wiadomość tą samą ścieżką i potwierdź, że jej uwierzytelniona domena jest już zgodna z widoczną domeną From.

Najbliższe 7 dni

  • Dodaj kontrole zmian, które wychwycą zduplikowane rekordy SPF lub takie z nadmiarem zapytań, brakujące selektory DKIM oraz uwierzytelnione domeny bez zgodności.

Kontrole techniczne

Dostarczalność

  • Porównaj wyniki SPF, DKIM, DMARC i compauth w nagłówku odbiorczym Microsoft 365 dla tej samej wiadomości objętej incydentem.
  • Dla DMARC sprawdź, czy co najmniej jedna uwierzytelniona domena z wynikiem pass w SPF lub DKIM jest zgodna z widoczną domeną From.

IT / DNS

  • Jeśli SPF ma wynik none lub permerror, sprawdź, czy nie brakuje rekordu, czy nie ma ich kilku albo czy nie zachodzi udokumentowany limit dziesięciu zapytań DNS.
  • Jeśli DKIM ma wynik none lub fail, sprawdź podpisywanie, selektor w DNS, zgodność klucza oraz to, czy wiadomość zmieniła się po podpisaniu.
  • Jeśli pojawia się SPF softfail lub fail, sprawdź, czy łączący się adres IP jest autoryzowany dla domeny nadawcy kopertowego, i uwzględnij przekazywanie (forwarding).

Kryteria weryfikacji

  • Nowo odebrana w Microsoft 365 wiadomość pokazuje w Authentication-Results oczekiwane wyniki SPF, DKIM, DMARC i compauth.
  • Jeśli DMARC ma się powieść, nowa próbka musi mieć co najmniej jedną tożsamość SPF lub DKIM z wynikiem pass, zgodną z widoczną domeną From.

Kryteria eskalacji

  • Eskaluj sprawę do Microsoft 365 lub dostawcy wysyłki, gdy nagłówek odbiorczy, message trace i raport NDR są ze sobą sprzeczne albo gdy mimo wskazanej poprawki nadal utrzymują się odrzucenie, kwarantanna lub trafienie do spamu z powodu uwierzytelniania.

Zapobieganie

  • Po każdej zmianie ścieżki wysyłkowej sprawdzaj na rzeczywiście odebranych wiadomościach strukturę i autoryzację SPF, podpisywanie DKIM i selektor w DNS oraz zgodność DMARC.

Wpływ na biznes

  • Prawidłowa poczta w Microsoft 365 może zostać odrzucona, poddana kwarantannie lub skierowana do folderu Junk Email, co opóźnia albo ukrywa wiadomości do klientów i komunikację operacyjną.

Uwagi dostawcy

  • Nagłówek odbiorczy Microsoft 365 zawiera wyniki SPF, DKIM, DMARC oraz wynik compauth od firmy Microsoft; to właśnie ten nagłówek traktuj jako dowód na poziomie wiadomości.

Otwarte pytania

  • Nie udostępniono nagłówków wiadomości objętych problemem, pól Authentication-Results, historii message trace z Microsoft 365 ani diagnostyki NDR.
  • Nie ustalisz zawodzącego mechanizmu ani ścieżki zgodności, dopóki nie odczytasz wyników SPF, DKIM i DMARC z tej samej wiadomości objętej problemem.
  • Nie są znane domeny objęte problemem, rekordy DNS, ścieżka przekazywania, zmiany wprowadzane przez bramę (gateway) ani wpływ na biznes.
Źródła (6)
  1. Troubleshoot email authentication in Microsoft 365 — Read authentication results in message headers > Key fieldsMicrosoft 365
  2. Troubleshoot email authentication in Microsoft 365 — Quick-reference troubleshooting tables > SPF failuresMicrosoft 365
  3. Troubleshoot email authentication in Microsoft 365 — Quick-reference troubleshooting tables > SPF failuresMicrosoft 365
  4. Troubleshoot email authentication in Microsoft 365 — Quick-reference troubleshooting tables > DKIM failuresMicrosoft 365
  5. Troubleshoot email authentication in Microsoft 365 — Troubleshoot DMARC > Domain misalignmentMicrosoft 365
  6. Troubleshoot email authentication in Microsoft 365 — IntroductionMicrosoft 365

Powiązane zasoby

Wojtek BlazalekWojtek BlazalekEkspert ds. dostarczalności e-mail

Masz incydent z pocztą? Pomagam zespołom przywrócić dostarczanie, reputację i uwierzytelnianie do normy.

Praktyczna praca nad dostarczalnością dla firm wysyłających na dużą skalę

Umów bezpłatną rozmowę diagnostycznąZobacz usługi
Umów bezpłatną rozmowę diagnostyczną