Delivery Routing Introduction

Document created by user.oxriBaJeN4 Employee on Sep 24, 2015Last modified by user.oxriBaJeN4 Employee on Mar 15, 2016
Version 2Show Document
  • View in full screen mode

Delivery routes are used to deliver emails from Mimecast; typically, inbound to your local infrastructure, although they can also be used to override MX records for outbound delivery. Delivery Routes contain the details of the delivery destination, such as the Host Name or IP Address of the email server. Mimecast’s flexible Routing Policies allow emails to be delivered to a specific server based on a domain, Group, Attribute or individual address.

 

Delivery routes determine the route to be used for inbound email delivery.  By default, outbound emails willbe delivered to the recipient using available MX records, however if an outbound delivery route has been configured, this would override the MX record. Delivery routes require the specific route to be configured, and then a policy to determine the flow of traffic. Alternate routes can also be created, which enables a failover option, should a customer’s primary route be unavailable.

If multiple similar routes (the FROM and TO variables are the same) are configured, this will result in a round robin (random selection) of these routes.  This is useful to balance mail server load.

If the customer infrastructure becomes unavailable, Mimecast will automatically queue inbound emails for up to a 4 day period.  After this period, the emails will be bounced to the sender, unless all inbound deliveries are paused.

Service Monitor can be configured to issue alerts to Administrators should the Delivery Queue exceed a specific threshold.

 

Mimecast offers intelligent email routing options which allows customers to configure when emails should be delivered. This could be to accommodate multiple sites, facilitate a mail server migration, configure a back-up delivery route, or even to load balance delivery of email.  Some possible applications of this functionality are described below:

 

  • Scenario 1: Single Email Server:
    In the simplest configuration of Delivery Route definitions, customers may have only one email server where all inbound emails should be delivered. A definition should be configured and then referenced by a Delivery Route Policy for all inbound emails.
  • Scenario 2: Active and Alternate Routes:
    To reduce the risk of email downtime, an organization can implement multiple on-premise servers, and configure alternate routes should the primary server be unavailable. The Delivery Route definition in Mimecast is configured with the primary server information (in the Host Name/IP address field), and then one or more alternate addresses for the failover servers.  If Mimecast will attempt delivery to a primary mail server - if that server is unavailable, and once the attempted connection times out, Mimecast then attempts to connect to the next alternate address on port 25.
  • Scenario 3: Multiple Domains with different Delivery Routes:
    When an organization manages multiple domains, e.g. domain1.com, domain2.com, domain3.com, etc., Administrators can configure the Delivery Route definitions to ensure that emails to specific domains are delivered to the correct mail server. For example, emails for domain1.com and domain2.com should be delivered to server A, and emails for domain3.com should be delivered to server B.  Two definitions are required - one for server A, and one for server B.  A Policy is then used to specify which emails should be delivered to which server.
  • Scenario 4: Load Balancing email delivery:
    To spread large volumes of inbound email across more than one server, it is first necessary to create the definitions for each server, e.g. Server A and Server B.  Note that each of the servers can also be specified as alternate routes in the other definition, so that Server A is the alternate route for Server B, and vice versa.  This ensures that if one of the servers is unavailable, all email flow will be delivered to the alternate route server (following a timeout of the server that is down).

Once the definitions are in place, a Policy for each definition is created to deliver all emails to the relevant server.  For example:

  • [External] to [Internal] - Server A
  • [External] to [Internal] - Server B

In order to implement this round robin delivery of emails, the Policies must match in terms of the FROM and TO variables.

 

See also...

 

Attachments

    Outcomes