SMTP
Mail server monitoring
The handshake, not just the port.
Try it now
One check, from one place, right now, and nothing is saved. A monitor checks from every location we run and confirms a failure from a second continent before anybody is woken, which a single look cannot show you.
What it is for
A mail server that stops accepting mail is expensive and quiet. Nobody phones to say your MX is refusing them; the mail simply queues on somebody else's machine for five days and then bounces, and by then the invoice, the password reset and the order confirmation are all gone.
This connects, completes the SMTP handshake and checks STARTTLS. A port check would pass against a server that accepts the connection and then says nothing, which is exactly what a half-dead mail server looks like from outside.
Like every check here, it runs from Amsterdam, New York and Sydney, and a failure is confirmed from a second continent before anybody is woken. How that works.
What you can set
Everything below is on the form when you add one, on every plan.
- STARTTLS
- Required, optional, or not used. Required is right for a server that takes mail from the internet. An internal relay that has never offered it is not broken, and saying so stops us reporting it down for ever.
- Expected greeting
- A regular expression the banner has to match. Without it this is a port check with a handshake on top.
Questions
Which ports does this work on?
Port 25 by default, which is the one other mail servers use to deliver to you, and any port you name after a colon. Port 587 is submission and is checked the same way, with STARTTLS. Port 465 is SMTPS, which wraps the connection in TLS from the first byte rather than upgrading partway through, so it gets the other path: the session is encrypted before the greeting arrives and there is no STARTTLS left to insist on.
Do you check my MX record as well?
Not from here. This connects to the host you name and talks to it, which is a different question from whether the world is still being told to send mail there. A DNS monitor on the MX record, with the answer you expect filled in, catches the record being changed. Anybody serious about mail runs both.
What does connection refused mean here?
Something answered and said no: nothing is listening on that port. A dead server, a firewall rule, or a hosting provider blocking outbound port 25, which many do. It is reported apart from a handshake that starts and then goes wrong, because those are different faults with different fixes.
Can you see my mail queue?
No, and we say so rather than implying otherwise. A queue lives inside your server and nothing outside it can count the messages waiting. What is visible from outside is the server that stopped accepting mail, which is the thing that fills everybody else's queue with your mail, and that is what this catches.
Do you verify the certificate when STARTTLS is used?
We check that STARTTLS is advertised and that the upgrade completes, and we stop there. Mail between servers is opportunistic by design and a great many working relays present a certificate no trust store would accept, so failing them would be reporting an outage that is not one. Watch expiry with a certificate monitor on the same host and port.
What is the difference between required, optional and not used?
Required means STARTTLS must be advertised and must succeed, which is right for a server taking mail from the internet. Optional means it is checked when offered and not held against a server that does not offer it. Not used skips it, for an internal relay that has never had TLS and is not broken for lacking it.