Platform architecture · KumoMTA + PowerMTA · per-tenant isolation · Lua customization

Platform architecture for marketing engineers and MarTech architects. What runs underneath.

This page is the technical deep-dive for the EMP marketing platform. The companion page at /services/email-marketing-platform.html covers the marketing-side proposition (verified Latin B2B audiences, Latin mailbox tuning, jurisdiction); this page covers the architecture-side proposition (dual MTA engine, per-tenant egress pools, Panama Scorer pre-send pipeline, observability stack, Lua policy customization). The audience profile here is different: marketing engineers, MarTech architects, RevOps platforms managers, SREs responsible for email infrastructure, CTOs and VPs of Engineering evaluating build-vs-buy. The questions answered here are the questions that come up in the technical review meeting after marketing has approved the fit verdict and procurement is the only blocker remaining. EMP runs KumoMTA (Rust + Lua, Apache 2 license, deployed since 2024) as the modern primary engine plus PowerMTA (commercial engine since 2010) as backup and legacy configuration target. Per-tenant isolation operates at three architectural layers (IP, throughput, reputation). Panama Scorer integrates as a synchronous pre-send hook with under 800 ms median decision latency on every campaign. Observability spans dashboards, Prometheus and Datadog metrics export, and message-level forensic logs in zstd-compressed JSONL with 12 month retention. Custom Lua policies on Enterprise tier with EMP engineering review. SOC 2 Type II report and ISO 27001 alignment documentation available under NDA.

Read architecture Integration patterns
MTA engines deployed2KumoMTA + PowerMTA
Scorer decision latency<800msmedian pre-send eval
Forensic log retention12mozstd JSONL segments
Metric series exported240+Prometheus + Datadog
Architecture overview · message lifecycle from injection to MX handoff

The message lifecycle. Injection to MX, with control points marked.

The diagram below shows the full message lifecycle from client injection (SMTP submission, HTTP API, or scheduled automation) through Panama Scorer evaluation, queue assignment, traffic shaping, and finally egress to the destination MX. Each control point exposes operational levers that distinguish a managed platform from a raw SMTP relay. The lifecycle described here is the same regardless of tier; the differences across tiers are in IP allocation depth, Lua policy customization scope, and observability granularity.

STAGE 1 Injection SMTP / HTTP / sched. STAGE 2 Panama Scorer™ <800ms · 8 dimensions STAGE 3 Scheduled Queue campaign:tenant@dom STAGE 4 Tenant routing → egress pool STAGE 5 Egress pool round-robin sources STAGE 6 Traffic shaping kumo-tsa-daemon TSA STAGE 7 Ready Queue source → site_name STAGE 8 SMTP egress → MX forensic logs

8 stages, 2 control points: Stage 2 (Panama Scorer) and Stage 6 (Traffic Shaping Automation) are the control points that distinguish managed operation from raw SMTP relay. Forensic logs feed back into TSA in real time, closing the loop on mailbox provider feedback. The architecture matches KumoMTA's documented configuration concepts (egress source, egress pool, site_name, ready queue) with EMP's pre-send Scorer integration added at Stage 2.

Dual MTA engine · why two engines, what each one does, transparent to most clients

KumoMTA + PowerMTA. Modern Rust primary, commercial backup since 2010.

Most managed email platforms run a single MTA engine: either commercial PowerMTA, or open source Postfix, or proprietary in-house code. EMP runs two engines because each one solves a different operational problem and the dual deployment hedges risk that a single-engine deployment cannot hedge. Both engines run on the same dedicated infrastructure with the same per-tenant isolation guarantees; the engine selection per tenant happens transparently based on workload pattern matching. Most clients never need to know which engine is handling their traffic at any moment; the abstraction matters only for clients with custom Lua policies on Enterprise tier, where KumoMTA is the explicit target.

KumoMTA

PRIMARY · OPEN SOURCE · RUST + LUA
Purpose

Modern primary engine for the bulk of EMP traffic. Designed from scratch in 2024 for high-volume commercial sending environments, which matches our workload profile precisely. Apache 2 license with no per-seat or per-volume cost.

