SuiteCRM Polska

Darmowy system CRM na licencji Open Source

Poczta w SuiteCRM 8: konfiguracja IMAP/SMTP i OAuth dla Microsoft 365 i Gmaila

Pocztę w SuiteCRM 8 konfiguruje się przez dwa typy kont: przychodzące (IMAP) i wychodzące (SMTP). Dla Microsoft 365 i Gmaila jedyną przyszłościową metodą logowania jest OAuth 2.0, ustawiany w modułach External OAuth Providers i External OAuth Connections. Google wyłączył logowanie hasłem do IMAP i SMTP w 2025 roku. Microsoft pod koniec grudnia 2026 domyślnie wyłączy uwierzytelnianie Basic dla SMTP AUTH w istniejących tenantach.

W skrócie: zaktualizuj SuiteCRM do wersji 8.10.2, zarejestruj aplikację w Microsoft Entra ID lub Google Cloud, utwórz w SuiteCRM provider OAuth i połączenie OAuth, a następnie podepnij je do kont IMAP i SMTP. Na koniec sprawdź, czy działa cron i zadanie importu poczty.

Jak działa poczta w SuiteCRM 8?

Poczta w SuiteCRM 8 opiera się na czterech powiązanych elementach. Provider OAuth przechowuje dane aplikacji zarejestrowanej u dostawcy poczty. Połączenie OAuth przechowuje tokeny dla konkretnej skrzynki. Konto przychodzące (Inbound Email Account) importuje wiadomości przez IMAP, a konto wychodzące (Outbound Email Account) wysyła je przez SMTP. Oba konta korzystają z tego samego połączenia OAuth, więc jedna autoryzacja obsługuje odbiór i wysyłkę.

Element SuiteCRM 8Co przechowuje lub robiGdzie go znaleźć
External OAuth ProviderClient ID, Client Secret, adresy autoryzacji i tokenu, zakresy uprawnień (scopes)Panel administracyjny → External OAuth Providers
External OAuth ConnectionToken dostępowy i token odświeżający dla jednej skrzynkiProfil → External OAuth Connections
Inbound Email AccountImport poczty przez IMAP, monitorowane foldery, tworzenie zgłoszeń (Cases)Profil lub panel administracyjny → Inbound Email Accounts
Outbound Email AccountWysyłka przez SMTP: konto systemowe, grupowe lub osobistePanel administracyjny → Outbound Email Accounts

Każdy z tych rekordów w SuiteCRM 8 występuje w wersji osobistej (Personal) lub grupowej (Group), a konto przychodzące dodatkowo w wersji Bounce, służącej do odczytu zwrotów z kampanii. Rekord grupowy jest przeznaczony dla skrzynek współdzielonych, np. biuro@ lub serwis@. Typy muszą się zgadzać: grupowe konto IMAP lub SMTP łączymy z grupowym połączeniem OAuth. Dokumentacja SuiteCRM ostrzega, że połączenie osobiste podpięte do konta grupowego powoduje błędy.

Providery OAuth w SuiteCRM 8 służą wyłącznie do autoryzacji skrzynek pocztowych, nie do logowania użytkowników do CRM. Logowanie kontem Microsoft lub Google realizuje się osobno, przez SAML (SSO). To częste nieporozumienie: administrator konfiguruje provider Microsoft i oczekuje, że na ekranie logowania SuiteCRM pojawi się przycisk „Zaloguj przez Microsoft”. Tak się nie stanie, bo moduł External OAuth Providers obsługuje tylko pocztę.

Dlaczego login i hasło przestają działać z Microsoft 365 i Gmailem?

Login i hasło przestają działać, bo obaj dostawcy wycofują uwierzytelnianie Basic na rzecz OAuth 2.0. Google wyłączył dostęp „mniej bezpiecznych aplikacji” dla wszystkich kont od 14 marca 2025 roku (Google Workspace Admin Help, 2025). Od tej daty IMAP, SMTP i POP nie działają z samym hasłem. Hasło aplikacji to nadal możliwe obejście dla kont z weryfikacją dwuetapową, ale nie nadaje się do skrzynek grupowych zarządzanych przez dział IT.

Microsoft zmienił harmonogram wycofania Basic Auth dla SMTP AUTH w Exchange Online kilkukrotnie. Według komunikatu MC786329 zaktualizowanego 27 stycznia 2026 roku SMTP AUTH z Basic Auth zostanie domyślnie wyłączony w istniejących tenantach pod koniec grudnia 2026. Nowe tenanty utworzone po tym terminie nie będą go miały domyślnie, a ostateczną datę usunięcia Microsoft ogłosi w drugiej połowie 2027 (Microsoft 365 Message Center, 2026).

