Skip to main content

Competitor MTA Research

Research on how major email service providers handle email delivery - Postfix vs Direct SMTP vs Custom MTAs.

Last Updated: February 2025

What Competitors Use​

Commercial ESPs (SendGrid, Mailgun, AWS SES)​

Architecture:

  • Custom/Proprietary MTAs - They don't use Postfix
  • SendGrid: Custom cloud-based MTA, processes 134+ billion emails/month
  • Mailgun: Custom MTA with managed SMTP servers
  • AWS SES: Amazon-built MTA integrated with AWS services

Performance:

  • SendGrid: 15,000 transactions/second, 1.9s median delivery
  • Mailgun: 72 million messages/hour (1.2M/min)
  • AWS SES: Massive scale, exact numbers not public

They use Postfix for: Integration point (customers relay TO them via Postfix)

Commercial High-Performance MTAs​

Companies building ESPs often use:

PowerMTA (by SparkPost)​

  • Cost: $8,000+/year
  • Performance: 1-3 million emails/hour per instance
  • Use case: Enterprise high-volume senders
  • Architecture: Proprietary, C++ based, extremely optimized
  • Features: Advanced IP rotation, intelligent bounce handling, per-domain throttling
  • Real example: Jobtome replaced 30 Postfix servers with 1 PowerMTA

Momentum (by Bird)​

  • Enterprise-grade, similar to PowerMTA
  • Used by large ESPs and corporations
  • Real-time routing, customizable workflows
  • Formerly called Ecelerity by Message Systems

KumoMTA (Open Source)​

  • Built by ex-email infrastructure engineers
  • High-performance, modern PowerMTA alternative
  • For organizations wanting PowerMTA performance without licensing costs

Open Source ESP Alternative: Postal​

Architecture:

Features similar to ESPs:

  • Multi-domain management
  • Click/open tracking
  • Webhook integrations
  • IP pool management
  • DKIM signing
  • Web dashboard

Built by: Krystal (UK hosting company) for their own needs, then open-sourced

Postfix vs Direct SMTP vs Custom MTA​

Postfix (Traditional Approach)​

Pros:

  • Free, open source, mature
  • Good performance (hundreds of msg/sec)
  • Well-documented, large community
  • Modular, secure architecture

Cons:

  • Not optimized for ESP use case
  • Complex configuration for high volume
  • Queue management not ideal for multi-tenant
  • Limited built-in analytics/tracking

Performance comparison:

  • Jobtome: 30 Postfix servers → 1 PowerMTA
  • But: Some cases show Postfix delivers Yahoo mail faster due to different backoff strategies

Direct SMTP (Application-Level)​

Who uses it:

  • Smaller services or internal tools
  • When you need absolute control
  • Microservices sending directly

Pros:

  • No intermediate queue
  • Immediate status feedback
  • Full application control

Cons:

  • Must handle all SMTP complexity yourself
  • IP reputation management
  • Retry logic in application
  • Connection pooling
  • DKIM signing in code

Custom MTA (ESP Approach)​

Why companies build/buy custom MTAs:

  1. Performance at scale

    • PowerMTA: 1-3M emails/hour on one instance
    • Postfix: Needs 30 instances for same throughput

  2. ESP-specific features

    • Per-organization IP pools
    • Smart throttling per receiving domain
    • Real-time bounce classification
    • Click/open tracking injection
    • Automatic retry with backoff per recipient domain

  3. Multi-tenancy

    • Isolate traffic by organization
    • Per-org rate limiting
    • Separate IP reputation

  4. Deliverability intelligence

    • ISP-specific rules (Gmail vs Yahoo vs Outlook)
    • Automatic IP rotation on blocks
    • Feedback loop processing
    • Reputation monitoring

Options for Postchi​

Option 1: Postfix (MVP/Small Scale)​

Good for:

  • MVP, getting started
  • <100K emails/day
  • Single organization or small multi-tenant

Challenges:

  • Will need replacement at scale
  • Queue management for retention
  • Multi-org isolation harder

Option 2: Postal (Open Source ESP)​

Good for:

  • ESP features without building from scratch
  • Multi-domain/multi-org
  • Built-in tracking, webhooks, IP pools
  • Active open source project

Challenges:

  • Another system to deploy/maintain
  • Ruby/Rails stack (vs our Node.js)
  • Community vs commercial support

Option 3: Direct SMTP with Node.js​

Good for:

  • Full control
  • Simplified architecture
  • No queue files on disk

Challenges:

  • Must implement retry logic
  • DKIM signing in code
  • IP reputation your responsibility
  • Connection pooling complexity

Option 4: Hybrid - Postfix for Now, Plan Migration​

Strategy:

  • Start with Postfix (proven, fast to implement)
  • Abstract sending behind interface
  • Migrate to custom/Postal when volume justifies it

Abstract the sender interface:

// Abstract the sender
interface EmailSender {
  send(message: Message): Promise<SendResult>
  getStatus(messageId: string): Promise<DeliveryStatus>
}

// Phase 1: Postfix implementation
class PostfixSender implements EmailSender { ... }

// Phase 2: Postal implementation (when ready)
class PostalSender implements EmailSender { ... }

// Phase 3: Custom MTA (if you get to SendGrid scale)
class CustomMTASender implements EmailSender { ... }

Start with:

  1. Postfix for actual sending (proven, fast)
  2. Direct SMTP response for immediate status
  3. Aggressive queue cleanup (1 hour max)
  4. S3 storage for message content
  5. PostgreSQL for metadata

This gives you:

  • Fast MVP with proven tech
  • Easy migration path
  • Storage solution that scales
  • Retention policies per tier