[ Zasady dostarczalności i nadawcy ]

Wymagania dotyczące nadawców dużej liczby przesyłek Outlook .com: rozróżnij pocztę konsumencką i korporacyjną

Diagnozuj masowe błędy uwierzytelniania Outlook .com w zakresie usług konsumenckich, zamiast stosować założenie dotyczące poczty korporacyjnej.

Przez zespół badawczy EmailAuth · 3 minuty czytania

[Kluczowe punkty]

  • Zidentyfikuj usługę skrzynek pocztowych firmy Microsoft dla klientów indywidualnych, a nie tylko aplikację Outlook .
  • Karnet DMARC może współistnieć z nieudanym oddzielnym wymaganiem SPF .
  • Zachowaj faktyczne odrzucenie i trasę przed zmianą uwierzytelnienia.
Na tej stronie

„ Outlook ” może oznaczać aplikację komputerową, skrzynkę pocztową dla klientów indywidualnych lub środowisko Microsoft 365 organizacji. Nie są to wymienne zakresy polityki. Zacznij od faktycznej usługi odbioru i diagnostyki, zanim użyjesz obszernej listy kontrolnej w celu wyjaśnienia nieudanej wiadomości.

Zidentyfikuj usługę konsumencką i jej bieżące wymagania

Bieżący artykuł pomocy technicznej firmy Microsoft dotyczący wersji 550 5.7.515 opisuje usługę Outlook .com i powiązane usługi konsumenckie, w tym Hotmail, Live.com i MSN. Identyfikuje nadawcę masowego wysyłania 5000 lub więcej wiadomości do tych usług przy użyciu tej samej domeny w widocznym 5322.Od adres. Jego sformułowanie pomocnicze stwierdza, że ​​oba SPF I DKIM musi minąć i że jest opublikowany DMARC polityka co najmniej p=none i przepustka DMARC są wymagane. Wskazówki dotyczące Microsoft 550 5.7.515.

W zaktualizowanym ogłoszeniu ustalono, że egzekwowanie zasad odrzucania rozpocznie się 5 maja 2025 r. Pierwotny plan dotyczący wyłącznie śmieci został skreślony; nie traktuj tego zastąpionego akapitu jako aktualnej polityki reagowania. Zaktualizowane ogłoszenie firmy Microsoft.

We wcześniejszym ogłoszeniu opisano dzienny wolumen i podano „ponad 5000”. Nie buduj wyjątków wokół sformułowań granicznych: obecne wytyczne dotyczące wsparcia przewidują 5000 lub więcej. Nie powinieneś także wymyślać okresu resetowania ani reguły trwałej klasyfikacji na tej stronie pomocy technicznej. Podczas interpretacji przypadku zapisz wersję i faktyczną otrzymaną diagnostykę.

Oddziel sukces protokołu od bramy dostawcy

Referencje: RFC 9989 §4.4, RFC 9989 §5.3.5.

DMARC może przejść przez wyrównany sukces Podpis DKIM nawet jeśli SPF zawiedzie. Ten wynik protokołu nie spełnia oddzielnego wymogu, który musi spełnić oba podstawowe mechanizmy. I odwrotnie, zarówno SPF , jak i DKIM mogą uchodzić za domeny niezwiązane z widocznym źródłem i powodować awarię DMARC . Zachowaj wszystkie trzy wyniki i tożsamości za nimi.

W przypadku wiadomości generowanej bezpośrednio przez usługę zapisz adres IP nadawcy, nadawca kopertowy domena, Z domeny, DKIM d= domena i selektor. Sprawdź bieżący DNS i ostateczną podpisaną wiadomość, a nie tylko ekran konfiguracji. Użyj rzeczywistych nazw protokołów: SMTP MAIL FROM to tożsamość koperty RFC 5321 , podczas gdy widoczny From należy do RFC 5322 .

Przeczytaj odmowę jako dowód, a nie scenariusz naprawy

