Throughout MailerQ, there are three properties frequently used to select certain messages: IPs, domains and tags.
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.
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.
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.
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.
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.
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.
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. Additionally, you can provide conditions, which means MailerQ will only apply the rule if for the selected message certain properties do or do not equal/contain/match specific values or patterns.
For monitoring and configuration on-the-fly
For sending, pausing and failing certain deliveries
For easy integration in any infrastructure
Add, organize and warm-up IPs in real-time without restart
Easily scale message queues across multiple machines
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.
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.
Adding records to the Suppression List in MailerQ will result in the MTA failing any message that matches one of these records. These records can be either entire recipient addresses or just the recipient domain. This way, you can suppress delivery attempts to faulty domains with typical typos like "hotmai.com", "gmail.co" but also to email addresses you know do not exist (the ones for which you received a "mailbox does not exist" response). You can update this list manually using the Management Console.
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 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 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.
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.
With the External MTA IPs, you can specify Network Address Translation (NAT) rules for mapping local IPs and ports to external IPs. This is specifically useful when MailerQ is deployed in cloud environments such as Amazon Web Services with limited public IPs available. It is also beneficial when your own IP addresses are managed on a different server than your MTA is running on.
Or plan a complete walk-through of the most powerful MTA with one of the MailerQ experts.
Try out for free