Strengths exploited

Granular per-tenant egress pool routing via TOML configuration; real-time Traffic Shaping Automation via kumo-tsa-daemon that adapts to mailbox provider feedback in production; Lua policy customization for client-specific rules with 50ms execution budget enforced per message; cloud-native deployment with Kubernetes orchestration support; clustered installation with kumo-proxy frontend.

When this engine handles your traffic

By default for new tenants on all tiers since 2024 KumoMTA deployment. About 87 percent of current EMP traffic flows through KumoMTA in steady state.

PowerMTA

BACKUP · COMMERCIAL · SINCE 2010
Purpose

Commercial engine in production at EMP since 2010, with 16 years of accumulated rule sets, IP reputation history, and vendor escalation paths. Fall-back routing target for KumoMTA maintenance windows and home for legacy client configurations migrated from earlier deployments.

Strengths exploited

Vendor-supported escalation path for the rare deliverability incidents that need vendor intervention with mailbox providers; legacy IP reputation continuity for clients whose IPs predate KumoMTA deployment; tested behavior under specific traffic patterns where the production track record matters more than feature breadth.

When this engine handles your traffic

Legacy client configurations not yet migrated; KumoMTA maintenance windows; specific high-stakes campaigns where the 16-year track record is the operational hedge. About 13 percent of current EMP traffic flows through PowerMTA in steady state.

Honest framing on dual engine: the dual engine setup adds operational complexity (two engines to monitor, two configuration formats to maintain, two upgrade cycles to plan). The complexity earns its place because PowerMTA's vendor relationship covers escalation scenarios that KumoMTA's open source community cannot match yet, and because the 16 years of accumulated PowerMTA reputation continuity is genuinely irreplaceable for some legacy IP allocations. For new tenants on Pro and Enterprise tiers since 2024, KumoMTA-only deployment is also available if the client prefers a single-engine setup; about 22 percent of new Enterprise clients choose KumoMTA-only configuration during onboarding. The dual engine remains the default because it delivers operational depth that single-engine setups do not match.
Per-tenant isolation · 3 architectural layers · independently enforced

Tenant isolation that works. Three layers, independently enforced.

The fear that haunts every shared infrastructure email platform is reputation contamination: another tenant on the same IP pool, the same throughput allocation, or the same deliverability stack damages your sender reputation through their bad behavior. EMP architecture addresses this fear at three independent layers calibrated by tier. Each layer is enforced by a different mechanism so that failure in one layer does not cascade into the others. The model is structurally tested in production since the 2024 KumoMTA deployment without any cross-tenant contamination incident recorded.

LAYER 1 · IP ISOLATION

Dedicated IPs from Pro tier; rate-limited shared pool on Starter

Pro and Enterprise tiers receive dedicated IP allocation through KumoMTA egress sources assigned to per-tenant egress pools; your IP reputation is yours alone, not co-mingled with other tenants. Starter tier shares IPs with rate limiting that prevents reputation contamination from any single tenant exceeding their share; the shared pool is reserved for low-volume tenants with engagement profiles that justify pool membership, and aggressive senders cannot enter the pool.

LAYER 2 · THROUGHPUT ISOLATION

Per-tenant connection_limit and max_message_rate enforced by KumoMTA

Per-tenant connection_limit and max_message_rate parameters in KumoMTA prevent any tenant from exhausting the shared infrastructure capacity. If your tenant tries to send 10x your normal volume in a 5-minute window, the rate limiting kicks in before the burst affects other tenants. The enforcement is at the queue maintainer layer; configuration is per-tenant in the KumoMTA queues.toml helper.

LAYER 3 · REPUTATION ISOLATION

Panama Scorer pre-send catches risk campaigns before they hit the queue

Every campaign passes through the Scorer pre-send pipeline regardless of tier. Campaigns with high reputation-damage risk get blocked or flagged before they hit the SMTP queue, protecting both the sender's reputation and the shared infrastructure from collateral damage. The Scorer threshold is configurable per tenant on Pro and Enterprise; default 65 on Starter. Manual override available on Pro and Enterprise with explicit risk acknowledgment.

