Maildome MTA

Superior delivery engine for performance, yield, and technological level

"We are proud to introduce you to MaildomeMTA, designed, developed and implemented entirely by our team of email marketing experts.
Our fastidious search for perfection and quality and our desire to achieve something different, which performs, but above all is valid in every situation, has led us to create a product without equal on the market."

After over twelve years of experience in email marketing, and in the use of tools and services for sending email communications, we came to the conclusion that it had become absolutely necessary to implement a proprietary technological solution.

Due to the evolution of email marketing and changes in the logic of providers' communications analysis in recent years, open-source and commercial solutions no longer respond appropriately to all the technical specifications necessary to guarantee optimal deliverability levels.

Our development team has spent months benchmarking and testing open-source solutions like Postfix, Exim, Sendmail and Qmail, but also paid MTA solutions. Unfortunately, results have always been the same: in most cases, we found ourselves facing a dead end.

open-source

"With these solutions, we cannot offer anything different from any of our competitors.
Indeed, none of these solutions meets our needs!"

send

"Our corporate mission is different: we want to and must provide a different product, a high-quality solution designed to adapt to all conditions, configurations and types of reception logic of the various ISP recipients."

This meant we could not compromise, and, hence:

"We needed to build our own Mail Transfer Agent, as only this offers maximum flexibility and customisation, and a product that meets all the needs for the domains present in our customers' databases"

networking

The only solution was to develop, implement and, thus, create a proprietary MTA (mail transfer agent).

Of course, we could have created a "standard" service, like many delivery platforms have done, but the obsessive search for perfection and quality and the desire to produce something different, which performed better, but above all, was valid in every situation, pushed us to this point.

After a feasibility study and technical analysis of the languages ​​to be used for the realisation, module structuring, and design of the entire infrastructure, we decided to launch this project to deliver a flexible tool that could meet the needs of various email providers.

Over three years of development, testing and debugging, we found that many ISPs did not respect – and still today don't comply with – the standards imposed by the SMTP protocol and its RFC.

Many open-source and commercial solutions have, and will always have, great difficulty in delivering email communications to those who do not respect the protocol.

Thanks to the specific study of over 11,000 configuration situations and different unique domains, we managed to build a state-of-the-art product: MaildomeMTA, which delivered at a 99.9% delivery rate for domains and senders with a good reputation.

delivery

After more than three years of development of a proprietary solution for email delivery, we have created a product with unparalleled performance in its category.

mta

Our MTA (mail transfer agent) is a product designed not only to manage huge transfer volumes, but also – and above all – to specifically adapt to every receiving server configuration, and all individual blocking or blacklisting logic of third-party products implemented on the receiving server, such as Cloudmark, Proofpoint and many others.

Intelligent adaptation to provider logic

The MTA engine features over 5,000 operational routines designed to perform all operations underlying email communication. Its most relevant feature, and one that makes our product unique worldwide, lies in its dynamic and intelligent behavioural adaptation to all receiving ISPs.

The engine of MaildomeMTA is constantly evolving and, thanks to self-learning logic, manages to keep up with the continuous changes and technological adaptations implemented by providers, from the largest and most important vendors to the smallest ones, often neglected by open-source solutions.

provider mta

One might think that sending or receiving an email would always work exactly the same way, regardless of the related email domain: nothing could be further from the truth.

Every single email provider adopts completely different logic and filters: for this reason, it is important that the latter are interpreted intelligently and used by the sender in an adequate manner, always guaranteeing good deliverability but, above all, maintaining the reputation (domains and IP) of the entity that sends communications; unfortunately, this reputation is increasingly compromised by the misguided delivery policies of various MTAs, which hardly adapt to all blocking, let alone to filtering solutions

Warmup

As a regular user of delivery platforms, you will have surely heard of "warmup" of sender domain IPs and database fragmentation policies .

Of course, procedures you always executed manually were prone to error, posed a major risk of non-compliance regarding the standards of various providers, and invariably led to problems following the "warmup" phase.

