Honest comparisons,
not marketing pages.

The compare page is the most-abused page on most email-vendor websites. The standard pattern is to publish a side-by-side feature matrix where the vendor's product checks every column, the alternative checks half of them, and the matrix is curated so the missing checkmarks happen to align with features the alternative does well. Procurement teams have been reading that pattern for fifteen years. The pattern still gets published because it converts better than honest alternatives. We publish a different pattern, and this page explains the reasoning so that a procurement-fluent reader can decide whether our comparisons are useful before reading any of them.

The nine comparisons we publish admit, by design, where the alternative wins. SendGrid wins on developer documentation breadth and on time-to-first-send. Mailgun wins on tag-based analytics and on the EU-specific endpoint architecture. Amazon SES wins on raw cost at low volume and on its integration with the rest of the AWS surface area. Postmark wins on median delivery time and on transactional-only deliverability for sub-100K US senders. Sparkpost (Bird) wins on omnichannel breadth and on MTA engineering at extreme volume. Mailjet wins on real-time template collaboration. Brevo wins on all-in-one platform breadth and on price at SMB volume. Self-hosted Postfix wins on control surface, on data ownership and on infrastructure cost for teams with existing MTA expertise. PowerMTA wins on operational maturity for senders above a specific scale; KumoMTA wins on configuration flexibility and on not being licensed software. Each comparison page identifies the buyer profile each option fits and shows the operational maths behind the recommendation, including the volume tier at which the cost calculus inverts and the engineer-hour cost that most ESP TCO calculators omit.

The comparisons are not written for casual evaluation. They are written for procurement teams running a vendor selection where the wrong choice is materially expensive (regulatory non-compliance, deliverability failure, sustained migration cost), and for senior engineers who need to defend the recommendation internally with data the procurement team can verify against published source material. If the comparison reads as long, that is because the question is long. The vendor that produces a one-page comparison is selling something other than infrastructure.

Pricing comparison. The pricing column is the single most distorted element in published vendor comparisons. We model pricing on a same-volume, same-feature basis: a target send volume in messages per month, the same set of dedicated IPs, the same retention period for delivery logs, the same level of customer support, the same sub-processor footprint. The comparison numbers we publish are calibrated against the published prices on each vendor's website at the publication date of the comparison page. Where a vendor's pricing requires a sales conversation to see, we note this and use the lowest publicly-confirmed enterprise number we can find, which is typically the number an enterprise sales team starts the conversation at rather than the number a customer ends up paying.

Engineer-hour cost. The cost calculation that most ESP TCO comparisons omit is the engineer-hour cost. A managed service that requires four hours of engineer time per week to operate has a higher real cost than its monthly invoice suggests. A self-managed alternative that requires forty hours of engineer time per week may have lower listed cost and higher real cost. The Amazon SES comparison is the page where this matters most; we model it explicitly at multiple volume tiers using a published engineer-hour rate of €110 per hour fully loaded, which is conservative against most published EU engineering cost benchmarks for 2025. The reader can substitute their own internal rate; the structure of the calculation does not change.

Feature parity. Feature parity matrices are inherently subjective. We list the features we have personally validated in production for our own customers, against the features the alternative documents in its public-facing material. We do not list features that exist only in enterprise tier without testing them against an enterprise contract, because enterprise-tier features are subject to negotiation in ways that public-tier features are not. Where the alternative has a feature we do not have, we list it. Where we have a feature the alternative does not have, we list it. Where the comparison turns on operational discipline rather than feature checkbox, we say so explicitly rather than pretending the matrix can capture it.

Operational trade-offs. The most important section in each comparison is not the matrix or the cost calculation. It is the section identifying the buyer profile each option fits. Some senders should use SendGrid. Some should use Amazon SES. Some should use Mailgun. The comparison page that recommends BIG BOX for every reader is a comparison page whose recommendation cannot be trusted on the cases where BIG BOX is not the right answer. The honest framing matters here for the same reason it matters in our vertical pages: a customer who chooses BIG BOX for the wrong reasons will churn at the first audit or at the first material change in their volume profile, and the long-term cost of that churn is higher than the short-term cost of a deal we did not chase.

Sub-processor jurisdiction. The first pattern is the one our trust documentation makes explicit. Most US-domiciled email vendors operate corporate structures whose sub-processor list crosses jurisdictions in ways that produce CLOUD Act exposure regardless of where the data physically sits. The vendor's marketing material describes "European hosting" or "EU data residency" without disclosing that the corporate counterparty is a Delaware-domiciled entity whose ownership chain produces process reach back to US courts. The OVH Canada ruling of September 2025 reframed this analysis for cloud providers more broadly, and the Schrems II line of CJEU decisions has been the legal anchor since 2020. Our compare-vs-Mailgun page makes the analysis explicit because Sinch (Mailgun's parent) is a publicly-listed Swedish company with a Delaware-domiciled US subsidiary that is the contractual counterparty for many Mailgun customers; the analysis applies to other US-headquartered vendors with the appropriate substitutions.

Shared-reputation cold start. The second pattern is shared-IP reputation cost. Most ESP entry tiers assign new customers to shared IP pools alongside thousands of other senders. The shared pool has an established reputation, which is good for time-to-first-send. The shared pool also has accumulated complaint patterns, blocklist incidents, and engagement-quality drift from the other tenants, which is bad for sustained deliverability. The honest version of the cold-start calculation is that a new sender on a shared pool inherits roughly 12 to 25 percent worse Gmail Postmaster reputation in the first three months than the same sender would experience on a properly-warmed dedicated IP. The compare-vs-Amazon-SES page documents this empirically with the SmartScreen and Yahoo deferral numbers measured across our migration engagements.

Free-tier mathematics. The third pattern is the free-tier mathematics. The published "free up to N messages per month" tier is the loss-leader for most ESP business models. Senders who stay below the free tier consume engineering attention from the vendor's customer success function and produce no revenue. Senders who cross the free tier discover that the next tier is priced at a level that assumes the customer has already integrated and faces switching cost. The compound cost of the free-tier strategy is that it produces a customer base whose median customer is unprofitable and whose top decile subsidises the rest, which translates into product roadmap incentives that favour cross-sell and upsell over operational discipline on the existing service. The Amazon SES comparison documents this most directly: SES's headline pricing of $0.10 per thousand messages does not include the eighteen specific things SES omits from its base offering, every one of which is a separate engineering or vendor cost.

What we do not currently compare ourselves against. Marketing-automation platforms (Mailchimp, Klaviyo, ActiveCampaign, Iterable) because the buyer is evaluating us against pure infrastructure rather than against an integrated marketing stack — the procurement question is different enough that a side-by-side comparison would mislead more than it would inform. Resend, despite the visible product momentum, because we have not yet run enough engagements where Resend came up against us in the same selection cycle to publish honest comparative data. Cold-email-focused tools (Smartlead, Instantly, Lemlist, Apollo) because we explicitly do not serve the cold-outreach use case and a comparison page would imply we do. SmtpExpress, Sendlayer, EmailLabs and other regional or category-specific providers where the customer overlap is currently too small to support a verified comparison. The reason in each case is the same: published comparisons require engagement evidence we can stand behind. When we have run enough head-to-head selection cycles against any of these alternatives to support a public comparison page, the comparison will appear here.