Testing communication

Document information

Document ID:4571
Subject:Troubleshooting outbound email problems
Creation date:12/14/15 4:35 PM
Last modified on:8/13/18 3:45 PM

Troubleshooting problems related to outbound emails

Consider the following scenario:
  • A user Mary (mary@yourCompany.com) wants to send an email to John (John@BusinessPartner.com)
  • John is a user on the Internet who may or may not use Xeams
  • Mary is a user on your network and has specified the host name or IP address of Xeams' machine in her MS Outlook or Thunderbird client.

Step 1 - Mary clicks the send button in her email client and gets an error. Some possible reasons for such error are:
  • The value for SMTP server is incorrectly specified in her email client. Click here for a resolution.
  • Mary's machine is not allowed to relay or she is not configured to use Authentication. Click here to allow relaying or here to use SMTP authentication
  • Xeams server is not running or there is no network connectivity from Mary's machine to the server.
Step 2 - The message is received by Xeams. Click here to see how to verify this step.

Step 3 - Once an outbound message arrives in Xeams it will:
  • Pass through filters
  • Will be sent to outbound message queue. If for any reason Xeams is not able to deliver the message to the final destination, it will sit in a folder called OutboundMailQueue. There could be several reason why an outbound message cannot be delivered. Below are the most common problems.
    • MX record for the destination server cannot be found in DNS
    • The destination server is not responding
    • The destination server won't accept the message
  • There are several log files that you can monitor to see what happens to a particular message. These logs files are:
    • SMTPOutboundConversation.log
    • SmtpQueue.log
    • OutboundAuditTrailFailure.log

Step 4 - The message is delivered to the final destination. To confirm if a message was delivered, search for the recipient's email address in OutboundAuditTrailSuccess.log file.

If you see an entry in this log file, that means the recipient server has accepted the message. If the end user claims that they did not receive it, that means a problem on their end.

User comments

Posted by David Johnson on 5/26/16 11:00 PM

A follow up on this as I got to the bottom of my issue. The issue was because the MTU size of the Ethernet interface was set too high. It needed to be lower than the default 1500 setting and fragmentation was not happening to some of the domains. Setting it to a lower value, meant that the packets could now get through to the mail servers for the other domains and the queue was quickly proceed. Just another thing to watch out for.

Add a comment to this document

Do you have a helpful tip related to this document that you'd like to share with other users? Please add it below. Your name and tip will appear at the end of the document text.
Your name:
Your email:
Hide my email address
Verification code:
Enter the verification code you see above more submitting your tip
Tip:Please limit tips to 1000 characters