This logic is implemented natively within the engine of our MTA, thanks to algorithms developed on the delivery side.

The management of this phase is fully automatic and transparent for the marketer , who will simply plan its campaigns whilst the system deals intelligently with limits, blocks, splitting, speeds and volumes, which differ completely among providers, without forcing the marketer to take any manual actions.

warm up
reputation mta

Reputation

Up until now, it was not uncommon to manage the reputation of one's domains and IPs manually, verifying and possibly excluding portions of some providers' databases, and receiving permanent blocks because of poor reputation

Here again, the MTA has been designed to solve or otherwise mitigate the problem in a completely automatic and native manner. Thanks to the real-time analysis of the reputation of all IPs associated with the platform, your system will no longer keep on sending emails from providers that have given you a low reputation due to spam compliance issues, hard bounces, or other factors.

This reputation can always be monitored within our platform: the delivery engine can manage loads and delivery queues in a smart, distinctive manner, without constantly emphasising providers with whom you have a poor reputation, thus allowing the reputation's gradual recovery.

Blocking and Blacklisting

More and more often we hear about filters like Cloudmark or Proofpoint, collaborative filters, and filtering and blocking solutions: these aspects are of fundamental importance, and cannot be ignored as often as various commercial and open-source MTAs do so.

Continuing to deliver without control to providers who have activated blocks or these sorts of blacklists penalises one greatly.

blocking

As these are collaborative filters, as in the case of Cloudmark, the risk lies in compromising not only the deliverability to the provider in question, but also to all those using Cloudmark: in no time, you will see your domain and IP being blocked on all providers using this filter.

Maildome also has the solution in this case! We have thoroughly studied the "blocking and blacklisting" issue and built a system that can identify blocks of any kind in real time, with the consequent adaptation of delivery policies to avoid the total blocking of all IPs. and sending domains.

Spamtrap

How many times have you heard about Spamtrap?

Most likely in all email marketing conferences, books, online video courses, websites and delivery platforms. Whilst everyone talks about it, the fact is that nobody manages it properly and in an optimal way.

Spamtrap may seem a problematic and negative element in the eyes of email markeers; in fact, it is an extremely useful tool, perhaps the only one that providers can draw upon to penalise and discard spam emails and determine the actual quality of a database.

spamtrap

There are different types of Spamtrap, classified according to their severity level. We will not dwell here on the most critical ones, which were possibly acquired illegitimately; we'll talk instead about those that used to be email addresses, belonging to real users.
Because of a prolonged period of inactivity, many of these emails have been transformed into Spamtrap by various providers, as a way to verify the cleanliness and updateness of the sender's database.

Correct Spamtrap address management

Quite often, due to inadequate database clean-up, it may happen that your database holds long dated and inactive email addresses.

These addresses, transformed into Spamtrap by various ISPs, often lead to penalisation. However, having this sort of Spamtrap in your database is not a symptom of illegal data acquisition but of database mismanagement.

For this reason, in our opinion, a good delivery platform should be able to manage these addresses the smart way , since the latter are constantly monitored by the various ISPs, which trigger blocks or penalties against sending domains delivering to these inboxes.

manage-spamtrap

Our MTA manages Spamtrap optimally by through special syntactic and behavioral analysis algorithms, the developmet of which was major undertaking on our part.
Our system is always looking for potential Spamtraps, thus preventing delivery to inboxes that could compromise the reputation of the sending domains and IPs.

A Spamtrap search system that is continuously learning and improving

To be sure, the challenge posed by Spamtrap identification is a major one: no provider in fact releases these addresses, because otherwise they would lose their effectiveness. Whilst this means we cannot ensure 100% coverage, we can certainly guarantee that our system is designed and suitable to address Spamtrap like no other. Spamtrap management is completely automatic and continuously learning and improving.

We also want to clarify that the database cleanup problems do not fall into this aspect, but are dealt with in a special section: our MTA does not deal with the cleanup of the database, but takes care to avoid sending on specific boxes considered precisely Spamtrap.

Would you like to discover other aspects of our platform?