SMTP monitoring: dostupnost mail serveru, banner a handshake
SMTP monitoring pomáhá ověřit, že je mail server dosažitelný a že opravdu mluví protokolem, který očekávají klienti i další mail servery. Pokud je pro váš produkt důležitý e-mail, nestačí, že je otevřený TCP port 25 nebo 587. Potřebujete vědět i to, že mail služba odpovídá správně a je připravená pokračovat v SMTP komunikaci.
Co SMTP monitoring skutečně ověřuje
SMTP monitoring kontroluje, že mail server přijme spojení a odpoví jako skutečná SMTP služba. Typicky to znamená potvrdit úvodní 220 banner a to, že server umí pokračovat v handshake, když klient pošle příkaz jako EHLO.
To je důležité proto, že otevřený TCP port ještě neznamená zdravý mail systém. Služba může být špatně nastavená, přetížená, filtrovaná nebo selhávat až na protokolové vrstvě, i když port spojení přijme.
Kdy týmy SMTP monitorují
E-mail je business-critical
Reset hesla, alerty, faktury, onboarding e-maily i transakční zprávy závisejí na tom, že SMTP někde v řetězci správně funguje.
Mail server musí dělat víc než jen poslouchat
Chcete mít jistotu, že SMTP proces odpovídá správně, ne jen že je port technicky dosažitelný.
Potřebujete včas vidět tiché problémy v mailu
Mail outage se často přehlédne až do chvíle, kdy přijdou support tickety, zvlášť pokud se fronty jen hromadí nebo selhává jen část serverů.
Provozujete vlastní nebo hybridní mail infrastrukturu
Custom SMTP setupy, relaye a kombinace cloud/on-prem mail cest profitují z aktivních checků, které ověřují, že služba na daném endpointu opravdu mluví SMTP.
Jak funguje základní SMTP handshake
Klient se připojí na SMTP port
Typicky jde o TCP 25 pro komunikaci mezi servery nebo TCP 587 pro autentizované odesílání z klientů.
Server vrátí 220 banner
Zdravý SMTP server obvykle začne tím, že po navázání spojení pošle 220 odpověď a identifikuje se jako připravený pokračovat.
Klient pošle EHLO nebo HELO
Tím začne SMTP session a server může vrátit své schopnosti a pokračovat v konverzaci.
Protokolový check dokazuje víc než jen otevřený port
Pokud server nevrátí očekávaný banner nebo neumí správně pokračovat, může být služba nezdravá, i když je samotný TCP port otevřený.
Jak číst běžné SMTP signály
SMTP troubleshooting se často točí kolem odpovědí jako:
220 mail.example.com ESMTP ready 250 OK 250-STARTTLS 421 Service not available 450 Requested action not taken 550 Requested action not taken: mailbox unavailable
220 banner
To je klasický signál, že je SMTP server po navázání TCP spojení připraven začít session.
250 odpovědi
Tyto kódy obvykle znamenají, že předchozí příkaz byl akceptován a komunikace může pokračovat.
4xx dočasné chyby
Často ukazují na dočasný problém, například přetížení, throttling nebo nedostupnou závislost.
5xx trvalé chyby
Ty obvykle znamenají tvrdší selhání nebo policy rejection, ne jen dočasnou situaci k opakování.
Proč SMTP potřebuje víc než port check
Mail server může mít otevřený TCP 25 a přitom vůbec nevracet správný SMTP banner nebo nedokázat správně pokračovat v protokolu. To je reálné riziko pro doručování, i když by obyčejný port check vypadal zdravě.
Protokolově orientovaný SMTP monitoring dává silnější signál, protože potvrzuje, že se endpoint chová jako SMTP služba, ne jen že na portu něco poslouchá.
SMTP monitoring vs TCP port monitoring
| Téma | SMTP check | TCP port check |
|---|---|---|
| Hlavní otázka | Odpovídá mail služba jako SMTP a pokračuje správně v handshake? | Je port dosažitelný a přijímá TCP spojení? |
| Nejlepší použití | Chování mail serveru, validace banneru a zdraví e-mailové služby na aplikační vrstvě. | Základní dostupnost listeneru na portu 25, 465 nebo 587. |
| Co může minout | Sám o sobě ještě nepotvrzuje plné end-to-end doručení do schránky. | Nepotvrzuje, že služba po connectu skutečně mluví SMTP správně. |
Potřebujete i transportní základ, na kterém SMTP stojí?
SMTP stojí na TCP port connectivity, takže monitoring TCP portů je pořád důležitý jako základní vrstva pod samotným mail checkem.
Přečíst článek o TCP a UDP →Jak interpretovat typické situace
TCP 25 je otevřený, ale 220 banner nepřijde
Na portu něco poslouchá, ale SMTP služba může být zaseknutá, špatně nakonfigurovaná, filtrovaná nebo se nechová jako zdravý mail server.
Banner přijde, ale další příkazy selžou
Listener žije, ale aplikace může mít problém v protokolu, autentizaci, policy nebo v backendu hlubší vrstvy.
Zpoždění mailu se objevuje jen občas
Dočasné 4xx chování může ukazovat na throttling, tlak ve frontách, problémy v závislostech nebo přetíženou infrastrukturu.
Submission port funguje, ale incoming relay ne
TCP 587 a TCP 25 mají odlišnou roli, takže je důležité monitorovat správný SMTP endpoint podle konkrétní delivery cesty.
Důležitá omezení
- ● SMTP monitoring automaticky nepotvrzuje plné doručení do každé cílové schránky ani akceptaci všemi externími providery.
- ● Zdravý SMTP handshake neznamená, že jsou zdravé downstream mail queue, relaye nebo recipient policy.
- ● Různé porty jako 25, 465 a 587 mají odlišné použití a často vyžadují samostatné checky.
- ● Mail infrastruktura má obvykle více vrstev, takže jeden zdravý endpoint neznamená, že je zdravý celý delivery flow.
Jak lidé SMTP ručně testují
telnet mail.example.com 25 Hodí se pro rychlou kontrolu, jestli server po připojení vrací očekávaný 220 SMTP banner.
nc -vz mail.example.com 25 Rychlý test základní TCP dostupnosti před hlubší SMTP kontrolou.
openssl s_client -starttls smtp -connect mail.example.com:587 Užitečné, když potřebujete zkontrolovat SMTP přes TLS na submission endpointu.
Časté dotazy
Otevřený mail port není totéž co zdravá mail služba.
nsmon vám pomůže monitorovat SMTP endpointy, takže uvidíte, kdy mail server přestane správně odpovídat dřív, než začnou v produkci selhávat resety hesel, alerty nebo transakční e-maily. Vytvořte si účet zdarma a začněte monitorovat SMTP služby, na kterých váš byznys závisí.