Microsoft wyłącza Basic Authentication dla SMTP AUTH w Exchange Online - jak przygotować migrację do OAuth?

TL;DR

Microsoft nie wyłącza protokołu SMTP AUTH, a jedynie sposób uwierzytelniania oparty na loginie i haśle (Basic Authentication). Oznacza to, że aplikacje i urządzenia nadal będą mogły wysyłać wiadomości przez ten sam punkt SMTP (smtp.office365.com:587), ale wyłącznie wtedy, gdy obsługują nowoczesne uwierzytelnianie OAuth 2.0.

Największe ryzyko dotyczy starszych urządzeń i aplikacji, które nie obsługują OAuth. W praktyce problem może dotyczyć m.in. drukarek i skanerów z funkcją „Scan-to-Email”, starszych systemów ERP i CRM, aplikacji biznesowych, systemów monitoringu, central telefonicznych czy narzędzi wysyłających automatyczne raporty i powiadomienia.

Powodem zmian są względy bezpieczeństwa. Basic Authentication wykorzystuje statyczne dane logowania, nie obsługuje uwierzytelniania wieloskładnikowego (MFA) i jest częstym celem ataków wykorzystujących wykradzione hasła. OAuth 2.0 wykorzystuje bezpieczne, rotujące tokeny dostępu oraz umożliwia precyzyjniejsze ograniczanie uprawnień aplikacji.

Jeżeli Twoje urządzenia lub aplikacje obsługują OAuth 2.0, migracja będzie stosunkowo niewielką zmianą. Nadal będą korzystać z SMTP AUTH, ale zamiast loginu i hasła wykorzystają nowoczesny mechanizm uwierzytelniania oparty na tokenach.

Jeśli starsze systemy nie wspierają OAuth, nadal istnieją alternatywne sposoby wysyłki wiadomości. W zależności od scenariusza można wykorzystać m.in. Microsoft Graph API, Direct Send, relay przez konektor w Exchange Online, lokalny serwer SMTP Relay lub usługę High Volume Email (HVE), która dla określonych zastosowań nadal obsługuje Basic Authentication.

Najlepiej rozpocząć przygotowania od inwentaryzacji środowiska - sprawdzenia, gdzie SMTP AUTH jest włączone, które konta rzeczywiście z niego korzystają oraz jakie urządzenia i aplikacje wysyłają wiadomości z wykorzystaniem Basic Authentication.

Choć Microsoft przesuwał termin wyłączenia Basic Authentication już kilkukrotnie, nie warto odkładać przygotowań. Zgodnie z obecnym harmonogramem podstawowe uwierzytelnianie dla SMTP zostanie domyślnie wyłączone w istniejących środowiskach pod koniec grudnia 2026 roku, a kolejnym etapem będzie jego całkowite usunięcie z usługi.

Co to jest SMTP AUTH?

SMTP AUTH, określany przez Microsoft jako Client Submission, to mechanizm wykorzystywany do wysyłania wiadomości e-mail przez Exchange Online z użyciem klienckiego punktu wysyłki (smtp.office365.com na porcie 587). Umożliwia aplikacjom i urządzeniom uwierzytelnienie się przed wysłaniem wiadomości.

Czym jest Basic Authentication?

Basic Authentication to metoda uwierzytelniania, w której aplikacja lub urządzenie loguje się do usługi przy użyciu statycznego loginu i hasła. W przypadku Exchange Online była ona przez lata wykorzystywana m.in. przez drukarki, skanery, starsze aplikacje biznesowe oraz systemy wysyłające automatyczne powiadomienia.

Co dla użytkowników Exchange Online oznacza wyłączenie Basic Authentication dla SMTP AUTH?

Coraz głośniej słychać kroki nadchodzącej zmiany. Dla wielu organizacji nieistotnej, bo dawno już nie korzystają z przestarzałych metod autentykacji. Dla wielu innych niebezpiecznej, ponieważ brak reakcji w odpowiednim momencie spowoduje problemy w komunikacji mailowej.

