Backup MX adds KisoLabs' robust and redundant mail infrastructure to your current configuration. If your mail exchanger(s) go down, KisoLabs will store your incoming mail for up to 30 days, and frequently retry delivery.
If you host your DNS with KisoLabs (using Dynamo Advanced, Serv Advanced or Serv Pro), configuring your DNS is easy: Edit your zone and click on the button Add KisoLabs MX Records. The appropriate MX records will be added in the zone editor. Then save your zone configuration.
If you host your DNS with another provider, you must edit your DNS configuration using their tools. Add the MX records as described above under DNS Configuration, above.
To ensure delivery of email to a port other than 25 (SMTP), you must have KisoLabs' MX servers listed as your only MX servers in your DNS configuration.
If your mail server has port 25 open to the internet, you may configure it as an MX in your DNS. Keep in mind that email delivered directly to your mail exchanger will not benefit from KisoLabs' virus and spam scanning.
Once your DNS is configured, your service is set up. Aside from enabling spam and/or virus scanning, there is nothing more to configure. KisoLabs' Backup MX is ready to relay your mail.
Even though email is delivered directly to your mail exchanger(s) under normal circumstances and you probably already have spam and virus scanning in place, it is common practice for spammers to target the last mail exchanger (MX) in your zone. This is because backup (or secondary) mail exchangers are usually less protected and are viewed only as failsafes.
When spam scanning is enabled, it will only prevent very obvious spam from being relayed. All other spam (or possible spam) messages will be flagged as spam in the message headers, and will have *[SPAM]* added to the beginning of the subject line. This is done so that you will still receive messages that may be incorrectly marked as being spam, and so that you can set up your own filters or rules in your mailbox to quarantine spam messages.
If a message is flagged as spam, the sender will not receive a "bounce back" notifying them that their message was flagged as spam.
When virus scanning is enabled, messages in which a virus is found will not be relayed. The intended recipient of the virus will instead receive an email notifying them of the infected message. The notification will include information about the original sender.
Full text logs for your services are available here.
Mail logs are formatted as space-delimited files with quotes enclosing any field that contains a space as content. The general format of the log is as follows:
Each of the fields is described below:
| Field | Type | Description |
|---|---|---|
| Date Queued | date | The UTC date and time that the message was queued. The format is: yyyy-MM-dd HH:mm:ss yyyy is the 4-digit year. MM is the month (01-12) with leading zeroes. dd is the day of the month with leading zeroes. HH is the hour (00-23) with leading zeroes. mm is minutes ss is seconds |
| Date Last Processed | date | The UTC date and time that the message was last processed. If delivery could not be made
this date/time will be updated at every following delivery attempt. The format is: yyyy-MM-dd HH:mm:ss yyyy is the 4-digit year. MM is the month (01-12) with leading zeroes. dd is the day of the month with leading zeroes. HH is the hour (00-23) with leading zeroes. mm is minutes ss is seconds |
| Queue Id | hexadecimal (string) | The queue id assigned by the KisoLabs mail server. This value does not have any real meaning for the purposes of log analysis, but can be useful when working with KisoLabs' support team to resolve email delivery issues. |
| Message Size | integer | The size of the message in bytes. |
| Client IP | IP address (string) | The IP address of the SMTP client that relayed the message to the KisoLabs mail server. |
| Client Host | string | The host name of the SMTP client that relayed the message to the KisoLabs mail server. This is the host name reported by the client with the HELO (or EHLO) command, and does not necessarily represent the DNS entry that resolves to the Client IP field. |
| Message Id | string | The message identifier (this is usually generated by the first SMTP server to relay the message). The
message identifier should be globally unique, and therefore may assist you in debugging mail delivery issues. The KisoLabs mail servers will not alter the message identifier, but in rare cases it may be modified in transit by an upstream or downstream server. |
| From Address | string | The email address of the sender of the message. |
| To Address | string | The email address to which the message will be delivered. For services that forward messages, such as Forwarder and Instance Mail, this field contains the ultimate destination address (in other words, the address to which the message was forwarded). |
| Original To Address | string | The email address to which the message was sent, if different than the To Address field. For services that forward messages, such as Forwarder and Instance Mail, this field contains the alias address defined in your service's configuration. For all other types of service, this field will contain a single dash (-) to indicate that it is unused. |
| Status Text | string | The textual description of the status code representing the delivery status of the message. This field may not be populated until
the message is delivered to, rejected by, or a timeout is reached for the destination mail exchanger. If the field is unpopulated it will be represented by a single dash (-). |
| Status Code | integer | The status code representing the delivery status of the message. This field may not be populated until
the message is delivered to, rejected by, or a timeout is reached for the destination mail exchanger. If the field is unpopulated it will be represented by a zero (0). |
| Spam (Virus) Status | string | The status reported by the spam and virus filter. If spam and virus filtering are disabled on your service, or if
spam and virus filtering were not completed for a message, this field will not be populated. If the field is unpopulated it will be represented by a single dash (-). |
| Spam Hits | decimal | A number representing the strength of the assertion by the spam filter that the message is spam. The number is qualitative, so the general rule is that a higher number will indicate that the message is more likely to be spam. |
| Last Delivery IP | IP address (string) | The IP address of the host to which the message was last delivered. This will be the address of the next-hop SMTP server
when delivery is successful. Important: If the address shown is 127.0.0.1 that indicates that it was not delivered externally, and was re-queued by the KisoLabs SMTP server. This is not an error condition, and will always occur when a message is blocked as spam, or blocked because it contains a virus. It may also occur when a message could not be delivered and is awaiting redelivery, however in that case this field may also contain a dash (-). |
It is important to remember that the mail logs represent the transactional nature of the SMTP message workflow.
In other words, when a message is received by the KisoLabs MX servers, the receipt of that message is logged. The message is then (if your service is so configured) scanned by our spam and/or virus filters, which is also logged. When delivery is attempted, that attempt is logged (and may be logged multiple times). When delivery succeeds, that is logged as well.
The logs for your MX service are generated by aggregating all of those log messages into one line. As such, a log line (or log file) may be updated retroactively when a new event occurs. For example, the following may take place:
In that example, a log line will be written into your service's log file for 2012-03-15 showing that the email was received by KisoLabs' server, but will not show delivery having been made. Approximately 24 hours later, your services log file for 2012-03-16 will be generated, but that log file will contain no information about the email in the example. Instead, the log file for 2012-03-15 will have been retroactively updated to include the final delivery status.
For most KisoLabs MX services, email messages can be queued for up to 30 days. Therefore it is possible that a log file that is 30 days old may be updated with the status of a message.
In some cases, an ill-formatted email message will not be locatable across transactional steps. This is particularly common when the message is spam and does not contain a message id (or the message id is not unique, or is too short to be globally unique). In that case, the message may cause more than one line to appear in your service's logs.
For the sake of example, five log lines are shown below for the imaginary recipient domain example.com.
The meanings of each of the sample lines are discussed below:
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 10:56:28 PM UTC from bob@sample.com to matt@example.com. The message size was 1,292 bytes, and was relayed from 10.203.80.101 (having the host name of mx01.sample.com). It was relayed to 172.16.54.92 with status code 250 ("sent") on March 15, 2012 at 10:56:30 PM UTC. It passed spam filtering, and was not considered to be spam ("Passed" 0.2781).
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 10:58:14 PM UTC from fred@flintstones.org to barney@example.com. The message size was 2,173 bytes, and was relayed from 192.168.78.22 (with an unknown host name). It was relayed to 10.88.22.11 with status code 250 ("sent") on March 15, 2012 at 10:58:15 PM UTC. It passed spam filtering, but was considered to have some characteristics of a spam message ("Passed SPAMMY" 10.2032).
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 11:01:45 PM UTC from homer@evergreent.com to sales@example.com. The message size was 2,159 bytes, and was relayed from 172.16.250.33 (having the host name of mail.simpsons.net). It was relayed to 10.3.1.87 with status code 250 ("sent") on March 20, 2012 at 9:32:18 AM UTC. It passed spam filtering, but was considered to have some characteristics of a spam message ("Passed SPAMMY" 18.3999).
This line shows a case where a message could not be delivered to the next mail exchanger for almost 5 days (the difference between the Last Processed and Queued dates). This would usually represent an issue with your mail server where it was inaccessible when the KisoLabs mail exchanger attempted delivery.
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 11:02:25 PM UTC from wentworth@uwnto.de to gesundheit@example.com. The message size was 2,181 bytes, and was relayed from 10.58.244.148 (with an unknown host name). The next mail exchanger (e.g. your mail server) responded on March 15, 2012 at 11:02:25 PM UTC with the status code 550 ("rejected"), most likely because the recipient ("gesundheit@example.com") did not exist. It passed spam filtering, and was not considered to be spam ("Passed" 1.4420). Note that the last delivery IP address is shown as 127.0.0.1 because the message was not relayed.
A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 11:03:01 PM UTC from lannister@westeros.net to tyrion@example.com. The message size was 5,129 bytes, and was relayed from 10.105.99.152 (having the host name of www.somesite.org). The message has just entered the system, and so there is no delivery status nor spam status.