EMG
EMG is an email sending operation based in Tanger-Tetouan-Al Hoceima, Morocco. We have run its sending infrastructure since January 2025, delivered remotely from the first day. Mailflow provisions EMG's servers and IP addresses, automates DKIM, SPF and reverse DNS, installs and configures PowerMTA, warms new addresses against seed lists, and reports blacklist status alongside per-ISP delivery, bounce and complaint statistics. Revline reads their sponsor and affiliate revenue, Storebridge holds their storage, and a long tail of custom applications and scripts covers the rest. We also trained the whole team on PowerMTA 5.
Every infrastructure engagement we had run before EMG started in a room. Someone opens a laptop, someone reads an IP range off a provider dashboard, and the first week happens at one screen. Comfortable to begin, bad to keep: the knowledge it produces lives in whoever was standing there.
EMG has been remote since January 2025. No on-site week to bootstrap it, so no option of fixing things by leaning over someone's terminal. That turned out to be the useful part. A remote engagement forces the discipline an on-site one lets you skip.
01 What does Cordytech run for EMG?
The sending layer end to end, plus the applications either side of it. Mailflow is the control plane. It creates the servers, pulls their public addresses, sets reverse DNS, publishes the matching forward records, generates DKIM keypairs and ships them to every node that signs with them, installs PowerMTA and writes the VMTA blocks, then warms addresses as seed campaigns. Once mail is moving it folds the accounting logs off every node into per-ISP delivery, bounce and complaint numbers, and checks the ranges against the DNSBLs on a schedule.
None of that is unusual work. What is unusual is that no step of it has required us to be in the same building as EMG — or, most days, in the same conversation.
02 Why does remote delivery need different habits?
Because every shortcut an on-site engagement permits leaves no record. In a room, "why is this box not sending" gets answered by a person scrolling their own shell history. That answer is correct, fast, and unavailable to anyone else — including the same person four months later.
Remote, none of those moves exist. You cannot watch a terminal you are not sitting at. The work has to move somewhere two people in different cities can both look, and that constraint improves it rather than taxing it.
| On-site habit | Why it survives in a room | What it becomes remotely |
|---|---|---|
| Install by hand over SSH | Someone watches the scrollback | A run of named steps streaming its log into the browser, failing with the command that killed it |
| VMTA layout in one engineer's head | You can ask them | Config generated from stored server, IP and domain records |
| Paste the DKIM key onto the second box | Thirty seconds, and it works | Keypair stored per domain, pushed to every signing node, published at DNS in one operation |
| Trade screenshots of last night's numbers | Everyone saw the same screen | Per-ISP statistics both sides read live |
| Explain the ramp verbally each week | Repeat it as needed | Seed results stored apart from campaign statistics, so one bad IP shows on its own |
The right-hand column describes how infrastructure should be run whether or not anyone is remote. Distance did not invent those requirements. It removed the option of ignoring them.
03 Where does the configuration live?
In the application, not in an SSH history. This is the position we take hardest and the one that makes the rest possible.
A sending stack accumulates state in the worst possible places. The IP block sits in a provider console, the PTR record in a different console, the DKIM selector in a DNS zone, the VMTA that uses all three in a file on a host — and the mapping between them in someone's memory. On site that spread is survivable, because the memory is in the room. Remote, it is the whole problem.
So Mailflow holds the mapping. A server is a record with its addresses attached; an address carries its reverse DNS and warm-up state; a domain carries its keypair and the nodes it signs on; a VMTA is generated from those relationships rather than typed. When EMG adds a fresh block of addresses, the same sequence runs, and the result is inspectable by anyone with an account rather than anyone with a key.
The install log is the handover
The most useful artefact in a remote engagement is a provisioning run you can watch stream. It answers the question that eats the most hours — which of forty commands failed on a box nobody can see — without a call, and it lets whoever did not build the server read what was done to it.
04 How do you train a team on PowerMTA 5 without being there?
By training against their own running system, and by treating the trainer leaving the call as the test. We trained EMG's whole team on PowerMTA 5, and the standard was simple: after each session, the team does the thing alone, on their own nodes, while we touch nothing.
| Area | What the team does unaided | Where it lives afterwards |
|---|---|---|
| VMTA structure | Read a pool; know which IP and domain a queue is bound to | Generated config, matched to server and address records |
| Queue control | Pause, resume and inspect a queue mid-send | Queue actions in the app, not typed on the host |
| Bounce classification | Tell a hard bounce from a transient deferral, and act differently | Accounting logs parsed per node into per-ISP statistics |
| Feedback loops | Recognise a complaint spike and stop the cause | FBL and bounce events tied to the campaign that produced them |
| Authentication failures | Diagnose a signature the receiver distrusts | DKIM, SPF and rDNS state stored per domain and address |
| Warm-up decisions | Hold or advance an address on the evidence | Seed results, stored apart from campaign statistics |
The right-hand column matters more than the middle one. Training that lives only in people decays the moment someone leaves, and a remote trainer cannot top it up by walking past a desk. Training that lands in a system the team uses daily keeps teaching after the call ends.
05 What did we build around the sending stack?
The parts no product ships with. Revline pulls EMG's sponsor and affiliate network APIs into one live revenue view, so the commercial side is read off the same kind of surface as the technical side. Storebridge manages their object storage across providers. Then the long tail: custom applications and scripts fitted to how EMG actually works rather than how a vendor assumed they would.
That long tail is usually the difference between a platform a team adopts and one it works around. Remote delivery makes it more important, not less — a script that matches the real workflow removes a conversation, and conversations across a distance are expensive.
06 What does the EMG engagement prove?
That the programme travels. Mobicentrum is where this tooling was invented under real load, between September 2023 and June 2025. Relentia is where it deepened, running since January 2024. EMG is the third case and the different one: the same infrastructure, the same warm-up discipline, the same PowerMTA training, delivered without ever being in the room.
We would now argue the remote version is the better one. Not cheaper — better. It leaves an install log instead of a memory, an application instead of a shell history, one set of per-ISP numbers instead of two opinions, and a team that can run the thing when the engineer who built it is offline. An on-site engagement can produce all that too. It just does not have to.
If you run sending infrastructure and the honest answer to "where does the config live" is a person, fix that first. Talk to us and we will show you what the EMG setup looks like from the inside.
Run your sending on the same stack
The engineering we run for EMG is the same we offer to any team accountable for where its mail lands. Tell us what you are sending.