Błędy uwierzytelniania i DNS

Pierwsze 15 minut

1. Przechwyć adres IP wysyłki, tożsamość MAIL FROM lub zastępczą tożsamość HELO, odpowiedź DNS oraz otrzymaną wartość Authentication-Results.
2. Sprawdź, czy istnieje wiele rekordów SPF, błędy składni, więcej niż dziesięć wyrażeń odpytujących DNS lub przejściowe błędy wyszukiwania DNS.
3. Sporządź inwentaryzację każdej usługi wysyłającej obecnie dla ocenianej tożsamości.

Teraz

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

Najbliższe 24 godziny

• Tylko wtedy, gdy ewaluacja SPF przekracza limit dziesięciu rekursywnych zapytań DNS, zredukuj ich liczbę, aby zmieścić się w limicie RFC.

Najbliższe 7 dni

• Wprowadź procedurę kontroli zmian przy wprowadzaniu nowych nadawców, aby upewnić się, że rekord SPF jest aktualizowany, gdy nowa usługa rozpoczyna wysyłanie.

Kontrole techniczne

Kryteria weryfikacji

• Nowo odebrana wiadomość po propagacji DNS (co według Google może zająć do 48 godzin) pokazuje w nagłówkach działający SPF.

Kryteria eskalacji

• Eskaluj do zespołu DNS lub dostawcy usług wysyłkowych, gdy błąd tymczasowy (temperror) utrzymuje się lub gdy poprawiony rekord nadal zwraca błąd stały (permerror) po sprawdzeniu autorytatywnych źródeł i odebranych wiadomości.

Zapobieganie

• Utrzymuj jeden prawidłowy rekord SPF, który uwzględnia każdego aktywnego nadawcę i mieści się w limicie dziesięciu zapytań 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 nowo odebrana wiadomość może zacząć wykazywać działający SPF nawet po upływie 48 godzin z uwagi na propagację DNS.

Uwagi dostawcy

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

Otwarte pytania

• Brak odpowiedzi DNS, rekordu TXT SPF, ocenianej domeny MAIL FROM lub HELO, wysyłającego IP lub otrzymanego nagłówka Authentication-Results.
• Wynikiem błędu może być stabilny fail, permerror, temperror, none lub błąd zgodności DMARC błędnie oznaczony jako SPF; należy zachować dokładny wynik.
• Obsługa wyników SPF zależy od lokalnej polityki odbiorcy, a czas propagacji DNS różni się w zależności od dostawcy i pamięci podręcznej resolvera.

Pierwsze 15 minut

1. Przechwyć domeny z nagłówków Authentication-Results, From (RFC 5322), MAIL FROM oraz d= dla DKIM z wiadomości dotkniętej problemem.
2. Sprawdź, czy autoryzowana przez SPF domena MAIL FROM przechodzi pomyślnie weryfikację i jest zgodna z domeną autora.
3. Sprawdź, czy jakakolwiek prawidłowa domena DKIM d= jest zgodna z domeną autora.
4. Sprawdź odpowiedni rekord TXT _dmarc i potwierdź, że v=DMARC1 to jego pierwszy tag.

Teraz

• Popraw tożsamość MAIL FROM, gdy SPF kończy się sukcesem, ale jego autoryzowana domena nie jest zgodna z domeną autora.
• Popraw tożsamość podpisującą DKIM, gdy ważna sygnatura używa niezgodnej domeny d=.
• Napraw brakujący, źle umiejscowiony lub niepoprawnie sformatowany tag wersji DMARC w odpowiednim rekordzie _dmarc.

Najbliższe 24 godziny

• Kontynuuj monitorowanie za pomocą raportów zbiorczych w czasie, gdy naprawiane są uprawnione strumienie bez autoryzacji lub zgodności.

Najbliższe 7 dni

• Zwiększ egzekwowanie dopiero po zinwentaryzowaniu uprawnionych źródeł i naprawieniu ich luk w autoryzacji i zgodności.

Kontrole techniczne

Kryteria weryfikacji

