In our previous post, we discussed the email round-trip monitoring level as the best solution for preventing email outages. Today we will dig a little deeper and see the possible scenarios which the email round-trip test can follow. Let me clarify what the email round-trip test actually does.

First, our monitoring agent connects to the SMTP server that you have specified or retrieved automatically through the MX records and sends a test message. By doing this, our system verifies that your SMTP server is working properly. Next, the agent will try to log into the POP3/IMAP server and retrieve the message. If the message is received, the test will be considered successful, and the message will be deleted. If, on the other hand, the message is not found in the mailbox after a certain period, which is configurable and usually between 5 and 15 minutes, the check will be considered a failure, and you will be alerted.

Depending on your system and your goals, there can be different scenarios.

Default configuration

In this case, the goal of the monitoring is clear. You want to keep an eye on the usual mail receiving procedure. For this purpose, the monitoring agent communicates with your SMTP and POP3/IMAP clients directly. But what if you cannot grant or don’t have access to the POP3/IMAP from the outside?

WebSitePulse mailbox scenario

This is the best option for monitoring the whole send-receive process if you have a Microsoft Exchange Server or don’t want to open your IMAP/POP3 to the outside. The difference in the setup here is that when the test message goes to the POP3/IMAP mailbox on your end, it should be automatically forwarded to a WebSitePulse mailbox. Our monitoring agent then checks the latter, and if the message is received, the test is considered OK. If your goal is to monitor authenticated SMTP servers and forwarders (relays), pay attention to round-trip scenario 3.

Authenticated SMTP servers scenario

You can see that in this case, the second SMTP server (SMTP 2), NOT the first SMTP, is responsible for the domain of the POP3/IMAP. The transaction starts by sending a message to the first SMTP server, which is then forwarded to SMTP 2. From there, the test email is dispatched to the POP3/IMAP mailbox, and our monitoring agent tries to retrieve it to verify the success of the check.

And what if you don’t want to monitor your own SMTP directly?

POP3/IMAP scenario

In this case, our system communicates with your POP3/IMAP only. Our monitoring agent sends the message via the local mail sending program. The message goes to the WebSitePulse mail server (WSP SMTP), and from there, it is sent to SMTP2 (responsible for the client’s domain). As in the previous scenario, the test email is sent to the POP3/IMAP mailbox, and our monitoring agent tries to retrieve it and thus complete the transaction.

The final email round trip test scenario shows the case where you do not want to monitor the SMTP directly and/or the POP3/IMAP servers.

WebSitePulse POP3/IMAP only scenario

As you can see, in this case, the monitoring agent communicates with the WebSitePulse POP3/IMAP only. However, while this type of monitoring setup can still guarantee that your email process is working, the procedure itself is not monitored, and the response times of your servers cannot be recorded.

So, now that you know how email round-trip works, why don’t you give it a try here?