3independent layers
IP isolation, throughput isolation, reputation isolation — failure of one does not cascade
0cross-tenant incidents
Recorded since 2024 KumoMTA deployment in production at EMP
<800msscorer median latency
Pre-send evaluation across 8 risk dimensions on every campaign regardless of tier
11Mscorer training events
B2B email events across portfolio since 2022 with Latin mailbox feature engineering
Observability stack · 3 layers · dashboards, metrics export, forensic logs

Observability for engineering teams. Beyond what mainstream platforms expose.

Mainstream email platforms expose campaign-level dashboards and basic delivery metrics. That depth fits marketing operations review meetings; it does not fit engineering troubleshooting when a deliverability incident surfaces and you need the SMTP conversation transcript with the destination MX to understand what actually happened. EMP exposes three observability layers calibrated by tier, with the depth required for engineering-grade troubleshooting available across all tiers (the differences across tiers are in retention duration and metric series count, not in fundamental log access).

LAYER 1 · DASHBOARDS

Near-real-time campaign metrics, deliverability per provider, IP reputation tracking

In-platform analytics with campaign-level metrics (sent, delivered, opened, clicked, bounced, complained, unsubscribed) updated with under 30 second lag from event to dashboard. Deliverability metrics with per-mailbox-provider inbox placement estimation. Reputation tracking per dedicated IP with weekly trend chart. Panama Scorer history per campaign showing risk score evolution across versions. Native interface in Spanish and English.

LAYER 2 · METRICS EXPORT

Prometheus, Datadog, OpenTelemetry · 240+ documented metric series

Prometheus endpoint with per-tenant metrics scrapeable from your monitoring stack: queue depth per egress source, throttle state per destination domain, retry distribution, error rate by SMTP response code. Datadog native integration with tagged metrics. OpenTelemetry collector support for custom observability stacks. Full metric catalog of 240+ documented series available in platform documentation under NDA.

LAYER 3 · FORENSIC LOGS

Message-level events in zstd JSONL · 12 month retention · queryable by API

Message-level event logs in zstd-compressed JSONL segments with 12 month retention. Queryable via dedicated log API with filters by campaign ID, tenant ID, recipient domain, time range, event type. Webhook delivery of events in real time for clients building their own log aggregation. Forensic logs carry the full SMTP conversation transcript per delivery attempt for audit and debugging — this level of detail is rare in mainstream platforms and matters when troubleshooting deliverability incidents with mailbox providers.

What mainstream platforms don't expose: Mailchimp, HubSpot Marketing Hub, and Klaviyo all expose Layer 1 (campaign dashboards). None of the three exposes Layer 2 metrics for ingestion into your own monitoring stack at the detail level EMP exposes; HubSpot exposes some marketing metrics via API but not the underlying SMTP-level metrics. None of the three exposes Layer 3 forensic logs at message-level SMTP conversation depth; this access pattern is reserved for self-hosted deployments and managed platforms that target engineering teams as primary users. The 240+ Prometheus metric series and the 12-month forensic log retention are operational features that earn their place when your team needs to troubleshoot deliverability against mailbox providers without waiting for vendor support tickets to clear.
Integration patterns · 6 paths · injection + event push covered

Integration patterns. Six paths covering production needs.

Three injection patterns plus three event push patterns covering most production integration needs. The choice of pattern depends on your existing infrastructure (legacy SMTP applications, modern REST API consumers, smart relay deployments) and your downstream needs (real-time webhooks, streaming analytics, batch reporting). Most clients use one injection pattern plus one event push pattern; some use combinations to handle different traffic types differently within the same tenant.

PATH 1 · INJECTION

SMTP submission on port 25 with TLS

Standard ESMTP on port 25 with TLS, AUTH PLAIN or AUTH LOGIN with per-tenant credentials. Full ESMTP support including pipelining, message size negotiation, 8BITMIME, BINARYMIME. Suitable for legacy applications that already speak SMTP.