Microsoft wyłączy Basic Authentication dla SMTP AUTH w Exchange Online w grudniu 2026 roku. Dotyczy to przede wszystkim organizacji korzystających z drukarek, skanerów, aplikacji ERP, CRM lub systemów monitoringu wysyłających wiadomości przez SMTP, które potencjalnie mogą wykorzystywać uwierzytelnianie Basic Auth.

Czy jednak zmiana jest aż tak dramatyczna, jak mogłoby się wydawać? Na wstępie warto doprecyzować jej zakres, bo w obiegowej opinii pojawia się sporo nieścisłości.

Microsoft nie wyłącza protokołu SMTP AUTH, ani klienckiego punktu wysyłki (smtp.office365.com na porcie 587). Wyłącza na nim tylko uwierzytelnianie podstawowe (Basic Authentication). Sam mechanizm SMTP AUTH (tzw. Client Submission) będzie działał dalej - tyle, że autentykacja loginem i hasłem zostanie zastąpiona tokenem OAuth.

Innymi słowy: aplikacja lub urządzenie, które potrafią uwierzytelnić się przez OAuth 2.0, połączą się dokładnie tym samym kanałem, co dotychczas. Zmieni się tylko sposób podania poświadczeń. Po wyłączeniu Basic Auth próby zalogowania starą metodą będą odrzucane komunikatem 550 5.7.30 Basic authentication is not supported for Client Submission.

Microsoft kilka razy już zapowiadał wycofanie się z przestarzałej metody uwierzytelniania, ale nieszczególnie garnął się do wymuszenia tej zmiany u Klientów. Termin blokady Basic Auth był już kilka razy przesuwany, według najnowszych doniesień nastąpi to w grudniu 2026 r.

Jak sprawdzić, czy wyłączenie Basic Authentication dotyczy Twojej organizacji?

Jeśli zastanawiasz się, w jakim obszarze infrastruktury Twojej lub Twojego klienta ta metoda przyjęła się i mocno zakorzeniła - oto, gdzie powinieneś zajrzeć w pierwszej kolejności:

• Urządzenia wielofunkcyjne (MFP) i skanery - wykorzystywane głównie do funkcji „Scan-to-Email”, gdzie urządzenie autoryzuje się w Exchange, aby wysłać zeskanowany dokument na skrzynkę użytkownika.
• Starsze aplikacje biznesowe (ERP, CRM, LOB) - systemy, które w kodzie źródłowym mają zaimplementowane użycie wyłącznie podstawowego uwierzytelniania, a są odpowiedzialne za wysyłkę różnego rodzaju dokumentów, raportów czy powiadomień (zarówno wewnętrznie, jak i do klientów końcowych).
• Systemy i aplikacje wewnętrzne (bazy danych, demony, systemy backupowe) - narzędzia, które cyklicznie rozsyłają raporty z wykonanych zadań wewnątrz infrastruktury (np. o błędach lub powodzeniu określonych zadań).
• Systemy monitoringu IT i alarmy - serwery, centrale telefoniczne, rejestratory CCTV, zasilacze UPS i rozwiązania sieciowe wysyłające alerty o eventach do działów wsparcia technicznego.

Dlaczego Microsoft wyłącza Basic Authentication dla SMTP AUTH?

Skoro wiemy, że uwierzytelnianie podstawowe dla SMTP jest wciąż szeroko wykorzystywane, to dlaczego tak właściwie musimy się go pozbyć? Odpowiedź jest prosta - dalsze utrzymywanie tej metody stoi w sprzeczności z nowoczesnymi standardami bezpieczeństwa.

Wbrew popularnemu uproszczeniu, problemem nie jest „przesyłanie hasła otwartym tekstem”. Wysyłka do Exchange Online wymaga szyfrowanego połączenia (STARTTLS/TLS), więc poświadczenia nie wędrują przez sieć w postaci jawnej. Rzeczywiste słabości leżą gdzie indziej:

