MailerQ is fast. It runs multiple parallel threads to deliver email, network calls are non-blocking and messages never hit a disk.
MailerQ uses message queues and JSON, giving you full control over your email flow. You can monitor and intervene when necessary. Prioritizing and routing has never been easier.
MailerQ is competitive. It beats every MTA in performance and pricing, and it has all the features that you find in other MTAs.
For most MTAs, disk performance is the bottleneck. But not for MailerQ. MailerQ is an MTA and handles incoming and outgoing SMTP traffic and processes MIME data. But it does not write to disk. It relies on RabbitMQ and NoSQL storage for messages queues and deferred messages. These tools are fast, reliable and scalable and were designed to handle big data flows, and do that much better than an MTA could ever do.
All data that passes through MailerQ is JSON encoded. The messages that you inject and the incoming messages are all consumed from and published to RabbitMQ as JSON objects. The delivery results are also JSON encoded and hold properties like the SMTP status code, the certificate details of the receiving server and much more.
RabbitMQ is a tool for message queueing. You can create your own mail flow that passes through filters and scripts, or that can be forked and sent to mailboxes, monitors or logs.
MailerQ connects to a MongoDB or Couchbase server to store deferred messages. If you do not want to use one of these tools, you can configure MailerQ to use disk based storage instead.
MailerQ runs in multiple threads to use all your CPUs. Each of these threads has a non-blocking architecture: MailerQ does not wait for slow system calls or blocking network operations. Messages do not get stored to disk, because disk operations slow down software too. This all makes that you can send millions of messages from a single server.
The table holds the hardware requirements if you would run MailerQ, RabbitMQ and MongoDB all on the same physical machine, using gzip compression for data interchange. For a high availability setup (to survive hardware failures) it is better to setup a cluster of two or three machines.
| Emails/day | Servers | Specs |
|---|---|---|
| 1 million | 1 | 2vCPU, 6GB RAM, 100GB HDD, 100Mbps |
| 10 million | 1 | 6vCPU, 10GB RAM, 300GB HDD, 1Gbps |
| 50 million | 1 | 24vCPU, 60GB RAM, 1400GB HDD, 256GB SSD, 1Gbps |
| 100 million | 1 | 48vCPU, 120GB RAM, 3250GB HDD, 512GB SSD, 2Gbps |
Other MTAs get their settings from long and complex configuration files that are hard to maintain and difficult to update. However, you want your MTA to be easy to tune, both manually and programmatically. This is possible with MailerQ.
Most of MailerQ's runtime configuration settings come from a relational database. This allows you to update on the fly: connect to the database and run queries to insert or update data. MailerQ picks up the new settings automatically. No restart or reload is needed. This is perfect if you want to integrate MailerQ into other dashboards, APIs or scripts.
MailerQ supports a couple of database engines: MySQL, PostgreSQL and Sqlite. You can use the one that fits you best. The databases are only used for configuration settings, not for real time queries. MailerQ periodically copies all settings to main memory to speed up the lookups. The database therefore never is the application's bottleneck, and slow queries never slow down delivery.
MailerQ comes packed with features right out of the box to improve your email deliverability.
MailerQ comes with a web-based management console, where you adjust deliverability settings on the go. You can use this dashboard if you do not want to connect to the database. The management console also allows you to monitor the real time performance of your deliveries and IPs, reroute emails to other IP addresses or set up flood patterns to react to server responses.
Delivery results are published to RabbitMQ and hold information about the delivery: the SMTP response code, the SSL certificate properties, and more.
Example of the email flow through RabbitMQ and MailerQ
This queue stores transient results for all deliveries that have not yet failed or succeeded. These messages will be retried.
These queues are used for the messages that are delivered successfully or failed completely and receive a subset of the message published in the results queue.
This queue is used by MailerQ to publish all results, both successful deliveries and failures.
MailerQ can open one or more SMTP ports on which it accepts incoming mail. All these incoming messages are published to RabbitMQ. The incoming messages are published to the inbox queue, as set with the "rabbitmq-inbox" setting in the config file.
If you use MailerQ to handle incoming email, you can also use scripts that pick up messages from the inbox queue, and store them in mailboxes or maildirs.
To secure your SMTP traffic, you can assign a private key and certificate.
By default, the whole universe can connect to the inbound SMTP server. You can restrict this based on credentials or IP range.
It is possible to run MailerQ behind a HAProxy server. If you do this, external clients do not directly connect to MailerQ, but to the proxy server instead.
An MTA is an application that runs on your own servers to send and receive email. MTAs are used by ISPs, ESPs and large organizations that handle their own mail.
Would you rather not get your hands dirty with installing, configuring and hosting MailerQ yourself? SMTPeter might be something for you. SMTPeter is a cloud-based SMTP server for fast and secure email delivery, based on MailerQ.
Learn more about SMTPeter
