Konfiguracja SMTP Microsoft 365 — porty, OAuth2 i błędy

Wysyłka e-maili przez SMTP Microsoft 365 brzmi prosto — dopóki nie trafisz na komunikat 535 5.7.3 Authentication unsuccessful o 17:00 w piątek. Ten artykuł daje Ci konkretny plan działania: właściwe porty, krok po kroku konfigurację OAuth2, ustawienia relay SMTP oraz listę najczęstszych błędów z ich rozwiązaniami. Zero lania wody — tylko to, czego potrzebujesz.

Jak działa wysyłka SMTP w Microsoft 365?

Microsoft 365 (dawniej Office 365) udostępnia serwer SMTP pod adresem smtp.office365.com. Możesz go używać zarówno do wysyłki z aplikacji desktopowych (Outlook, Thunderbird), jak i z systemów zewnętrznych — drukarek sieciowych, aplikacji CRM, platform mailingowych czy własnych skryptów. Ważne jest jednak, że Microsoft wyróżnia trzy różne scenariusze wysyłki, które rządzą się odmiennymi regułami.

Trzy scenariusze wysyłki — który dotyczy Ciebie?

• SMTP AUTH (uwierzytelniony klient) — standardowa wysyłka z aplikacji lub skryptu przy użyciu loginu i hasła lub OAuth2. Wymaga licencji Microsoft 365 z aktywną skrzynką.
• Direct Send — wysyłka bezpośrednio do serwera MX odbiorcy, bez uwierzytelniania. Działa tylko dla adresatów w tej samej dzierżawie (tenant) — nie nadaje się do wysyłki zewnętrznej.
• SMTP Relay przez Microsoft 365 — wysyłka z urządzeń lub aplikacji przez łącznik (connector) skonfigurowany w centrum administracyjnym. Wymaga statycznego IP lub certyfikatu TLS.

Jeśli wysyłasz e-maile z zewnętrznej aplikacji do odbiorców poza organizacją, interesuje Cię scenariusz pierwszy (SMTP AUTH) lub trzeci (relay). Direct Send jest użyteczny wyłącznie w środowiskach wewnętrznych.

Porty SMTP w Office 365 — który wybrać?

Wybór portu to jedna z pierwszych decyzji, a błędna konfiguracja skutkuje brakiem połączenia lub odrzuceniem wiadomości. Poniższa tabela porównuje dostępne opcje:

Wniosek praktyczny: do uwierzytelnionej wysyłki z aplikacji zawsze używaj portu 587 z STARTTLS. Port 465 nie jest obsługiwany przez smtp.office365.com — jeśli Twoja aplikacja wymaga wyłącznie SSL na 465, musisz skonfigurować lokalny relay lub zmienić ustawienia klienta. Port 25 jest zarezerwowany dla scenariusza relay i nie przyjmuje połączeń SMTP AUTH.

Konfiguracja SMTP AUTH krok po kroku

Zanim zaczniesz, upewnij się, że konto ma aktywną licencję Microsoft 365 (np. Business Basic, Business Standard lub Exchange Online Plan 1/2). Konta bez licencji Exchange nie mogą wysyłać przez SMTP AUTH.

Krok 1 — Włącz SMTP AUTH dla skrzynki

Od 2020 roku Microsoft domyślnie wyłącza SMTP AUTH na poziomie dzierżawy dla nowych kont. Musisz go włączyć ręcznie — globalnie lub per użytkownik.

1. Zaloguj się do centrum administracyjnego Microsoft 365 (admin.microsoft.com).
2. Przejdź do Użytkownicy → Aktywni użytkownicy i wybierz konto.
3. Kliknij zakładkę Poczta, następnie Zarządzaj ustawieniami aplikacji pocztowych.
4. Przełącz opcję Uwierzytelniony protokół SMTP na Włączony.
5. Zapisz zmiany — propagacja trwa do 60 minut.

Alternatywnie możesz włączyć SMTP AUTH dla całej dzierżawy przez Exchange Admin Center: Ustawienia → Przepływ poczty → Uwierzytelniony protokół SMTP klienta. Pamiętaj jednak, że globalne włączenie SMTP AUTH zwiększa powierzchnię ataku — bezpieczniejsze jest włączanie go selektywnie, tylko dla kont, które faktycznie tego potrzebują.

Krok 2 — Parametry połączenia SMTP

Po włączeniu SMTP AUTH wpisz w swojej aplikacji lub skrypcie następujące dane:

