Relentia: per-ISP email infrastructure

Short answer

Relentia is an email marketing company in Tanger-Tetouan-Al Hoceima, Morocco. We have run its sending infrastructure since January 2024 — two years and seven months of continuous work, and the deepest of our engagements. Cordytech operates Relentia's servers, addresses and PowerMTA configuration through Mailflow, analyses sponsor and affiliate revenue through Revline, holds its files in Storebridge, and trained the whole team on PowerMTA 5. We also built three per-ISP reporting applications and a private tool that creates the seed mailboxes their placement testing depends on.

Most outside engineering work has an end date. You arrive, you build what was scoped, you hand over a document, and everything you learned about how the operation behaves leaves the building with you.

Relentia is the other case. We started in January 2024 with the same base we bring to any sending operation, and what runs there today is not that base. It is that base plus two and a half years of things we only found out by operating it: three separate reporting applications, because three mailbox providers do not agree on what a report is, and an internal tool that exists because a seed list is worth nothing without the mailboxes behind it.

01 What does Cordytech run for Relentia?

Six things, and they are not equally interesting. The first three are the base any sending operation needs. The last three exist only because this engagement kept going.

Mailflow runs the sending estate: server and IP provisioning, DKIM keys and selectors, SPF, reverse DNS, PowerMTA installs, VMTA definitions, warm-up runs driven by seeds, blacklist checks, suppression. Revline pulls the sponsor and affiliate network APIs into one revenue view, so the commercial side of a send is visible the same day as the technical side. Storebridge holds the files.

Layer	What runs it	The question it answers
Servers, IPs, DNS, PowerMTA	Mailflow	Is the estate configured the way we think it is?
Sponsor and affiliate revenue	Revline	Which offer, on which network, actually paid this week?
Exports, archives, creative assets	Storebridge	Where does the data sit, and what does it cost?
Placement at Yahoo, Outlook, Gmail	Three custom reporting applications	Which provider is quietly holding our mail back?
Seed mailboxes	Creator, an internal application	Do we still own a test panel that reflects the real inbox?
Everything else	A long tail of custom scripts	The jobs too specific to belong in any product

The bottom half of that table is the part a three-month project never reaches.

02 Why does per-ISP reporting need one application per ISP?

Because a single aggregate delivery number is the most reassuring lie in email. Blend the providers together and the total looks healthy right up to the moment you find that one of them is deferring most of what you hand it — and that it holds the largest share of the list. The average absorbs the problem. The provider does not.

Each provider also hands a sender a different surface. Not a different skin over the same data — a different shape, keyed on different things, reporting on things the others do not report on at all. One generic dashboard means picking the lowest common denominator across all three and throwing away the signal each one is actually good at. So Relentia has three reporting applications, one per provider.

Provider	What it exposes to a sender	What we read from it
Yahoo	The thinnest surface: a complaint feedback loop keyed on the DKIM signing domain, plus a sender support path. No self-serve reputation dashboard.	Complaint volume per signing domain, deferral and rejection text from the PowerMTA logs, and seed placement — there is no dashboard to fall back on.
Outlook	IP-centric. Per-address data: sampled volumes, complaint-rate bands, spam-trap hits, filter verdicts, plus a complaint feed for registered addresses.	Whether the problem is one address or the whole range — the difference between pulling an IP from rotation and stopping a campaign.
Gmail	Domain-centric. Reputation for the sending domain and the IP, spam-rate reporting, SPF, DKIM and DMARC pass rates, TLS, delivery-error breakdowns.	Whether reputation is attached to the domain or the address, and whether authentication passes at the rate we think it does.

A Yahoo problem and a Gmail problem are diagnosed from different evidence, so the applications are built differently. The Yahoo one leans on complaint attribution and on our own transport logs, because Yahoo tells you little directly. The Outlook one is organised around the IP address, Microsoft's unit of judgement. The Gmail one is organised around the domain, Google's.

We hold a position here: reporting should be shaped like the thing being reported on. A dashboard that flattens three providers into one row of green numbers is not simpler, it is less true.

03 What is Creator, and why build a tool just for seed mailboxes?

Creator is a private, internal application that creates the mailbox accounts used as seed accounts for seed-list testing. It exists because a seed panel is inventory, and inventory has to be maintained.

Seed testing only works if you own the mailboxes. You send through a specific IP and VMTA to addresses you control at each provider, then read those mailboxes and record where the message landed. It is the only measurement that reports placement rather than acceptance — PowerMTA logging a 250 tells you the provider took the message, not what it did with it next.

The catch is the panel itself. Mailboxes get created, go dormant, get locked, need re-verification and credential rotation, and need to be readable programmatically — over IMAP with an app password where the provider still allows one, over OAuth where it does not. Doing that by hand across three providers is the bottleneck in the measurement loop, and a bottleneck in measurement quietly becomes a gap in measurement. So it got its own tool: create the account, record the credentials against the panel, keep the inventory current, and let the seed campaigns in Mailflow draw from a list that is actually alive.

Owning the test panel is the point. A borrowed or rented seed list tells you where somebody else's mail landed.

04 What changed when the whole team learned PowerMTA 5?

The escalation path got shorter. We trained Relentia's team on PowerMTA 5 rather than keeping the configuration behind us, so a deferral at one provider is now read by the person watching the queue instead of being forwarded to us as a screenshot.

Most deliverability damage happens in the hours between a symptom appearing and someone who understands VMTAs looking at it. Teaching the operators to read the accounting logs and know which knob to turn removes that gap. It also changed what we get asked: the questions are about design now, not syntax.

05 What does a continuing engagement buy that a project cannot?

Compounding. Every custom piece above came from an observation we could only have made by running the system through a full cycle of good and bad weeks.

The per-ISP applications exist because we watched aggregate reporting hide a single-provider problem. Creator exists because we felt the seed panel decay. The custom scripts exist because a repeated manual step only announces itself after the thirtieth time. None of that arrives in a scoping document. It arrives in month nine.

Our other engagements answer different questions. The work with Mobicentrum was the founding one, where Mailflow itself was designed. Relentia is the case for staying.

06 How does an engagement like this start?

Small, and against your real setup. Nobody signs up for two and a half years on day one — Relentia did not. It began with sending infrastructure that needed provisioning, authentication and honest measurement, and the rest was built as the operation told us what it was missing.

If you send at volume and your reporting is one averaged number, that is usually the first thing worth fixing. Tell us what you are sending and where it is landing and we will look at the actual logs.