• Basic Auth opiera się o statyczne poświadczenia z długim cyklem życia, które trzeba przechowywać na urządzeniu lub w konfiguracji aplikacji - często w sposób słabo zabezpieczony, a niejednokrotnie jawnie.
• Metoda ta nie obsługuje wieloskładnikowego uwierzytelniania (MFA), co dyskwalifikuje ją w zderzeniu z dzisiejszymi politykami dostępu.
• Wykradzione poświadczenia są w pełni reużywalne - działają, dopóki ktoś nie zmieni hasła lub nie zablokuje konta e-mail.
• Konta serwisowe z włączonym Basic Auth, z racji niskiego poziomu zabezpieczeń, są dominującym celem ataków typu password spraying oraz brute-force. Ich przejęcie daje atakującym furtkę do rozsyłania phishingu zarówno do wewnętrznych odbiorców jak i na zewnątrz.
• Na domiar złego metoda ta nie oferuje dostosowywania uprawnień (np. limitowania wysyłki do konkretnych aplikacji czy odbiorców). Nowoczesne standardy pozwalają ograniczyć zakres dostępu wyłącznie do niezbędnego zadania.

Jakie są alternatywy dla SMTP Basic Authentication?

Czy zatem istnieje coś lepiej dostosowanego do współczesnych potrzeb biznesowych i wymagań bezpieczeństwa? Oczywiście. Warto jednak rozróżnić dwie zupełnie różne sytuacje, bo dostępne opcje nie są równorzędnymi „alternatywami”.

Najmniejsza zmiana - ta sama ścieżka SMTP, inne logowanie. Jeśli urządzenie lub aplikacja potrafi uwierzytelnić się przez OAuth 2.0, to nie migrujesz na żadną nową technologię. Łączysz się dokładnie tym samym SMTP AUTH (smtp.office365.com:587), tyle że zamiast statycznego hasła aplikacja posługuje się bezpiecznym, rotującym tokenem dostępowym. To najmniej inwazyjna droga - pod warunkiem, że oprogramowanie realizujące wysyłkę natywnie wspiera ten standard. W przypadku starych urządzeń lub aplikacji bywa to bariera nie do przejścia.

Jeśli natywne OAuth na SMTP odpada, do wyboru są osobne usługi dedykowane różnym zastosowaniom, co pozwala na lepszą skalowalność i znacznie ogranicza szkody na wypadek skutecznego ataku na któreś z narzędzi:

• Microsoft Graph API - ścieżka zalecana przez Microsoft dla nowo tworzonych aplikacji i skryptów. To już inny protokół (REST), a nie SMTP, więc wymaga przepisania integracji. Komunikacja opiera się o uwierzytelnianie oparte na certyfikatach lub sekretach przechowywanych w Microsoft Entra ID z precyzyjnie ograniczonymi uprawnieniami.
• Microsoft 365 High Volume Email (HVE) - usługa dedykowana dla aplikacji i urządzeń generujących duży wolumen powiadomień wewnętrznych. HVE obsługuje wyłącznie odbiorców w obrębie tenanta. Usługa jest nowa, osiągnęła ogólną dostępność (GA) pod koniec marca 2026 r. i jest płatna w modelu pay-as-you-go. HVE korzysta z własnego punktu wysyłki - smtp-hve.office365.com na porcie 587 z wymaganym TLS.
• Azure Communication Services (ACS) - usługa w ramach Azure, stworzona dla systemów, które muszą masowo komunikować się z klientami na zewnątrz (poczta transakcyjna, bulk, marketingowa), całkowicie odciążając korporacyjną usługę pocztową.

Jest jeszcze jeden często pomijany szczegół, który potrafi kupić sporo czasu: HVE wspiera Basic Auth aż do września 2028 r. Microsoft świadomie utrzymał tam stare uwierzytelnianie z myślą o aplikacjach LOB i urządzeniach, które nie zdążą dostać wsparcia dla OAuth. W praktyce oznacza to, że stary skaner robiący „Scan-to-Email” do wewnętrznych skrzynek można przepiąć na konto HVE z Basic Auth i zyskać niemal dwa dodatkowe lata ponad graniczny grudzień 2026 r.

