Postmark delivers fast — but “delivered” is not “inboxed”

Postmark is the developer-favourite transactional ESP. The API is tight, the webhook events are reliable, the message streams model forces you to separate transactional from broadcast. It is one of the ESPs where “delivered” actually means the receiving mail server accepted the message. That is already a better guarantee than most.

But delivered still is not inboxed. Gmail accepts the message, applies its tab classifier, and routes to Primary, Promotions, or Spam. Microsoft accepts the message and applies junk scoring. Postmark cannot tell you where that routing ended, because Postmark never sees it. Only the recipient’s mailbox can tell you, which is why seeds are the answer.

Postmark’s message streams model

Postmark requires you to choose a message stream when sending. There are two kinds:

• Transactional streams. Default for API sends. Designed for password resets, receipts, 2FA, notifications. Treated by Postmark and receiving providers as high-priority, low-volume, high-expected-engagement mail.
• Broadcast streams. For marketing and newsletters. Treated by receivers as bulk mail, with different reputation expectations.

The streams model exists precisely because mixing transactional and marketing on one IP pool is a classic deliverability foot-gun. Postmark enforces the split. But even with the split, each stream has its own reputation and its own placement pattern at each receiver. You need seed testing on both.

Where transactional placement goes wrong

Transactional emails fail in specific, repeatable ways:

• Gmail Promotions. A receipt that has a marketing footer, a social-share block, or too many links ends up in Promotions. The user does not see it when they expect to.
• Outlook Junk. Misaligned DMARC or a new IP Microsoft has not seen before. Password reset lands junk, user files a support ticket.
• Delay at Yahoo. Yahoo throttles aggressively. A 2FA code arriving after 2 minutes is a UX failure that no Postmark metric will flag.
• ProtonMail and niche providers. These have strict spam rules. A template that passes at Gmail and Outlook can still fail here.

Postmark’s dashboard shows delivery rate, bounce rate, spam complaint rate. It does not show Primary-tab placement at Gmail or Junk verdicts at Microsoft. You can have a 99.9 percent delivery rate and still route 15 percent of mail to Promotions.

Seed BCCs on critical templates

Pick the templates where placement failure hurts most. These are the critical set:

1. Password reset.
2. Two-factor authentication code.
3. Email address verification on signup.
4. Payment receipt or invoice.
5. Account security alert (new login, password change).

For each of these, configure your mail-sending helper to optionally BCC a panel of seed mailboxes. The BCC is invisible to the real user. Each seed receives a copy that lets you inspect placement.

The Postmark API accepts Bcc as a comma-separated string. A minimal request body using a template looks like this:

POST https://api.postmarkapp.com/email/withTemplate HTTP/1.1
Accept: application/json
Content-Type: application/json
X-Postmark-Server-Token: abcd-ef12-3456-7890

{
  "From": "no-reply@example.com",
  "To": "user@example.com",
  "Bcc": "seed-gmail@your-seed-domain.test, seed-outlook@your-seed-domain.test, seed-yahoo@your-seed-domain.test",
  "TemplateAlias": "password-reset",
  "TemplateModel": {
    "product_name": "Example",
    "reset_url": "https://app.example.com/reset?token=xyz",
    "support_email": "support@example.com"
  },
  "MessageStream": "outbound"
}

The seed panel receives a copy that is byte-identical at the message level. What differs is the envelope (the BCC addresses are not in the visible To header), but the body, subject, merge-rendered HTML, and headers are the same.

Synthetic hits as an alternative

For template monitoring, synthetic tests are cleaner than BCC. A cron job hits your own reset endpoint every 15 minutes with a seed recipient. The seed receives a real reset email, generated end-to-end by your application. Advantages over BCC:

• Privacy is intact — you are not copying real user mail.
• The test exercises your full stack, not just Postmark.
• Schedule is predictable, so regressions alert on a known cadence.
• The seed volume to each mailbox stays natural.

Message stream reputation monitoring

Postmark maintains reputation per stream. A broadcast campaign with a high complaint rate can affect that stream’s deliverability on its assigned IP pool. Your transactional stream is sheltered by the architecture, but not immune — if you ever use Postmark’s shared IPs for both, a neighbour’s problem still bleeds over.

Seed testing per stream gives you per-stream placement data:

• Seeds for transactional: focus on Primary placement at Gmail, Inbox at Outlook, no delay at Yahoo.
• Seeds for broadcast: focus on Promotions versus Primary at Gmail, engagement patterns over a week, DMARC alignment.

When the data diverges — transactional still inboxing, broadcast suddenly in Junk — you know the problem is scoped to the broadcast stream and you can act accordingly.

FAQ