Odrzucenia DMARC w Outlook.com podobno dotyczą także nadawców nieseryjnych
Outlook.com podobno zaczął odrzucać wiadomości części małych nadawców 5 listopada, mimo że opublikowana przez Microsoft reguła uwierzytelniania koncentruje się na domenach o dużym wolumenie wysyłki. Zgłaszane odrzucenia DMARC w Outlook.com dotyczą domen bez DMARC — standardu poczty e-mail, który łączy wyniki uwierzytelniania z adresem widocznym dla odbiorców. To rozróżnienie ma znaczenie: zwykła odpowiedź biznesowa może stać się problemem z dostarczeniem, nawet gdy nadawca nigdy nie prowadzi newslettera.
Raport pochodzi od MailRoute, dostawcy zabezpieczeń poczty e-mail opisującego obserwacje ze swoich systemów wychodzących. Udokumentowana polityka Microsoftu już wymaga silniejszego uwierzytelniania od nadawców o dużym wolumenie. Niezweryfikowane pozostaje, czy nowo zgłoszone zachowanie oznacza celowe rozszerzenie, zmianę filtrowania czy problem z implementacją.
Główne napięcie dotyczy przewidywalności dostarczania. Firmy planują działania w oparciu o opublikowane wymagania, podczas gdy dostawcy odbierający zachowują swobodę decydowania o wiadomościach przychodzących. Gmail stanowi przydatny punkt odniesienia dla ustalonych wymagań dotyczących uwierzytelniania. Natychmiastowe pytanie dotyczy jednak Microsoftu: czy mali nadawcy napotykają szerszy obowiązek, niż jasno opisuje jego publiczna dokumentacja?
Odrzucenia DMARC w Outlook.com mają inny błąd
Zgłaszane listopadowe zachowanie należy odróżnić od ustalonego egzekwowania zasad Microsoftu wobec nadawców o dużym wolumenie.
W poście z 6 listopada założyciel MailRoute, Thomas A. Johnson, datuje obserwacje na poprzedni dzień. Opisuje sporadyczne awarie dotyczące konsumenckich usług Microsoftu, w tym Outlook.com, Hotmail, Live i MSN. MailRoute twierdzi, że wśród dotkniętego ruchem znajdują się zwykłe, niskowolumenowe wiadomości.
Zgłaszany błąd obejmuje 550 5.7.1 oraz identyfikator AS9031519, wraz z komunikatem o brakujących rekordach uwierzytelniania. Różni się to od 550 5.7.515, udokumentowanego przez Microsoft odrzucenia uwierzytelniania dla nadawców o dużym wolumenie. To rozróżnienie jest dostępne w opisie odrzucenia uwierzytelniania przedstawionym przez MailRoute.
Ta różnica daje administratorom konkretny sposób na rozdzielenie zgłoszeń. Nie dowodzi jednak, że każde wystąpienie ma tę samą przyczynę. Identyfikator błędu stanowi punkt wyjścia do dochodzenia, a nie pełne wyjaśnienie decyzji odbiorcy.
MailRoute zgłasza również niespójne wyniki: niektóre wiadomości docierają, podczas gdy inne zawodzą. Jego opis nie ustala uniwersalnego wskaźnika odrzuceń ani zmierzonej populacji dotkniętych domen. Dostępne dowody potwierdzają zatem zgłoszony problem z dostarczaniem, a nie potwierdzone ogłoszenie polityki obowiązującej w całej usłudze.
Równie ostrożnie należy traktować czas. 5 listopada to data, w której MailRoute twierdzi, że po raz pierwszy zaobserwował te awarie. Nie powinna automatycznie stać się oficjalną datą wprowadzenia reguły Microsoftu. Zaobserwowanie zachowania i ustalenie, kiedy dostawca celowo je wprowadził, to różne twierdzenia raportowe.
Słowo „po cichu” również wymaga zastrzeżenia. Dostawca może zmieniać filtrowanie bez ogłaszania każdej korekty, a usterka operacyjna może przypominać nieudokumentowaną regułę. Żadna z tych możliwości nie ustanawia intencji. Dowody nie uzasadniają twierdzenia, że Microsoft celowo ukrył nowe wymaganie.
Dla dotkniętych organizacji ta niepewność nie usuwa jednak pytania operacyjnego. Odrzucona wiadomość nadal wymaga uwagi, zanim szersza debata o polityce otrzyma ostateczną odpowiedź. Użyteczna reakcja zaczyna się od zachowania dowodów, w tym pełnego błędu, usługi docelowej, systemu wysyłającego i czasu.
Te zapisy pomagają odróżnić ten raport od niezwiązanych awarii dostarczania. Zapobiegają również znanemu błędowi: przypisywaniu każdego problemu z Outlookiem temu wyjaśnieniu, które ostatnio przyciągnęło najwięcej uwagi. Różne awarie mogą wymagać różnych reakcji, nawet jeśli ich objawy wyglądają podobnie dla osoby wysyłającej wiadomość.
Dlatego precyzyjne twierdzenie ma większe znaczenie niż szeroki nagłówek. Obecna historia dotyczy dostawcy zgłaszającego określony wzorzec wykraczający poza oczekiwany zakres opublikowanych wymagań. To, czy wzorzec ten stanie się ustaloną polityką, pozostaje otwartym pytaniem.
Mali nadawcy stają przed problemem niezawodności, zanim uzyskają odpowiedź dotyczącą polityki
Mała organizacja może ponieść poważną porażkę w dostarczaniu, nie generując dużego wolumenu wiadomości e-mail.
Rozważmy przykładową wymianę dotyczącą rekrutacji. Rekruter wysyła potwierdzenie rozmowy kwalifikacyjnej do prywatnej skrzynki Microsoft kandydata. Jeśli dostarczenie się nie powiedzie i nikt nie zareaguje na odrzucenie, kandydat nie może odróżnić problemu technicznego od milczenia pracodawcy.
To samo rozumowanie dotyczy konsultanta odpowiadającego potencjalnemu klientowi lub organizacji społecznej potwierdzającej obecność. Te przykłady ilustrują ekspozycję na ryzyko, a nie udokumentowane incydenty z listopadowego raportu. Ich znaczenie wynika z relacji między dostarczeniem a działaniem, którego ktoś oczekuje w następnej kolejności.
Wolumen jest słabą miarą znaczenia pojedynczej wiadomości. Kampania marketingowa może stracić część dostarczeń, wciąż docierając do odbiorców. Osobista wymiana może całkowicie zależeć od wiadomości, która nie dotarła. Ta asymetria wyjaśnia, dlaczego zgłoszenia dotyczące małych nadawców zasługują na uwagę.
Presja rozkłada się na kilka ról. Pracownik widzi nieudaną rozmowę, administrator bada uwierzytelnianie, a właściciel firmy zajmuje się niedotrzymanym zobowiązaniem. Bez jasnego przekazania odpowiedzialności każda osoba może założyć, że problem należy do kogoś innego.
Odrzucenie może także ujawnić słabości w istniejącym procesie organizacji. Czy ktoś przegląda wiadomości zwrotne z systemów automatycznych? Czy personel wsparcia potrafi zidentyfikować usługę, która wysłała powiadomienie do klienta? Czy istnieje alternatywna droga kontaktu, gdy ważna wymiana nie dochodzi do skutku?
Te pytania pozostają przydatne nawet wtedy, gdy Microsoft później wskaże tymczasową usterkę. Dotyczą odporności operacyjnej, a nie przewidywania ostatecznego wyjaśnienia polityki. Organizacje nie powinny potrzebować definitywnego komunikatu platformy, by zauważyć, że oczekiwana korespondencja nie dotarła.
Sporadyczne zachowanie utrudnia tę odpowiedzialność. Udany test może przedwcześnie uspokoić zespół, a nieudany test może wywołać niepotrzebnie szeroką reakcję. Żaden wynik sam w sobie nie ustala, jak zachowa się każda prawidłowa wiadomość organizacji.
Właściwą jednostką dochodzenia jest faktyczna ścieżka wysyłki. Skrzynka pracownika, usługa obsługi klienta i system powiadomień aplikacji mogą wysyłać wiadomości pod powiązaną marką. Nadal jednak reprezentują odrębne konfiguracje i odrębnych właścicieli operacyjnych.
Ta fragmentacja tworzy praktyczne ryzyko: zespół naprawia system, który zna najlepiej, i zakłada, że cała organizacja jest objęta ochroną. Udana odpowiedź pracownika niewiele mówi o niezwiązanej usłudze wysyłającej faktury lub powiadomienia o koncie.
Zespoły dokumentujące dochodzenie mogą przechowywać dowody dotyczące dostarczania wraz z przeszukiwalną bazą wiedzy. Wartość polega na zachowaniu powiązania między objawami, zmianami konfiguracji, odpowiedzialnymi właścicielami i zweryfikowanymi wynikami.
Natychmiastowa reakcja biznesowa powinna być zatem proporcjonalna. Zidentyfikuj ważne nieudane wymiany, zachowaj dowody i przypisz odpowiedzialność. Następnie oddziel przywracanie komunikacji od udowadniania szerszego twierdzenia o zachowaniu Microsoftu.
Opublikowana reguła Microsoftu nadal koncentruje się na domenach o dużym wolumenie
Microsoft udokumentował wymóg uwierzytelniania dla dużego wolumenu; listopadowy raport rodzi pytania o zachowanie poza tym jasno określonym zakresem.
Microsoft ogłosił swoje wymagania 2 kwietnia 2025 roku i zaktualizował wyjaśnienie dotyczące egzekwowania zasad 29 kwietnia. Aktualizacja określała rozpoczęcie odrzucania od 5 maja 2025 roku. Jego wymagania dla nadawców o dużym wolumenie opisują domeny wysyłające ponad 5 000 wiadomości dziennie.
Ogłoszenie wymaga SPF, DKIM i DMARC dla tej grupy. SPF, czyli Sender Policy Framework, identyfikuje infrastrukturę upoważnioną do wysyłania wiadomości przy użyciu domeny. DKIM, czyli DomainKeys Identified Mail, wykorzystuje kryptograficzny podpis domeny do uwierzytelniania podpisanej treści wiadomości.
Oddzielne wytyczne Microsoftu dotyczące błędów uwierzytelniania opisują 550 5.7.515 jako odrzucenie dotyczące nadawców o dużym wolumenie. Wymagają pomyślnego przejścia zarówno SPF, jak i DKIM, przy czym co najmniej jeden z nich musi być zgodny z widoczną domeną nadawcy.
To ujęcie na poziomie domeny ma znaczenie. Osoba wysyłająca okazjonalne wiadomości z aktywnej domeny organizacyjnej nie musi znajdować się poza udokumentowanym wymaganiem. Aktywność pojedynczej skrzynki i całkowita aktywność domeny są różnymi miarami.
W konsekwencji zbadanie pozornie małego nadawcy wymaga czegoś więcej niż pytania, ile wiadomości wysyła dany pracownik. Organizacja musi zrozumieć szerszą aktywność wysyłkową domeny. W przeciwnym razie przypadek przedstawiany jako dowód niskiego wolumenu może już należeć do opublikowanej kategorii.
To rozróżnienie wyjaśnia również główny konflikt. Historia nie polega po prostu na tym, że Microsoft wymaga uwierzytelniania, a firmy się temu sprzeciwiają. Bardziej użyteczne pytanie dotyczy tego, czy administratorzy mogą dokładnie wywnioskować swoje obowiązki z udokumentowanego zakresu i obserwowalnych błędów.
Gmail zapewnia istotny kontekst, nie rozstrzygając tego pytania. Jego wymagania dla nadawców e-maili rozróżniają ogólne obowiązki od dodatkowych reguł dla nadawców przekraczających 5 000 wiadomości dziennie do prywatnych kont Gmail. Dodatkowe wymagania dotyczące uwierzytelniania obejmują DMARC.
To porównanie pokazuje, że oczekiwania dotyczące silniejszego uwierzytelniania są ustaloną praktyką branżową. Nie dowodzi ono, że Microsoft celowo wdrożył listopadowe zachowanie. Podobne cele bezpieczeństwa mogą współistnieć z różnymi progami, obsługą błędów, harmonogramami egzekwowania zasad i procesami wsparcia.
Dla firm praktycznym problemem związanym z wymaganiami DMARC w Outlooku jest luka między zrozumieniem reguły a rozpoznaniem jej zastosowania. Dokumentacja powinna pomagać administratorowi ustalić, czy awaria wynika z tej reguły, czy z innej decyzji odbiorcy.
Dla Microsoftu jaśniejsza komunikacja ograniczyłaby niepotrzebne rozwiązywanie problemów. Precyzyjne wyjaśnienie mogłoby wskazać objęty ruch, oczekiwany stan uwierzytelniania i odpowiedni identyfikator odrzucenia. Pomogłoby to prawidłowym nadawcom reagować bez przekształcania rozproszonych obserwacji w uniwersalne twierdzenie.
Dopóki takie wyjaśnienie nie istnieje, ustalona polityka pozostaje wiarygodnym punktem odniesienia. Listopadowy raport zasługuje na zbadanie równolegle z nią, bez rozciągania żadnego ze źródeł poza to, co faktycznie wykazuje.
Opublikowany rekord to nie to samo co uwierzytelniona poczta
Dodanie rekordu DMARC może usunąć brak, ale obecność rekordu nie dowodzi, że wiadomość uwierzytelnia się prawidłowo.
To rozróżnienie znajduje się w centrum technicznej stawki tej historii. Firma może opublikować deklarację dotyczącą swojej domeny, podczas gdy konkretna usługa wysyłająca pozostaje nieprawidłowo skonfigurowana. Deklaracja i zachowanie dostarczonej wiadomości wymagają osobnej oceny.
Dopasowanie oznacza, że uwierzytelniona domena odpowiada domenie widocznej w polu From adresu lub pozostaje z nią we właściwym związku. Od tej relacji zależy DMARC. Pozytywny wynik kontroli uwierzytelnienia dla niepowiązanej domeny usługi nie potwierdza automatycznie widocznej tożsamości organizacji.
Specyfikacja DMARC rozróżnia również preferencję właściciela domeny dotyczącą obsługi od sposobu przetwarzania przez system odbierający. Minimalny rekord zawierający v=DMARC1; p=none nie wyraża preferencji dotyczącej szczególnego traktowania niepowodzeń uwierzytelnienia.
To ustawienie nie naprawia braku autoryzacji, nie tworzy prawidłowego podpisu ani nie sprawia, że niepowiązana uwierzytelniona tożsamość zostaje dopasowana. Nie gwarantuje też dostarczenia do skrzynki odbiorczej. Traktowanie tego tekstu jako uniwersalnego rozwiązania problemów z dostarczalnością myli deklarację domeny ze skutecznym uwierzytelnieniem wiadomości.
Raportowanie wprowadza kolejne rozróżnienie. Powyższy minimalny rekord nie określa miejsca docelowego dla raportów zbiorczych, które podsumowują zaobserwowaną aktywność uwierzytelniania. Żądanie takich raportów wymaga odpowiedniego adresu raportowego za pomocą pola rua.
Ma to znaczenie, gdy ktoś opisuje minimalny rekord jako automatycznie włączający monitorowanie. Opublikowanie polityki i otrzymywanie użytecznych informacji zwrotnych to odrębne działania. Organizacja potrzebuje rzeczywistego mechanizmu raportowania, zanim będzie mogła oczekiwać, że takie informacje wpłyną na decyzje.
Dla czytelników śledzących listopadowe twierdzenie szersza lekcja dotyczy jakości dowodów. Wiarygodny raport o odzyskaniu sprawności powinien wskazywać, co się zmieniło i co wydarzyło się później. Samo ogłoszenie, że ktoś „dodał DMARC”, pozostawia ważne pytania bez odpowiedzi.
Czy administrator zmienił także usługę wysyłającą? Czy udany test obsłużyła inna trasa? Czy pierwotny typ wiadomości dotarł do tej samej usługi docelowej? Te szczegóły określają, jak dużą pewność obserwator powinien przypisać pozornej naprawie.
Organizacja musi też oddzielić pocztę pracowników od innych systemów wysyłających. Dostawca aplikacji może konfigurować uwierzytelnianie inaczej niż główny dostawca skrzynek pocztowych. Ta sama widoczna marka nie oznacza tej samej uwierzytelnionej tożsamości.
To sprawia, że dostarczalność jest stałą relacją między własnością domeny a konfiguracją usługi. Osoba kontrolująca ustawienia domeny potrzebuje informacji od osób obsługujących aplikacje wysyłające. Żadna z tych ról nie musi samodzielnie dysponować pełnym obrazem sytuacji.
Praktyczny kompromis jest jasny. Mała zmiana konfiguracji może być prosta, ale potwierdzenie jej efektu wymaga ostrożności. Odpowiedzialny wniosek brzmi: brakujący rekord zasługuje na uwagę, natomiast skuteczne uwierzytelnienie wymaga dowodów z faktycznie wysyłanych wiadomości.
Dowody nie potwierdzają jeszcze uniwersalnej polityki Microsoftu
Dostępny raport wskazuje wiarygodny kierunek dochodzenia, ale pozostawia nierozstrzygnięty zakres i przyczynę listopadowego zachowania.
MailRoute ma bezpośredni wgląd w ruch przechodzący przez jego systemy. To sprawia, że jego obserwacje są istotne dla tej historii. Firma sprzedaje również usługi pocztowe, co daje czytelnikom powód, by rozróżniać dowody operacyjne od rekomendacji związanych z jej ofertą komercyjną.
Zaangażowanie komercyjne nie unieważnia raportu. Zwiększa wartość potwierdzenia ze strony organizacji korzystających z innej infrastruktury. Niezależne obserwacje pomogłyby ustalić, czy wzorzec wykracza poza konkretnych klientów i trasy wysyłania jednego dostawcy.
Obecna luka w weryfikacji dotyczy czegoś więcej niż tego, czy ktoś otrzymał odrzucenie. Chodzi o to, dlaczego wiadomość nie została dostarczona i czy to samo wyjaśnienie ma zastosowanie gdzie indziej. Rzeczywiste niepowodzenie może mimo to wspierać zbyt szeroką interpretację.
Nadal możliwych jest kilka wyjaśnień. Microsoft może stosować dodatkowy sygnał uwierzytelniający, dostosowywać istniejące filtrowanie albo doświadczać problemu z implementacją. Domena może też mieć większą aktywność wysyłkową, niż administrator początkowo rozpoznał. Dostępne dowody nie pozwalają rozstrzygająco wybrać między tymi wyjaśnieniami.
Są to hipotezy do zbadania, a nie ustalenia dotyczące wewnętrznych systemów Microsoftu. Przypisanie mechanizmu bez potwierdzających dowodów sprawiłoby, że historia brzmiałaby pełniej, lecz byłaby mniej wiarygodna.
Najmocniejsze dodatkowe dowody połączyłyby błąd po stronie odbiorcy ze stanem uwierzytelnienia wiadomości i istotną konfiguracją domeny. Kontrolowane porównanie udokumentowałoby także zmiany między niepowodzeniem a odzyskaniem sprawności. Bez tego połączenia sama chronologia może wprowadzać w błąd.
Na przykład dostarczenie wiadomości po aktualizacji konfiguracji nie dowodzi, że każda część aktualizacji miała znaczenie. Późniejsze udane ponowne wysłanie nie dowodzi też, że pierwotne odrzucenie było nieistotne. Przerywane wyniki komplikują oba rodzaje twierdzeń przyczynowych.
Rozróżnienie między odrzuceniem poczty przez odbiorcę a jej cichym utraceniem również wymaga ostrożności. Odrzucenie może spowodować widoczne niepowodzenie po stronie nadawcy. Problem operacyjny staje się mniej widoczny, gdy to niepowodzenie trafia do systemu bez nadzoru lub nie spotyka się z dalszymi działaniami.
Nazywanie każdego takiego zdarzenia „cichym blokowaniem” zacierałoby tę różnicę. Organizacje muszą wiedzieć, czy odbiorca odmówił przyjęcia wiadomości, zaakceptował ją czy umieścił w nieoczekiwanym miejscu. Te wyniki oznaczają inne dowody i inną odpowiedzialność.
Porównania uwierzytelniania Outlook z Gmail również nie mogą ustalić związku przyczynowego. Wiadomość docierająca do Gmail, ale nieudana w Outlook, pokazuje odmienne wyniki. Sama w sobie nie wskazuje, która kontrola Microsoftu spowodowała różnicę.
Najbardziej obronny opis zachowuje zatem wyraźne granice. Dostawca zgłasza nowy wzorzec dotyczący pozornie małych nadawców. Microsoft dokumentuje istniejący wymóg dla dużej liczby wiadomości. Relacja między tymi faktami pozostaje głównym pytaniem bez odpowiedzi.
Czytelnicy powinni traktować tę niepewność jako użyteczną informację. Określa ona, co musi ustalić dalsze raportowanie, i pomaga administratorom unikać zastępowania diagnozy nagłówkiem.
Trzy sygnały zdecydują o tym, co stanie się dalej
Kolejny etap tej historii zależy od jaśniejszego zakresu, niezależnego odtworzenia problemu i zweryfikowanego odzyskania sprawności.
Pierwszym sygnałem jest publiczne wyjaśnienie Microsoftu. W nadchodzących miesiącach najistotniejszym wydarzeniem byłyby wytyczne bezpośrednio odnoszące się do zgłoszonego listopadowego identyfikatora odrzucenia. Użyteczna aktualizacja określałaby dotkniętych nadawców, oczekiwania dotyczące uwierzytelnienia oraz relację z istniejącymi zasadami dla dużej liczby wiadomości.
Wyraźne rozszerzenie na domeny o mniejszym wolumenie wzmocniłoby interpretację, że odrzucenia DMARC przez Outlook.com odzwierciedlają szerszy obowiązek. Udokumentowany incydent lub korekta osłabiłyby tę interpretację. Każdy z tych wyników dałby administratorom solidniejszą podstawę do podejmowania decyzji.
Jakość wyjaśnienia ma równie duże znaczenie jak samo jego istnienie. Ogólne przypomnienie o uwierzytelnianiu poczty pozostawiłoby zgłoszoną rozbieżność bez rozwiązania. Administratorzy potrzebują wystarczającej liczby szczegółów, aby połączyć zaobserwowane odrzucenie z udokumentowaną przyczyną.
Drugim sygnałem jest niezależne odtworzenie problemu. Raporty od niepowiązanych dostawców wysyłki miałyby większą wagę, gdyby obejmowały porównywalne dowody. Użyteczne pytanie brzmi, czy ten sam warunek braku rekordu wielokrotnie towarzyszy temu samemu błędowi po stronie odbiorcy.
Dowody dotyczące domen o rzeczywiście niskim wolumenie byłyby szczególnie istotne. Odniosłyby się do możliwości, że indywidualny nadawca wydawał się mały, podczas gdy szersza domena spełniała istniejące progi. Raporty powinny więc rozróżniać osobistą aktywność wysyłkową od ruchu w całej domenie.
Spójne odtworzenie w oddzielnych środowiskach wzmocniłoby argument za szerszym zachowaniem. Niepowodzenia ograniczone do konkretnej trasy lub konfiguracji zawęziłyby historię. Oba ustalenia byłyby użyteczne, ponieważ zmniejszyłyby niepewność co do tego, kto napotyka presję.
Trzecim sygnałem jest trwałe odzyskanie sprawności po udokumentowanej korekcie. Administrator potrzebuje dowodów, że legalny ruch z pierwotnej ścieżki wysyłki nadal działa. Pojedyncza pomyślnie dostarczona wiadomość daje mniej pewności, gdy początkowa skarga dotyczy wyników przerywanych.
Najbardziej informacyjne relacje o odzyskaniu sprawności wyodrębniałyby zmianę konfiguracji i zachowywały porównywalne dowody sprzed i po zmianie. Jeśli dodanie prawidłowego rekordu konsekwentnie rozwiązuje to samo niepowodzenie bez innych zmian, zgłaszany związek staje się bardziej przekonujący.
Jeśli niepowodzenia utrzymują się mimo prawidłowego uwierzytelnienia, wyjaśnienie o braku rekordu staje się mniej kompletne. Skierowałoby to uwagę na inne decyzje po stronie odbiorcy lub problemy z implementacją. Podważyłoby również uproszczone porady przedstawiające rekord domeny jako całe rozwiązanie.
Te sygnały utrzymują prognozę na solidnych podstawach. Pytanie nie brzmi, czy uwierzytelnianie poczty stanie się modne ani czy dostawcy będą nadal walczyć z nadużyciami. Pytanie brzmi, jak jasno Microsoft definiuje swoje wymagania i jak niezawodnie legalni nadawcy mogą wykazać zgodność.
Dla czytelników biznesowych oczekiwanie na te odpowiedzi nie powinno oznaczać ignorowania bieżących niepowodzeń. Przejrzyj ważną korespondencję, która wróciła z błędem, zidentyfikuj system wysyłający i upewnij się, że ktoś odpowiada za dochodzenie. Zachowaj oryginalne dowody przed zmianą ustawień, a następnie zweryfikuj dostarczenie tą samą legalną ścieżką. Traktuj odrzucenia DMARC przez Outlook.com jako konkretne pytanie o niezawodność, a nie powód do wprowadzania niezwiązanych zmian w infrastrukturze. Poproś dostawcę o wyjaśnienie, które kontrole uwierzytelnienia przeszły pomyślnie, jaką tożsamość zweryfikowano i co dokładnie odrzuciła usługa odbierająca. Jeśli proponowana naprawa dotyczy wyłącznie obecności rekordu, poproś o dowody, że dotknięte wiadomości są teraz uwierzytelniane i konsekwentnie docierają. To praktyczny standard, który warto stosować, dopóki szersze stanowisko Microsoftu pozostaje niejasne.
