Learn how to use the Delivery Rules feature of Hurricane MTA to optimize message processing and improve deliverability.
Hurricane MTA allows for senders to customize how SMTP traffic is managed with a feature called Delivery Rules. By default, all MTA installations included a default ruleset called the Smart Delivery Rules™. These rules cover the largest mailbox providers which represent the most frequent systems the Hurricane MTA is likely to interact with in normal usage. These rules are regularly updated and improved over time as mailbox providers change their limits, and as we can further optimize the rules. SocketLabs does not automatically push new rules down to on-premises MTA Installations. We recommend using the MTA Administration page to check for updated Smart Delivery Rules every 90 days.
Hurricane MTA customers are also able to build and create their own rules in the MTA. There are two different levels of specificity (both below the Smart Delivery Rules) in which rules can be applied. Rules can be applied across the entire MTA and all therefore all virtual accounts, or on a per account basis. Delivery rules be targeted across messages at two different levels - by recipient Domain or by the MX record. The logic for how delivery rules are applied is a cascade. The cascading logic for Delivery Rules is as follows:
1) Smart Delivery Rules (Domain mask)
↳ 2) MTA Delivery Rules (Domain mask)
↳ 3) Account Delivery Rules (Domain mask)
↳ 4) Smart Delivery Rules (MX mask)
↳ 5) MTA Delivery Rules (MX mask)
↳ 6) Account Delivery Rules (MX mask)
As you can see when the MTA picks up a message from a given domain bucket in the queue, it will first apply the domain targeted delivery rules. It will start with any smart delivery rules, then slowly work down to the MTA rules, and finally account level rules. Then after applying the domain level rules, the MTA will begin the delivery process. The delivery process starts with a DNS query for the MX records of the domain. It is at this point we then check for any MX rules, based on the MX record selected from the DNS results. MX rules will override a domain specific rule as they are applied at a later stage in the delivery process.
MTA level delivery rules can be managed under the Configuration -> Delivery Rules page in the Hurricane MTA Web Interface.
A default MTA installation will include the smart delivery rules and a generic catch-all rule that will apply to all mail not matching a Smart Delivery Rule.
When creating a delivery rule there are many options for modifying how mail is processed.
Lets go over each of the parameters to see how they can be used:
Enabled
Use this check box to choose if the rule is On(Enabled) or Off(Disabled). This flag can be very helpful when troubleshooting a complex rule and only want to temporarily disable it, rather than delete it.
Priority
Changes the priority of the rule. Rules are evaluated top to bottom. The lower the priority setting, the higher the priority. A setting of 1 is the highest priority. When creating a rule that will override the smart delivery rules across an MTA, you must configure the delivery rule with a higher priority than the Smart Delivery Rules and the wildcard catch-all rule.
Mask
Specifies the domain that this rule applies to. An * may be used as a wildcard. A mask can also specify that the rule should only be applied to specific IP addresses, or a group of IP addresses by using the tag feature in the IP Addresses configuration. To associate a tag with a delivery rule, append a pipe symbol to the end of the mask followed by the tag. i.e. setting a rule's mask to "*.google.com|cold" would cause this rule to apply to traffic to Google, but only for the IP addresses tagged with "cold".
Apply Rule To
Specifies whether this rule applies to the recipient's domain or to the recipient's mail exchange. The recipient's mail exchange is the server that handles the mail for the recipient's domain.
Override Protect
If checked the delivery rule override settings will not apply to this rule. Delivery Rule Overrides are configured per MTA account and include settings like Using TLS, and per domain throttles.
Action
Determines the action that should be taken when this rule is matched. The default value is Normal which causes the rule to be applied normally according to the other parameters of the delivery rule, other options are Defer, which causes the messages to be forced to defer, and Fail, which causes the messages to be forced to fail immediately. An example use case of the Fail option would be to clear message queues to a single specific domain or mailbox provider(MX)
Timeout
By default the MTA uses a standard timeout period in which it will wait for a reply to a specific SMTP command or connection attempt. The Timeout setting allows you to shorten (Shortest|Short) or Extend (Long|Longest) this default Timeout length. One common use case of the Timeout setting is to adjust for receiving mail systems that may take an extended time to issue a 250ok response to the end of message mark due to the spam scanning process it performs. Extending the Timeout length can slow down message delivery to that domain or MX.
SSL/TLS
Specifies SSL/TLS options for connections to the remote server.
If not enabled, SSL/TLS is not used and all other options are ignored. If the Enable option is selected, the outbound connection will attempt to initiate SSL/TLS using the STARTTLS command. If the remote server does not support SSL/TLS or if there is a problem negotiating, the connection will be made without using SSL/TLS.
The Bypass Certificate Validation option allows delivery to continue encrypted even if the server certificate is untrusted or bears the wrong name.
The Force option prohibits connections with remote servers that do not support SSL/TLS and whose implementations are not compatible. Messages that cannot be delivered using SSL/TLS will fail if this option is selected. This option can be combined with the "Bypass Certificate Validation" option in which case when a certificate name mismatch occurs the connection will still continue using encryption.
If you wish to run in Opportunistic mode (favors delivery over security) you should select both the Enabled option and the Bypass Certificate Validation option. We recommend only using the Force option if you know the remote server supports TLS/SSL and is compatible with your operating systems security options.
Return Path Encoding
Enables you to disable return-path VERP encoding for messages that match this delivery rule. This will prevent Hurricane MTA Server from receiving asynchronous bounces for these messages, however this may be helpful in cases where specific domains have issues with long return-paths or use the return-path for authentication of validation(i.e. Email to Fax services).
Max Messages / Conn
Specifies the maximum number of messages that may be sent per connection. Setting this value to a higher number may improve throughput, however some ISPs may find sending too many messages per connection suspicious. Very few mailbox providers document a single specific limit of accepted messages per connection. Many mailbox providers may also determine the allotted messages per connection dynamically based on reputation. When establishing the Smart Delivery Rules we will tend to err on the side of caution regarding these limits to ensure even mid-to-low reputation senders do not experience delivery issues. Extremely high reputation senders can override the Smart Delivery Rules with a new rule that sends additional messages per connection to improve throughput.
Max Concurrent Conn
Specifies the maximum number of concurrent connections. Just like with the Max Messages/Connection, some mailbox providers may find a high number of concurrent connections suspicious, don’t publish the figures publicly, and/or determine them dynamically. Low volume and low reputation senders may want to establish new rules with very low connection and messages per connection rates to reduce the likelihood of deliverability issues.
Throttle
Can be used to limit the maximum number of messages sent over a time period.
Dynamic Block Rules
Dynamic Block Rules enable Hurricane MTA Server to take a specific action, such as pausing delivery based on real-time responses received from mailbox providers to protect your reputation and increase overall deliverability. Dynamic Block Rules are really a rule within a rule to handle specific SMTP response. Dynamic Block Rules have their own parameters:
Enabled
Enables or disables the Dynamic Block Rule.
Priority
Changes the priority of the rule. Rules are evaluated top to bottom. The lower the priority setting, the higher the priority. A setting of 1 is the highest priority.
Action
Determines the action that should be taken when this rule is matched. The default value is Alert Only which triggers a delivery alert but does not change delivery. The next option is Defer, which when selected instructs the MTA to defer all messages to this domain or MX for the specified period of time. Lastly, the final option is Fail, which causes the remaining messages in queue to be forced to fail immediately. All three options will trigger a delivery alert.
Alert – Mark As Critical
Every Dynamic Block Rule generates a delivery alert, however you can choose to have the alert marked as critical. The Alerts Configuration page enables you to process critical alerts differently than regular alerts.
Duration
Specifies a duration for the defer action. This value is ignored if the action is set to Alert Only or Fail.
Response Match
A regular expression that will be compared to each response from the ISP. A positive match triggers the rule.
Notes
Can be used to store free-form notes for the rule. For reference only.
We highly recommend that when creating a delivery rule you include any Dynamic Block Rules included in the Smart Delivery Rules. These back-offs are critical to reputation management at the largest mailbox providers. Creating a new Delivery Rule that is applied in lieu of the Smart Delivery Rules is one mechanism of deliverability troubleshooting. Increasing the deferral duration when encounter error response codes may help improve deliverability for lower reputation senders.
Relay
This feature allows for you to provide a Hostname, Username, and Password to perform an authenticated SMTP Relay of the targeted messages. An example of this may be routing the mail to another MTA account, or to the SocketLabs cloud service for delivery.
Notes
Free form notes for this rule.
Any further questions regarding the MTA Delivery rules feature should be directed to our customer support team. If you are looking to have rules and MTA performance reviewed and optimized by our team of experts, check out our Deliverability Services offerings here