Sprawdziłeś rekordy SPF i DKIM, potwierdziłeś, że domena nadawcza wygląda na czystą, i uruchomiłeś kampanię. Następnie aplikacja zwraca błąd uwierzytelniania, zanim pierwsza wiadomość opuści Twój system. Konfiguracja DNS niekoniecznie była błędna. Twoja aplikacja wysyłająca mogła nie przejść logowania klienta wymaganego przez wychodzący serwer SMTP.
To rozróżnienie odpowiada na praktyczne pytanie: czym jest uwierzytelnianie SMTP. SMTP AUTH potwierdza, że klient, aplikacja lub użytkownik ma uprawnienia do przesyłania poczty przez serwer. SPF, DKIM i DMARC dotyczą innego problemu z tożsamością — tego, czy dostawca odbierający powinien ufać domenie powiązanej z wiadomością. Niezawodna dostarczalność zależy od obu tych warstw, a także od starannej higieny listy przed wysyłką.
Ukryty strażnik dostarczalności wiadomości e-mail
Zespół marketingowy może spędzić wiele dni na analizowaniu reputacji nadawcy, zgodności domeny i treści wiadomości, by dopiero wtedy odkryć, że jego CRM nie może uwierzytelnić się na wychodzącym serwerze pocztowym. Kampania nigdy nie dociera do infrastruktury odbiorcy, ponieważ serwer przesyłania najpierw odrzuca połączenie.
Na tym polega rola uwierzytelniania SMTP. To strażnik między aplikacją a serwerem pocztowym, który akceptuje wiadomości wychodzące. Klient identyfikuje mechanizm uwierzytelniania, przeprowadza wymianę z serwerem i otrzymuje zgodę na przesyłanie poczty. Bez tej zgody poprawnie napisana wiadomość i prawidłowo opublikowane rekordy domeny nie mają jeszcze znaczenia.
Dwa sprawdzenia tożsamości, nie jedno
Dostarczanie wiadomości e-mail wiąże się z dwoma odrębnymi pytaniami:
- Czy ten klient może przesyłać pocztę przez ten serwer?
- Czy odbiorca powinien ufać tożsamości nadawcy reprezentowanej przez tę wiadomość?
SMTP AUTH odpowiada na pierwsze pytanie. SPF, DKIM i DMARC odpowiadają na drugie. CRM może mieć prawidłowe dane uwierzytelniające, ale wysyłać z domeny, której brakuje zgodnych rekordów uwierzytelniania. Z drugiej strony domena może publikować silne rekordy, podczas gdy aplikacja używa wygasłego hasła, wyłączonej metody lub serwera, który odmawia przekazywania poczty dla tego konta.
Zasada operacyjna: Debuguj ścieżkę wysyłania po kolei. Najpierw sprawdź, czy klient może ustanowić bezpieczną, uwierzytelnioną sesję przesyłania. Następnie zweryfikuj uwierzytelnianie na poziomie domeny i zasady po stronie odbiorcy.
Standard stojący za SMTP AUTH to RFC 4954, który sformalizował uwierzytelnianie SMTP jako rozszerzenie usługi oparte na SASL. Pozwala on serwerowi ogłaszać obsługiwane mechanizmy, a klientowi wybrać jeden z nich bez zmiany podstawowych poleceń SMTP służących do przesyłania wiadomości. Ta konstrukcja nadal stanowi podstawę uwierzytelnionego przesyłania poczty w firmowych systemach pocztowych i na platformach wysyłkowych.
Dlaczego marketerzy napotykają ten problem
Błąd często pojawia się po zmianie infrastruktury, a nie po zmianie treści lub grupy docelowej. Dostawca może wyłączyć starszą metodę uwierzytelniania. Administrator może wyłączyć SMTP AUTH dla danego konta. Polityka bezpieczeństwa może wymagać szyfrowanego przesyłania. Zapora sieciowa może zezwalać na ruch między serwerami, jednocześnie blokując port używany przez aplikację marketingową.
Dlatego stwierdzenie „hasło jest poprawne” nie wystarcza do postawienia diagnozy. Serwer może odrzucać metodę uwierzytelniania, zabezpieczenia połączenia, uprawnienia konta do przekazywania poczty lub konfigurację klienta wysyłającego. Traktuj SMTP AUTH jako mechanizm kontroli na poziomie protokołu, a nie pole formularza.
Zrozumienie uzgadniania SMTP AUTH
SMTP AUTH to negocjowana wymiana. Klient nie wysyła nazwy użytkownika, licząc, że serwer ją zaakceptuje. Serwer najpierw określa, co obsługuje, a następnie klient wybiera zgodny mechanizm i rozpoczyna sekwencję uwierzytelniania.
Sekwencja protokołu
Wymiana zazwyczaj przebiega w następującej kolejności:
- Klient otwiera połączenie. W przypadku uwierzytelnionego przesyłania aplikacja zwykle łączy się za pośrednictwem wyznaczonej usługi przesyłania i uzgadnia bezpieczeństwo transportu, zanim dane uwierzytelniające zostaną ujawnione.
- Klient wysyła EHLO. To rozszerzone powitanie informuje serwer, które funkcje SMTP klient rozumie.
- Serwer ogłasza możliwości. Odpowiedź może zawierać wiersz
250-AUTHz listą obsługiwanych mechanizmów SASL. Klient musi wybrać jeden z mechanizmów oferowanych przez serwer. - Klient wysyła AUTH. Polecenie przyjmuje wybrany mechanizm jako pierwszy parametr, zgodnie ze specyfikacją polecenia AUTH w RFC 4954.
- Strony kończą wymianę. W zależności od mechanizmu serwer może wysyłać wyzwania, a klient odpowiada wymaganymi danymi uwierzytelniającymi. Kodowanie Base64 może reprezentować dane uwierzytelniające podczas wymiany, ale kodowanie nie jest szyfrowaniem. TLS musi chronić sesję.
- Serwer akceptuje lub odrzuca sesję. Pomyślne uwierzytelnienie zwykle zwraca
235. Nieudana próba zwykle zwraca535, choć szczegóły diagnostyczne różnią się w zależności od dostawcy.
Najważniejsze jest to, że SMTP AUTH odbywa się przed przesłaniem przez klienta koperty i treści wiadomości. Po uwierzytelnieniu aplikacja może przejść do poleceń takich jak MAIL FROM, RCPT TO i DATA, z zastrzeżeniem kontroli przekazywania i zasad serwera.
Co mówią odpowiedzi
Brak możliwości AUTH może oznaczać, że klient połączył się z niewłaściwą usługą, użył nieobsługiwanego portu lub skontaktował się z serwerem, który nie oferuje uwierzytelnionego przesyłania. Odpowiedź 535 może oznaczać nieprawidłowe dane uwierzytelniające, zablokowane konto, wyłączoną metodę uwierzytelniania lub odrzucenie przez dostawcę starszego sposobu logowania.
Dzienniki aplikacji powinny rejestrować kody odpowiedzi serwera i uzgodniony stan bezpieczeństwa, unikając jednocześnie zapisywania haseł i tokenów. Podczas analizowania wiadomości, która została zaakceptowana, ale później odfiltrowana, zespoły mogą również bezpłatnie analizować nagłówki wiadomości e-mail, aby sprawdzić wyniki uwierzytelniania zapisane przez systemy odbierające.
SMTP AUTH nie zastępuje również zabezpieczeń konta. Jeśli skrzynka pocztowa lub konto usługi korzysta z uwierzytelniania wieloskładnikowego, należy sprawdzić obsługiwany przez dostawcę proces zamiast zakładać, że zwykłe hasło zadziała. Przewodnik Finchum Fixes IT dotyczący 2FA zawiera przydatne informacje o tym, dlaczego drugi składnik zmienia model logowania.
W przypadku zespołów oczyszczających dane odbiorców zasilające te systemy, BillionVerify to profesjonalna usługa weryfikacji adresów e-mail, stworzona, aby rozwiązać jeden problem: nieprawidłowe dane e-mail kosztują firmy pieniądze. Dotyczy to jakości listy adresowej, a nie samego logowania SMTP.
Uwierzytelnianie SMTP a uwierzytelnianie nadawcy
Najlepszym porównaniem jest identyfikator pracownika zestawiony z firmowym papierem firmowym.
SMTP AUTH to identyfikator. Informuje serwer poczty wychodzącej, że ten klient lub konto ma uprawnienia do przesłania wiadomości. SPF, DKIM i DMARC to papier firmowy oraz znaki weryfikacyjne. Pomagają dostawcy odbierającemu ocenić, czy wiadomość reprezentuje domenę wyświetlaną odbiorcy.
Pomyślna weryfikacja identyfikatora nie sprawia, że podejrzany papier firmowy staje się wiarygodny. Podobnie prawidłowo skonfigurowane rekordy domeny nie upoważniają aplikacji do wstrzykiwania wiadomości do kolejki serwera.
| Funkcja | Przesyłanie przez klienta (SMTP AUTH) | Weryfikacja domeny (SPF/DKIM/DMARC) |
|---|---|---|
| Główne pytanie | Czy ten klient może przesyłać pocztę? | Czy odbiorca powinien ufać tej tożsamości domeny? |
| Gdzie działa | Między klientem wysyłającym a serwerem wychodzącym | Między wiadomością, rekordami DNS a dostawcą odbierającym |
| Główne komponenty | EHLO, reklamowane mechanizmy AUTH, wymiana SASL, uprawnienia do przekazywania | Autoryzacja SPF, walidacja podpisu DKIM, zgodność i polityka DMARC |
| Typowa awaria | Odrzucenie uwierzytelnienia, wyłączone konto, nieobsługiwana metoda | Nieudane wykrywanie podszywania się, brak zgodności, filtrowanie oparte na polityce |
| Skutek powodzenia | Serwer może zaakceptować wiadomość do dalszego dostarczenia | Odbiorca może wykorzystać sygnały tożsamości domeny przy podejmowaniu decyzji o filtrowaniu |
Co potwierdza każda warstwa
SPF autoryzuje wyznaczone adresy IP nadawców dla domeny. DKIM dołącza podpis kryptograficzny, który pozwala systemowi odbierającemu sprawdzić, czy podpisana treść wiadomości i podpis domeny są prawidłowe. DMARC łączy te wyniki z widoczną domeną From i określa sposób obsługi wiadomości, które nie przechodzą kontroli zgodności. Różnice zostały jasno podsumowane w tym porównaniu SPF, DKIM i DMARC.
SMTP AUTH nie publikuje żadnych z tych instrukcji dotyczących domeny. Nie gwarantuje również, że odbiorca umieści wiadomość w skrzynce odbiorczej. Jedynie potwierdza, że usługa wysyłająca zaakceptowała klienta jako uprawnionego nadawcę.
Publikacja to nie egzekwowanie
Różnica między posiadaniem rekordów a egzekwowaniem polityki ma znaczenie operacyjne. Pomiar z 2026 roku obejmujący 5,5 miliona domen wykazał, że SPF opublikowano dla 56,0%, DMARC dla 30,4%, a DKIM dla 22,7% domen, zgodnie z badaniem uwierzytelniania poczty firmy DMARC Guard. W osobnym badaniu obejmującym 10 000 największych domen publikacja SPF osiągnęła 84,5%, publikacja DMARC 76,6%, a egzekwowanie DMARC za pomocą polityk kwarantanny lub odrzucania 54,0%, według tego samego źródła.
Wniosek praktyczny jest prosty. Domena może wyglądać na skonfigurowaną, a mimo to nadal działać wyłącznie w trybie monitorowania. Użyj narzędzia do sprawdzania DMARC, aby skontrolować politykę i zgodność, ale dane uwierzytelniające SMTP analizuj osobno. Żadne z tych narzędzi nie zastępuje drugiego.
Porty i protokoły bezpiecznego przesyłania
Dane uwierzytelniające nigdy nie powinny być przesyłane przez niezabezpieczoną sesję przesyłania po stronie klienta. Dlatego SMTP AUTH należy łączyć z szyfrowaniem transmisji i portem przeznaczonym do przesyłania wiadomości, a nie z nieograniczoną ścieżką przekazywania.
Zdefiniowany w standardach port przesyłania to 587, zwykle używany z STARTTLS, jak opisano w tym przeglądzie portów uwierzytelniania SMTP. Klient ustanawia sesję SMTP, odbiera informacje o możliwościach serwera, żąda przejścia na TLS, a następnie przeprowadza uwierzytelnianie w ramach chronionego połączenia.
Wybór właściwego punktu końcowego
Port 25 jest przede wszystkim kojarzony z przekazywaniem wiadomości między serwerami. Nie jest standardowym wyborem dla aplikacji, CRM ani platformy marketingowej wysyłającej pocztę przy użyciu danych uwierzytelniających użytkownika. Wiele sieci go ogranicza, ponieważ nadużycia związane z otwartym przekazywaniem oraz przejęte hosty sprawiły, że nieograniczony wychodzący SMTP stał się problemem bezpieczeństwa.
Port 465 używa niejawnego TLS, co oznacza, że połączenie jest szyfrowane od samego początku. Niektórzy dostawcy i aplikacje nadal go wymagają, ale konfiguracja musi odpowiadać oczekiwaniom serwera. Klient, który zakłada użycie STARTTLS na punkcie końcowym z niejawnym TLS albo zakłada niejawny TLS tam, gdzie serwer oczekuje powitania w postaci zwykłego tekstu, a następnie przejścia na szyfrowanie, zakończy działanie przed uwierzytelnianiem.
| Typ połączenia | Typowa rola | Oczekiwania dotyczące bezpieczeństwa |
|---|---|---|
| Port 25 | Przekazywanie między serwerami | Nie jest standardową ścieżką uwierzytelnionego przesyłania przez klienta |
| Port 587 | Przesyłanie wiadomości | STARTTLS jest zwykle negocjowany przed SMTP AUTH |
| Port 465 | Przesyłanie, gdy jest wymagane | Niejawny TLS rozpoczyna się w momencie nawiązywania połączenia |
Kontrole konfiguracji zapobiegające ujawnieniu danych
Przed przetestowaniem danych uwierzytelniających potwierdź, że punkt końcowy aplikacji, port, tryb szyfrowania i mechanizm uwierzytelniania są zgodne z dokumentacją dostawcy. Port może być dostępny, a negocjacja TLS nadal może się nie powieść. Podobnie serwer może reklamować AUTH, jednocześnie odrzucając konto, ponieważ uprawnienia do przekazywania lub zasady dzierżawy uniemożliwiają przesyłanie.
Narzędzie do weryfikacji rekordów MX pomaga zidentyfikować serwery pocztowe odpowiedzialne za odbieranie poczty dla domeny, ale dane MX nie zastępują punktu końcowego przesyłania dostarczonego przez dostawcę poczty wychodzącej. Infrastruktura odbierająca pocztę i uwierzytelniona infrastruktura wysyłająca mogą być oddzielnymi usługami.
Granica bezpieczeństwa: Nie „naprawiaj” błędu uwierzytelniania przez wyłączenie TLS. Może to ujawnić dane uwierzytelniające i treść wiadomości, pozostawiając nierozwiązany podstawowy problem zgodności lub zasad.
W systemach o dużej przepustowości API może być operacyjnie prostsze niż utrzymywanie rozbudowanej sesji SMTP, ale SMTP pozostaje użyteczny, gdy aplikacja już go obsługuje, a dostawca udostępnia stabilną usługę przesyłania. Wybór powinien wynikać z potrzeb integracji, obserwowalności i mechanizmów bezpieczeństwa, a nie z przyzwyczajenia.
Wpływ wycofania starszych metod uwierzytelniania
Proces wysyłania może przestać uwierzytelniać wiadomości, nawet jeśli jego hasło się nie zmieniło. Dostawcy zastępują Basic Authentication, które przesyła bezpośrednio nazwę użytkownika i hasło, OAuth oraz innymi przepływami autoryzacji, pozwalającymi administratorom kontrolować tokeny, zakresy uprawnień, zgody i unieważnianie dostępu.
Ogłoszony plan firmy Microsoft zakłada, że działanie Basic Authentication pozostanie bez zmian do grudnia 2026 roku. Później ma ona zostać domyślnie wyłączona dla istniejących dzierżaw, natomiast nowe dzierżawy utworzone po tym terminie mają korzystać z OAuth jako obsługiwanej metody. Microsoft planuje ogłosić ostateczną datę całkowitego usunięcia tej funkcji w drugiej połowie 2027 roku. Te przewidywane terminy przedstawiono na stronie harmonogramu wycofywania SMTP AUTH w Microsoft Exchange Online.
Dlaczego prawidłowe hasła nadal zawodzą
Dostawca może odrzucić metodę uwierzytelniania, zanim sprawdzi hasło. Administrator dzierżawy mógł również wyłączyć SMTP AUTH dla skrzynki pocztowej, a aplikacja może obsługiwać wyłącznie LOGIN lub PLAIN, podczas gdy usługa wymaga przepływu opartego na tokenie. Pomyślny test logowania z jednej skrzynki nie potwierdza więc, że każda integracja wysyłająca będzie nadal działać.
Wcześniejsza komunikacja firmy Microsoft opisywała etapowe odrzucenia rozpoczynające się 1 marca 2026 roku, z całkowitym wyłączeniem do 30 kwietnia 2026 roku dla objętej zmianami ścieżki Basic Authentication, jak opisano w tym przewodniku migracji SMTP AUTH. Harmonogramy dostawców i zasady dzierżaw mogą się zmieniać, dlatego należy sprawdzić aktualny status każdego środowiska, zamiast traktować starą datę wdrożenia jako gwarancję.
Praktyczny plan migracji
Sporządź wykaz każdego systemu, który wysyła pocztę za pośrednictwem dzierżawy, w tym przepływów CRM, aplikacji rozliczeniowych, narzędzi monitorujących, formularzy i skryptów. Dla każdego z nich zapisz konto, punkt końcowy, port, tryb szyfrowania, mechanizm uwierzytelniania i właściciela. Oddziel integracje obsługujące OAuth od tych, które wymagają zastąpienia lub zatwierdzonego użycia hasła aplikacji.
Przetestuj nowy przepływ w kontrolowanym środowisku przed zmianą sekwencji produkcyjnych. Sprawdź wygasanie tokenów, wymagania dotyczące zgody, obsługę błędów i odwoływanie dostępu. Potwierdź również, że przepływ nadal prawidłowo obsługuje odpowiedzi dostawcy po pomyślnym uwierzytelnieniu. Łącznik bez obsługi OAuth może zawieść podczas kampanii, mimo że zapisane hasło pozostaje prawidłowe.
Weryfikacja dostarczalności poza logowaniem
Uwierzytelnienie na serwerze wysyłającym potwierdza uprawnienia do przesyłania wiadomości. Nie dowodzi jednak, że skrzynka odbiorcy istnieje, że domena odbiorcy akceptuje pocztę na ten adres ani że wiadomość uniknie filtrowania.
Proces weryfikacji przed wysyłką rozpoczyna się od wyszukiwania MX. Rekordy MX identyfikują serwery pocztowe odpowiedzialne za odbieranie poczty dla domeny, a domena bez rekordów MX nie może odbierać poczty, jak wyjaśniono w tym omówieniu jak działa weryfikacja adresów e-mail. Następnie usługa weryfikacyjna może sprawdzić serwer odbiorcy za pomocą rozmowy SMTP, aby ocenić, czy adres wydaje się dostarczalny.
Co dokładnie sprawdza proces weryfikacji
Usługa nie musi wysyłać wiadomości kampanii, aby uzyskać przydatne informacje. Może zidentyfikować host MX domeny odbiorcy, otworzyć sesję SMTP i zapytać, czy serwer zaakceptuje wskazanego odbiorcę. Pozytywna odpowiedź nadal może być niejednoznaczna, ponieważ niektóre serwery akceptują pocztę dla każdego adresu w domenie.
W tym miejscu istotne jest wykrywanie obsługi wszystkich adresów. Weryfikator wysyła drugi, testowy adres do tego samego hosta MX. Jeśli serwer zaakceptuje również losowy adres, domena zostaje sklasyfikowana jako obsługująca wszystkie adresy, zamiast traktować to jako dowód istnienia pierwotnej skrzynki, jak opisano w tym procesie wykrywania obsługi wszystkich adresów.
Przydatne rozróżnienie: „Zaakceptowany przez serwer” i „potwierdzony jako konkretna skrzynka” nie zawsze oznaczają ten sam wynik.
Dlatego weryfikacja najlepiej sprawdza się jako system klasyfikacji ryzyka, a nie uproszczony przełącznik poprawny lub niepoprawny. Działania marketingowe mogą oddzielić prawdopodobnie dostarczalne adresy od nieznanych, obsługujących wszystkie adresy, jednorazowych, funkcyjnych lub w inny sposób ryzykownych rekordów, zanim kampania wygeneruje twarde odbicia.
Narzędzie BillionVerify do sprawdzania dostarczalności może być częścią takiego przeglądu przed wysyłką jako jedno z narzędzi ocenianych przez zespół do kontroli adresów i ścieżki wysyłki. Cel operacyjny jest szerszy niż pomyślne logowanie: ograniczyć liczbę nieprawidłowych odbiorców, chronić reputację nadawcy i zapewnić kampanii lepiej oczyszczoną grupę odbiorców.
Budowanie odpornej infrastruktury wysyłkowej
Odpornego systemu wysyłkowego nie należy opierać na uwierzytelnianiu jako pojedynczym polu wyboru, lecz jako wielowarstwowym mechanizmie kontroli. Klient musi bezpiecznie uwierzytelnić się w usłudze wychodzącej. Widoczna domena nadawcy musi przejść zgodne kontrole tożsamości. Dane odbiorców muszą być na tyle aktualne, aby kampania nie generowała możliwych do uniknięcia odbić.
Zacznij od audytu infrastruktury
Zmapuj całą trasę — od aplikacji do odbiorcy. Dla każdego procesu wysyłkowego udokumentuj dostawcę obsługi wysyłki, metodę uwierzytelniania, wymagania dotyczące szyfrowania, właściciela konta oraz zachowanie awaryjne. Taki spis często ujawnia porzucone integracje, które nadal opierają się na hasłach lub starych ustawieniach SMTP.
Następnie celowo przetestuj scenariusze awarii:
- Awaria wysyłki: Potwierdź, że klient łączy się z właściwym punktem końcowym, negocjuje TLS, widzi oczekiwaną możliwość AUTH i otrzymuje pomyślną odpowiedź uwierzytelniającą.
- Awaria domeny: Sprawdź autoryzację SPF, podpisywanie DKIM oraz zgodność DMARC dla domeny wyświetlanej w adresie From.
- Awaria danych: Zweryfikuj nowe i importowane adresy, zanim trafią do kampanii lub sekwencji sprzedażowej.
- Awaria reputacji: Monitoruj odbicia, skargi, sygnały z list blokad oraz nagłe zmiany w zachowaniu związanym z akceptacją, korzystając z narzędzia do sprawdzania reputacji IP.
Standard RFC 4954 zapewnia podstawę protokołu, ale sama zgodność ze standardami nie gwarantuje odporności operacyjnej. Dostawcy mogą nakładać zasady dotyczące dzierżawców, wyłączać mechanizmy lub zmieniać wymagania uwierzytelniania.
Uczyń higienę częścią procesu
Nie czekaj, aż lista będzie duża lub kampania zostanie zaplanowana. Dodaj weryfikację podczas rejestracji, importu, synchronizacji z CRM oraz przed dużymi wysyłkami. Kontrola w czasie rzeczywistym może zatrzymać oczywiście ryzykowny adres przed jego dodaniem do bazy danych, natomiast przegląd zbiorczy może wskazać nieaktualne rekordy zgromadzone przez zespoły sprzedaży i marketingu.
Najlepszy proces zachowuje również wynik i jego przyczynę. „Nieznany, ponieważ catch-all” wymaga innego postępowania niż „skrzynka odrzuciła wiadomość” lub „domena nie ma serwera odbierającego”. Segmentacja pozwala zespołowi zdecydować, czy adres wyciszyć, sprawdzić lub ostrożnie przetestować, zamiast traktować każdy niepewny rekord jako bezpieczny.
Wielowarstwowy program wymaga również jasno określonej odpowiedzialności. Zespoły infrastruktury powinny zarządzać migracjami OAuth i zasadami TLS. Działy operacji marketingowych powinny utrzymywać zgodność domeny wysyłkowej oraz reguły wyciszania. Zespoły danych powinny definiować sposób obsługi statusów weryfikacji. Bez jasno określonej odpowiedzialności każda grupa zakłada, że inny zespół chroni ścieżkę wysyłki.
Ten film oferuje wizualne wyjaśnienie dotyczące koncepcji infrastruktury:
Najważniejsza lekcja jest praktyczna: SMTP AUTH umieszcza wiadomość w kolejce wychodzącej, natomiast uwierzytelnianie domeny i weryfikacja odbiorcy decydują, czy szerszy system dostarczania ma powody, by jej zaufać. Zachowaj te mechanizmy oddzielnie w monitoringu, ale połącz je w procesie operacyjnym.
BillionVerify zapewnia weryfikację adresów e-mail, aby sprawdzać dane odbiorców, zanim trafią do kampanii, procesów i sekwencji wychodzących. Użyj go, aby połączyć weryfikację na poziomie SMTP, sygnały MX i catch-all oraz przegląd dostarczalności w procesie poprzedzającym wysyłkę, a następnie odwiedź stronę BillionVerify, aby ocenić ten proces pod kątem potrzeb swojego zespołu.