• Serwer SMTP: smtp.office365.com
• Port: 587
• Szyfrowanie: STARTTLS (nie SSL)
• Użytkownik: pełny adres e-mail (np. jan.kowalski@twojafirma.pl)
• Hasło: hasło do konta Microsoft 365
• Uwierzytelnianie: LOGIN lub PLAIN (zależnie od klienta)

OAuth2 dla SMTP — dlaczego warto i jak to skonfigurować?

Microsoft konsekwentnie ogranicza użycie haseł w protokołach legacy. Od października 2022 roku Basic Authentication (login + hasło) jest wyłączone dla większości protokołów w Microsoft 365, w tym dla SMTP AUTH w nowych dzierżawach. Jeśli Twoja aplikacja nadal używa hasła, możesz działać tylko dlatego, że Twój tenant był założony przed tą datą i nie miałeś włączonej polityki wyłączenia Basic Auth. To się może zmienić. Rozwiązaniem jest OAuth2 — nowoczesna metoda autoryzacji, która nie wymaga przekazywania hasła do aplikacji zewnętrznej.

Jak działa OAuth2 w kontekście SMTP?

Zamiast hasła aplikacja używa tokenu dostępu wydanego przez Azure Active Directory (Microsoft Entra ID). Token ma ograniczony czas życia (domyślnie 60 minut) i zakres uprawnień — nawet jeśli wycieknie, atakujący nie zna hasła użytkownika. Mechanizm autoryzacji opiera się na protokole XOAUTH2 obsługiwanym przez smtp.office365.com.

Krok po kroku — rejestracja aplikacji w Azure AD

1. Zaloguj się do portal.azure.com jako administrator.
2. Przejdź do Microsoft Entra ID → Rejestracje aplikacji → Nowa rejestracja.
3. Podaj nazwę aplikacji (np. "MailerPRO SMTP"), wybierz typ konta (Tylko konta w tym katalogu organizacyjnym).
4. Skopiuj Identyfikator aplikacji (client_id) i Identyfikator katalogu (tenant_id).
5. Przejdź do Certyfikaty i klucze tajne → Nowy klucz tajny klienta. Ustaw ważność (max 24 miesiące) i skopiuj wartość klucza — zobaczysz ją tylko raz.
6. Przejdź do Uprawnienia interfejsu API → Dodaj uprawnienie → Microsoft Graph → Uprawnienia aplikacji i dodaj Mail.Send.
7. Kliknij Udziel zgody administratora — bez tego krok nie zadziała.

Uzyskiwanie tokenu i wysyłka przez SMTP

Token OAuth2 uzyskujesz przez żądanie POST do endpointu:

https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token

W ciele żądania przekazujesz: grant_type=client_credentials, client_id, client_secret oraz scope=https://outlook.office365.com/.default. W odpowiedzi otrzymujesz access_token, który następnie przekazujesz jako mechanizm uwierzytelnienia XOAUTH2 w sesji SMTP. Większość nowoczesnych bibliotek (np. Python msal + smtplib, PHPMailer z OAuth2, Nodemailer) obsługuje ten przepływ natywnie. Platformy mailingowe takie jak MailerPRO obsługują OAuth2 dla Microsoft 365 bez potrzeby ręcznego zarządzania tokenami — wystarczy jednorazowa autoryzacja przez interfejs.

SMTP Relay w Microsoft 365 — dla urządzeń i serwerów

Drukarki, skanery, starsze systemy ERP czy serwery aplikacyjne często nie obsługują SMTP AUTH ani OAuth2. W takich przypadkach rozwiązaniem jest Microsoft 365 SMTP Relay — wysyłka przez port 25 z uwierzytelnieniem na podstawie statycznego adresu IP lub certyfikatu TLS.

Konfiguracja łącznika (connector) w Exchange Admin Center

1. Zaloguj się do admin.exchange.microsoft.com.
2. Przejdź do Przepływ poczty → Łączniki → Dodaj łącznik.
3. Jako źródło wybierz Serwer poczty e-mail organizacji, jako cel Office 365.
4. W sekcji uwierzytelniania wybierz Sprawdzanie adresu IP nadawcy i dodaj statyczny IP urządzenia/serwera.
5. Alternatywnie możesz wybrać weryfikację przez certyfikat TLS — wpisz nazwę podmiotu certyfikatu (CN).
6. Zapisz łącznik i poczekaj na propagację (do 1 godziny).

