Postmark Broadcast Vs Transactional Streams Explained

Postmark’s Broadcast and Transactional Message Streams are designed to keep two very different kinds of email separate: messages an individual needs because of something they did, and messages an organisation chooses to send to a group of subscribers or users.

That separation matters because a password reset and a newsletter have different delivery expectations, different recipient expectations and different reputation risks. A delayed password reset can lock someone out of an account. A product update sent to an unengaged list can generate complaints, unsubscribes and low engagement. Treating both as identical SMTP traffic is an avoidable operational risk.

Postmark routes Transactional and Broadcast streams through separate infrastructure, including separate IP ranges. Its own guidance describes Transactional streams as one-to-one messages prompted by a user action, while Broadcast streams are for one-to-many sends such as newsletters, announcements and product updates. Postmark’s Message Streams guide also recommends distinct streams and subdomains for the two categories.

What is a Transactional Message Stream?

A Transactional stream is for expected, individual application email where the message is closely connected to a recipient’s account, activity or request. It should normally be sent automatically and promptly as the result of a specific event.

Typical examples include:

• password resets and email-verification links;
• receipts, invoices and payment-failure notices;
• order confirmations, delivery updates and cancellation confirmations;
• account invitations and security alerts;
• contact-form auto-replies and requested support updates.

“Transactional” is not simply a label for any email produced by software. The useful test is whether the recipient reasonably expects that specific message because of an action, status or service relationship. A welcome email sent immediately after registration can be transactional. A “welcome” sequence sent over the next month to encourage a paid upgrade is marketing and should be handled as Broadcast traffic.

Postmark’s Transactional streams are intended for one-to-one email and do not support bulk messages. The distinction is intended to protect the speed and reliability expected of application email. Postmark’s definition of transactional email is especially clear that product announcements and promotional marketing do not belong in a Transactional stream.

What is a Broadcast Message Stream?

A Broadcast stream is for application-driven bulk email: a message selected, scheduled or triggered by the sender and delivered across a stored audience. It may still be highly relevant and permission-based. “Broadcast” does not mean indiscriminate email; it means the same campaign, update or class of message is being distributed to many recipients.

Common examples are:

• newsletters and editorial round-ups;
• product announcements and release notes;
• promotions and renewal campaigns;
• scheduled activity digests;
• updates to terms, policies or service communications where the message is sent across a broad audience.

Personalisation does not turn a broadcast into a transaction. Adding a first name, a tailored content block or account usage data to a monthly digest may make the email more useful, but it remains a Broadcast send if it is sent on a planned cadence to a segment or list.

Postmark requires unsubscribe management for Broadcast Message Streams. Its default is Postmark-managed unsubscribes, while approved accounts can use custom unsubscribe management. That is a practical safeguard, but it does not replace a sender’s own permission records, suppression logic or preference-centre design. Postmark’s Message Streams API documentation sets out the unsubscribe-management options for each stream type.

The difference in practice

Question	Transactional	Broadcast
Why is it sent?	To fulfil or support an individual account action, request or service event.	To communicate a campaign, update, digest or announcement to an audience.
Who receives it?	Usually one person whose action or account state caused the send.	A list, segment or group of subscribers, customers or users.
How quickly must it arrive?	Often immediately or within minutes.	Usually important, but seldom dependent on an individual real-time action.
Can the recipient opt out?	Often not for essential service or security messages, although notification preferences may still be appropriate.	Normally yes, particularly for marketing and optional product communications.
Example	“Use this link to reset your password.”	“See what’s new in this month’s release.”

The categorisation also affects how problems should be investigated. A sudden rise in bounces from a transactional password-reset flow may point to a form-validation, account-data or integration issue. Poor Broadcast engagement may point instead to stale consent, excessive frequency, a weak audience fit or a campaign that was sent too broadly. Keeping the streams separate makes those patterns easier to see.

How to decide when a message sits on the boundary

Some messages genuinely have characteristics of both categories. Legal notices, event updates, activity digests and certain service announcements are common examples. The recipient count alone cannot resolve every case.

Start with the reason for sending:

