Check whether mail arrives, not only whether a port opens
Your website is online, but an important email never reaches its destination. The mail server may accept connections while authentication, forwarding or mailbox access fails elsewhere in the delivery path. A green website check cannot explain that result.
Mailserver monitoring with MetriBeacon lets you separate connectivity, protocol behaviour and actual receipt. Use SMTP and IMAP service checks to inspect individual services, then add a mail delivery test when you need evidence that a controlled message reaches a mailbox you administer.
This guide explains what each check proves, how to configure a first test and how to investigate a missing or delayed result without confusing it with a confirmed delivery failure.
What do TCP, SMTP, IMAP and delivery checks prove?
Start with the question you need to answer. Opening a network connection, speaking a mail protocol and finding the intended message are different observations.
| Check | What a successful result supports | What it does not establish |
|---|---|---|
| TCP connection | The selected address and port accepted a connection | Authentication or message receipt |
| SMTP service check | The configured SMTP interaction succeeded | Delivery to the recipient mailbox |
| IMAP service check | The configured mailbox-service interaction succeeded | That a newly sent message arrived |
| Mail delivery test | The identified test message was found through configured IMAP access | Delivery to every recipient or every folder |
SMTP acceptance is an intermediate step. For the delivery test, MetriBeacon confirms receipt by finding its identified message in the configured mailbox. It does not treat an SMTP acknowledgement alone as completed delivery.
For related dependencies, use DNS monitoring to inspect an expected mail record and certificate monitoring to understand certificate checks. Those observations complement the mail test; neither replaces receipt evidence.
Choose a test path you can explain
Use dedicated test access and mailboxes you own or administer. Select a sending address, a receiving address and the IMAP folder where the message should appear. Check that those choices represent the path you want to observe.
A test between two mailboxes at the same provider answers a narrower question than a path between providers. Neither arrangement automatically tests every customer's inbox, your application's message-generation code or its password-reset flow. If the application itself must generate a message, that is a separate scenario to design explicitly.
An illustrative setup might submit through your usual authenticated SMTP service and receive in a dedicated IMAP mailbox. It is a planning example, not a preconfigured connection to your provider. Use the server names, ports and TLS modes documented for your own accounts.
Keep credentials in the setup's protected secret fields. Monitor names, descriptions and public incident updates do not need passwords or private mailbox details.
Create SMTP and IMAP service checks first
Follow the network and service check guide. Choose Add monitor → Network & certificates, then a service check and the SMTP or IMAP protocol you need.
Enter the intended host and port. Configure TLS and the supported authentication fields where required. Select offered checking locations, an interval and only the measurements that help you answer your question. Inspect the usage estimate before saving.
Review the first result. Confirm that the selected protocol and target match the service you meant to inspect. A name such as “mail delivery” on an ordinary TCP monitor does not change what that check executes.
Use the network monitoring overview to compare check types. Setup offers supported locations and capabilities; it does not grant arbitrary access to private mail servers. Choose an explicitly supported local setup when the target is private.
Add a mail delivery test in MetriBeacon
When you need actual receipt evidence, select the Mail delivery test option in the service-check setup. Configure the SMTP and IMAP endpoints separately, even if they belong to the same provider.
- Enter the SMTP host, port, TLS mode and protected authentication values.
- Enter the IMAP host, port, TLS mode and protected authentication values.
- Set the sending and receiving addresses and the folder to inspect.
- Confirm that you own or administer both configured mailboxes.
- Set the maximum delivery time and review test-message cleanup options.
- Select a location that offers mail delivery tests, choose the interval and review usage.
- Save, inspect the first completed result and explicitly enable suitable alarms.
Mail delivery tests have their own cadence: the default interval is 30 minutes and the minimum is 15 minutes. The delivery deadline and the interval are different settings. The deadline bounds how long a particular message may take; the interval controls how often a new scheduled attempt begins.
An explicit test sends a real test message, so review and confirm that action when the interface asks. Do not repeatedly start new tests simply because a message is still awaiting receipt. Read the existing attempt's progress first.
Interpret delivery time with its evidence source
MetriBeacon distinguishes a usable mailbox arrival timestamp from the time at which the checker confirms receipt. When the mailbox timestamp is consistent with the attempt, it supplies the delivery-time measurement.
If that timestamp is absent or inconsistent, confirmation time provides an upper bound. For example, a hypothetical message found after 40 seconds may have arrived earlier between observations. That result does not prove an exact 40-second transport delay.
Keep the time source alongside the duration when comparing results. A series of mailbox-timestamp measurements and a confirmation-time upper bound should not be interpreted as equally precise latency samples.
A slow confirmed receipt, a message still being awaited and a result that could not be confirmed require different investigations. Open the result and read its status before drawing a conclusion from the duration alone.
Investigate the failed stage
Begin with the result's phase. If SMTP rejects the sender, recipient or message submission, inspect the relevant account permissions and server policy. If IMAP access fails, inspect the receiving endpoint, authentication, TLS and selected folder.
Missing IMAP access prevents the checker from establishing receipt. It does not by itself establish that the destination lost the message. Similarly, an uncertain SMTP acknowledgement does not prove either acceptance or rejection.
MetriBeacon tracks a distinct attempt and message identity. After an uncertain send outcome, it can continue looking for that message without blindly sending it again. Investigate the current attempt rather than assuming that another send resolves its uncertainty.
When SMTP acceptance is established and an authenticated final mailbox check confirms the message is absent after the deadline, that supports a different conclusion from missing checking evidence. Preserve that distinction in incident notes.
Review cleanup separately from delivery
You can request removal of the received test message. MetriBeacon targets its own identified message and uses precise IMAP cleanup support rather than expunging unrelated mail.
A mailbox may not support the required precise cleanup operation. In that case, confirmed receipt remains meaningful while cleanup is reported separately as unavailable. Do not turn a cleanup limitation into a claim that the message never arrived.
Check the cleanup result and manage retained test messages in the dedicated mailbox if necessary. A controlled test destination makes that routine easier to understand.
Make the alert useful when email is affected
Connect a confirmed notification destination and test it with the alarm setup guide. The email and Telegram article explains those notification paths.
Consider a separate destination such as Telegram if your usual alert email depends on the mail service being monitored. A delivery incident and the delivery of its alert are separate facts: a missing alert email does not prove the monitor failed to detect a problem.
Review the incident and delivery history, restore the intended configuration and confirm a fresh successful test before closing the investigation. Publish reviewed service information through a status page when visitors need an explanation.
Frequently asked questions about mailserver monitoring
Does an open SMTP port prove that email works?
No. It establishes a connection to the configured endpoint. Use the appropriate protocol check and an actual receipt test for the additional outcomes you need.
Does the mail delivery test check every recipient's inbox?
No. It tests the configured sending path and receiving mailbox. It does not certify worldwide deliverability or every spam filter's decision.
Is cleanup failure the same as delivery failure?
No. Receipt and cleanup are separate results. A test message can arrive successfully while precise automatic removal is unavailable.
Is mailserver monitoring free with MetriBeacon?
MetriBeacon is free within its documented technical quotas. Review the usage overview, selected measurements and mail-specific interval when planning checks.
Start with one important mail path
Create a free MetriBeacon account, inspect your SMTP and IMAP services and add one controlled delivery test where receipt matters. Review the first result and test an actionable alert. The Website/API template below starts a complementary HTTP monitor; create mail checks through the separate Network & certificates setup.