Referencje: RFC 8601 §5.

Odrzucenie 550 5.7.515 oznacza, że ​​domena nadawcy nie spełnia wymaganego poziomu uwierzytelnienia. Zachowaj cały identyfikator diagnostyczny, czasowy, odbiorcy i wiadomości. Nie odpowiadaj, dodając każdego dostępnego dostawcę do SPF lub wyłączając Egzekucja DMARC bez zrozumienia zawodzącej tożsamości.

Porównaj strumienie, których to dotyczy, i strumienie, których nie dotyczy. Usługa rozliczeniowa może mieć poprawną niestandardową konfigurację podpisywania, podczas gdy usługa kampanii nadal podpisuje się tylko przy użyciu własnej domeny. Jeżeli w grę wchodzi spedycja lub inny pośrednik, należy zachować trasę i przekształcenia. Założenia dotyczące poczty bezpośredniej mogą nie wyjaśniać ścieżki pośredniej i kopiowanej Authentication-Results linia nie zastępuje dowodów zaufanego odbiorcy.

Przeprowadź diagnostykę syntetyczną

Referencje: RFC 9989 §5.3.5.

Wyobraź sobie kontrolowaną wiadomość, której wynikiem SPF jest niepowodzenie, a którego wynikiem DKIM jest powodzenie wyrównaniei którego wynik DMARC jest pozytywny. Wynik DMARC jest wewnętrznie spójny. Zgodnie z wymaganiami firmy Microsoft dotyczącymi dużych ilości danych awaria SPF nadal wymaga naprawy. To logiczny przykład, a nie przechwycona odmowa Microsoftu.

Następną czynnością jest ustalenie, czy oceniany nadawca koperty autoryzował rzeczywisty adres IP połączenia. Po zatwierdzonej korekcie wykonaj test ponownie tą samą zamierzoną trasą i zachowaj nowy wynik. Nie używaj ponownie starego biletu jako dowodu zmiany wiadomości lub trasy.

Trzymaj sprawy korporacyjne na własnej ścieżce dowodowej

Dzierżawca Microsoft 365 może zastosować własne zasady i łączniki ruchu przychodzącego. Odbiorca korzystający z aplikacji Outlook nie poddaje swojej organizacji dokładnej bramie artykułu konsumenckiego. W przypadku przedsiębiorstw należy zebrać kontekst diagnostyczny i zasady dzierżawy, zamiast zakładać, że wersja 5.7.515 wyjaśnia każdą odpowiedź wersji 5.7.x.

Zamknij usługę, której dotyczy problem, domenę nadawcy, zaobserwowane wyniki mechanizmu i poprawioną trasę. Nie ma tu mowy o testowaniu skrzynek pocztowych Microsoft na żywo, a zgodność z uwierzytelnianiem różni się od rozmieszczenia skrzynek odbiorczych.

[Na wynos]

Zachowaj faktyczne odrzucenie i trasę przed zmianą uwierzytelnienia.

[ Według roli ]

Co to oznacza dla Ciebie

Wybierz swoją rolę, aby uzyskać praktyczne dalsze kroki.

Administrator IT / poczty

Zachowaj każdy wynik uwierzytelnienia

Sam DMARC może ukryć awarię oddzielnego mechanizmu.

Kolejne kroki

  1. Przechwytuj pełną diagnostykę.
  2. Koperta mapy i tożsamość.
  3. Przetestuj ponownie poprawioną trasę.

CISO / SecOps

Unikaj osłabiania polityki poprzez domysły

Odrzucenie jest powodem do zbadania, a nie do rozszerzenia zezwolenia.

Kolejne kroki

  1. Wąsko przejrzyj zmiany SPF .
  2. Zachowaj dowody pośrednie.
  3. Oddziel politykę najemcy od wytycznych dla konsumentów.

Założyciel / Nietechniczny

Określ zakres zdarzenia przed eskalacją

