Mobicentrum: where Mailflow was built

Short answer

Mobicentrum is an email sending operation based in Tanger-Tetouan-Al Hoceima, Morocco. From September 2023 to June 2025, Cordytech built and ran the software side of that operation: applications and custom scripts across their sending workflow, and then Mailflow, written as a custom application for their teams and later turned into a Cordytech product. Their analysts also worked in Revline for sponsor revenue and Storebridge for storage, and we trained the whole team through the move to PowerMTA 5. The engagement ran one year and ten months and is complete.

Mailflow was born on this engagement. We did not design a product and then look for someone to run it. We were the ones doing the work — provisioning, signing, warming, watching listings — and we wrote the application because we were tired of doing half of it twice.

The engagement is finished, and we say so in the past tense on purpose. Work you can describe from first day to last hides nothing behind the word "ongoing".

01 What did Cordytech actually do for Mobicentrum?

We were the software side of their sending operation — not an agency beside it, but the people who wrote, deployed and fixed what their teams used daily. That came in four parts:

Applications and custom scripts across the sending operation, written against how their teams worked rather than how a platform assumed they would.
Mailflow, built as a custom application for them: server and IP provisioning, DKIM, SPF and reverse DNS, PowerMTA install and VMTA configuration, seed-driven warm-up, blacklist monitoring, per-ISP statistics.
Two of our other applications in daily use by their analysts — Revline for sponsor and affiliate revenue, Storebridge for object storage.
Training the whole team on PowerMTA 5: the migration itself and the working practices around it.

The order matters: scripts first, application second. Had we opened a repository called Mailflow on day one, it would have been the wrong application.

02 Why did the work start as scripts?

Because you cannot design a control plane for a job you have not done by hand. Every screen in Mailflow exists because someone ran the equivalent command at two in the morning and wanted a button.

Job on the floor	How we handled it first	What Mailflow ended up owning
New server, fresh IP block	A shell script per provider, run from a laptop	Provider API call, instance created, addresses pulled back and mapped
DKIM keys and selectors	Generate on one box, copy by hand to the others	Keypair per domain, shipped to every signing node, record published at the registrar
SPF, forward and reverse DNS	Registrar and provider consoles, one record at a time	Records written through the provider API as part of the build
PowerMTA install and VMTA blocks	Config edited on the node over SSH	Templated VMTA definitions pushed to every node from one screen
IP warm-up	A ramp plan agreed in advance and followed	Seed campaigns through one named IP, their statistics stored apart from campaign data
Blacklist checks	Manual lookups whenever something felt wrong	Scheduled checks per address across the major DNSBLs
Bounce and complaint handling	Accounting files pulled and read by eye	Parsed on each node into delivery, bounce and complaint figures per ISP

Read the middle column again. None of it is unreasonable; it is how most sending operations run. It holds until a provider hands you a block of fresh addresses that each need DNS, reverse DNS, a keypair, a VMTA definition and a ramp. Then it stops being slow and starts being wrong.

03 Why build a new application instead of buying one?

There are products that do pieces of this. We looked. They all abstract away the layer you are accountable for: a dashboard on top, and underneath it a mail server whose configuration you cannot see and whose reputation is still your name on the PTR record.

We take a position here that not everyone shares. Do not build internal tooling until you have done the job by hand long enough to know which parts are merely boring and which are dangerous. Boring work can wait for a script. Dangerous work — a DKIM selector never copied to the second server, an IP added to a live pool before it was warmed — needs the application to make the mistake impossible rather than merely visible.

Mailflow got built in that order: provisioning and DNS first, as the most repeated steps, warm-up and statistics later, once we had watched enough of what the seeds and the accounting logs said to trust a schema with it.

04 Where did Revline and Storebridge fit in?

Sending is half of an operation like this. The other half is knowing what it earned and where the files ended up.

Application	The question it answered	Where its data came from
Mailflow	Is the mail leaving, authenticating and landing?	PowerMTA accounting logs, seed placement, DNSBL checks, feedback loops
Revline	What did yesterday earn, and from which sponsor?	Affiliate and sponsor network APIs pulled into one live dashboard
Storebridge	Where does a file live, and on whose storage?	S3, Google Cloud Storage, Azure Blob, Hetzner, R2 and B2

Sponsor revenue arrives split across networks with their own portals, their own definitions of a conversion and their own reporting delays; one view with alerts on a phone turns a morning of tab-switching into a glance. Storebridge did the same for object storage — creatives, suppression files and exports addressed from one place instead of six consoles. Neither was sold in as a platform; they were used because the analysis was easier with them.

05 What did the move to PowerMTA 5 involve?

A migration and a re-education, and the second one took longer. We trained the whole team on the new version — not only the upgrade path, but the habits that keep a PowerMTA fleet honest afterwards.

Area	What the migration touched	What the team was trained to do
Configuration	Rewritten per node rather than carried forward unread	Treat the config file as the source of truth, not the wiki page about it
VMTAs and pools	Pool definitions rebuilt against the current IP inventory	Change a VMTA in the template, never by hand on one box
Accounting and logs	Every consumer of the accounting files re-checked against the new install	Verify a statistic end to end before trusting a dashboard
Queue operations	Queue inspection and control re-learned on the new build	Diagnose a stuck queue by domain before touching the whole node
Authentication and TLS	DKIM signing and TLS re-verified on every node after upgrade	Treat authentication as a per-node fact, checked rather than assumed

Training is the part clients underrate, and the part that decides whether an upgrade holds. An operator who understands why a pool is throttled will pause it; one who does not will raise the limit and burn the range.

06 What does a finished engagement leave behind?

Two things, going in opposite directions.

Mobicentrum kept an operation whose daily work is a screen instead of a runbook, a team trained on the version of PowerMTA they actually run, and applications shaped to how they work. In June 2025 it was done.

We kept the tool. Mailflow is now a Cordytech product and the largest thing we build; everything sharp about it was sharpened here — the streaming install log, seed statistics kept apart from campaign data, the per-node view of authentication. Our other engagements have different shapes; the EMG rollout was run largely at a distance. Mobicentrum is the one where the tooling was invented under load, by the people carrying the load.

If a column in the tables above describes your week, tell us what your operation looks like now. We will say which parts are worth an application and which are honestly still a script.