What happens if the target server is not reachable?

Normally, messages are delivered directly to the target server and are not stored on the filtering server. However, if a temporary error occurs during the transmission of incoming messages to your server, all messages sent to known recipients are stored in a queue on the filtering server. 

Access queue

You can access the queue via the admin panel (Continuity > Delivery queue - incoming or >Delivery queue - outgoing) and try to send saved messages again from there.

Schedule for automatic delivery attempts

Messages for addresses known to our system are redirected, in case of non-accessibility of the receiving mail server, by means of the following intervals:

• In the first 2 hours after receiving the message, the system tries to deliver the message every 15 minutes.
• During the following 14 hours, the delivery attempt is made at a variable interval with a factor of 1.5: the first attempt is made after 15 minutes, the second attempt is made after 22.5 minutes, the third attempt is made after a further 34 minutes, and so on.
• 16 hours after the original receipt of the message in the EuropeanMX filter, an attempt will be made to send the message every 6 hours until 4 days after receipt of the message.
• If delivery is still not possible after 4 days, the system generates an error message (bounce message) to the sending mail server.

If a message is frozen (message can neither be delivered to the recipient nor sent back to the sender), no more automatic delivery attempts are made. A super administrator then has the option of re-triggering the delivery of the message if the problem has been resolved.

EuropeanMX stores valid recipients for up to 4 days. If the entries have expired, EuropeanMX no longer stores messages for this recipient, but temporarily rejects the messages so that the messages are stored on the sending mail server. In such cases, a new delivery attempt is made by the sending mail server. If you use the "Local recipients" feature (with catch-all function), the storage of recipients is bypassed and EuropeanMX accepts and stores all messages for created local recipients in the queue.

Messages in queue

According to the SMTP RFC 5321 guidelines, the sending server is obliged to store messages in a queue that cannot be delivered directly to the recipient due to a temporary error on the recipient side. Therefore, in the event of a temporary problem with the email infrastructure, messages are not immediately rejected (bounced), but are saved on the sender side and automatically attempted to be delivered again. If the receiving mail server is unavailable, only messages that are known to be valid in our system are accepted. Valid recipients are always stored for 96 hours.

If a destination server can no longer be reached after 4 days, all messages are rejected (bounced) after 4 days and further emails are no longer accepted/stored in the queue until the server can be reached again. This 4-day period is compliant with the SMTP RFC guidelines. The reason why messages are not stored for longer is that it is important for the sender to know that the message could not be delivered so that he can contact the recipient if necessary.

Your own fallback servers

Please note that if you specify multiple target physicians, the EuropeanMX system may assume that you are using your own fallback system. If the specified fallback server cannot be reached by receiver callouts, then no internal database is created with the valid recipients. We would not recommend that you enter one or more fallback servers, unless you have a special infrastructure to handle failures of the target server.

Troubleshooting queued messages

If messages are stored in the queue, this is basically because the posting of the message on the target server has failed. To investigate the problem, proceed as follows:

1. Make sure that the route to the destination server is set up correctly. (Please also make sure that you do not use more than one route. Normally only one route should be created!)
2. Check the log files on your target server to learn more about the reason why the delivery attempts were rejected.
3. Perform a Telnet test to check the response from your mail server.
   a. From the message queue by selecting the option Telnet SMTP Test  from the drop-down menu next to one of the messages; this will take you directly to the page Network Tools . 
   b. Under Continuity > Network Tools, switch to the tab SMTP. You can then enter the data there. (see the Telnet tips in the field on the right)
4. If the problem still persists after the completed steps, please contact our support and send us all necessary information and examples.