MailerQ Features

Management Console

Segment messages based on IPs, Domains and Tags

Throughout MailerQ, there are three properties frequently used to select certain messages: IPs, domains and tags.

  • IPs are IP addresses that are available on the host that MailerQ is running on. If specified they are made available to the MTA.
  • If a rule is set for a certain domain and a message matches the MX record of this domain, the same rule will be applied to all similar domains. Furthermore, using MX Pattern Groups, you can define a pattern for matching MX records on certain domains.
  • Tags are many-to-many labels that you can attach to messages for identification, for example to specify a customer, a campaign, whether it’s a transactional or bulk email, and so forth.

Real-time statistics in the dashboard

The overview dashboard allows for real-time insights in delivery attempts and results, queues, error logs and a lot more. You can view these insights per MTA instance, IP, target and even per customer, campaign or message type using tags. The displayed widgets can be customized to match your needs.

Monitor attempt logs, SMTP connections and rendered email

Besides publishing all results to RabbitMQ, MailerQ can write delivery attempts to log files in a customizable format. In the Management Console, you can monitor the logs and filter on IP, domain and tag. Using the SMTP monitor, you can track the entire SMTP connections for a segment of your traffic (using the same filters), and using Email preview you can view fully rendered messages currently being processed by the MTA.

Sending policies

Define delivery rates using email throttling

Define delivery rates using email throttling

Using Email throttling, you can specify the number of connections and delivery rates for specific combinations of source IP and target domain. Examples of capacities that can be set here are messages per minute, new connections per minute, bytes per minute, the maximum number of active simultaneous connections, timeouts throughout the SMTP handshake and much more. These rules will automatically apply to all target domains with matching MX records.

Reduce delivery rates using flood patterns

Reduce delivery rates using flood patterns

Defining Flood patterns is very similar to Email throttling. Whereas Email throttling is used to proactively define capacities, with Flood patterns you can temporarily pause communication and then start sending again on a reduced capacity based on server responses (such as “temporarily rate limited due to IP reputation”). This pattern can be a substring, wildcard string or regular expression.

Adapt MTA behaviour using response patterns

Adapt MTA behaviour using response patterns

Using Response patterns, you can adapt MTA behaviour based on server responses. You can define a trigger, being a combination of a message selection based on IP, target domain and tag, and a server response pattern (exact match, substring, wildcard or regular expression). For every trigger, you can add a suitable follow-up actions such as adding or removing IP addresses for the matching deliveries, fail or retry the delivery, adding or removing tags and changing other message properties.

Warm up IPs using email throttle schedules

Warm up IPs using email throttle schedules

Email throttle schedules allow you to create a schedule for a specific number of days describing what email throttles to use on which day. This schedule can then be applied to any combination of source IP and target domain. Again, these rules will automatically apply to all target domains with matching MX records. Typically, this feature allows for a more automated approach when warming up new IP addresses.

Reroute deliveries using rewrite rules

Reroute deliveries using rewrite rules

Rewrite rules can be used to dynamically reroute messages. To create a rewrite you need two things: a trigger and at least one action. A trigger is a combination of IP, target domain and a tag, that will say what kind of messages - such as a specific campaign that’s being delivered to a certain ISP - should trigger an action. An action tells what should MailerQ do for matching messages - this can be adding, removing or setting an IP for a specific delivery, or redirecting a message to a smarthost.

Delivery interception

Temporarily stop sending using paused deliveries

One way to manually interfere with ongoing deliveries is by using this feature to pause certain deliveries based on source IP, target domain and/or tags. For example, this means you can temporarily pause all messages from a certain campaign sent using a certain IP address until you’ve resolved the issue (by setting up a Rewrite rule, for instance). When you’ve set up MailerQ in a cluster, you can choose to immediately apply this rule across all instances.

Permanently fail deliveries using forced errors

Another way to manually interfere with ongoing deliveries is by using Forced errors to permanently defer certain deliveries based on source IP, target domain and/or tags. For example, this means you can return an error code and message (which you can specify) for all messages from a certain customer sent using a certain IP address. When you’ve set up MailerQ in a cluster, you can choose to immediately apply this rule across all instances.

Configuration

Validation

Manage DKIM keys

For every key, you can specify a signing domain, selector, additional headers to include, FROM-address to match on, and the signature type (DKIM or ARC). You can use the Management Console to manage DKIM keys or you can provide the key in the message JSON.

IP pools

Group IP addresses using IP Pools

IP Pools allow you to group a set of IPs under one name (a pool). This allows for management or preview of a whole group at once. These pools can also be used when injecting emails, instead of specifying individual IP addresses.

MX pattern

Group MX records using MX Pattern Groups

MX Pattern Groups can be used to group domains more generically. Instead of requiring all MX records to match exactly, you can specify a pattern which should be used to match. This means that heavily load-balanced domains that point to the same pool of servers can be treated as a single domain.

Email address

Route inbound emails using local email addresses

Local email addresses enable you to publish incoming messages to a queue in RabbitMQ based on the specified recipient address. This can for example be used to publish DMARC reports or any other inbound messages to certain queues to be consumed by some other application.

Try these and much more features by yourself!

Or plan a complete walk-through of the most powerful MTA with one of the MailerQ experts.

Try out for free Plan a demo