W praktyce SuiteCRM z wysyłką przez smtp.office365.com i zwykłe hasło przestanie wysyłać wiadomości po zmianie domyślnych ustawień tenanta. Typowy objaw w logu to błąd 535 5.7.139 Authentication unsuccessful, basic authentication is disabled. Administrator Microsoft 365 może ponownie włączyć SMTP AUTH dla wybranych skrzynek, ale to tylko odsuwa problem do ogłoszenia daty ostatecznej. Przejście na OAuth przed końcem 2026 roku usuwa to ryzyko.

Konfiguracja poczty w SuiteCRM 8

Od której wersji SuiteCRM 8 obsługuje OAuth dla poczty?

SuiteCRM 8 obsługuje OAuth dla poczty przychodzącej od wersji 8.2, a dla poczty wychodzącej od wersji 8.8.1. Wersja 8.2 wprowadziła moduły External OAuth Providers i External OAuth Connections oraz logowanie IMAP przez XOAUTH2 (SuiteCRM Release Notes 8.2). Wydanie 8.8.1 dodało OAuth przy konfiguracji kont wychodzących (SuiteCRM, 2025). Starsze instalacje 8.x wymagają aktualizacji przed migracją skrzynek na OAuth.

Rekomendowaną wersją do konfiguracji poczty jest SuiteCRM 8.10.2, wydana 31 lipca 2026 roku. Poprawia ona błędy modułu Email, które łatwo pomylić z błędami konfiguracji OAuth: wybór folderów, strefę czasową importu IMAP i resetowanie haseł konta wychodzącego (SuiteCRM, 2026). Aktualizacja do 8.10.2 przed diagnozowaniem problemów z pocztą oszczędza czas, bo eliminuje znane błędy samej aplikacji.

Jak skonfigurować OAuth dla Microsoft 365 w SuiteCRM?

Konfiguracja OAuth dla Microsoft 365 w SuiteCRM 8 wymaga rejestracji aplikacji w Microsoft Entra ID, utworzenia providera z konektorem „Microsoft” i autoryzacji połączenia. Cały proces zajmuje kilkanaście minut, jeśli administrator ma uprawnienia do rejestracji aplikacji w tenancie. Poniższe kroki dotyczą providera grupowego, czyli jednej aplikacji Entra ID dla wszystkich skrzynek w domenie firmy.

  1. Zarejestruj aplikację w Microsoft Entra ID. W portalu Azure otwórz App registrations → New registration. Nadaj nazwę (np. „SuiteCRM”), wybierz typ kont (dla jednej organizacji: Single tenant) i ustaw Redirect URI: https://<adres-suitecrm>/index.php?entryPoint=setExternalOAuthToken. Azure akceptuje wyłącznie adresy HTTPS, z wyjątkiem localhost.
  2. Skopiuj Client ID i utwórz Client Secret. Application (client) ID z ekranu Overview to Client ID dla SuiteCRM. W Certificates & secrets utwórz nowy sekret i od razu skopiuj jego wartość, bo Azure pokazuje ją tylko raz. Zapisz datę wygaśnięcia sekretu w kalendarzu zespołu IT.
  3. Dodaj uprawnienia delegowane. W API permissions dodaj: offline_access, IMAP.AccessAsUser.All, User.Read, a jeśli SuiteCRM ma także wysyłać pocztę, również SMTP.Send. W razie potrzeby udziel zgody administratora (Grant admin consent).
  4. Ustaw opcje uwierzytelniania. W sekcji Authentication zaznacz „Access tokens (used for implicit flows)”, zgodnie z dokumentacją SuiteCRM.
  5. Skopiuj adresy endpointów. W Endpoints skopiuj „OAuth 2.0 authorization endpoint (v2)” i „OAuth 2.0 token endpoint (v2)”.
  6. Utwórz provider w SuiteCRM. W panelu administracyjnym otwórz External OAuth Providers → New Group OAuth Provider. W polu Connector wybierz „Microsoft”, wpisz Client ID, Client Secret, Authorize URL i Access Token URL. Jako scopes podaj: offline_access, https://outlook.office.com/IMAP.AccessAsUser.All, https://outlook.office.com/SMTP.Send i User.Read.
  7. Autoryzuj połączenie. W External OAuth Connections utwórz połączenie grupowe, wybierz provider i kliknij Authenticate. Po zalogowaniu w oknie Microsoft pola tokenów wypełnią się automatycznie. Zapisz rekord.
  8. Sprawdź ustawienia skrzynki w Microsoft 365. Skrzynka musi mieć włączone IMAP, a do wysyłki także uwierzytelniony SMTP (SMTP AUTH). Administrator sprawdzi to w Exchange admin center lub poleceniem PowerShell Set-CASMailbox -Identity <adres> -ImapEnabled $true -SmtpClientAuthenticationDisabled $false.