Sprawy konsumenckie i korporacyjne wymagają różnych dowodów.

Kolejne kroki

  1. Zidentyfikuj usługę skrzynki pocztowej.
  2. Śledź dotknięte strumienie.
  3. Unikaj uniwersalnej etykiety Outlook .

[ Często zadawane pytania ]

Często zadawane pytania

Czy korzystanie z aplikacji Outlook identyfikuje politykę odbierania?

Nie. Zidentyfikuj rzeczywistą usługę i diagnostykę skrzynki pocztowej.

Jakie usługi obejmuje artykuł 5.7.515?

Outlook .com i powiązane usługi poczty e-mail firmy Microsoft dla klientów indywidualnych.

Aktualne wytyczne dostawcy

Czy DMARC może przejść pomyślnie, gdy SPF zawiedzie?

Tak, poprzez dopasowany, pomyślny podpis DKIM .

RFC 9989 §5.3.5

Czy to koniecznie satysfakcjonuje klientów korzystających z dużych ilości towarów?

Nie. Artykuł pomocy technicznej firmy Microsoft wymaga zaliczenia zarówno SPF , jak i DKIM .

Aktualne wytyczne dostawcy

Czy dokładnie 5 tys. należy traktować jako zwolnienie?

Nie. Obecne sformułowanie wsparcia używa 5000 lub więcej.

Aktualne wytyczne dostawcy

Czy ustanawia to stałą regułę dotyczącą statusu dużej liczby osób?

Nie. Nie należy wyciągać wniosków o okresie ważności klasyfikacji na podstawie cytowanej strony pomocy technicznej.

Aktualne wytyczne dostawcy

Czy administrator powinien wyłączyć DMARC , aby naprawić odrzucenie?

Najpierw zdiagnozuj wadliwą tożsamość; nie osłabiaj polityki w ramach ślepej naprawy.

Czy przykład syntetycznego niepowodzenia SPF został przesłany do firmy Microsoft?

Nie. Ilustruje różnicę pomiędzy logiką protokołu a wymaganiami dostawcy.

[ Źródła ]

Źródła

  1. RFC 8601

    Sekcje §5

  2. RFC 9989

    Sekcje §4.4 · §5.3.5

  3. Oficjalne wymagania MICROSOFT

    Sekcje Co definiuje nadawcę masowego (dużego) przepływu? · Wymagania dotyczące uwierzytelniania

  4. Oficjalne wymagania AKTUALIZACJI MICROSOFT

    Sekcje Harmonogram egzekwowania

[ Słowniczek ]

Słowniczek

Skrzynka pocztowa konsumencka
Skrzynka pocztowa w ramach usług konsumenckich dostawcy, a nie dzierżawa korporacyjna.
5322.Od
Adres autora widoczny w nagłówku Od wiadomości.
5321.Poczta od
Tożsamość nadawcy koperty SMTP używana podczas przesyłania wiadomości.

Pochodzenie przedsiębiorstwa

Dlaczego najlepsze instytucje finansowe i rządy wycofali swoje panele bezpieczeństwa poczty e-mail.

Tradycyjne platformy uwierzytelniania poczty e-mail oferują pulpit nawigacyjny i proszą inżynierów o wykonanie pracy. W środowiskach o dużej stawce ręczny nadzór oznacza opóźnione egzekwowanie, zmianę konfiguracji i niemonitorowane domeny-cienie.

EmailAuth to platforma agentowego pochodzenia wiadomości e-mail. Nasi agenci egzekwują p=reject, dostosuj zewnętrznych nadawców i przenieś swoje domeny do pełnych adresów RFC 9989 zgodność, nowy standard DMARC , z możliwością kontroli przez człowieka.

Rządy Duże przedsiębiorstwa Instytucje finansowe poziomu 1

SaaS · Dedykowany najem · Lokalne rozwiązanie typu air-gapped · Szyfrowanie BYOK

Baza wiedzy