We would love to see native support for the Postmark API as an additional sending method alongside SendGrid.

Many businesses already use Postmark for all transactional email because of its outstanding deliverability, reliability, and developer experience. It would be great if MailPoet could leverage the same infrastructure for newsletters and marketing automations without relying on SMTP.

Why this matters

Using Postmark via SMTP works well, but it has several disadvantages compared to a native API integration:

Slower delivery of large campaigns due to SMTP overhead.

Less reliable throughput for high-volume newsletters.

No access to Postmark-specific features such as Message Streams, Tags, Metadata, and server-side optimizations.

Additional SMTP configuration instead of a simple API token.

A native API integration would provide faster campaign delivery while maintaining MailPoet's existing features such as segmentation, automations, open tracking and click tracking.

Requested features

Native Postmark API authentication using Server API Token.

Support for Broadcast Message Streams.

Optional support for Transactional Message Streams.

Ability to select the Message Stream from within MailPoet.

Support for Tags and Metadata.

Optional webhook integration for bounces, spam complaints and delivery events where appropriate.

Why Postmark?

Postmark has become a popular choice for companies that value high deliverability and a simple, reliable infrastructure. Many WordPress sites already use Postmark for WooCommerce, Gravity Forms and WordPress system emails. Native MailPoet support would allow users to consolidate all email sending on one platform while avoiding SMTP bottlenecks.

This would be a valuable addition alongside the existing SendGrid integration and would likely be appreciated by many professional users.