SendPost review

SendPost is a hosted cloud MTA and email delivery service, not a client library or self-hosted mail server. Applications connect through its Email API or SMTP relay, while a web dashboard provides deliverability analytics and controls for sending traffic. Webhooks report email events to systems in your stack.

The service is intended to sit alongside an existing MTA and application: the homepage says teams can add SendPost for visibility and route traffic through it when ready. It focuses on operational signals that basic sending integrations may not expose, including ISP responses, IP and domain reputation, and sender-level performance. Teams can use per-ISP throttling, queues, routing, and shared or dedicated IP pools to respond to those signals. AI alerts flag bounce, deferral, or reputation changes, and automation covers warmup, backoff, and retries. That makes SendPost more relevant to ESPs and deliverability teams managing multiple senders than to a small app that only needs transactional email.

The homepage shows an HTTP API endpoint, GET /api/v1/subaccount/stat/aggregate, queried with date parameters and an X-SubAccount-ApiKey header. Its example returns JSON statistics for processed, delivered, opened, bounced, dropped, unsubscribed, and spam messages. SendPost also offers an SMTP relay, webhooks for opens, clicks, bounces, and complaints, and event logs with traceability.

The vendor says SDKs are available in six languages, but does not name them on the homepage. Check the API docs to confirm support for your language and SDK maintenance status before choosing an integration. The homepage links to API documentation and a full API reference; it does not list a CLI or plugins. The platform also advertises Slack and email alerts, plus Slack-command workflows. Its controls for subaccounts and groups are useful when an ESP needs to separate traffic and reporting across customers. Confirm authentication, webhook retry behavior, and event retention in the docs before relying on them in production.

The pricing information checked on 2026-11-06 lists three monthly USD tiers: Starter costs $7 for 10,000 emails, Growth costs $197 for 600,000 emails, and Scale costs $997 for 3,000,000 emails. There is no free plan, and no free trial is listed. Annual prices are not published.

Each tier includes a monthly email allowance, with overage email costs applying beyond it. The per-email overage rate is not published, so the cost of a traffic spike cannot be calculated from the tier prices alone. Ask SendPost for the overage rate and how usage is counted before routing production traffic. The pricing information also says current self-serve pricing is available on request after scheduling a demo, despite recording public monthly tier prices. Treat the listed amounts as a starting point and confirm the quote, billing terms, and included features directly. Seat charges and add-on prices are not listed.

SendPost is presented as a cloud service integrated through its API and SMTP relay. The vendor does not publish a source licence or a self-hosting option, so teams should not plan on running SendPost in their own infrastructure without written confirmation. Data export options are not published either; ask how to retrieve message events, reputation history, and incident records if you leave.

The sending interface is based on standard integration surfaces—HTTP API, SMTP, and webhooks—but its deliverability controls, analytics, and workflows are part of SendPost. Replacing the sending path may be simpler than reproducing those operational features. Before adopting it, confirm whether you can export event and suppression data in a usable format, how long that data remains available, and what happens to IP arrangements when an account closes. The vendor says SendPost can work alongside an existing MTA, which may help teams stage a migration rather than switch all traffic at once.

SendPost advertises support for high-volume operations and says it works alongside an existing MTA. Its homepage cites SendX processing more than 300 million emails per month, but those are vendor-published claims, not a service-level commitment. The vendor does not publish API rate limits or reliability targets on the homepage, and the listed plan allowances do not explain burst handling. Ask about throughput caps, queue behavior, incident response, and SLA terms before moving critical mail.

Security and compliance details also need verification. The homepage shows an API key header but does not describe key rotation, access controls, encryption, data residency, or compliance certifications. Confirm these with the vendor, along with webhook delivery guarantees and event retention. For capacity planning, get the overage rate and expected behavior when a plan's monthly email allowance is reached. Use staged traffic routing and monitor ISP responses, bounces, and reputation signals as you increase volume.