Connecting Postmark to n8n: transactional emails, Message Streams and bounce webhooks

A failed transactional email — order confirmation, password reset, invoice — costs more than a failed marketing email: a customer doesn't chase a missing newsletter, but they do contact support when their invoice never shows up. Postmark built its reputation on exactly this point: maximum deliverability for transactional mail, strict separation from marketing via Message Streams, and webhooks that report every bounce within seconds. Pairing that rigor with an n8n workflow lets you close the loop automatically — a failed send triggers an action, not silence.

What n8n provides natively (and what you have to build yourself)

n8n includes a native Postmark Trigger node, which receives Postmark's incoming webhooks (bounce, open, click, spam complaint, inbound email). For receiving events, no manual HTTP setup is needed: the node generates its own webhook URL and handles the subscription.

There is, however, no dedicated Postmark action node for sending. Sending an email goes through a regular HTTP Request node, exactly as described in our guide to the HTTP Request node for driving a REST API — a limitation that mirrors the one you hit with Resend, where the API is likewise called via a raw HTTP Request rather than a dedicated node.

Verifying a sender before the first send

Postmark refuses any send until the From address is attached to a confirmed sender signature (a single address validated by a confirmation email) or a verified domain (DNS: SPF, DKIM, and a Return-Path for bounce tracking). Without this step, every API call returns a 422 error — unlike some competing APIs that allow an unverified test send from a shared domain.

This strictness around authentication isn't arbitrary. A study by Tatang, Zettl and Holz, presented at the RAID 2021 conference (« The Evolution of DNS-based Email Authentication: Measuring Adoption and Finding Flaws », see on Google Scholar), shows that adoption of SPF, DKIM and DMARC remains very uneven across the web as a whole, and that domains properly covered by all three protocols meaningfully cut their exposure to spoofing and spam classification. Requiring verification before any send, as Postmark does, effectively enforces that baseline instead of leaving it to each sender's discretion.

Once the domain is added and the DNS records pasted at the registrar, the status switches to Verified in the Postmark dashboard (Sender Signatures or Domains tab) — usually within minutes, depending on DNS propagation.

Sending an email with the HTTP Request node

The HTTP Request node calls the Postmark API with this configuration:

• Method: POST
• URL: https://api.postmarkapp.com/email
• Authentication: a Header Auth credential, header X-Postmark-Server-Token, value the Server API Token (found under the API Tokens tab of the relevant Postmark server)
• JSON body: From (verified address), To, Subject, HtmlBody and/or TextBody, and optionally MessageStream (see below)

To test without any risk of a real send, replace the Server API Token with the literal value POSTMARK_API_TEST: Postmark responds normally (same response structure) but delivers nothing — useful for validating a workflow before wiring in the real production token, on the same principle as the test mode described in our guide to Stripe webhooks.

For emails with attachments (a PDF invoice, a CSV export), the Attachments field accepts an array of objects with Name, Content (base64-encoded) and ContentType — content generated upstream by a PDF invoice built in the same workflow or fetched via the Convert to File node.

Separating transactional and marketing with Message Streams

A Message Stream is an isolated sending channel, with its own deliverability reputation, its own statistics, and its own webhooks. Every Postmark server has a default outbound stream for transactional mail, and can add a broadcast-type stream for marketing sends or newsletters.

This separation matters in practice: a marketing send spike (a newsletter, a promo campaign) that hurts a domain's reputation should never push a password-reset email into spam. By specifying MessageStream in the HTTP Request body (for example "outbound" for transactional mail), the n8n workflow preserves that boundary — useful if the same site also sends an automatic newsletter generated from an RSS feed: the two use cases should never share the same stream.

Reacting to bounces with the Postmark Trigger

The Postmark Trigger node receives the events configured under the Webhooks tab of a Postmark stream: Bounce, Open, Click, SpamComplaint, Delivery, or InboundMail depending on the stream type. Each Bounce event in particular distinguishes a HardBounce (invalid address, permanent) from a SoftBounce (full mailbox, temporarily unavailable server) — a distinction the workflow should handle differently:

1. The Postmark Trigger node receives the Bounce event.
2. An IF or Switch node (see our guide to conditional routing) separates HardBounce from the other types.
3. On a HardBounce, the address gets flagged as invalid in the CRM or database — the same reflex described in our guide to automated follow-ups, where any follow-up sequence must first check that the contact channel is still valid before insisting.
4. For other cases, the workflow can simply log the event or alert the support team via a Slack bot past a certain threshold.

A concrete case: invoice sent, tracked, and followed up if needed

A full scenario shows why pairing the API with a webhook beats sending an email "blind":

1. An invoicing workflow generates the PDF invoice and triggers the send via POST /email, keeping the MessageID Postmark returns alongside the invoice number in a Supabase table (see our Supabase connection guide).
2. The Postmark Trigger listens for Delivery and Bounce events on the stream, and updates that same table as soon as a status changes.
3. If no Delivery event shows up within a reasonable window and a HardBounce arrives instead, a second scheduled workflow (see our Schedule Trigger guide) follows up on the invoice through an alternate channel — SMS via Twilio or a direct message on an already-connected CRM.

This pattern — send, track via webhook, escalate on failure — turns an email send from a one-off, silent action into a process whose outcome you always know, without ever having to ask the customer whether they actually received their document.

---

To go further: the email automation and invoicing workflows in the Compliance & Audit Pack and the RAG Assistant Pack already include these traceability patterns, ready to adapt to your own stack.