Selecting the wrong email service provider costs more than the monthly invoice. A transactional ESP with poor uptime affects user activation and retention. A marketing ESP with shared IP pools of poor quality damages sender reputation. An ESP that does not support custom domain DKIM signing builds reputation on its own domain, not the sender's — meaning the reputation investment made over months of good sending history is lost if the programme ever needs to switch providers. The ESP selection decision deserves the same rigour as any significant infrastructure choice. This guide provides the evaluation framework for 2026.
ESP Type Selection: Transactional vs Marketing vs Dedicated
The first ESP selection decision is the type of ESP needed — which is determined by the email use case, not by brand recognition or pricing. Using the wrong ESP type for a given use case produces worse deliverability and worse operational outcomes than using the right type at a higher cost.
Transactional ESP (Postmark, Mailgun, Amazon SES, SparkPost): Optimised for triggered, one-to-one email delivery with sub-second injection to delivery latency. Maintained on dedicated IP pools separate from marketing email. Provides per-message delivery event webhooks and detailed logging. Best for: password resets, order confirmations, welcome emails, any email where delivery speed and reliability are commercially critical. Not appropriate for: batch marketing campaigns, newsletter sends (volume patterns and engagement signals from marketing email degrade transactional pools).
Marketing ESP (Klaviyo, Mailchimp, Brevo/Sendinblue, ActiveCampaign, Omnisend): Optimised for campaign management, list segmentation, and marketing automation workflows. Provides campaign analytics, A/B testing, and audience management features that transactional ESPs do not offer. Best for: newsletters, promotional campaigns, marketing automation sequences, lifecycle marketing. Not appropriate for: high-volume transactional email that requires sub-second delivery and dedicated reputation isolation.
Dedicated sending infrastructure (PowerMTA/MailWizz, Postal, self-managed MTA): Full control over IP pools, sending configuration, accounting log data, and retry logic. No shared pool reputation risk. Requires engineering resources to operate. Best for: programmes above 500K-2M monthly messages, agencies managing multiple client sending programmes, or senders with specific compliance requirements. Not appropriate for: low-volume programmes without engineering resources for MTA management.
Transactional ESP Comparison: Postmark, Mailgun, SendGrid, SES
Postmark: The strongest reputation for transactional email deliverability among major ESPs. Postmark maintains strict separation between transactional and marketing email — marketing campaigns cannot be sent through Postmark (it only accepts transactional email), which means all Postmark IPs remain dedicated to transactional traffic with no reputation contamination from marketing sends. Custom domain DKIM signing is supported on all plans. Per-message delivery stream logging with 45-day retention. Pricing: from $15/month for 10K messages. The premium cost relative to SES is justified by the deliverability guarantees and operational support for production transactional programmes.
Mailgun: Developer-friendly API with strong documentation and flexible sending configuration. Supports custom domain DKIM, dedicated IPs on paid plans, and per-message delivery webhooks. Mailgun allows both transactional and marketing email (unlike Postmark) — which means transactional senders must use separate sending domains and streams to avoid shared pool issues with marketing traffic. Pricing: from €15/month for 50K messages. Good balance of deliverability control and developer experience for programmes that need both transactional and marketing in one platform.
SendGrid (Twilio): The largest email API provider by volume. Strong deliverability infrastructure at scale, thorough API documentation, and good dedicated IP options. Custom domain DKIM supported. SendGrid's Marketing Campaigns feature allows using the same platform for both transactional and marketing — with the same shared pool risk as Mailgun if streams are not separated. Pricing: from €20/month for 50K messages. SendGrid has had intermittent deliverability issues in past years (shared pool quality concerns), though the dedicated IP option eliminates shared pool risk for volume-qualified senders.
Amazon SES: The lowest per-message cost of any major transactional ESP ($0.10 per 1,000 messages). Requires more setup than other ESPs (IAM configuration, bounce and complaint handling setup, dedicated IP leasing at $24.95/IP/month). Custom domain DKIM supported (and required for MAGY compliance when using SES). Excellent for high-volume programmes with engineering resources for setup and monitoring. Not recommended as a starter ESP for teams without AWS experience due to configuration complexity. SES uptime is very high (99.99% SLA) and throughput scales essentially without limit.
Marketing ESP Comparison: Klaviyo, Mailchimp, Brevo
Klaviyo: The dominant marketing ESP for e-commerce. Strongest deliverability features among marketing ESPs: custom domain DKIM on all plans, dedicated sending IP option (above 250K monthly threshold), multi-tier engagement-based suppression, and per-campaign delivery analytics. Deep e-commerce platform integrations (Shopify, WooCommerce, BigCommerce). Pricing scales with contacts — can become expensive above 100K contacts. Best for: e-commerce brands requiring sophisticated marketing automation with deliverability awareness built into the platform.
Mailchimp: The most widely used email marketing platform globally. Custom domain authentication available (requires DNS record setup). Strong template builder and basic automation features. Deliverability features are less sophisticated than Klaviyo — no dedicated IP option on standard plans, limited per-campaign bounce analysis. Pricing competitive at low contact counts, expensive at high contact counts. Best for: small-to-medium programmes that prioritise ease of use and marketing features over deliverability sophistication.
Brevo (formerly Sendinblue): Good deliverability features including custom domain DKIM, dedicated IP options, and transactional email support in the same platform. More competitive pricing than Mailchimp or Klaviyo at mid-range contact counts. Growing CRM and marketing automation features. Best for: programmes that want a cost-effective single platform for both marketing and transactional email with solid deliverability fundamentals.
Evaluation Criteria: Deliverability, Auth, Reporting, Cost
The ESP evaluation criteria that determine deliverability outcomes, in order of impact:
1. Custom DKIM signing from own domain (non-negotiable): Any ESP that cannot sign with d=your-domain.com is not acceptable for a programme that wants to build domain reputation under its own domain. This eliminates ESPs that only offer shared domain signing. Verify this capability exists on the specific pricing tier being considered — some ESPs gate custom DKIM behind paid tiers.
2. IP pool quality and separation: For shared IP senders, how does the ESP manage its shared IP pools? Does it separate transactional from marketing traffic? Does it actively monitor and remove poor-quality senders from shared pools? What is the ESP's process for addressing shared pool quality events? Dedicated IP option availability and pricing — is dedicated IP available, and what is the warmup support provided?
3. Bounce and complaint processing: How quickly does the ESP process hard bounces and add them to suppression? Does it enroll in ISP FBLs and process complaint notifications? What data does it provide on per-campaign bounce rates and complaint rates?
4. Delivery event reporting: Per-message delivery event data (delivered, deferred, bounced, complained) with full SMTP response text. Per-ISP delivery breakdown. Historical data retention period. Webhook delivery event notifications. Without detailed delivery event data, diagnosing deliverability problems is much harder than with a self-managed MTA's accounting log.
5. Uptime SLA and support quality: For transactional email, uptime below 99.9% is commercially unacceptable. What is the ESP's historical uptime record? What is the support response time commitment for deliverability issues? For high-volume or commercial-critical programmes, dedicated account manager and deliverability specialist access is worth the price premium.
6. Pricing at projected volume: Calculate the per-message cost at the programme's current and projected 12-month volume. Include the cost of dedicated IPs if needed, the cost of higher feature tiers, and the operational cost of any limitations (e.g., no dedicated IP means more time managing shared pool issues). Total cost of ownership, not invoice cost.
When Dedicated Infrastructure Beats ESP
Dedicated email infrastructure (self-managed PowerMTA or similar) becomes the better operational and financial choice when the programme has outgrown what shared ESP infrastructure can provide. The decision matrix:
- Volume above 500K monthly: Per-message ESP pricing typically exceeds managed dedicated infrastructure monthly cost above this threshold on a total-cost-of-ownership basis.
- Investigation needs: More than 2 significant deliverability incidents per year where limited accounting log access delayed diagnosis. Dedicated infrastructure provides full accounting log access.
- Multi-client management: Agency or multi-brand scenario where VMTA-per-client isolation is needed — ESPs cannot provide this level of isolation on shared infrastructure.
- Specific compliance requirements: HIPAA BAA, data residency in specific jurisdictions, or FINRA/SEC email retention requirements that most ESPs cannot fulfil.
- Warmup speed and control: The programme needs faster or more controlled IP warmup than the ESP's automated warmup system provides.
ESP Migration: What to Evaluate Before Switching
ESP migration decisions must account for the reputation transfer problem: reputation built on the current ESP may not transfer to the new one, depending on how authentication is configured. If the current ESP is signing with its own shared domain (d=esp.com), the reputation built under that domain stays with the ESP — the new ESP starts from zero reputation for the programme's own domain. If the current ESP is signing with the programme's own domain (d=yourdomain.com), the domain reputation transfers to the new ESP configuration — warmup on the new infrastructure benefits from the established domain reputation and is significantly faster.
Before migrating: confirm the current ESP's DKIM signing domain. If it is not the programme's own domain, implement custom domain DKIM on the current ESP before migration — this builds the domain reputation that will transfer to the new ESP, and avoids a cold-start warmup on the new infrastructure.
ESP Red Flags: What to Avoid in 2026
- No custom domain DKIM on any plan: This is a hard disqualifier — any ESP that cannot sign with the programme's own domain cannot be used for production sending under MAGY compliance requirements.
- No FBL enrollment or complaint processing: An ESP that does not process ISP feedback loops and suppress complainers is accumulating reputation damage on the programme's behalf without visible feedback.
- No dedicated IP option for programmes above 200K monthly: At this volume, sharing IPs with unknown co-tenants creates reputation risk that an acceptable ESP should offer to eliminate through dedicated IP options.
- Below 99.9% historical uptime: For transactional email, downtime is directly lost revenue. Any ESP with a track record below 99.9% uptime is not acceptable for transactional email.
- Unclear data ownership and export rights: Programme subscriber data must be fully exportable in a standard format. ESPs that make data export difficult or expensive create an unhealthy lock-in dependency.
The ESP Selection Framework
The selection decision process: (1) Define the primary use case (transactional, marketing, or both) and select the ESP type accordingly. (2) Screen candidates against the non-negotiable requirements (custom DKIM, MAGY compliance, FBL processing, minimum uptime SLA). (3) Evaluate the remaining candidates against the secondary criteria (dedicated IP option, reporting depth, support quality, pricing). (4) Run a proof-of-concept with the top 1-2 candidates — send test messages, check headers for correct authentication, verify delivery event data completeness. (5) Evaluate the migration path from the current ESP, including reputation transfer and warmup requirements. (6) Select the ESP that best meets the combination of deliverability capability, operational features, and total cost of ownership for the programme's current and projected state.
The ESP market continues to evolve — capabilities that differentiate providers in 2024 may be commoditised by 2026. Review the ESP selection annually against updated programme requirements and the current provider landscape. The right ESP for a programme at 100K monthly messages may not be the right one at 2M monthly messages; proactive evaluation prevents the reactive migration that happens after an ESP has become a constraint rather than an enabler.
ESP selection done right is infrastructure strategy done right. Choose the right type for the use case, verify the non-negotiables, test before committing, and review annually as the programme grows. The ESP that serves the programme well at 50K monthly messages will be evaluated and potentially replaced at 5M monthly messages -- and that evolution is healthy, not a failure. Build the evaluation muscle; apply it at each growth inflection point; and the ESP stack will always be the right one for the programme's current state.
The programme that selects its ESP with deliverability criteria at the centre of the evaluation -- not pricing or feature lists -- will consistently outperform programmes that select on cost alone. Deliverability is the ESP's primary function; everything else is secondary to ensuring the messages reach inboxes reliably, at scale, with the authentication and reporting infrastructure that makes the programme manageable over time.