Usually, messages are delivered directly to the target server and are not stored on the filtering server. However, if the target server is not reachable, all messages sent to known recipients are stored in a queue on the filtering server. Messages that are permanently rejected by the target server with a 5xx error are not stored in the queue and getting rejected by the system. Here you can find a list of SMTP errors:
500 - The server could not recognize the command due to a syntax error.
501 - A syntax error was encountered in command parameters or arguments.
502 - This command is not implemented.
503 - The server has encountered a bad sequence of commands.
504 - A command parameter is not implemented.
550 - No mailbox by that name is currently available (ex. because it was not found, or because the command was rejected due to policy reasons, such as a full mailbox. Please clear the callout cache after the mailbox has been emptied).
551 - The recipient is not local to the server. The server then gives a forward address to try.
552 - The action was aborted due to exceeded storage allocation.
553 - The command was aborted because the mailbox name is invalid.
554 - The transaction failed. Blame it on the weather.
If the target mail server uses the "catch-all"function, we do not store any recipients. The messages are only stored in the queue if the valid address was created as a local recipient in the EuropeanMX Control Panel.
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.
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:
If a message is frozen (message can neither be delivered to the recipient nor returned to the sender), no automatic delivery attempts are made. A super-administrator will then be able to retrigger the delivery of the message if the problem has been solved.
EuropeanMX stores valid recipients for up to 4 days. When the entries have expired, EuropeanMX no longer saves messages for this recipient, but temporarily rejects them so that the messages are stored on the sending mail server. In such cases, the resubmission attempt will be carried out by the sending mail server. If you use the "local recipients"feature (with catch-all function), the storage of the recipients is bypassed and EuropeanMX accepts and stores all messages for created local recipients in the queue.
In accordance with SMTP RFC 5321 guidelines, the sending server is required to queue messages that cannot be delivered directly to the recipient due to a temporary error on the receiver side. Therefore, in case of a temporary problem with the e-mail infrastructure, messages are not rejected (bounced) immediately, but stored on the sender's side and automatically attempted to be delivered again.If the receiving mail server cannot be reached, only messages that are valid in our system will be accepted. Valid recipients are always stored for 96 hours.
If a target server can no longer be reached after 4 days, all messages are rejected (bounced) after 4 days and further e-mails are no longer accepted/stored in the queue until it is reachable again. This 4-day period complies with the SMTP RFC guidelines. The reason why messages are no longer stored is that it is important for the sender to know that the message could not be delivered and that he can contact the recipient if necessary.
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.
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:
If the problem still persists after the completed steps, please contact our support and send us all necessary information and examples.