From a Deliverability Audit to a KumoMTA Migration: the Laposta Case
2026/04/16 by Yves-Marie Le Pors-Chauvel.

Your email infrastructure is running, emails are going out, campaigns are being sent and performance looks good… Or at least, that's what you think! But have you ever wondered what an outside perspective on your stack would reveal? That's exactly what Laposta did when they brought in Postmastery for a full infrastructure audit. And the least we can say… is that the consequences were very positive.
It all started with a Deliverability Audit
Laposta is a Dutch ESP managing newsletters for the majority of municipalities in the Netherlands, as well as major hospitals, non-profits, and e-commerce brands. When Postmastery began working with them, the initial objective was straightforward: conduct a deliverability audit and identify areas for improvement.
The analysis of SMTP logs, loaded and processed in the Delivery Analytics module of the Postmastery Console, highlighted several possible Postfix optimisations to notably improve performance.
Beyond the optimisations identified, it was the architecture itself that raised questions. The infrastructure had grown organically over the years, and certain features that had become essential for maintaining good deliverability, Bounce Rewrite, Suppression List, and FBL management, simply did not exist in Postfix.
Two options, one informed choice
At the end of the audit, two paths were available to Laposta:
- Optimise the existing Postfix infrastructure: a simple but incomplete solution.
- Migrate to a sender-oriented MTA: a more complex, but complete solution.
The second option was chosen. And one key factor made it particularly attractive: Laposta owned its IP addresses outright, they could be reused immediately, with no warmup phase required, and with the sending reputation built on those IPs fully preserved.
Why KumoMTA and not another solution?
Postmastery supports its clients across all major on-premise MTAs: PowerMTA, Halon, GreenArrow, Postfix, KumoMTA. Our approach is completely independent: each solution has its own technical characteristics and its own model. Our role is to help each sender identify the one that best matches their needs, both technical and contractual.
For Laposta, the choice landed on KumoMTA with Postmastery as their partner. Beyond the migration itself, the goal was also to enable Laposta's teams to build expertise on this new environment, supported by Postmastery's engineering and know-how from A to Z.
A 4-phase migration: structured, progressive and with zero service disruption
The migration took place over approximately six weeks, following a four-phase plan managed entirely by Postmastery.
Phase 1: Replication and foundation
The goal of this first phase was to fully replicate within KumoMTA everything the existing Postfix infrastructure was doing, with no regression and no surprises. On top of that, a first layer of native improvements was added: Traffic Shaping Automation, Bounce Rewrite and FBL management.
A custom development was also required: the OpenDKIM configuration relied on a MySQL database. Since KumoMTA does not natively support MySQL, a specific migration tool had to be developed to convert that database to SQLite and integrate it into the new configuration, while ensuring the Postfix infrastructure, still in production, remained fully functional.
Functional testing validated every element and immediately demonstrated improved performance as well as reduced resource requirements.
Phase 2: Ramp-up and optimisation
Traffic was progressively shifted to the first KumoMTA instance, up to 50% of total volume. This phase made it possible to fully leverage the platform's capabilities:
- Fine-tuned performance optimisation
- Development of a custom Lua script for a Suppression List
- Continuous Traffic Shaping adjustments based on data surfaced by the Postmastery Console
- Reduction in the number of IPs to optimise their reputation.
By the end of this phase, the traffic previously handled by 100 IPs and 100 Postfix instances was being managed by a single KumoMTA instance using just 8 IP addresses.
Phase 3: Infrastructure preparation on Laposta's side
In parallel, Laposta evolved its internal infrastructure to handle multiple KumoMTA instances simultaneously, including the implementation of an SMTP load balancer managing KumoMTA specific headers.
This phase was primarily driven by Laposta's own teams.
Phase 4: Second instance and finalisation
The second KumoMTA instance was deployed, configured and integrated in just a few hours.
The target architecture was reached: two KumoMTA instances, 16 IP addresses, all running on two VMs and fully monitored by the Postmastery Console.
The Postmastery Console: from the first log line to post-migration monitoring
The Postmastery Console played a central role at every stage of the project.
It provided the framework for the initial audit: Postfix infrastructure SMTP logs were streamed in real time into the Delivery Analytics module, making it possible to visualise and precisely analyse every anomaly. It was on this basis that recommendations were built and the two options presented to Laposta.
During the migration, the Postmastery Console enabled real-time comparison of the old and new infrastructure's performance: sending speed, bounce rates, deferral rates and bounce causes. It was from this data that each phase could be validated and the configuration of the new instances adjusted accordingly.
Since the migration, Laposta's team reviews the Postmastery Console every week, in direct contact with Postmastery's teams, to track per-campaign performance and detect anomalies.
Where manually sifting through hundreds of thousands of log lines was once the only option, everything is now accessible at a glance.
Results
- Average delivery time cut in half
- IP volume reduced by over 90%
- Infrastructure consolidated onto 2 VMs
- Infrastructure costs reduced by 33%
- Zero service interruption, zero IP changes
The most important result remains structural: Laposta now has a solid, fully controlled and monitored infrastructure, built to grow and to be managed proactively.
Key takeaways from this project
Every sender has their own infrastructure, history and constraints. Our role at Postmastery is not to sell a ready-made solution, it's to understand precisely where you stand, identify what you actually need and support you all the way to results.
It always starts with an objective analysis of the current state, in order to recommend the solution best suited to your real needs, not to market trends, with structured support and the right measurement tools at every step.
If you have questions about your current email infrastructure, start with an audit. And discover how the Postmastery Console and our KumoMTA services can help you go further.
This project was also the subject of a case study published by our partner KumoMTA. Both articles cover the same project and reflect our close collaboration. Read the KumoMTA case study
There are many more interesting blogs by category for you to read.
Categories
Featured