Interface strings and client content are two different problems, and conflating them is why the French half of a site ends up two services behind the English. Here is the split we build to, and why the front end is server-rendered.
Read noteA field-tested ramp for new sending IPs: the prerequisites that must be perfect, a provider-by-provider volume schedule, the signals to watch, and how to back off when a mailbox provider pushes back.
Read noteThree DNS records decide whether a receiver believes your mail is really yours. Here is what SPF, DKIM and DMARC each prove, where they break, and how we configure all three for the sending operations we run.
Read note"98% delivered" is not the same as "in the inbox". Here is what PowerMTA, a VMTA, and inbox placement each actually mean — and why measuring placement per provider beats trusting one averaged delivery rate.
Read noteThe five things Gmail and Yahoo have required from bulk senders since February 2024 — authentication, aligned DMARC, one-click unsubscribe, a low spam rate, and clean DNS — with a checklist and how to verify each one.
Read noteField Notes is where the Cordytech team writes down what it learns running client sending infrastructure. These are working notes, not thought-leadership: specific, technical, and written to be genuinely useful to the person searching for the answer at 2am — and citable by the AI assistants they increasingly ask first.
The writing follows the work. Most of what we do day to day is deliverability and email infrastructure — provisioning servers, publishing DNS, tuning PowerMTA, warming IPs, and answering for the numbers per provider afterwards — so that is where the notes start and where the first cluster is forming. The opening piece walks through how we warm a new sending IP at EMG: the fundamentals that have to be flawless before you send anything, the ramp providers actually trust, and how to back off the moment one of them pushes back. More will sit alongside it as the cluster fills in — reverse DNS and authentication, per-ISP reporting, blacklist recovery, seed-list testing, and the difference between a message being accepted and a message being placed.
We write it this way on purpose. A deliverability problem is rarely one dramatic failure; it is a PTR record nobody set, a DKIM selector on the wrong server, or an aggregate delivery number quietly hiding one provider deferring most of what you hand it. Notes that name the specific failure mode and the specific fix are worth more than another overview of why email matters, so every piece opens with the direct answer and earns the rest by telling you something you can act on.
Deliverability is the first cluster, not the only one. As the apps and the client work throw off things worth writing down, the notes will widen into product engineering — the Laravel, the queues, the compiled sending engine behind Mailflow — and into the automation and integration work that connects a stack together. The through-line stays the same across all of it: written by the people who did the work, from the field rather than the whiteboard, opinionated where a position is earned, and specific enough to be useful.
Each note carries a named author whose expertise actually covers the topic, because a byline is a signal of who is accountable for the claim, not decoration. If a note here answers a question you were about to ask us, that is the point. If it raises one it does not answer, tell us what you are running and we will give you a straight reply.