PATH 2 · INJECTION

HTTP API for batch injection

REST API supporting batch injection up to 1000 messages per request. Rate-limited per tenant by default 100 requests per second, increasable on Enterprise tier. Higher throughput than SMTP for modern applications and easier observability of injection failures.

PATH 3 · INJECTION

SMTP relay with custom routing

For applications that need to send through EMP but maintain their own MTA in front, EMP can act as smart relay with per-domain or per-recipient routing rules. Useful for hybrid deployments transitioning from self-hosted to managed.

PATH 4 · EVENT PUSH

Webhooks with HMAC-signed payload

Real-time delivery of delivery, bounce, complaint, open, click, unsubscribe events to client-specified HTTPS endpoint. HMAC-signed payload verification. Retry semantics with exponential backoff up to 24 hours. Dead letter queue for events that exceed retry limit.

PATH 5 · EVENT PUSH

Streaming logs over dedicated connection

Dedicated log streaming connection delivering JSONL events as they happen for clients building real-time analytics. Higher throughput than webhook polling and lower latency than batch log API queries. Available on Pro and Enterprise tiers.

PATH 6 · EVENT PUSH

Batch log API for historical queries

Query historical events via REST API with filters by campaign, tenant, recipient domain, time range, event type. Suitable for periodic reporting and audit workflows. 12 month retention on the underlying forensic logs that back the API.

Lua policy snippet · custom tenant routing on Enterprise tier

The snippet below shows a representative custom Lua policy that an Enterprise tenant might deploy to route campaigns differently based on a custom header. The policy executes within the KumoMTA get_queue_config hook with a 50 ms execution budget enforced per message. Custom policies are reviewed by EMP engineering before production deployment with 5 business day turnaround for standard policies.

-- Custom tenant routing policy · executes in get_queue_config hook -- Routes campaigns by region tag to region-specific egress pools -- Reviewed by EMP engineering · deployed on Enterprise tier · 50ms budget kumo.on('get_queue_config', function(domain, tenant, campaign, routing_domain) local region = kumo.get_msg_metadata('X-Region') or 'default' if region == 'mexico' then return kumo.make_queue_config{ egress_pool = 'pool-mx-dedicated', max_age = '12 hours', retry_interval = '8 mins', } elseif region == 'colombia' or region == 'peru' then return kumo.make_queue_config{ egress_pool = 'pool-andean-dedicated', max_age = '18 hours', retry_interval = '12 mins', } end -- Default fallback for non-Latin regions return kumo.make_queue_config{ egress_pool = tenant } end)
Lua policy limits: 50 ms execution budget per message processing event (KumoMTA enforces this; longer policies trigger circuit breaker); no network calls from within Lua hooks (use webhooks for downstream integration instead); no filesystem writes (use kumo.spool API for spooling); no infinite loops or recursive calls. About 18 percent of Enterprise tier clients use custom Lua policies; 82 percent operate within the standard policy set we maintain. The standard policy set covers most use cases that clients initially think require customization.
Build vs buy economics · honest comparison · self-hosted KumoMTA / PowerMTA vs managed EMP

Build vs buy. Honest economics for production volume.

The discovery call surfaces this question on about 40 percent of technical reviews: should we build this in-house with KumoMTA or PowerMTA on our own infrastructure, or should we buy managed operation from EMP? The honest answer depends on volume, team capacity, and strategic factors. The numbers below come from the actual cost structure of running production-grade email infrastructure; they are calibrated for a 5-10 million message volume per month profile, which is the range where the build-vs-buy decision typically becomes interesting.

