Mail roundtrip monitoring
Notice when your mail server stops delivering. Even while it's reachable.
A mail server can be online and still not deliver a single message. Ports 25 and 465 answer, the certificate is valid, every port and SSL check is green. And yet invoices, password links and customer requests arrive nowhere: because DNSSEC validation fails, because the IP is on a blacklist, because the provider blocked port 25 or because the queue is stuck. Usually nobody notices until someone complains that nothing has come through for days. That's why the mail roundtrip doesn't check whether the server answers, but whether a mail actually arrives.
How it works
You enter the credentials of your SMTP server and of a receiving mailbox at an external provider, for example web.de or GMX. On every check, UptimeAlien sends a test mail with a unique token through your server and polls the receiving mailbox via IMAP every 30 seconds until the mail shows up or the timeout runs out. If it lands in the inbox, the monitor is up. If it takes longer than the threshold you set or only lands in the spam folder, it counts as degraded. If it never arrives or your SMTP server rejects it, the monitor is down. The test mail is deleted once found, so the mailbox stays clean.
When to use it
- Your own mail servers running Postfix, Exim or Mailcow
- Transactional mail from shops and web apps sent through your own SMTP server
- Mail servers with DNSSEC, where an expired signature stops delivery
- Catching blacklisting before your customers do
- Relays and smarthosts whose queue can get stuck
- Keeping an eye on deliverability after DNS, SPF or DKIM changes
What you get
Delivery time as a history, the folder the mail arrived in, and a clear message whether sending or receiving failed.
Example
mail.example.com:465 → probe@web.de
Why port and SSL checks can't see this
A TCP check on port 25 tells you the server accepts connections. An SSL check tells you the certificate is valid. Neither says anything about whether the mail your server just accepted reaches the recipient. The typical delivery failures happen after that: the receiving server drops the mail because your domain's DNSSEC chain doesn't validate, because your IP ended up on a blacklist or because SPF and DKIM no longer match. Or your server accepts the mail and never sends it on, because the queue is stuck. Only a real delivery test sees that.
Choosing the receiving mailbox
The receiving mailbox should sit at a different provider than your mail server, otherwise you only test internal delivery. Large freemail providers like web.de or GMX work well: they validate DNSSEC, filter strictly and so behave like your customers' mailboxes. Both require POP3/IMAP access to be enabled in the mailbox settings. Because freemail providers throttle frequent logins, the minimum interval is 15 minutes. One check per hour is recommended.
Spam isn't an outage, but it's a warning
If the test mail only arrives in the spam folder, delivery works technically, but your server's reputation is suffering. UptimeAlien reports this as degraded and names the folder, so you can act before spam turns into rejection. The same goes for slow delivery: if the mail takes longer than your threshold, that is often the first sign of a filling queue or throttling at the recipient.
Frequently asked questions
Which credentials do I need?
For sending, the SMTP credentials of your mail server (port 465 with TLS or 587 with STARTTLS); for receiving, the IMAP credentials of a mailbox at an external provider. The recipient address is the IMAP username.
How are the passwords stored?
Encrypted with AES-256-GCM. They are only decrypted for the delivery test, never displayed and never sent to the browser. When editing, the password fields stay empty; leaving them empty keeps the stored password.
Do the test mails pile up in the mailbox?
No. The test mail is deleted as soon as it's found. If a run is interrupted, a later check cleans up leftover test mails older than 24 hours.
What if the receiving mailbox itself has a problem?
If the IMAP login fails, the monitor reports it explicitly as a problem with the receiving mailbox, not with the mail server being checked. That way you don't look in the wrong place.
Will I get the alert if my mail server goes down?
Not by email if your alert mailbox lives on that very server. Enable another channel for this monitor as well, such as PushPig, Discord or Telegram.
Can I test the settings first?
Yes. "Test now" in the form runs a single roundtrip, and you see live how the mail is sent and after how many seconds it arrives in which folder.