Serwer SMTP dla relay to ten sam adres — smtp.office365.com port 25. Pamiętaj, że relay przez Microsoft 365 pozwala wysyłać e-maile tylko z domen zweryfikowanych w Twojej dzierżawie. Próba wysyłki z nieznanych domen zakończy się błędem 550 5.7.64 Relay Access Denied.

Typowe błędy SMTP Office 365 i jak je naprawić

Poniżej zebrałem najczęstsze komunikaty błędów, z którymi zgłaszają się administratorzy, wraz z ich przyczynami i konkretnymi rozwiązaniami.

535 5.7.3 Authentication unsuccessful

Najczęstszy błąd. Przyczyny:

• SMTP AUTH nie jest włączony dla konta — sprawdź ustawienia w centrum administracyjnym (patrz Krok 1).
• Błędne hasło lub login (pamiętaj: login to pełny adres e-mail, nie sama nazwa użytkownika).
• Konto ma włączone MFA bez skonfigurowanego hasła aplikacji — utwórz hasło aplikacji w ustawieniach bezpieczeństwa konta.
• Basic Authentication jest zablokowany przez politykę warunkowego dostępu — przejdź na OAuth2.

550 5.7.64 TenantAttribution / Relay Access Denied

Pojawia się w scenariuszu relay, gdy adres IP nadawcy nie jest na liście dozwolonych w łączniku lub gdy domena nadawcy nie jest zweryfikowana w dzierżawie. Sprawdź konfigurację łącznika i zweryfikuj domeny w centrum administracyjnym Microsoft 365 (Ustawienia → Domeny).

421 4.3.2 Service not available / Too many connections

Microsoft 365 stosuje limity wysyłki: maksymalnie 30 wiadomości na minutę przez SMTP AUTH i 10 000 odbiorców dziennie na skrzynkę. Przekroczenie tych limitów skutkuje tymczasowym blokowaniem. Jeśli wysyłasz kampanie e-mailowe, rozważ dedykowaną platformę mailingową lub rozkładaj wysyłkę w czasie.

530 5.7.57 Client not authenticated

Aplikacja próbuje wysłać wiadomość bez uwierzytelnienia lub z użyciem portu, który nie obsługuje SMTP AUTH (np. port 25). Zmień port na 587 i upewnij się, że mechanizm uwierzytelnienia jest ustawiony na LOGIN lub XOAUTH2.

Certyfikat TLS / SSL handshake failed

Zwykle oznacza, że aplikacja próbuje nawiązać połączenie SSL bezpośrednio (jak na porcie 465) zamiast użyć STARTTLS na porcie 587. Zmień typ szyfrowania w ustawieniach klienta z SSL/TLS na STARTTLS.

Bezpieczeństwo i zgodność z RODO

Konfigurując SMTP w Microsoft 365 dla celów biznesowych, warto pamiętać o kilku aspektach zgodności. Zgodnie z art. 32 RODO, administrator danych jest zobowiązany do wdrożenia odpowiednich środków technicznych zapewniających bezpieczeństwo przetwarzania — w tym szyfrowania danych w transmisji. Używanie STARTTLS na porcie 587 spełnia ten wymóg. Unikaj konfiguracji bez szyfrowania (plain text SMTP), nawet w środowiskach wewnętrznych.

Jeśli wysyłasz e-maile marketingowe do klientów, pamiętaj o obowiązku uzyskania zgody (art. 6 ust. 1 lit. a RODO lub art. 10 ustawy o świadczeniu usług drogą elektroniczną) oraz o obowiązku prowadzenia rejestru czynności przetwarzania (art. 30 RODO). Sama techniczna konfiguracja SMTP to dopiero połowa drogi — równie ważna jest podstawa prawna wysyłki.

Konfiguracja SMTP w Microsoft 365 nie musi być skomplikowana — pod warunkiem, że wybierzesz właściwy scenariusz (SMTP AUTH vs. relay), włączysz odpowiednie ustawienia w centrum administracyjnym i zadbasz o nowoczesną metodę uwierzytelnienia. OAuth2 to dziś standard, a nie opcja — jeśli Twoja aplikacja nadal używa hasła do SMTP, zaplanuj migrację zanim Microsoft wymusi ją za Ciebie. Jeśli szukasz gotowego rozwiązania, które obsługuje OAuth2 dla Microsoft 365 i pozwala wysyłać kampanie z własnych skrzynek bez ryzyka przekroczenia limitów — sprawdź, co oferuje MailerPRO.