Cost dimension Self-hosted KumoMTA / PowerMTA EMP Managed
PowerMTA license $14,000–$48,000 annually depending on volume tier Included in tier subscription
Infrastructure (servers, IPs, redundancy) $24,000–$60,000 annually for HA deployment Included in tier subscription
Senior infra engineer (1.0 FTE) $110,000–$180,000 annually loaded cost Not required (EMP team operates)
Deliverability specialist (0.5 FTE) $45,000–$80,000 annually loaded cost Not required (EMP team operates)
On-call rotation overhead $15,000–$30,000 annually opportunity cost Not required (EMP 24/7 on Enterprise)
Legal + compliance (0.1 FTE) $10,000–$25,000 annually loaded cost Included (Ley 81 compliance built-in)
Total annual cost @ 5–10M msg/mo $218,000–$423,000 $22,680–$45,360 (Pro to Enterprise)
Where self-hosted wins despite the cost gap: clients with unique compliance requirements that only their own jurisdiction can satisfy; clients whose volume is large enough to justify dedicated team economics (typically 50 million plus messages monthly); clients with strategic reasons for in-house infrastructure ownership; clients building their own ESP product where email infrastructure is the core competency. About 4 percent of EMP discovery calls end with the recommendation to build in-house instead because the self-hosted economics genuinely fit better for that specific situation. The honesty matters: a 6-figure operational saving for the right client is worth pointing toward even when the call resolves with us not getting the business.
Three platform tiers · architectural differences emphasized

Platform tiers from the architecture perspective.

The three tiers from the marketing-side companion page apply equally here, with emphasis on architectural differences rather than marketing capabilities. Pro tier is the entry point for engineering teams that need dedicated IPs and Lua policy customization is reserved for Enterprise. Most engineering-led evaluations land on Pro or Enterprise; Starter rarely fits the build-vs-buy profile.

Latin Starter

Shared infrastructure tier. Test the platform.

$99 / month
  • Up to 25,000 emails per month
  • Shared IP pool with rate limiting
  • Panama Scorer pre-send (default threshold 65)
  • Layer 1 dashboards observability
  • Standard SMTP + HTTP injection
  • Webhooks event push
  • Standard email support business hours
  • No Lua policy customization
  • Engine: KumoMTA only
Test on Starter

Latin Pro

Dedicated IPs. Layer 2 metrics export. Production-grade.

$499 / month
  • Up to 250,000 emails per month
  • Dedicated IP allocation per tenant
  • 8-week structured warmup by team
  • Panama Scorer with manual override
  • Layer 1 + Layer 2 (Prometheus, Datadog)
  • SMTP + HTTP + smart relay injection
  • Webhooks + streaming logs event push
  • Email + Slack support business hours
  • Engine: KumoMTA primary + PowerMTA backup
Book Pro discovery

Latin Enterprise

Lua customization. Full observability. 24/7 support.

$1,890 / month base
  • Unlimited emails within infrastructure limits
  • Multiple dedicated IPs with geo segmentation
  • Custom Scorer rule sets per industry
  • Layer 1 + 2 + 3 (forensic logs API)
  • All injection patterns + custom integration
  • All event push patterns + dead letter queue
  • 24/7 critical support + Slack channel
  • Custom Lua policies (5 day review cycle)
  • Engine: dual or KumoMTA-only by choice
  • Custom DPA + SOC 2 review supported
Book Enterprise discovery
Tier guidance from architecture perspective: Starter rarely fits engineering-led evaluations because the lack of dedicated IP and Lua customization makes it a poor build-vs-buy comparison target. Pro fits teams with established email engineering capacity who want managed operation but expect Layer 2 metrics for their own monitoring stack and dedicated IP for reputation control. Enterprise fits teams with custom routing requirements (Lua), high-volume operations (above 250K monthly), regulated-industry compliance scope (custom DPA, SOC 2 review), or 24/7 operational requirements. Among engineering-led discovery calls specifically, about 8 percent land on Starter, 47 percent land on Pro, 45 percent land on Enterprise; the distribution differs from marketing-led calls because the architectural depth is the buying trigger.
Hard questions from engineering review

What MarTech architects ask before approving deployment.

"What's the actual SLA we sign up for? And what happens when it's missed?"

