Short answer: For transactional email with versioned templates and a suppression list, choose the lowest-total-cost candidate that can replay each receipt's policy decision and delivery trail.
The cheapest transactional email service is the one that can produce acceptable evidence when a welcome message or order receipt is disputed. Unit price comes second. For a marketplace sending receipts after payment settles, I would choose the candidate that passes an evidence replay test, keeps template versions identifiable, and applies suppressions before delivery. If two candidates pass, then compare their total operating cost.
| Choice | What to verify in a proof | Choose it when | Avoid it when |
|---|---|---|---|
| Evidence-first managed API | A receipt can be traced from payment event to template version, suppression decision, and provider response | Audit response time is the binding constraint | Its evidence export cannot meet the retention policy |
| Cost-first email transport | The same trace can be assembled reliably in your own system | You already operate the event log and delivery ledger | The apparent saving creates recurring manual evidence work |
| Self-managed delivery | Ownership, access, retention, and deletion controls all match policy | Delivery operations are already a core competency | A solo team would have to become its own deliverability operation |
This is a decision note, not a price ranking. Amazon SES, Resend, Postmark, and Mailgun are reasonable candidates to put through the same test, but a static article can't verify the contract, region, account limits, template behavior, and suppression semantics that apply to a particular account in 2026. Record those current answers in the worksheet; don't infer them from a logo or an old pricing screenshot.
How should you compare transactional email templates and suppression lists?
Start with one real business event: payment.settled. Give it an immutable event ID, the marketplace order ID, the recipient reference, the template ID and version, the consent or transactional-purpose basis, and a timestamp. The email request should be a consequence of that event, not an untraceable side effect inside the checkout request. That distinction matters when support asks why a receipt was sent twice, why it wasn't sent, or what exact content the buyer received.
Then run the same acceptance test against every candidate. Send a welcome email and a post-payment receipt to controlled addresses. Repeat the event. Add one address to the relevant suppression source and replay again. Change the template. Export the resulting evidence without using a vendor dashboard. The expected output is a chain an engineer can explain: accepted payment event, idempotency decision, template version, policy decision, delivery request, provider response, and later delivery-state events.
Keep the scorecard blunt:
- Can an operator identify the exact rendered template without reconstructing it from today's template?
- Is the suppression decision captured as data, including which policy produced it?
- Can webhook events be authenticated, deduplicated, and linked to the original event ID?
- Can evidence be exported and deleted under the retention policy?
- How many engineer-hours per month go into reconciliation, failed-event review, and vendor-specific code?
The last line is where “cheapest” gets honest. A lower message charge can lose to four hours of monthly reconciliation; a higher charge can also be wasteful if the supposed evidence features don't match the policy. I'm not sure which candidate wins for your account until those tests and current commercial terms are side by side. Your mileage may vary — especially across regions and sending volumes.
Compliance evidence is a data product
Treat the evidence ledger as part of the application, not as whatever the provider happens to retain. Store references instead of unnecessary message content. Separate customer-facing order data from delivery telemetry. Give every record a retention class, because “keep everything forever” is neither a compliance strategy nor a useful debugging plan.
The important split is between business intent and transport state. Business intent says the marketplace owed the buyer a receipt after settled payment. Transport state says a particular provider accepted a particular request and later reported a state transition. If you collapse those into one sent boolean, you lose the ability to distinguish “we decided to send,” “the API accepted it,” and “the mailbox provider reported delivery.” Those are different claims.
Consider an order whose payment event is accepted at 09:14, while the delivery worker does not claim its outbox row until 09:16. The evidence chain should preserve both times, the stable event ID, the policy version used at 09:16, and the digest of the rendered receipt. If the worker retries, each transport attempt belongs under that same business event rather than masquerading as another receipt obligation. Later, an authenticated webhook can append a delivery transition without rewriting the earlier decision. Support can then answer the buyer with a sequence of claims, and an auditor can inspect the policy and content that actually applied. A single mutable row cannot do that job: every update erases part of the story, while a provider dashboard may retain a different slice for a different period. This example is intentionally provider-neutral because the ledger must remain useful after an adapter changes.
Short flags fail fast.
Suppression data needs the same precision. A marketing opt-out should not be treated as a vague global boolean without reviewing the legal and product policy for transactional messages. RFC 8058 defines a one-click unsubscribe mechanism for list email; it doesn't turn every order receipt into marketing mail. Classification belongs in policy, with counsel where needed, and the resulting decision should be logged by policy version. The code shouldn't make legal meaning out of a provider's generic suppression label.
This is also why templates need versions. Saving only receipt-v4 proves little if that identifier points to editable content. Store a content digest or immutable artifact reference with the render inputs needed by policy. Avoid secrets and excess personal data in logs. Evidence should answer a narrow question without creating a second customer database.
Put idempotency before the email API
The clean boundary is a small, vendor-neutral delivery interface backed by an outbox. Payment settlement writes the business event and outbox row in one transaction. A worker claims the row, checks policy, renders an immutable template version, calls the adapter, and records the result. Provider webhooks enter through a separate authenticated ingestion path and update the ledger idempotently.
type ReceiptCommand = {
eventId: string;
orderId: string;
recipientRef: string;
template: { id: "order-receipt"; version: number; digest: string };
policyVersion: string;
};
type DeliveryAcceptance = {
providerMessageId: string;
acceptedAt: string;
};
interface TransactionalEmailPort {
sendReceipt(command: ReceiptCommand): Promise<DeliveryAcceptance>;
}
async function processReceipt(
command: ReceiptCommand,
email: TransactionalEmailPort,
): Promise<void> {
const existing = await evidenceLedger.findByEventId(command.eventId);
if (existing) return;
const policy = await suppressionPolicy.evaluate({
recipientRef: command.recipientRef,
purpose: "order-receipt",
version: command.policyVersion,
});
if (policy.action === "suppress") {
await evidenceLedger.recordSuppression(command, policy.reason);
return;
}
const accepted = await email.sendReceipt(command);
await evidenceLedger.recordAcceptance(command, accepted);
}
The sketch leaves database transaction details out on purpose. In production, claiming work and recording attempts need concurrency control; otherwise two workers can both pass the initial lookup. Put a unique constraint on the event ID, define retryable outcomes in the adapter, and make webhook event IDs unique as well. Don't let a provider's message ID become the business idempotency key — a retry may create another transport attempt for the same business obligation.
Ship this behind a shadow evidence check first. The worker can exercise policy and rendering against test recipients while the existing path remains authoritative. Compare ledger completeness, then move a narrow slice of receipt traffic. Weekly shipping is useful here because each step has a reversible boundary; a giant migration mixes template changes, policy changes, and transport changes into one hard-to-audit release.
The runner-up wins when operations are already owned
The evidence-first managed option is not suitable when its retention, export, regional processing, or access model conflicts with your policy. Stick with a transport-oriented option when your application already has a mature outbox, immutable template store, authenticated webhook ingestion, and evidence export. In that case, paying for overlapping workflow features can add another control plane without reducing engineering work.
Self-managed delivery is the narrower runner-up. It makes sense when delivery operations are strategically important and someone already owns reputation, feedback processing, abuse response, and on-call work. It is a poor default for a one-person SaaS shipping weekly: those hours compete directly with customer-facing work, and outsourcing undifferentiated transport usually protects revenue per engineering hour.
There is another boundary: welcome email and SMS verification shouldn't share a suppression model merely because both are “messaging.” The WebOTP API concerns receipt of specially formatted SMS messages for one-time passwords. That purpose, browser mediation, and threat model are different from a marketplace receipt. Share event-envelope conventions if they help, but keep purpose-specific policy and evidence.
Make the 2026 comparison reproducible
For each of Amazon SES, Resend, Postmark, and Mailgun, capture the date, region, account tier, quoted billing units, minimums, template version behavior, suppression scopes, webhook authentication method, event retention, export path, and deletion controls. Link every cell to a current primary document or a saved contract artifact. A blank cell means “unknown,” not “probably supported.”
Run the proof again after material account or policy changes. Vendor capabilities and commercial terms move; your acceptance test is the stable asset. The final selection is whichever passing option produces the lowest combined message bill and operating burden under the same workload assumptions, with no special weighting for brand familiarity.
One rule survives every spreadsheet: if you can't replay a receipt decision, you don't have compliance evidence.
References
- RFC 8058, “Signaling One-Click Functionality for List Email Headers”: https://datatracker.ietf.org/doc/html/rfc8058
- MDN, “WebOTP API”: https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API
Top comments (0)