Próba wdrożenia nowych metod często jednak obnaża poziom długu technologicznego w organizacji, a także braki kompetencyjne w zespołach. Przejście na Graph API lub OAuth wymaga biegłości w zarządzaniu Microsoft Entra ID, poprawnego przypisywania ról, rejestrowania aplikacji i zarządzania cyklem życia ich sekretów, co dla mniejszych zespołów bywa wyzwaniem. Wiele sprawnych, ale starych skanerów i drukarek, a także aplikacji biznesowych nigdy nie otrzyma wsparcia dla OAuth 2.0 od swoich producentów. W ich przypadku bezpośrednia uwierzytelniona autoryzacja do chmury stanie się trwale niemożliwa i wymusi stosowanie obejść lub wymianę technologii.

Harmonogram wyłączania Basic Authentication

Skoro wiemy, że Microsoft w przeszłości już wielokrotnie przesuwał daty graniczne, to również do obecnych zapowiedzi możemy podchodzić z dystansem. Niemniej jednak według najnowszej korekty ogłoszonej 27 stycznia 2026 r. (która anulowała wcześniejszy, znacznie bliższy termin 30 kwietnia 2026 r.) ostateczny harmonogram prezentuje się następująco:

• Do grudnia 2026 r. działanie Basic Auth dla SMTP pozostaje bez zmian na poziomie całej usługi. To najlepszy moment na sprawdzenie raportów uwierzytelniania i inwentaryzację urządzeń oraz systemów.
• Z końcem grudnia 2026 r. uwierzytelnianie podstawowe dla SMTP zostanie wyłączone domyślnie we wszystkich istniejących środowiskach (tenantach). Administratorzy zyskają jeszcze możliwość ręcznego, tymczasowego włączania go z powrotem - traktowanego jako pomoc w migracji, a nie rozwiązanie docelowe.
• Dla nowych środowisk założonych po tej dacie Basic Auth dla SMTP będzie niedostępne domyślnie, a jedyną wspieraną metodą uwierzytelniania pozostanie OAuth.
• W drugiej połowie 2027 r. Microsoft ogłosi oficjalną datę twardego i nieodwracalnego usunięcia obsługi Basic Auth dla SMTP AUTH.

Jak przygotować inwentaryzację środowiska przed wyłączeniem Basic Authentication?

Inwentaryzacja to absolutny punkt wyjścia, a na wstępie trzeba rozróżnić, gdzie SMTP AUTH jest dozwolone oraz gdzie jest faktycznie używane. Pierwsze powie Ci, gdzie potencjalnie coś może się zepsuć; drugie - co realnie przestanie działać. Pominięcie tego rozróżnienia kończy się albo migrowaniem martwych kont, albo przeoczeniem nieoczywistego nadawcy.

Krok 1: Sprawdź ustawienie na poziomie tenanta

Najpierw ustal, jaka jest domyślna polityka dla całej organizacji:

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

Wartość False oznacza, że SMTP AUTH jest domyślnie włączone dla całego tenanta (poza skrzynkami wyłączonymi indywidualnie). Wartość True oznacza, że jest domyślnie wyłączone - i wtedy działa tylko tam, gdzie ktoś włączył je punktowo na konkretnej skrzynce.

Krok 2: Znajdź skrzynki, które mogą korzystać z SMTP AUTH

Na poziomie skrzynki właściwość SmtpClientAuthenticationDisabled przyjmuje trzy stany: $null (dziedziczy ustawienie tenanta), $false (jawnie włączone) i $true (jawnie wyłączone). Aby wylistować skrzynki z jawnie włączonym SMTP AUTH:

Get-CASMailbox -ResultSize Unlimited |
Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
Select-Object DisplayName, PrimarySmtpAddress, SmtpClientAuthenticationDisabled

Pamiętaj o logice dziedziczenia: jeśli na poziomie tenanta SMTP AUTH jest włączone (False), to z metody mogą korzystać również wszystkie skrzynki o wartości $null - nie tylko z jawnym $false. W takim scenariuszu sama powyższa komenda nie pokaże Ci pełnego obrazu i warto raczej wyszukać skrzynki jawnie wyłączone ($true), traktując całą resztę jako potencjalnie aktywne.

