Mailflow

Sending a million emails is not hard. Sending a million emails that arrive is an infrastructure problem, and it fails in layers — a PTR record nobody set, a DKIM selector sitting on the wrong server, a VMTA pool pointed at an address that got listed on Spamhaus overnight. Each of those is a small mistake on its own. Together they are the difference between a delivered campaign and a domain that nobody accepts mail from.

Most sending operations hold this together with a spreadsheet of IPs, a folder of SSH keys, and one person who remembers which box the config lives on. That survives right up until a provider hands you a fresh block of addresses, and every one of them needs DNS, reverse DNS, a DKIM keypair, a VMTA definition, and a ramp plan. We built Mailflow because we ran that manual loop for years and got tired of the ways it broke.

01 What does Mailflow actually replace?

It replaces four things a sending team normally holds together by hand: server builds, DNS, PowerMTA configuration, and reporting. Each of those has its own tooling somewhere on the internet. None of them talk to each other, which is exactly the problem — an IP is only useful when compute, DNS, authentication, and transport agree about it.

A server build in Mailflow is a script, not a runbook. The app connects over SSH, detects the distribution, refuses anything it does not support, and then runs a provisioning script that reports each step back over an API callback so the install log streams into the browser while it happens. Hostname, base packages, PHP, the tracking app, PowerMTA 5, IMAP, the proxy, Certbot certificates, firewall rules — each is a named step that either completes or fails loudly with the command that killed it.

That last detail matters more than it sounds. Half of infrastructure work is not doing the thing; it is finding out which of forty commands failed on a box you cannot see.

02 How does it provision servers, IPs and DNS?

Through provider APIs, one layer at a time, with the app holding the mapping between them. You pick a cloud account, Mailflow creates the instance, pulls its public addresses, sets reverse DNS on each one, publishes the matching forward records at your registrar, and hands the finished node to the installer.

Why DKIM and rDNS get their own machinery

Because they are the two records that fail silently. A missing SPF entry usually announces itself; a DKIM key that was generated on server A and never shared with server B produces mail that is signed with a selector the DNS does not know about, and the receiving side simply distrusts it. Mailflow generates the keypair, stores it against the domain, ships it to every server that will sign with it, and publishes the record through the domain provider in the same operation.

03 How does it warm a new IP?

With seed lists, not a printed calendar. A warm-up in Mailflow is a seed campaign: a list of mailboxes you control across the providers you care about, sent through one specific IP with its own throughput parameters — total volume, how much of it each address carries, the pause between addresses, the pause between messages, and how often a seed is interleaved into the stream.

We take a position here that not everyone agrees with. A fixed day-by-day ramp table is a starting hypothesis, not a plan. The ramp is driven by what the seeds report back, and the seed statistics are stored separately from campaign statistics precisely so a bad day on one IP is visible without being diluted by everything else you sent. If deliveries fall and soft bounces climb on one provider, that IP holds where it is until the numbers recover.

Every campaign, drop and warm-up also carries a bounce limit. The helper application running on each sending node calls back to the platform to check accumulated hard bounces against that limit, which is the difference between noticing a bad list on Tuesday and noticing it after you have burned the address range.

04 How does a campaign actually leave the building?

Through one of three transports, chosen per campaign, in either a serial or a parallel form. Laravel builds the recipient set, the templates, and the rotation state, writes a config, and spawns a compiled binary that does the sending.

The PowerMTA submission verbs are not standard SMTP, so a stock mail library is no help — the client is written by hand against the wire format, including CRAM-MD5 authentication, buffered command writes, and the multi-line reply parsing that decides whether a batch succeeded. That sender started life as a .NET binary and was rewritten in Go: a static, cross-compiled executable that talks to Postgres directly instead of shelling back into the application for every progress update.

On the queue side, a campaign fans out into a Redis-backed batch with one job per VMTA and a staggered delay per IP, so the ramp is enforced by the scheduler rather than by a loop somewhere sleeping.

05 How do you know deliverability is holding?

From four signals that do not depend on the sender's own optimism. Mailflow collects all of them continuously and joins them to the same campaign, IP and domain identifiers.

The accounting files are parsed on each server, folded down, and written into a monthly-partitioned statistics table keyed by campaign, ISP, list, server, IP, domain, offer, sender, subject, creative and VMTA. That granularity is the whole point: "which subject line hurt that IP at that provider" becomes a query instead of an argument. Suppression files, opt-outs and bounce-driven type changes feed back into the address data, so the next send is smaller and cleaner rather than identical.

Everything sits behind teams, roles and per-ISP permissions, because a platform this sharp should not let every operator touch every address range.

06 Who builds Mailflow, and how do you get it?

Cordytech builds and runs it. It started as a custom application for one client and became the platform the rest of our work leans on: it was built during our engagement with Mobicentrum, and it now runs the sending infrastructure at Relentia and EMG. The platform exists because we were the ones doing the manual work, and we refused to do it by hand a second time.

It is also the reference build for how we approach multi-tenant SaaS product engineering — provider abstractions behind a factory, long-running work in queues, an install log you can watch, and a compiled engine where PHP would have been the wrong tool. The other apps in the portfolio inherit those habits at smaller scale.

There is no self-serve sign-up, and there will not be one. Sending infrastructure is configured against real domains, real address ranges and real provider accounts, so every rollout starts with a walkthrough against your setup. Talk to us about a demo and we will show it running, not screenshotted.