SLA structure differs by tier. Starter: 99.5% monthly availability calculated on injection acceptance, no formal credit structure (the $99 entry price does not justify formal credits; downtime affecting Starter triggers communication and root-cause notification but no credit). Pro: 99.9% monthly availability calculated on injection acceptance and queue processing; missed SLA triggers credit equal to 10% of monthly fee per percentage point below SLA, capped at 50% of monthly fee. Enterprise: 99.95% monthly availability with same calculation method; missed SLA triggers credit equal to 25% of monthly fee per percentage point below SLA, capped at 100% of monthly fee. Credits apply against the next invoice automatically. Excluded events: client-caused incidents (configuration errors triggering rate limiting, Panama Scorer holds the client overrides incorrectly), force majeure events affecting upstream infrastructure providers, scheduled maintenance windows notified at least 72 hours in advance. Track record since 2024 KumoMTA deployment: 4 SLA-affecting incidents recorded (1 affected Pro tier, 3 affected Starter tier; Enterprise tier has not experienced an SLA-affecting incident in this period). All incidents resolved within 3 hours; root cause analysis published to affected clients within 5 business days.

"How do we test the platform before committing? Can we do a parallel deployment?"

Two evaluation patterns supported. Pattern 1 scoped pilot: 30-day Pro tier subscription with full functionality, dedicated IP allocation, Panama Scorer access, all observability layers, scoped to specific traffic segment (typically 10-20% of total volume initially). The pilot ships structured success metrics agreed during discovery (deliverability lift target, operational integration validation, team adoption confirmation) and a clear go-or-no-go decision at day 30. About 73 percent of pilots convert to ongoing subscription. Pattern 2 parallel deployment: client maintains existing email infrastructure (Mailchimp, HubSpot, self-hosted, etc.) and deploys EMP in parallel for direct comparison on identical campaign workloads. Parallel deployment runs typically 60-90 days with side-by-side metrics tracked across both platforms. Available on Pro and Enterprise tiers. Operational complexity higher than scoped pilot (you maintain two platforms during evaluation) but gives direct evidence for procurement decisions where comparison data is required. The discovery call covers which pattern fits better for your situation.

"How does platform behavior change as we scale 10x or 50x our current volume?"

Honest scaling characteristics. KumoMTA is designed for high-volume commercial sending; the engine itself handles scale linearly without architectural changes. The variables that change with scale are: dedicated IP allocation count (typically 2-3 IPs for 1M monthly, 5-8 IPs for 10M monthly, 15-25 IPs for 50M monthly with geographic segmentation); warmup duration for new IPs (8 weeks per IP, scheduled to overlap minimally with existing reputation traffic); Panama Scorer rule customization needs (default rules cover most cases up to about 5M monthly; volumes above tend to surface edge cases that benefit from custom rule sets on Enterprise); observability stack requirements (Layer 2 metrics export becomes mandatory above 1M monthly because dashboard polling does not scale to high-frequency operational decisions). Pricing scales with volume: Enterprise tier base $1,890 plus volume-based scaling at $0.0008 per email above 250K base allocation. Migration from Pro to Enterprise typically happens around 2-3M monthly volume. The 10x and 50x scaling decisions are explicitly discussed during onboarding for clients with growth trajectory; the engineering team plans IP allocation and warmup schedules ahead of expected scale.

"What's the disaster recovery story? RPO and RTO commitments?"

DR architecture documented per tier. Recovery Point Objective (RPO): for in-flight messages in the KumoMTA spool, RPO is 15 minutes (the spool fsync interval combined with backup snapshot frequency); for client configuration data (tenants, egress pools, Lua policies, Scorer thresholds), RPO is 1 hour. Recovery Time Objective (RTO): for KumoMTA service restoration, RTO is 30 minutes via warm standby in alternate availability zone; for full platform restoration including web interface and analytics, RTO is 2 hours. Geographic redundancy: primary infrastructure in Panama with warm standby in Costa Rica (different power grid, different telecom infrastructure, different jurisdiction from US-affected geography); cold backup with 24-hour RTO in EU jurisdiction for clients requiring intercontinental redundancy on Enterprise tier. Tested DR exercises: quarterly failover tests to warm standby with documented results; annual full DR exercise with cold backup activation. Track record: 1 actual DR event since 2024 (caused by upstream telecom infrastructure incident in Panama City); failover to Costa Rica warm standby completed in 22 minutes with 4 minute message processing delay during transition.

