Postmark

Founders note: Postmark is amazing because it’s the right balance of feature set. I hate it when I review a tech stack and find that the stack builders used one or two key features in a stack component, but either ignore or do not need the rest.

What Postmark is

Postmark does not do everything. But what it does do is amazing. First: email signatures, templates, open/click analytics, webhooks. These features are accessible in other solutions but either with too much complexity or too high a package price. At its most basic it gives you solid email delivery.

I have used everything—from SendGrid to Mailchimp. As with most solutions, I optimize for depth of utility. It’s not hard for a tech stack to use the full suite of features. When I measure the percent of features I use versus do not use I find I can get to an 80% utility rate. If you read my framework, this is one of my key eval points.

More important, the real value prop is they offer deliverability. They offer transactional and non-transactional streams. Signatures, templates, webhooks, and analytics sit on top of that—not instead of it.

Scalpel vs machete — SendGrid

In the old days—as in ten or twelve years ago—we would have in a large tech startup two or three people dedicated toward mail deliverability: warming up IPs, securing domains, making sure we didn’t have spam or bounce-back rates that limited deliverability. Deliverability was a big deal until SendGrid came along.

You could still go with SendGrid. I wouldn’t use it. It feels like it’s 1980s software, even though I know it’s not true. But Twilio bought them and then essentially seemed to let them sit and rot in time. They haven’t kept up with a whole bunch of standards that are important.

Surprisingly, SendGrid has lost its place in my view of the tech stack. It hasn’t really changed. It’s kind of cryptic and hard to use—even though most of the core features in SendGrid are now part of Postmark. Postmark is hyper focused. It’s the scalpel to SendGrid’s machete.

Most founders think email deliverability is just the one feature they need. And so with Postmark, they don’t offer that much on paper. The real product is deliverability—and a focused operator you can actually run at high utilization.

Resend — drop-in peer, different tradeoff

What’s important to note is that there’s a drop-in replacement equally valuable and has the same utility level, which is Resend. I put Postmark in the same bucket as Resend: developer-friendly email infra with solid APIs.

Resend in some ways probably gets a slightly higher reuse and time-to-wow factor because it’s got a slightly cleaner UI—and its real power feature is that it gives you examples of how to do everything in code, which means MCP integration is just a little bit simpler and it is more designed to help non-technical coders get comfortable with mail delivery. Go read the Resend playbook entry for that side of the comparison.

Postmark quietly ships a killer feature that Resend still doesn’t: first-class email templates. I really wish Resend offered this level of templating. Until they do, Postmark keeps winning my “actually shippable for founders” vote when templates, streams, and webhook-driven engagement are part of the product—not just firing off a first transactional send.

The ignorance gap — webhooks and analytics

Webhooks and analytics. With one or two flags, you can enable analytics. You could know the open rate on pretty much any architecture. You turn on the feature and you give it a webhook to send the data back, and you can know if a customer opens an email, how often they open, and what they click on in it. It is a really simple solution to understand basic engagement on either your transactional or your non-transactional emails.

Analytics and webhook callback are often features that are ignored by both the developer and the product team. The product team doesn’t know you can do this. The tech team doesn’t see why it’s valuable. This is one of those features that falls into kind of an ignorance gap. I see it regularly that this feature is left off when it does amazing things for measuring observability.

You can give your support team the ability to understand the users who are ignoring input, not taking care of things, not responding. You can even measure the distance between the time sent, the time opened, and the time clicked to understand behavior of the customer.

Deliverability founders miss

Most people don’t—most non-technical founders don’t realize that email deliverability is an issue. If you abuse a domain or an IP address, you can have a lot of your email end up in spam folders. I still have to ping newsletter founders in which all their emails are missing basic deliverability. Their DMARC is missing, their SPF record is poorly performed, or they’re sending emails on their production primary root domain instead of a subdomain.

Email deliverability is super easy to ignore for the non-technical founder. But Postmark kind of makes it turnkey easy. You don’t have to do much to be good at email with Postmark.

What not to pitch investors

If you mention mail deliverability to your investor, you’re crazy. You’re not having the right conversation with your investor if you’re telling them that you’re 100% sure your emails are getting delivered.

But if you’re talking about the fact that you have a low-end solution that lets you measure user or customer engagement without having to bring in a heavy tech stack or without violating any terms and conditions or privacy policies, that’s a power feature.

How we use it — Supabase, Inngest, and the edge

Postmark is 100% vibe-codable with Supabase Edge functions: tell Cursor, Lovable, or Bolt you want Postmark, pull the npm package, and wire sends from edge handlers—not a separate mail microservice. Give your server API token to MCP if you want power-user setup without hand-rolling config.

We use Postmark for our mail delivery. Postmark has an API which we’ve hooked directly into our Inngest jobs. This allows us to have preset templates for things we need to do and allows us to send emails either transactional emails or potentially marketing emails.

We’ve tightly integrated our Stripe with our Postmark, with our Inngest, so that the processes work seamlessly and then that they know which signals need to be sent back out to the higher level to a Slack message so we can see what’s happening pattern wise.

See the stack map: Fractional.tools tech stack — Supabase for data, Inngest for jobs, Postmark for product email.

At a glance

• What it is: Deliverability-first mail—transactional and broadcast streams, templates, signatures, webhooks, open/click analytics—without becoming a mail ops team.
• Best for: Product and ops email you will actually measure; stacks where you want ~80% feature utilization, not one API call and ignore the rest.
• Not a fit: When you need a full marketing suite in one box—or when cleaner UI and Resend’s DX edge matter more than Postmark-grade templates (compare both entries).
• Peer pick: Resend — same utility band, swap-friendly; slightly higher time-to-wow for some stacks. SendGrid — viable, but not my pick.

When to reach for it

Reach for Postmark when deliverability and engagement observability matter and you will wire the full suite—DNS done right, streams separated, webhooks feeding your stack. Tell Bolt, Lovable, or Cursor you want Postmark; give your server API token to MCP if you want power-user setup without hand-rolling config.

Watchouts

DNS is real work: set up your domain records so you don’t shoot yourself in the foot. That is why time-to-wow is not instant— but it is also why you are not the newsletter founder missing DMARC on the root domain.

See it in the stack: Fractional.tools and the tech stack map — Postmark next to Supabase, Inngest, Stripe, and Slack signals in production.

In Stephan’s MCP workbench: Stephan’s MCP workbench — templates, signatures, tags, and both sides of edge-function email integration.

Related playbook entries

• Supabase — Postgres, auth, and edge functions; where Postmark sends are wired in production stacks.
• Resend — drop-in peer with a cleaner UI and higher time-to-wow for some stacks; compare before you commit.

Going deeper: An upcoming post on how I built my own newsletter CRM engine—Postmark as the layer for open rates, deliverability signals, and reader engagement. Subscribe if you want that when it ships.

AI prompts for vibe coding