Email infrastructure, seven services.

The seven services in our catalogue are not a feature menu. They are seven different categories of operational work that email infrastructure customers typically need, packaged so that customers can buy the categories they need without buying the categories they do not. A small transactional sender on five hundred thousand messages a month does not need IP warmup as a separate service; warmup happens inside the SMTP relay tier. A regulated-financial customer migrating from a US-domiciled vendor needs IP warmup, SPF/DMARC audit, and offshore dedicated combined into a single engagement. The service catalogue is built around the second pattern, with the smaller-scale services available standalone for customers whose situation does not justify the full bundle.

What "managed" actually means in this context is worth being explicit about. Most ESP marketing language uses managed to mean "we run the software so you do not have to deploy it". That is correct but incomplete. The harder operational work in email infrastructure is not the deployment. It is the ongoing reputation management, the per-ISP tuning, the bounce-handling rule maintenance, the DKIM key rotation, the DMARC aggregate-report triage, the responding-to-complaints work that keeps a sender out of trouble with mailbox providers. Our seven services collectively cover this work. The customer's engineering team builds the application that submits messages to our infrastructure. Our engineering team handles the work between the application's submission and the recipient's inbox.

The pricing structure reflects this division. Each service is priced for the work our engineering team does, not for software licences passed through with margin. The PowerMTA hosting price includes the Port25 licensing cost as a pass-through with our margin on the operations work; the KumoMTA hosting price does not include software licensing because KumoMTA is open source. The price difference between the two services is not a margin difference; it is a software-cost difference passed through honestly. The service catalogue exists in this form because it is the structure we wish vendors had when we were customers ourselves.

Relay-only pattern. The seven services compose into a small number of recurring patterns. About half our customer base uses the SMTP relay tier alone, with no other services. These are senders below five million messages a month whose deliverability and compliance profile is straightforward: transactional sending with a single domain, recipients concentrated in mainstream mailbox providers, no banking-grade compliance overlay. The relay tier handles SPF, DKIM, DMARC configuration, bounce processing, and per-ISP throttling without separate engagement on those services. Customers in this profile typically stay on the same configuration for years.

Dedicated-MTA bundle. The next pattern is the dedicated-MTA bundle. Customers whose volume is above five million messages a month, or whose deliverability requirements justify dedicated IPs, typically buy PowerMTA Hosting or KumoMTA Hosting alongside Offshore Dedicated. The PowerMTA-or-KumoMTA decision turns on configuration philosophy and licensing model, with a separate compare page that walks through the trade-offs. The Offshore Dedicated component is the bare-metal infrastructure these MTA services run on; we do not run dedicated MTAs on shared virtualisation. About thirty percent of our customer base operates in this configuration, and it is the most common shape of regulated-industry engagements.

Migration pattern. The migration pattern is the third recurring shape. Customers moving off SendGrid or Mailgun or Amazon SES typically buy the destination MTA service combined with IP Warmup, SPF/DMARC Audit, and one of the Compliance services. The IP Warmup and SPF/DMARC Audit services are designed to be bought standalone for migrations even when the customer's eventual destination is not us; we have run a small number of audits where the customer used the audit output to remain on their existing provider with corrected configuration. The migration guide we publish describes the technical sequence in detail.

Auth-suite pattern. The auth-suite pattern is the fourth recurring shape. Email Authentication Suite combines DMARC monitoring, MTA-STS deployment, BIMI/VMC issuance, and TLS-RPT configuration into a single engagement. Customers who buy this service are typically not buying our MTA hosting; they are running their own infrastructure and want the authentication layer operated by specialists. The pricing reflects this — the Authentication Suite is priced standalone rather than as an add-on, and we have a small number of customers who use only this service across their otherwise self-managed email stack.

The reputation work. The reputation work is the daily ongoing operation that customers see least and benefit from most. Mailbox provider reputation is a moving target. Gmail's spam classifier updates continuously; Yahoo's bulk-sender thresholds tighten without published warning; Microsoft's SmartScreen produces unexplained sudden deferrals on senders that were clean the previous week. Our engineering team monitors per-customer postmaster signals across the major mailbox providers, identifies degradation early, and runs the remediation work (warming a fresh IP, splitting traffic across additional IPs, pausing problematic segments, adjusting sending pace per ISP) before the customer's marketing team notices the inbox-placement drop in their own analytics. This work is mostly invisible. It is also the single largest reason customers stay with us across years.

Bounce-handling and complaint loops. Bounce processing sounds straightforward and is not. The SMTP response code at the moment of delivery is one input; the postmaster feedback loop response from Gmail or Yahoo or Outlook is another; the abuse-complaint feedback from a recipient hitting "report spam" is a third; the Outlook SmartScreen quarantine signal that does not produce an SMTP rejection is a fourth. Our infrastructure normalises these signals into a single bounce-classification taxonomy with retry pacing rules per ISP, hard-bounce removal at the message-acceptance layer, and complaint handling that flags the originating list segment for review rather than silently dropping the addresses. The customer's application sees a clean bounce/complaint webhook. The complexity of the upstream signal correlation is on our side.

DKIM rotation and TLS hygiene. DKIM keys need rotation. The recommended cadence in 2026 is annually for 2048-bit keys and at the moment of any team turnover that affected key custody. Most customers do not perform this rotation because the procedure is fiddly enough to surface bugs in the templating-service integrations described in our migration guide. We perform rotation on an annual schedule per customer, with a seven-day overlap window and customer-side notification before each rotation. TLS certificates on customer-facing endpoints renew automatically through ACME; our infrastructure handles renewal without customer involvement, and we publish the certificate fingerprint history to support customer audit requirements where they exist.

Compliance correspondence. Regulatory correspondence sits between us and the customer's compliance team. The correspondence we handle directly: Information Commissioner correspondence on the GDPR processor side; CSIRT.RO incident reporting under NIS2; DMARC aggregate-report ingestion and analysis; sub-processor disclosure updates; security-questionnaire responses on standardised CAIQ-Lite or SIG-Lite templates. The correspondence the customer's compliance team handles directly: their own supervisory authority correspondence; their internal records of processing activities; their data subject rights requests where the customer is the controller and we are the processor. The boundary is documented in the DPA and clarified during the onboarding call. Customers occasionally try to push compliance work onto us that is properly theirs; we decline politely and explain why.

What we explicitly do not provide. Application-level email composition: we do not write the customer's transactional templates or marketing copy. Subscriber list management: we do not host the customer's subscriber database or the consent records associated with it. Engagement analytics beyond delivery: open rates, click rates, conversion attribution belong to the customer's analytics platform. Content moderation: we do not screen the customer's outbound content for compliance with their own marketing policy. Legal advice: the customer's general counsel is the right interface for the legal questions, with our DPO providing technical input the counsel needs. Each of these boundaries exists because the work belongs to the customer's domain expertise rather than ours, and pretending otherwise produces engagements that fail when the customer's actual subject-matter expert needs to step back into the loop.