"Can we run our own KumoMTA instance and use EMP for orchestration only?"

Hybrid pattern is supported but rare; about 3 percent of Enterprise clients run hybrid configurations. The pattern: client operates their own KumoMTA instance for primary sending, EMP ships Panama Scorer pre-send evaluation as a service, EMP runs observability infrastructure (Prometheus aggregation, forensic log aggregation), EMP handles deliverability incident escalation when client operations team needs vendor-grade response. Pricing for hybrid: custom quoted because the cost structure differs from standard managed tiers; typically $2,500-$6,000 monthly depending on Scorer evaluation volume and observability scope. Honest framing: hybrid earns its place when you have engineering capacity to run KumoMTA in production but want EMP's Panama Scorer and operational depth as a service layer. It does not earn its place when the goal is cost reduction over standard Enterprise tier; the operational overhead of running KumoMTA in production typically exceeds the savings from removing managed infrastructure. The discovery call covers whether the pattern fits your specific operational profile honestly.

"What does the migration path look like from our current platform?"

Migration scope depends on source platform and tenant complexity. From Mailchimp / HubSpot / Klaviyo / ActiveCampaign / Constant Contact: contact list migration with consent metadata preservation, automation flow translation to EMP equivalents (most flows translate directly; some require workflow restructuring), template migration with HTML preservation, segmentation rule translation, sender authentication setup with overlap period to minimize reputation disruption. Standard migration timeline 3-6 weeks depending on contact volume and automation complexity. Pro tier folds in migration for sub-25K contact lists; Enterprise tier covers full migration scope. From self-hosted PowerMTA or KumoMTA: simpler in some ways (the SMTP submission point typically needs only DNS change) and harder in others (existing IP reputation needs continuity planning, custom configurations need translation to managed equivalents). Standard timeline 4-8 weeks for self-hosted migrations. Detailed migration playbook at /migration-mailchimp-hubspot.html covering risk profile, rollback procedures, parallel sending periods, and warmup overlap planning.

FAQ · technical depth questions covered on every architecture review

Architecture review FAQ.

Why dual MTA engine? KumoMTA + PowerMTA, what does each one do?
  • KumoMTA (Rust + Lua, Apache 2): modern primary, ~87% of EMP traffic in steady state
  • PowerMTA (commercial since 2010): backup + legacy, ~13% of EMP traffic
  • Dual deployment hedges single-engine risk; vendor escalation path via PowerMTA when needed
  • Same per-tenant isolation guarantees on both engines
  • KumoMTA-only deployment available on Pro and Enterprise (~22% of new Enterprise choose this)
  • Engine selection transparent to clients except those using custom Lua on Enterprise
How does per-tenant isolation actually work?
  • Layer 1 IP isolation: dedicated IPs from Pro tier; rate-limited shared pool on Starter
  • Layer 2 throughput: per-tenant connection_limit + max_message_rate enforced by KumoMTA
  • Layer 3 reputation: Panama Scorer pre-send catches risk campaigns before SMTP queue
  • Layers independently enforced; failure of one does not cascade
  • 0 cross-tenant contamination incidents recorded since 2024 KumoMTA deployment
What does Panama Scorer integration look like in pre-send?
  • Synchronous evaluation hook before SMTP queue assignment
  • <800 ms median decision latency, full eval <2 seconds for complex campaigns
  • 8 evaluation dimensions: subject, content, links, reputation drift, list freshness, recipient profile, MBP distribution, time-of-send
  • 0-100 risk score with category breakdown + recommended actions
  • Configurable threshold per tenant (default 65 on Starter)
  • Manual override on Pro and Enterprise with explicit risk acknowledgment
  • Trained on 11M B2B email events since 2022 with Latin MBP feature engineering
