Postmark deliverability: streams, signatures and policy limits

Postmark's design assumption is that transactional mail — receipts, password resets, notifications — should never share reputation with anything promotional. That assumption is enforced in the product through message streams, and most of what you need to do for deliverability on Postmark is to respect it.

Streams are the main deliverability feature

Each server has separate streams: a transactional stream, a broadcast stream for bulk or newsletter-style mail, and inbound. They are not labels. Mail sent through the wrong stream is the single most common self-inflicted Postmark problem, because a promotional send on a transactional stream drags your receipts' reputation with it.

Practical rules:

• Receipts, resets, alerts and anything a user is waiting for: transactional stream.
• Product announcements, digests, newsletters: broadcast stream, with unsubscribe handling.
• If a message has an unsubscribe link, it almost certainly belongs on broadcast.
• Keep the subdomains separate too, so reputation is split at the DNS level as well as inside the platform.

Authenticate the domain, not just the address

A sender signature verifies a single From address, which is enough to start sending but leaves the signing on Postmark's side. Add the domain instead: in the account's domain settings, Postmark gives you a DKIM record on a selector it generates plus a CNAME for a bounce/return-path subdomain. Publish both from the values on that screen — account-specific, and they change.

The return-path record is the part people skip. With it, SPF authenticates a subdomain you own and can contribute to DMARC alignment; without it, only DKIM can, which works until a forwarder breaks the signature.

Verify from the receiving side: send a real message, read the raw headers, and confirm dkim=pass with header.i= on your domain and dmarc=pass with header.from= on your domain.

Know the policy before you build

Postmark declines prospecting and purchased-list mail, and accounts are reviewed. This is not a quirk to work around; it is why their shared IPs perform well. Two consequences:

• Cold outreach does not belong on Postmark. One-to-one prospecting belongs on a real mailbox — Google Workspace or Microsoft 365 — where replies thread and the message looks like correspondence.
• Marketing to an opted-in list belongs on the broadcast stream, with genuine consent and working unsubscribes.

If your use case is cold email, choose a different path rather than hoping to stay under the radar.

Capture the data before it expires

Postmark's activity search and message detail are excellent — you can see the actual delivery event and the receiver's response for an individual message, which is more than most platforms show. But retention is finite, and the support question you need to answer always concerns a message from last month.

Set up webhooks on day one for delivery, bounce, spam complaint, open and link events, and store them yourself with the receiver's raw SMTP response string intact. That string is the diagnosis: a 421 or 451 deferral means slow down, a 550 5.7.1 means a policy or reputation block, and a 550 5.1.1 means the address is wrong. A bounce rate cannot distinguish those.

A bounce classified only as "hard" or "soft" by Postmark's own label hides which of these actually happened - the raw string is what tells you whether to fix your sending pattern or clean your list.

When a dedicated IP is worth asking about

Postmark keeps most customers on well-maintained shared infrastructure and separates reputation by stream, which removes most reasons to want a dedicated IP. A dedicated IP becomes relevant only at high and consistent volume — enough every day to keep it warm. Below that, the shared pool will outperform it, and you lose the dilution that a well-behaved pool provides. If you do get one, register it with Microsoft SNDS and the Junk Mail Reporting Program, since that feedback only goes to the IP's owner.

A short checklist

1. Add the domain and publish both the DKIM and return-path records; verify alignment from real headers.
2. Publish DMARC with a rua= address, start at p=none, read a week of reports, then tighten.
3. Put every message on the correct stream, and separate subdomains per stream.
4. Wire webhooks and store events, including the raw SMTP response.
5. Keep bounces out of your source system automatically — hard bounces removed, not just suppressed.
6. Measure placement per provider with seed testing, because Postmark can tell you a message was delivered but not which folder it reached.

What not to do

• Do not send promotional mail on a transactional stream to get "better" delivery. It damages the stream you depend on.
• Do not rely on a sender signature long-term. Domain authentication is the one that aligns.
• Do not treat a delivery event as inbox placement. It is an acceptance.
• Do not route a cold list through Postmark.
• Do not skip the return-path record because DKIM already passes. Forwarding is where that shortcut fails.

MailPilot connects to Postmark over SMTP and IMAP, so warm-up traffic takes the same path and carries the same signature as your production mail. It checks SPF, DKIM and DMARC on the sending domain, measures real inbox placement per provider through its seed network, and tracks reputation per mailbox daily — the folder-level view that no delivery event can give you.