Najczęstszy błąd na tym etapie dotyczy zakresów uprawnień. Zakresy Microsoft Graph (np. Mail.Read) nie dają dostępu do IMAP i SMTP. SuiteCRM łączy się z serwerami Exchange Online przez protokoły IMAP i SMTP, więc w polu scopes providera potrzebne są zakresy zasobu Outlook z prefiksem https://outlook.office.com/. Autoryzacja z samymi zakresami Graph kończy się poprawnie, ale późniejsze połączenie IMAP zwraca błąd uwierzytelnienia.

Jak skonfigurować OAuth dla Gmaila i Google Workspace?

OAuth dla Gmaila i Google Workspace konfiguruje się w SuiteCRM 8 przez provider typu „Generic”, bo dedykowany konektor istnieje tylko dla Microsoft. Oficjalna dokumentacja SuiteCRM opisuje krok po kroku wyłącznie konfigurację Microsoft, dlatego przy Google najwięcej problemów sprawiają dwa elementy: adresy endpointów wpisywane ręcznie i uzyskanie tokenu odświeżającego. Bez tokenu odświeżającego połączenie przestaje działać po wygaśnięciu tokenu dostępowego, czyli po około godzinie.

  1. Utwórz projekt i ekran zgody w Google Cloud Console. Dla Google Workspace wybierz typ „Internal”, dzięki czemu aplikacja działa dla kont organizacji bez weryfikacji przez Google. Typ „External” jest potrzebny tylko dla prywatnych kont @gmail.com.
  2. Utwórz identyfikator klienta OAuth. W Credentials utwórz OAuth client ID typu „Web application” i dodaj Authorized redirect URI: https://<adres-suitecrm>/index.php?entryPoint=setExternalOAuthToken. Skopiuj Client ID i Client Secret.
  3. Utwórz provider w SuiteCRM. W External OAuth Providers wybierz Connector „Generic”. Authorize URL: https://accounts.google.com/o/oauth2/v2/auth, Access Token URL: https://oauth2.googleapis.com/token. Jako scope wpisz https://mail.google.com/ oraz openid email profile, a adres danych właściciela zasobu ustaw na https://openidconnect.googleapis.com/v1/userinfo.
  4. Wymuś token odświeżający. Do opcji adresu autoryzacji dodaj parametry access_type=offline i prompt=consent. Po autoryzacji połączenia sprawdź, czy pole tokenu odświeżającego (refresh token) jest wypełnione. Puste pole oznacza, że połączenie przestanie działać po godzinie.
  5. Autoryzuj połączenie i utwórz konta. Utwórz External OAuth Connection, kliknij Authenticate i zaloguj się kontem Google. Następnie skonfiguruj konto IMAP (imap.gmail.com, port 993, SSL) i SMTP (smtp.gmail.com, port 587, TLS) z typem uwierzytelniania OAuth.

Przy kontach @gmail.com i ekranie zgody typu „External” obowiązują dwa ograniczenia Google. Aplikacja w statusie „Testing” wydaje tokeny odświeżające ważne tylko 7 dni, więc połączenie w SuiteCRM wygasa co tydzień. Zakres https://mail.google.com/ należy do zakresów zastrzeżonych (restricted), dlatego publikacja aplikacji typu External wymaga weryfikacji przez Google. Dla firm na Google Workspace typ „Internal” omija oba problemy.

Jakie parametry IMAP i SMTP wpisać dla Microsoft 365 i Gmaila?

Parametry serwerów dla Microsoft 365 i Gmaila w SuiteCRM 8 różnią się adresami, a pokrywają portami. W obu przypadkach typ uwierzytelniania kont ustawiamy na OAuth i wybieramy wcześniej utworzone połączenie OAuth. Nazwa użytkownika w koncie IMAP i SMTP musi być identyczna z kontem, którym autoryzowano połączenie.

