Now, Next and Later — the order, not the dates
A roadmap is useful only if it's honest about its own uncertainty. This one is organised by priority order rather than ship dates, because for infrastructure the meaningful promise is the direction, not the fourteenth of the month — a receiving provider can change its rules in a quarter and reorder everyone's priorities overnight. It's grouped by theme with the reasoning behind each, and it's explicit that nothing here is a contractual commitment and the Later section is genuinely just "on our radar."
What we're working on, what's next, and what's only on the radar
A roadmap is useful only if it's honest about its own uncertainty. This one is organised as Now, Next and Later — the order things sit in, not the dates they'll ship on — because for infrastructure the meaningful promise is "this is the direction and the priority," not "this lands on the fourteenth." Anyone who's run email infrastructure knows that a receiving provider can change its rules in a quarter and reorder everyone's priorities overnight, so a roadmap pinned to calendar dates would be dishonest by the time you read it. What follows is grouped by theme, with the reasoning behind each, so you can see not just what we're building but why it earned a place ahead of the alternatives.
Two honest caveats first. This is not a contractual commitment — nothing here is a guarantee of delivery or timing, and for customers whose procurement needs a committed feature date, that's a conversation for a specific agreement, not a public page. And the further down this page an item sits, the less certain it is; the Later section is genuinely "on our radar," not a quiet promise. We'd rather under-state and ship than over-state and apologise.
Now — in active work
Deepening DANE/TLSA coverage. Transport-security enforcement through MTA-STS is in place; the active work is extending DANE/TLSA provisioning to make it a one-step option for every customer with DNSSEC-capable correspondents, rather than something arranged per domain. The theme behind it is that transport encryption should be enforced and verifiable by default, not opportunistic — particularly for the German and Dutch networks where DANE is the expected standard.
Faster authentication-anomaly alerting. The DMARC report pipeline now runs on a four-hour cycle; the current work is turning that data into proactive alerts so a managed customer hears from us about an alignment or placement anomaly before they notice it themselves. The theme is shifting from reporting what happened to flagging what's starting to happen — the difference between a dashboard and an early-warning system.
Sharpening the self-service diagnostic tools. The free DMARC, SPF, DKIM, blocklist, TLS-RPT and BIMI tools are being refined to explain results in plainer language and catch more of the subtle misconfigurations — the aligned-but-failing cases, the pathologically large source records — that the first version flagged only crudely. The theme is that a diagnostic tool should teach, not just report a pass or fail.
Next — committed direction, not yet started
Richer per-stream controls on Managed PowerMTA. Per-stream isolation exists; the next step is finer-grained control over throttling, queue policy and reputation reporting at the individual-stream level, so a customer running a dozen streams can tune each independently without an operator ticket. The theme is moving routine control from "ask us" to "do it yourself," while keeping the operator available for the genuinely hard cases.
Expanded regional options within the EU. Sweden and Germany are available now; the direction is additional EU data-centre locations for customers whose residency requirements are more specific than "in the EU." The theme is that data residency should be selectable to the country, not just the bloc — which matters increasingly as national regulators publish their own expectations on top of GDPR.
A second-generation webhook schema. The v2 webhook format carries structured authentication results; the next iteration broadens the event types and adds replay and verification features for customers building serious automation on top of delivery events. The theme is treating delivery data as a first-class API surface rather than a notification afterthought.
How priorities actually get set
The single biggest input to what moves from Later to Next is what customers tell the operator team they're struggling with — per-stream controls and faster alerting both started as recurring support conversations. If something here matters to you, or something you need isn't here at all, telling the operator team is the most direct way to influence the order. A roadmap shaped by real sending problems beats one shaped by what's fashionable.
Later — on the radar, no commitment
Predictive deliverability signals. The industry is moving toward predictive monitoring — surfacing a reputation problem from leading indicators before placement actually drops. It's a hard problem to do honestly rather than as a vanity score, which is exactly why it sits in Later: we'd rather not ship it than ship a number that misleads. The theme is genuine early warning, and the bar for shipping it is that it has to be more useful than the first-party provider tools, not just prettier.
Deeper BIMI and VMC support. BIMI validation exists as a tool; further out is making the whole path — from DMARC enforcement through VMC procurement to logo display — something we can shepherd end to end for customers who want the verified-logo outcome without becoming experts in the four gates it requires. The theme is owning the complexity so the customer doesn't have to.
Broader compliance-evidence tooling. As NIS2, DORA and national frameworks mature, the recurring customer need is evidence: the artefacts an auditor asks for, generated rather than assembled by hand. The radar item is tooling that turns the platform's existing logs and configurations into the specific evidence a given framework expects. The theme is reducing the compliance tax on the customer's side, which is increasingly the real cost of operating regulated email.
What's deliberately not on here
A roadmap is as defined by its omissions as its entries. There's no AI-feature line item for its own sake, no expansion outside the EU, and no move toward the per-message, usage-metered pricing the rest of the industry favours — because none of those serve the kind of customer this platform is built for, and adding them to look modern would be the feature-factory trap. The strongest thing a roadmap can communicate is a clear sense of what the product is choosing not to become, and for an EU-sovereign, flat-priced, operator-run platform, the discipline of staying that is itself a roadmap decision.
How this page is maintained
A roadmap with stale statuses is worse than no roadmap, so this one is reviewed on a regular cadence and items move between sections as reality moves them — including backward, when something in Next turns out harder than it looked or a receiving-provider change reshuffles the priorities. When that happens, the honest move is to say so here rather than quietly delete the item, because watching how a provider handles a slipped priority tells you more about them than watching the priorities that went smoothly. If you want to know where a specific item actually stands today, the operator team will give you the unvarnished version.