Krok 3: Ustal, co naprawdę wysyła pocztę przez SMTP AUTH

To najważniejszy krok, bo konfiguracja mówi tylko o tym, co wolno, a nie o tym, co się dzieje. Najbardziej wiarygodnym źródłem są logi logowań w Microsoft Entra ID. W portalu: Entra ID → Monitoring & health → Sign-in logs, a następnie filtr Client app → SMTP. Zobaczysz konto, źródłowy adres IP oraz aplikację - co zwykle pozwala namierzyć konkretne urządzenie czy serwer w sieci.

To samo można pobrać skryptowo przez Microsoft Graph (wymaga modułu Microsoft.Graph oraz uprawnienia AuditLog.Read.All):

Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "clientAppUsed eq 'Authenticated SMTP'" -All |
Select-Object CreatedDateTime, UserPrincipalName, IpAddress, AppDisplayName |
Sort-Object CreatedDateTime -Descending

Jedna istotna uwaga: standardowa retencja logów w Entra ID wynosi od 7 do 30 dni (zależnie od licencji). Jeśli masz urządzenia wysyłające pocztę rzadko - np. raport raz w miesiącu albo alert tylko przy awarii - krótkie okno obserwacji może to przeoczyć. Przy tej skali warto rozważyć eksport logów do Log Analytics lub innego magazynu o dłuższej retencji i monitorować ruch przez pełny cykl biznesowy, zanim uznasz inwentaryzację za kompletną.

Co zrobić, jeśli urządzenia nie obsługują OAuth? Czy istnieje obejście?

Tak - i to jest często najistotniejsza część całej układanki, bo dotyczy dokładnie tych urządzeń, które nigdy nie dostaną wsparcia dla OAuth. Kluczowa obserwacja jest następująca: nie każda metoda wysyłki poczty przez Exchange Online w ogóle korzysta z SMTP AUTH. Dwie z nich - Direct Send oraz relay przez konektor - nie uwierzytelniają się loginem i hasłem, więc wygaszenie Basic Auth zupełnie ich nie dotyczy.

Direct Send

Urządzenie wysyła pocztę bezpośrednio do punktu MX Twojego tenanta (twojadomena-pl.mail.protection.outlook.com) na porcie 25 bez żadnego uwierzytelniania. To najprostsze obejście, ale ma twarde ograniczenia: działa wyłącznie dla odbiorców wewnętrznych (w obrębie Twoich domen), a publiczny adres IP urządzenia powinien być uwzględniony w rekordzie SPF, aby poczta nie lądowała w spamie.

Ważne zastrzeżenie bezpieczeństwa: Direct Send bywa wykorzystywany do podszywania się pod wewnętrznych nadawców w atakach phishingowych, dlatego Microsoft udostępnił przełącznik pozwalający go zablokować na poziomie organizacji (Set-OrganizationConfig -RejectDirectSend $true). To rozwiązanie funkcjonalne, ale nie należy go traktować jako „bezpiecznego z definicji” - w środowiskach o podwyższonych wymaganiach bywa świadomie wyłączane.

Relay przez konektor (certyfikat lub statyczne IP)

Jeśli potrzebujesz wysyłać również do odbiorców zewnętrznych albo chcesz większej kontroli, właściwym rozwiązaniem jest dedykowany konektor przychodzący w Exchange Online i autoryzujący ruch na podstawie statycznego adresu IP lub certyfikatu TLS - także bez poświadczeń per urządzenie:

New-InboundConnector -Name "Relay-urzadzenia-LAN" -ConnectorType OnPremises -SenderIPAddresses xxx.xxx.xxx.xxx -RequireTls $true -RestrictDomainsToIPAddresses $true

Urządzenia kierują wówczas pocztę na punkt MX tenanta, a Exchange Online dopasowuje połączenie do konektora po adresie IP (lub certyfikacie) i zezwala na relay. Brak haseł oznacza brak czegokolwiek do wykradzenia czy rotacji.

Lokalny SMTP Relay