ParametrMicrosoft 365Gmail / Google Workspace
Serwer IMAPoutlook.office365.comimap.gmail.com
Port IMAP993, SSL993, SSL
Serwer SMTPsmtp.office365.comsmtp.gmail.com
Port SMTP587, TLS (STARTTLS)587, TLS (alternatywnie 465, SSL)
Konektor providera w SuiteCRMMicrosoftGeneric
Kluczowe scopesoffline_access, IMAP.AccessAsUser.All, SMTP.Send, User.Read (z prefiksem outlook.office.com dla IMAP i SMTP)https://mail.google.com/, openid, email, profile
Typ uwierzytelniania kontOAuthOAuth

Przykład w dokumentacji SuiteCRM podaje dla konta wychodzącego serwer smtp-mail.outlook.com, który obsługuje konsumenckie konta Outlook.com. Dla skrzynek w firmowym tenancie Microsoft 365 właściwym adresem jest smtp.office365.com. Foldery monitorowane w koncie IMAP wybieramy dopiero po wypełnieniu pól połączenia OAuth, nazwy użytkownika, serwera, portu i SSL. W innej kolejności lista folderów w oknie wyboru jest pusta.

Dlaczego SuiteCRM nie importuje poczty mimo poprawnej konfiguracji?

SuiteCRM nie importuje poczty mimo poprawnej konfiguracji kont najczęściej dlatego, że nie działa cron lub zadanie harmonogramu „Check Inbound Mailboxes” jest nieaktywne. Import poczty w SuiteCRM 8 nie dzieje się w tle samoczynnie. Uruchamia go harmonogram (Schedulers), wywoływany przez cron systemu operacyjnego co minutę. Działające konto IMAP bez crona pokazuje pocztę w module Email, ale nie tworzy rekordów ani zgłoszeń.

Drugą przyczyną jest typ konta. Import automatyczny do zgłoszeń (Cases) i reguły tworzenia rekordów działają na kontach grupowych. Konto osobiste służy głównie do pracy pojedynczego użytkownika w module Email. Aby skonfigurowane konto było widoczne w module Email, użytkownik musi je dodatkowo zaznaczyć w swoim profilu: Settings → Folder Management. Bez tego kroku poprawnie skonfigurowana skrzynka nie pojawia się na liście.

Co zmieniły SuiteCRM 8.10 i 8.10.2 w module Email?

SuiteCRM 8.10 przebudował edytor wiadomości, a 8.10.2 naprawił błędy importu i ustawień poczty. Edytor w 8.10 działa w trybie pełnoekranowym, pozwala dołączać dokumenty z CRM, wstawiać zmienne i zarządzać szkicami (SuiteCRM Community, 2026). Opcja Email PDF w ofertach, fakturach i umowach otwiera gotową wiadomość z wygenerowanym PDF. Wersja 8.10 przejęła też z SuiteCRM 7.15 zaktualizowany automatyczny import poczty.

SuiteCRM 8.10.2 naprawił trzy grupy błędów modułu Email (SuiteCRM, 2026). Pierwsza dotyczy folderów: niezapisujących się folderów głównych, nietworzących się folderów wysłanych, nazw ze znakami specjalnymi i kolejności podfolderów. Druga to import IMAP z błędną strefą czasową lub z pominiętą datą, przez który część wiadomości nie była importowana. Trzecia to resetowanie danych logowania konta wychodzącego po zmianie niezwiązanego pola w ustawieniach.

Wersja 8.10 wprowadziła też nowy proces roboczy (background worker) dla zadań asynchronicznych, który według informacji o wydaniu wymaga konfiguracji po aktualizacji (SuiteCRM Release Notes 8.10). Aktualizując instancję w celu poprawy obsługi poczty, warto zaplanować konfigurację workera w tym samym oknie serwisowym, zamiast odkrywać jego brak po fakcie przy migracji załączników.

Jakie błędy najczęściej blokują pocztę w SuiteCRM?