• Was it caused by one recipient’s action or account condition? An individual failed-payment notice or an event change affecting that person’s booking is normally Transactional.
• Is it being sent to a saved list or segment? That is a strong Broadcast signal, even if each email contains personalised details.
• Would a reasonable recipient expect it immediately? A one-time login code clearly needs Transactional treatment. A weekly account summary generally does not.
• Can people choose not to receive it? If so, it is likely Broadcast. Make that choice easy to exercise.
• Is the content partly promotional? Put the promotional material in Broadcast. Do not use a service notification to bypass marketing preferences.

Postmark’s own classification guidance recognises that legal notices, event updates and activity digests can be context-dependent. Urgency, whether the message is required, whether it is automated, whether it is sent to a stored list and whether the recipient can opt out are all relevant factors. Its Transactional vs Broadcast guide is a useful decision reference, but senders should document their own classification rules so that marketing, product and engineering teams apply them consistently.

Examples of borderline messages

Monthly usage digest: Usually Broadcast, even when every user receives different metrics. It is periodic, audience-based and normally optional.

Subscription renewal reminder: It depends on the content and expectation. A message needed to prevent an imminent interruption to a service the customer has bought may be transactional in character. A general “renew now and save” campaign is Broadcast.

Terms-of-service update: A genuinely necessary notice may warrant Transactional treatment where it is tied to an active account relationship and must reach the user. A broad announcement about policy changes, especially if it includes promotional messaging or goes to inactive contacts, belongs in Broadcast. Keep a clean version of the required notice separate from marketing content.

Security notification: A warning that a new device has signed in is Transactional. A monthly email encouraging users to review security settings is better treated as Broadcast unless it responds to a particular account risk.

How Postmark stream selection works

Each Postmark server has a default Transactional stream. If an application does not specify a stream when it sends through the API, Postmark uses that default. This is convenient for a purely transactional application, but it creates a real implementation risk when a product later adds newsletters or scheduled digests: a developer can unintentionally route Broadcast mail into the Transactional stream by omitting the stream ID.

For API sends, set the MessageStream field explicitly. For example:

{
  "From": "updates@news.example.com",
  "To": "member@example.net",
  "Subject": "September product update",
  "HtmlBody": "<html>...</html>",
  "MessageStream": "broadcasts"
}

For SMTP, Postmark documents a separate Broadcast host, smtp-broadcasts.postmarkapp.com, and supports stream selection via an X-PM-Message-Stream header or per-stream SMTP credentials. Its Transactional SMTP host is different. The setup documentation gives the current configuration details.

Do not rely only on a user-interface setting. Build the classification into the sending code and test it. A sensible release test checks that password resets use the intended Transactional stream, that campaigns use the Broadcast stream, and that a message cannot silently fall back to the default stream because an environment variable was missing.

When sending a campaign, create one message per recipient rather than exposing a list through visible recipient fields. This also gives the sending system the opportunity to apply per-recipient preferences, language choices, suppression rules and metadata before a message is queued.

Separate streams are useful, but they do not isolate every reputation signal

Postmark’s infrastructure separation is valuable: weak engagement or complaint risk in a Broadcast campaign should not directly share the same Postmark IP range as password resets and receipts. It is still a mistake to regard streams as a permission or deliverability workaround.

Mailbox providers evaluate more than an IP address. They assess authentication, sending-domain reputation, complaint behaviour, recipient engagement and message patterns. Google advises senders to use different IPs for different message types where multiple IPs are necessary, to keep message categories on consistent From addresses, and to authenticate mail correctly. Google’s email sender guidelines also require bulk senders to use SPF, DKIM and DMARC, align the visible From domain with SPF or DKIM, and provide one-click unsubscribe for marketing and subscribed messages.

A separate sending subdomain is therefore a sensible companion to a separate Postmark stream. For example, an organisation might use notify.example.com for account and receipt mail, and news.example.com for newsletters. Each needs its own authentication setup. Postmark explains that DKIM and Return-Path settings are domain-specific, so a subdomain must be added and verified individually. Its subdomain guidance explains the related DNS requirements.