• Wygenerowany przez odbiorcę nagłówek Authentication-Results w testowej wiadomości wskazuje zatwierdzenie DMARC przez co najmniej jedną prawidłową i zgodną gałąź SPF lub DKIM.
• Raporty zbiorcze DMARC identyfikują oczekiwane uprawnione źródła i nie wykazują już znanych brakujących lub niezgodnych identyfikatorów.

Kryteria eskalacji

• Eskaluj do właściciela domeny lub odpowiedzialnego za dostarczalność (deliverability), gdy raporty zbiorcze ujawniają uprawnione źródła, których nie można zidentyfikować lub autoryzować.
• Wymagaj wyraźnej zgody właściciela przed złagodzeniem istniejącej polityki egzekwowania podczas reagowania na incydent.

Zapobieganie

• Regularnie inwentaryzuj uprawnionych nadawców za pomocą raportów zbiorczych DMARC i śledź brakujące lub niezgodne uwierzytelnione identyfikatory.
• Zastosuj tryb monitorowania (p=none) i raportowanie zbiorcze przed przejściem do egzekwowania polityki, w pierwszej kolejności naprawiając uprawnione strumienie.

Wpływ na biznes

• Dopóki wiadomość dotknięta problemem nie wykaże co najmniej jednej prawidłowej i zgodnej gałęzi autoryzacji, zespół nie może potwierdzić zatwierdzenia DMARC na poziomie wiadomości ani podjąć bezpiecznej decyzji o wysyłce.

Otwarte pytania

• Nie dostarczono nagłówka Authentication-Results, RFC 5322 From, MAIL FROM, domen DKIM d=, wyników selektora ani aktualnej odpowiedzi DNS z wiadomości, której dotyczy problem.
• Błędnie działająca gałąź nie zostanie rozwiązana, dopóki wyniki zatwierdzenia i zgodności z danej wiadomości nie zostaną porównane z obowiązującą polityką DMARC.
• Pokrycie raportowania po stronie odbiorcy, zachowanie przy pośrednim przekazywaniu, wykrywanie domen organizacyjnych oraz różnice między ścisłą a luźną zgodnością mogą zależeć od ścieżki wiadomości i samego odbiorcy.

Pierwsze 15 minut

1. Przechwyć rzeczywisty publiczny źródłowy adres IP oraz pełną odpowiedź zdalnego serwera SMTP, a następnie oddziel odroczenia 4.7.23 od blokad 5.7.25 w Gmailu.
2. Rozwiąż adres źródłowy IP na odpowiadającą mu nazwę hosta w rekordzie PTR, a następnie rozwiąż tę nazwę z powrotem przez rekord A lub AAAA, aby upewnić się, że wskazuje na ten sam IP.

Teraz

• Skoryguj rekord PTR lub rekordy A / AAAA, aby rzeczywisty wysyłający IP i jego nazwa hosta wzajemnie się na siebie rozwiązywały.

Najbliższe 24 godziny

• Ponownie sprawdź mapowanie w przód i wstecz (forward-and-reverse) dla każdego aktywnego IP w danej ścieżce wysyłkowej, gdy tylko zmiany w DNS staną się widoczne.

Najbliższe 7 dni

• Udokumentuj sprawdzone mapowanie PTR na nazwę hosta i adres IP dla każdego produkcyjnego adresu wysyłkowego i uwzględnij to w procedurach kontroli zmian infrastruktury.

Kontrole techniczne

Kryteria weryfikacji

• Aktualne publiczne zapytanie DNS pokazuje, że nazwa hosta w rekordzie PTR wysyłającego IP rozwiązuje się przez rekord A lub AAAA z powrotem na ten sam adres IP.
• Kontrolowane próbki do Gmaila nie zwracają już błędów 4.7.23 lub 5.7.25 dla dotkniętego problemem źródłowego IP.

Kryteria eskalacji

• Eskaluj do właściciela DNS lub platformy wysyłkowej, jeśli nie można skorygować mapowania, lub do wsparcia dostawcy, jeśli konkretna odpowiedź 5.7.25 utrzymuje się pomimo poprawnego zmapowania.

Zapobieganie

• Wymagaj publicznej kontroli (preflight) mapowania forward i reverse DNS dla każdego wysyłającego IP przed jego aktywacją lub zmianą w infrastrukturze.

Wpływ na biznes