To rozwiązanie, które zdejmuje problem z głowy raz na zawsze, nie dotykając samych urządzeń. Stawiasz w sieci lokalny serwer przekazujący (rola IIS SMTP, Postfix lub inny lekki relay), który przyjmuje niezautoryzowaną pocztę od starych skanerów i aplikacji w LAN, a następnie sam przekazuje ją do Exchange Online - przez konektor/Direct Send albo uwierzytelniając się nowocześnie przez OAuth w imieniu całego zbioru urządzeń i aplikacji.

Zalety są dwie. Po pierwsze, granicę modern auth obsługuje jeden dobrze utrzymywany punkt zamiast kilkudziesięciu urządzeń. Po drugie, archaiczne MFP i aplikacje LOB mogą zostać dokładnie tak, jak są - z perspektywy ich konfiguracji „serwer pocztowy” stoi w lokalnej sieci i przyjmuje połączenie po staremu. To zwykle najtańsza i najmniej ryzykowna droga dla środowisk z dużą liczbą niezdolnych do modernizacji urządzeń.

HVE z Basic Auth (do września 2028)

Dla wysyłki ściśle wewnętrznej (powiadomienia, alerty, raporty trafiające do skrzynek w tenancie) osobną furtką jest przepięcie urządzeń na punkt wysyłki HVE (smtp-hve.office365.com:587), który - jako jedyny - zachowuje obsługę Basic Auth aż do września 2028 r. To rozwiązanie pomostowe: kupuje czas, ale nie zwalnia z docelowej migracji, wiąże się też z dodatkowymi opłatami w modelu pay-as-you-go.

Niezależnie od wybranej ścieżki morał jest jeden: czasu tylko pozornie jest dużo, więc okno między lipcem a grudniem 2026 r. najlepiej potraktować jak twardy harmonogram projektu - inwentaryzacja, testy, migracja, sprzątanie wyjątków. W myśl starej zasady: lepiej zapobiegać niż leczyć.

FAQ

Co to jest SMTP AUTH?

SMTP AUTH (Client Submission) to mechanizm umożliwiający aplikacjom i urządzeniom wysyłanie wiadomości e-mail przez Exchange Online z wykorzystaniem punktu smtp.office365.com na porcie 587. Microsoft nie wycofuje samego SMTP AUTH - zmienia jedynie sposób uwierzytelniania użytkowników i aplikacji.

Czym jest Basic Authentication?

Basic Authentication to metoda uwierzytelniania oparta na loginie i haśle. Ze względu na ograniczenia w zakresie bezpieczeństwa, takie jak brak obsługi MFA oraz wykorzystanie statycznych poświadczeń, Microsoft wycofuje ją dla SMTP AUTH w Exchange Online i zastępuje uwierzytelnianiem opartym na OAuth 2.0.

Czy Microsoft całkowicie wyłącza SMTP AUTH w Exchange Online?

Nie. Microsoft nie wyłącza samego protokołu SMTP AUTH ani klienckiego punktu wysyłki (smtp.office365.com na porcie 587). Wyłączone zostanie wyłącznie uwierzytelnianie podstawowe (Basic Authentication). Oznacza to, że SMTP AUTH będzie nadal działać, ale tylko z wykorzystaniem nowoczesnego uwierzytelniania OAuth 2.0.

Kiedy Microsoft wyłączy Basic Authentication dla SMTP AUTH?

Zgodnie z aktualnym harmonogramem opisanym w artykule, Basic Authentication dla SMTP AUTH zostanie domyślnie wyłączone w istniejących środowiskach Exchange Online pod koniec grudnia 2026 roku. Administratorzy będą mogli jeszcze tymczasowo ponownie włączyć tę metodę uwierzytelniania, jednak rozwiązanie to ma służyć wyłącznie ułatwieniu migracji.

Jakie urządzenia i aplikacje mogą zostać dotknięte zmianą?

Najczęściej są to urządzenia wielofunkcyjne i skanery wykorzystujące funkcję „Scan-to-Email”, starsze systemy ERP, CRM i aplikacje biznesowe, systemy monitoringu IT, centrale telefoniczne, rejestratory CCTV, zasilacze UPS oraz różnego rodzaju aplikacje i usługi wysyłające automatyczne raporty lub powiadomienia przez SMTP.

