portMTA Architecture
portMTA sits between your message generating sources and your
target clients.
It’s horizontally scalable architecture enables the deployment of many portMTA instances and share any message transmission load that you might generate. So, there is no hard limits in send rate/hour of the system. Our recommended hardware configuration alternatives support relaying message volumes by 100k messages/hour up to 1mn messages/hour per instance and there is no limitation on the number of instances to be deployed.
portMTA gives you two different methods to transmit your messages to its stack. One of them is the direct message over SMTP where the messages are pushed directly to their corresponding queue in the stack. The other method is pushing the messages to the Rabbit MQ stack. The latter method enables the stack to consume the messages by popping them from the Rabbit MQ and pushing them into the internal queues.
This enables a level of extra high availability as well since the messages are kept on the Rabbit Queues and potential downtimes for maintenance or any other configuration changes do not result in losing the messages.
The interaction between your business applications and the portMTA stack can be carried out by any standard SMTP component or portMTA’s C# API calls.
portMTA Deliverability Stack is exploiting its Virtual MTA (VMTA) technology to differentiate, prioritize and separate different message streams from each other thus guaranteeing a reliable and reputable deliverability.
As a real-life example, the stream of mass marketing messages must be separated from the transactional email streams since IP address pools of mass marketing messages usually have lower reputation than transactional IP addresses. In order to ensure deliverability, transactional messages and mass marketing messages must be separated from each other and should be sent from different VMTAs.
It is also possible to select a specific VMTA for different messaging templates created. If a template is mostly likely to be used for transactional messaging customization, you have to option to bind a transactional VMTA for that template. This ensures that messages customized by using this very template will be routed to the particular Virtual MTA bound to the corresponding template.
Message relay reports are also generated and sent back to your backend systems in raw format. portMTA stack has another message queue that stores the deliverability reports such as sent log, sent content, delivery details and recipient lists, bounce, subscriptions, open, clicked details and lists. These messages are generated by the signals retrieved from ESPs.