• Wiadomości dotknięte problemem wysyłane na Gmaila mogą być opóźniane przez odroczenia 4.7.23 lub blokowane przez 5.7.25, przerywając pilną komunikację z klientami.

Uwagi dostawcy

• W udokumentowanych przypadkach Gmail oznacza tymczasowe odroczenia związane z odwrotnym DNS kodem 4.7.23, a permanentne blokady kodem 5.7.25.
• Udokumentowany przypadek 5.7.25 dla Exchange Online dotyczący odwrotnego DNS ogranicza się do anonimowego ruchu przychodzącego IPv6 i nie powinien być uogólniany na każdą ścieżkę firmy Microsoft.

Otwarte pytania

• Dotknięty problemem wysyłający IP, jego bieżące wyniki PTR i DNS, jak i dokładna odpowiedź SMTP z Gmaila nie zostały udostępnione.
• Zasięg odrzuceń (rejections) we wszystkich domenach (Gmail i inni dostawcy) jest nierozwiązany, dopóki wyniki SMTP nie zostaną pogrupowane według miejsca docelowego i źródłowego IP.
• Inni dostawcy usług pocztowych mogą wymagać innych warunków odwrotnego DNS i stosować inne kody odpowiedzi.

Pierwsze 15 minut

1. Zbierz nagłówek Authentication-Results w Microsoft 365 dla pojedynczej wiadomości z problemem i odczytaj z niego wyniki SPF, DKIM, DMARC oraz compauth.
2. Zapisz łącznie wyniki SPF, DKIM, DMARC oraz compauth z nagłówka odbierającego na poziomie tej właśnie wiadomości.

Teraz

• Skoryguj tylko ten mechanizm, który został wskazany w wiadomości: rekord SPF lub autoryzowane IP, podpisywanie DKIM czy selektor, lub zgodność w ramach DMARC.

Najbliższe 24 godziny

• Wyślij wiadomość kontrolną tą samą ścieżką i upewnij się, że autoryzowana w niej domena jest teraz zgodna z widoczną domeną From.

Najbliższe 7 dni

• Dodaj weryfikację zmian, która wychwytuje podwójne lub przekraczające limity wyszukiwań rekordy SPF, brakujące selektory DKIM oraz niezgodne domeny autoryzacji.

Kontrole techniczne

Kryteria weryfikacji

• Nowo odebrana w Microsoft 365 wiadomość zgłasza w Authentication-Results oczekiwane wyniki dla SPF, DKIM, DMARC i compauth.
• Nowa próbka posiada co najmniej jedną prawidłową tożsamość SPF lub DKIM zgodną z widoczną domeną From, kiedy oczekiwane jest zatwierdzenie DMARC.

Kryteria eskalacji

• Eskaluj do firmy Microsoft 365 lub dostawcy wysyłki, gdy nagłówek odbierający, śledzenie wiadomości (message trace) oraz raport NDR są sprzeczne, lub gdy po zastosowaniu rozwiązania wciąż utrzymują się odrzucenia, kwarantanna lub trafienia do spamu powodowane problemami z uwierzytelnianiem.

Zapobieganie

• Waliduj strukturę SPF i jego autoryzację, mechanizm podpisywania i domeny selektorów DKIM oraz zgodność DMARC w rzeczywistych odebranych wiadomościach po każdej modyfikacji ścieżki wysyłkowej.

Wpływ na biznes

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

Uwagi dostawcy

• Nagłówek odbierający w Microsoft 365 zawiera wyniki SPF, DKIM, DMARC oraz specyficzny dla firmy wynik compauth; to właśnie ten nagłówek powinien stanowić dowód na poziomie wiadomości.

Otwarte pytania

• Nie podano nagłówków wiadomości dotkniętych problemem, wartości Authentication-Results, historii śledzenia wiadomości (message trace) z Microsoft 365, ani diagnozy NDR.
• Błędnie działający mechanizm i ścieżka zgodności nie zostaną ustalone, dopóki wyniki SPF, DKIM oraz DMARC nie zostaną odczytane z tej samej wiadomości.
• Nie są znane dotknięte problemem domeny, rekordy DNS, ścieżki forwardowania, modyfikacje dokonywane przez bramę (gateway) i wpływ na biznes.