Dlaczego Microsoft wycofuje Basic Authentication?

Basic Authentication wykorzystuje statyczne poświadczenia, które często są przechowywane w sposób niewystarczająco zabezpieczony. Metoda ta nie obsługuje uwierzytelniania wieloskładnikowego (MFA), a przejęte dane logowania mogą być wykorzystywane przez atakujących aż do momentu zmiany hasła lub zablokowania konta. Nowoczesne standardy uwierzytelniania pozwalają ograniczyć zakres dostępu aplikacji wyłącznie do niezbędnych zadań, dzięki czemu zwiększają poziom bezpieczeństwa.

Czy urządzenia obsługujące OAuth muszą zmienić sposób wysyłania wiadomości?

Nie. Jeśli urządzenie lub aplikacja obsługuje OAuth 2.0, nadal może korzystać z tego samego mechanizmu SMTP AUTH oraz tego samego punktu wysyłki. Zmieni się jedynie sposób uwierzytelniania - zamiast loginu i hasła wykorzystywany będzie token dostępu.

Jak sprawdzić, czy moja organizacja korzysta z Basic Authentication dla SMTP AUTH?

Autor rekomenduje rozpoczęcie od inwentaryzacji środowiska. Należy sprawdzić konfigurację SMTP AUTH na poziomie całego tenanta oraz poszczególnych skrzynek pocztowych, a następnie zweryfikować logi logowań w Microsoft Entra ID. Dopiero analiza rzeczywistego ruchu pozwala ustalić, które urządzenia i aplikacje faktycznie korzystają z Basic Authentication.

Co zrobić, jeśli urządzenie nie obsługuje OAuth?

Artykuł opisuje kilka możliwych rozwiązań. W zależności od scenariusza można wykorzystać Direct Send, relay przez konektor w Exchange Online, lokalny serwer SMTP Relay albo usługę High Volume Email (HVE). Dobór odpowiedniej metody zależy od sposobu wysyłania wiadomości oraz możliwości technicznych urządzeń i aplikacji.

Czy High Volume Email (HVE) nadal obsługuje Basic Authentication?

Tak. Zgodnie z informacjami przedstawionymi w artykule usługa High Volume Email (HVE) zachowuje obsługę Basic Authentication do września 2028 roku. Jest to jednak rozwiązanie przejściowe, przeznaczone dla wysyłki wewnętrznej, które nie zastępuje docelowej migracji do nowoczesnych metod uwierzytelniania.

Czy warto czekać z przygotowaniami do ostatniej chwili?

Nie. Choć Microsoft kilkukrotnie przesuwał termin wycofania Basic Authentication, autor zaleca potraktowanie okresu poprzedzającego grudzień 2026 roku jako czasu na realizację projektu migracyjnego. Obejmuje on inwentaryzację środowiska, testy, migrację oraz uporządkowanie wyjątków.

Źródła

• Microsoft Tech Community - Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline (korekta harmonogramu z 27 stycznia 2026 r.): techcommunity.microsoft.com
• Microsoft Tech Community - Exchange Online to retire Basic auth for Client Submission (SMTP AUTH): techcommunity.microsoft.com
• Microsoft Learn - Deprecation of Basic authentication in Exchange Online: learn.microsoft.com
• Microsoft Tech Community - High Volume Email: Continued support for Basic Authentication & other important updates (wsparcie Basic Auth w HVE do września 2028 r., usunięcie wysyłki zewnętrznej): techcommunity.microsoft.com
• Microsoft Tech Community - Public Preview / Updates to High Volume Email for Microsoft 365 (GA, model rozliczeń, OAuth): techcommunity.microsoft.com
• Microsoft Learn - Manage High Volume Email for Microsoft 365 (uwierzytelnianie, endpoint, ograniczenia): learn.microsoft.com
• Microsoft Learn - Use OAuth authentication for high volume emails for Microsoft 365 (XOAUTH2, ograniczanie aplikacji): learn.microsoft.com