Can I customize behavior with Lua policy?
  • Available on Enterprise tier as part of platform offering
  • Hooks supported: get_queue_config, get_egress_path_config, smtp_server_message_received, should_enqueue_log_record, custom DKIM
  • 50ms execution budget per message (KumoMTA enforced circuit breaker)
  • No network calls from Lua hooks (use webhooks for downstream integration)
  • EMP engineering review: 5 business days standard, 10 days complex
  • ~18% of Enterprise clients use custom Lua; 82% use standard policy set
How does observability work? What's accessible?
  • Layer 1 dashboards: campaign-level metrics, <30s lag, deliverability per MBP, IP reputation
  • Layer 2 metrics export: Prometheus + Datadog + OpenTelemetry, 240+ metric series
  • Layer 3 forensic logs: message-level events in zstd JSONL, 12 month retention, queryable API
  • Forensic logs carry full SMTP conversation transcript per delivery attempt
  • Mainstream platforms (Mailchimp/HubSpot/Klaviyo) do not expose Layer 2 or Layer 3
What happens during platform maintenance? Is there downtime?
  • Routine maintenance: monthly window up to 4h, Sunday 02:00-06:00 Panama time, 72h advance notice
  • Emergency maintenance: as-needed, ~30min advance notice when possible
  • Message injection acceptance continues during maintenance (queues absorb delay)
  • No in-flight message lost during routine or emergency maintenance
  • SLA excludes notified routine windows; covers emergency windows
  • Track record since 2024: 14 routine windows + 2 emergency windows, 0 message loss
How does this compare to running our own KumoMTA or PowerMTA?
  • Self-hosted total annual @ 5-10M msg/mo: $218,000–$423,000
  • EMP managed annual: $22,680–$45,360 (Pro to Enterprise)
  • Self-hosted wins: clients above 50M monthly, unique compliance, strategic in-house ownership
  • Managed wins: 1-50M monthly range, no dedicated email engineering capacity
  • ~4% of EMP discovery calls end with recommendation to build in-house instead
What integration patterns does the platform support?
  • Injection 1: SMTP submission port 25 with TLS, AUTH PLAIN/LOGIN
  • Injection 2: HTTP REST API, batch up to 1000 msg/request, 100 req/sec default
  • Injection 3: SMTP relay with custom routing for hybrid deployments
  • Push 1 webhooks: HMAC-signed, exponential backoff up to 24h, dead letter queue
  • Push 2 streaming logs: dedicated connection JSONL, Pro+ tier
  • Push 3 batch log API: historical query with filters, 12mo retention
  • Native integrations: HubSpot, Salesforce, Pipedrive, Stripe, Shopify, Zendesk, Intercom + 5 more
  • Low-code: Zapier (8K+), Make.com (1.5K+), n8n (300+)

Architecture review call: 60 minutes. Engineering depth, no marketing pitch.

Architecture review format: 60-minute video call covering current email infrastructure stack (mainstream platform, self-hosted MTA, hybrid configuration), production volume and growth trajectory, integration requirements (CRM, ecommerce, BI, custom applications), observability stack (existing Prometheus, Datadog, custom OpenTelemetry), regulatory and compliance scope (SOC 2 review, ISO 27001 alignment, custom DPA, data sovereignty), and the specific technical questions blocking your architecture review meeting. Output: explicit fit verdict (Pro tier sufficient, Enterprise tier with specific custom Lua policy scope, hybrid pattern with self-hosted KumoMTA + EMP services, or build in-house when honestly that fits better), draft Statement of Work delivered within 5 business days when platform fit confirmed, sample Lua policy code for client-specific routing patterns when Enterprise scope discussed. Mutual NDA signed before sensitive technical detail exchanged. About 64 percent of architecture review calls convert to platform subscription, 28 percent get redirected to alternative pattern (hybrid, self-hosted, or staying on current platform), 8 percent decide to defer based on infrastructure roadmap. The architecture call is genuinely diagnostic, not a sales pitch in disguise.

Book 60-min architecture review Read marketing-side companion
60-min architecture review · Mutual NDA · Draft SoW (5 days) · Sample Lua policy when Enterprise scoped · Honest build-vs-buy verdict including "build in-house" when that fits