This article contains information on configuring and managing Delivery Routes in Mimecast, including inbound and outbound email routing, failover options, load balancing, and policies for specific scenarios like multiple domains or server migrations.
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 will be 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 the email server load.
If the customer infrastructure becomes unavailable, Mimecast will automatically queue inbound emails for up to 4 days. 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 allow customers to configure when emails should be delivered. This could be to accommodate multiple sites, facilitate a mail server migration, configure a backup delivery route, or even 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 attempts 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:
-
-
- [Everyone] to [Internal]—Server A.
- [Everyone] to [Internal] - Server B.
-
To implement this round-robin delivery of emails, the policies must match in terms of the From and To variables.
Comments
Please sign in to leave a comment.