Pocztę w SuiteCRM 8 najczęściej blokują błędy konfiguracji po stronie dostawcy poczty i niedziałający harmonogram, a rzadziej sama aplikacja. Poniższa lista porządkuje objawy zgłaszane na forum społeczności SuiteCRM i w dokumentacji, od najczęstszych do rzadszych.

  • Niedziałający cron lub nieaktywne zadanie „Check Inbound Mailboxes”. Konta są skonfigurowane, ale nowe wiadomości nie trafiają do CRM.
  • Niezgodny Redirect URI. Adres w Entra ID lub Google Cloud różni się od adresu instancji (http zamiast https, inna domena, reverse proxy). Po autoryzacji okno kończy się pustą stroną, a tokeny nie zapisują się.
  • Wygasły Client Secret w Entra ID. Połączenia przestają działać jednocześnie, a log SuiteCRM zawiera komunikat „Access token has expired”. Rozwiązanie: nowy sekret w Azure i aktualizacja providera.
  • Zakresy Microsoft Graph zamiast Outlook. Autoryzacja przechodzi, ale IMAP i SMTP zwracają błąd uwierzytelnienia.
  • Wyłączony SMTP AUTH dla skrzynki w Microsoft 365. Wysyłka kończy się błędem 535 5.7.139, mimo poprawnego OAuth.
  • Brak tokenu odświeżającego Google. Połączenie działa około godziny i przestaje.
  • Aplikacja Google w statusie „Testing”. Połączenie wygasa co 7 dni.
  • Połączenie osobiste podpięte do konta grupowego. Błędy importu i wysyłki dla skrzynek współdzielonych.
  • Wersja starsza niż 8.10.2. Gubione wiadomości przy imporcie IMAP i resetujące się hasła konta wychodzącego.

Najczęściej zadawane pytania

Czy SuiteCRM obsługuje OAuth dla Gmaila?

Tak. SuiteCRM 8 obsługuje OAuth dla Gmaila i Google Workspace przez provider typu „Generic”. Wymaga to ręcznego wpisania adresów autoryzacji i tokenu Google oraz zakresu https://mail.google.com/. Dedykowany konektor i instrukcja w dokumentacji istnieją tylko dla Microsoft 365.

Co się stanie z SuiteCRM i Microsoft 365 pod koniec 2026 roku?

Pod koniec grudnia 2026 Microsoft domyślnie wyłączy Basic Auth dla SMTP AUTH w istniejących tenantach. SuiteCRM wysyłający pocztę przez smtp.office365.com z hasłem przestanie wysyłać wiadomości. Rozwiązaniem jest konto wychodzące z uwierzytelnianiem OAuth, dostępne od SuiteCRM 8.8.1.

Od której wersji SuiteCRM obsługuje OAuth dla poczty wychodzącej?

OAuth dla kont wychodzących (SMTP) jest dostępny od SuiteCRM 8.8.1 i 7.14.7. OAuth dla poczty przychodzącej (IMAP) działa od SuiteCRM 8.2. Do konfiguracji poczty rekomendujemy wersję 8.10.2, która naprawia błędy importu IMAP i ustawień kont wychodzących.

Dlaczego SuiteCRM nie pobiera nowych e-maili?

Najczęstsza przyczyna to niedziałający cron lub nieaktywne zadanie „Check Inbound Mailboxes” w harmonogramie. Kolejne to wygasły token OAuth, brak tokenu odświeżającego (Google) oraz błąd strefy czasowej importu IMAP naprawiony w SuiteCRM 8.10.2.

Czy można logować się do SuiteCRM kontem Microsoft lub Google?

Nie przez moduł External OAuth Providers, bo służy on wyłącznie do autoryzacji skrzynek pocztowych. Logowanie do SuiteCRM 8 kontem Microsoft lub Google konfiguruje się osobno, przez SSO oparte na SAML.

Czy hasło aplikacji zastąpi OAuth w SuiteCRM?

Hasło aplikacji działa jako obejście dla pojedynczych kont z weryfikacją dwuetapową, ale nie zastępuje OAuth. Wymaga obsługi przez użytkownika, nie podlega centralnemu zarządzaniu i w Microsoft 365 nadal korzysta z Basic Auth, który jest wycofywany.

Podsumowanie

Przejście poczty w SuiteCRM 8 na OAuth to w praktyce cztery rekordy: provider, połączenie, konto IMAP i konto SMTP, oraz jedna rejestracja aplikacji po stronie Microsoft lub Google. Najwięcej czasu zajmują nie kroki konfiguracji, tylko diagnoza po nich: cron, zakresy uprawnień, token odświeżający i wersja aplikacji. Zanim zaczniesz konfigurację, sprawdź jedno: która skrzynka w waszym SuiteCRM nadal loguje się hasłem i kto dostanie powiadomienie, gdy w styczniu przestanie wysyłać wiadomości?

Jeśli zainteresował Cię ten temat, skontaktuj się z nami. Chętnie odpowiemy na Twoje pytania!

Źródła:

Tagged:

You Might Also Like