Helo: A New Developer Email API from the Former Postmark Team

A Team from Postmark, Rebuilding Email API from Scratch

Email delivery sounds straightforward — but for developers and SaaS platforms that need to send email on behalf of their customers, it hides a tangle of thorny problems: one bad-actor tenant can tank deliverability for the entire system, per-customer analytics, unsubscribe lists, and credentials are hard to isolate, and setting up custom sending domains is a constant headache. Helo is an email API product built specifically to solve these pain points.

Notably, Helo was created by former members of the Postmark team — a service that has built a solid reputation in the transactional email space over many years. A team of veterans starting independently usually means they know exactly where all the landmines are buried. Helo currently has 99 upvotes and 9 comments on Product Hunt, ranking #13, under the Email, API, and Developer Tools categories.

Core Positioning: Built for Platforms That Send on Behalf of Others

Helo's target users are very specific — developers and platforms that need to send email "on behalf of their customers." This scenario is extremely common in SaaS products, marketing tools, and notification systems, and is also where multi-tenant management challenges tend to be most severe.

Containing Bad Senders

The biggest risk in a multi-tenant email system is this: one tenant's poor sending behavior (high bounce rates, spam complaints) can contaminate the reputation of a shared IP, dragging down deliverability for all customers. Helo emphasizes the ability to "contain bad senders before they drag down deliverability" — isolating and controlling problematic senders before they affect the broader system. This is a must-have capability for any platform-level email service.

The root cause of IP reputation pollution lies in the traditional Shared IP Pool architecture: multiple tenants share the same set of outbound IP addresses, and email service providers (ESPs) and recipient-side anti-spam systems evaluate reputation at the IP level rather than the account level. Once a tenant triggers a high bounce rate or a surge of spam complaints, the reputation score of that IP range drops, making it more likely that other tenants' emails end up in the spam folder or get blocked entirely. Solutions typically include assigning dedicated IPs to high-risk tenants, implementing rate-limiting circuit breakers, and monitoring bounce and complaint metrics per tenant in real time — automatically throttling or suspending sending permissions when thresholds are exceeded. These measures are non-trivial to implement technically, yet they represent the basic compliance bar for any platform-level email service.

Letting Customers Send from Their Own Domains

Helo supports customers sending email from their own domains, which is critical for B2B2C scenarios where brand consistency matters. Combined with per-tenant isolation of analytics, unsubscribe lists, and credential management, each customer's email ecosystem is cleanly segmented — making both billing and troubleshooting much easier.

Custom sending domains technically require customers to add several DNS records: an SPF record (Sender Policy Framework) to declare authorized sending servers, a DKIM record (DomainKeys Identified Mail) to provide a cryptographic signature for each email, and an optional DMARC policy record to specify handling when verification fails. In a multi-tenant platform, this entire process must be configured and verified independently for each customer, with management complexity growing linearly with the number of tenants. Some platforms simplify setup through DNS proxying or wildcard subdomain approaches, but this can affect header alignment, which in turn impacts DMARC pass rates. Helo's emphasis on supporting this workflow means it needs to maintain separate signing keys and DNS verification states for each tenant — itself a meaningful technical bar for platform-level email services.

Technical Foundation: Everything Developers Expect

Helo repeatedly emphasizes "covers the fundamentals" in its messaging, with all the expected features in place:

• REST API and SMTP dual channels: Supports both modern API calls and legacy SMTP integrations
• Multi-language SDKs: Official SDKs for major programming languages, lowering the integration barrier
• Separate transactional and broadcast infrastructure: Particularly important — physically separating notification emails (transactional) from marketing blasts (broadcast) prevents bulk-send volume fluctuations from impacting the timely delivery of critical notifications

This architectural separation of transactional and broadcast channels is a direct reflection of the Postmark team's accumulated experience — they know firsthand how mixing the two can wreck deliverability.

The fundamental difference between transactional email and bulk/broadcast email lies in the trigger mechanism and user expectation: transactional emails are triggered in real time by user actions (e.g., registration verification, password reset, order confirmation) — recipients expect them, open rates are high, and complaint rates are low. Broadcast emails are scheduled marketing content sent in bulk; even with a double opt-in list, complaint rates are relatively higher. Leading ESPs like SendGrid and Mailgun both recommend isolating the two via separate sub-accounts or IP ranges, precisely because the volatile reputation risk of broadcast email can negatively affect the priority delivery of transactional mail. At the SMTP protocol level, this isolation typically manifests as separate SMTP endpoints or API keys, eliminating traffic mixing at the source.

Pricing: Usage-Based, with a Very Low Entry Point

Helo uses a usage-based pricing model, starting at just $0.00035 per email, with "all features included" — no feature gating across tiers.

To put that in perspective: sending one million emails costs roughly $350. For high-volume platforms, a pure pay-as-you-go model with no feature-tier lock-in has genuine appeal. Compared to many competitors that restrict advanced features to higher-tier plans, Helo's "all features included" promise is notably more transparent.

Closing Thoughts: A Focused Bet from an Experienced Independent Team

The emergence of Helo reflects the fact that there is still room for targeted differentiation in the email infrastructure market. Rather than trying to be a general-purpose service that does everything, Helo focuses on the specific scenario of "multi-tenant, send-on-behalf" use cases, and leverages a seasoned team's experience to address real pain points around deliverability isolation and data isolation.

For developers building SaaS products who need to provide email capabilities to a large number of customers, Helo is a new option worth evaluating. That said, as a newly launched product, its real-world deliverability performance, SDK maturity, and long-term stability will still need to be validated through actual production use.