This is reputation separation, not a licence to send unwanted email from a fresh subdomain. Google counts the bulk-sender threshold across the same primary domain, including subdomains, and says senders that meet the threshold are permanently classified as bulk senders. Google’s sender-guidelines FAQ also recommends keeping reported spam rates below 0.1% and avoiding 0.3% or higher.

Operational controls that matter most for Broadcast mail

Broadcast streams need more deliberate audience controls than transactional flows. Before a large send, apply global unsubscribes, relevant topic preferences, hard-bounce suppressions and any internal suppression rules. Send only to people with the appropriate permission and a credible reason to expect the message.

Frequency deserves similar care. A contact who has not interacted with a programme for a long time may receive many campaigns but contribute little positive engagement. A re-permission or re-engagement approach, followed by suppression where appropriate, is usually safer than repeatedly increasing contact pressure.

Ramp new Broadcast traffic gradually rather than releasing an unfamiliar volume or a radically changed template to the entire database at once. Google specifically recommends a consistent sending rate, gradual volume increases to engaged users, and reducing volume when bounces or deferrals begin. This is particularly relevant when moving an existing newsletter onto Postmark or introducing a new sending subdomain.

For permission-based organisations dealing with a delivery decline, Email Foundry’s work is most relevant around the boundary between stream design and operational reality: checking authentication and infrastructure, validating suppression and audience logic, monitoring provider feedback, and managing a controlled recovery rather than simply moving problematic Broadcast traffic into a Transactional route.

Common mistakes to avoid

Putting newsletters into Transactional because they are important

Importance does not make an email transactional. A product launch may be commercially important, but it is still a broadcast campaign if it is selected and sent to an audience. Misclassification risks service disruption and undermines the protection the streams are intended to provide.

Including a promotional block in an essential account email

A receipt can contain a restrained service message, but turning it into a sales campaign muddies consent and classification. Keep an essential notification focused on the transaction. Send optional marketing separately through Broadcast, subject to the recipient’s preferences.

Assuming the stream solves authentication

Stream selection does not create SPF, DKIM or DMARC alignment. Verify each sending domain or subdomain, configure DKIM and a custom Return-Path where appropriate, and examine real delivered headers to confirm that authentication works as intended.

Treating an API batch as a stream choice

Postmark’s batch endpoint can submit up to 500 messages in one API request, but batching is an efficiency mechanism rather than a classification decision. A Broadcast message in that batch must still specify the Broadcast MessageStream. Postmark’s API sending guide documents the default stream behaviour and batch requirements.

The practical rule

Use Postmark Transactional Streams for prompt, individual messages that recipients need because of a specific action or account event. Use Broadcast Streams for permission-based announcements, digests, newsletters and campaigns sent across an audience.

Where a message is debatable, classify it by the recipient’s expectation and the reason for the send, then keep promotional content, preferences, suppression handling and reporting appropriately separate. That approach protects the messages users depend on while giving Broadcast email the audience management it requires.

Frequently asked questions

Can Postmark Broadcast streams send personalised email?

Yes. A Broadcast message can use per-recipient content and still be a Broadcast send. The deciding factor is usually that it is being sent to an audience or segment as a campaign, digest or update, rather than in response to one person’s immediate action.

Do Transactional emails need an unsubscribe link?

Essential, event-driven transactional messages generally do not need a marketing unsubscribe link. However, optional notifications should be governed by user preferences, and promotional or subscribed mail should be sent through a Broadcast stream with appropriate unsubscribe handling.

Can I use the same From domain for Postmark Broadcast and Transactional streams?

You can, but separate sending subdomains are often easier to manage operationally because they distinguish message types and their reputations. Each subdomain needs its own authentication and verification configuration.

What happens if I do not specify MessageStream in the Postmark API?

Postmark uses the server’s default Transactional stream. Applications that send both categories should explicitly set MessageStream for every send, especially for Broadcast traffic.

Sources and further reading

• How to create and send through Message Streams — Postmark
• Transactional vs. Broadcast — Postmark
• Message Streams API — Postmark
• Email sender guidelines — Google
• Email sender guidelines FAQ — Google
• How to send from subdomains — Postmark