Postmark for WordPress: Approval, Message Streams, and Why It Is Strict

Postmark has an unusually strong reputation for transactional delivery, and it maintains it by being stricter than its competitors about what you may send. That strictness is the product. It also means two things surprise WordPress users, and both are better known in advance.

1. Every new account is manually reviewed

You cannot sign up and start sending. New accounts go through manual approval, typically around a day, and until it completes sending is restricted to verified addresses.

This is a deliberate quality gate — it is part of why their delivery is good — but it means Postmark is the wrong provider to choose on launch day. Set it up a week ahead.

Approval is more straightforward if you describe your sending accurately: what the mail is, that it is transactional, that recipients are your own customers, and how you handle bounces. Vague answers get follow-up questions and another day.

2. Message Streams are not optional

This is the one that generates support tickets.

Postmark separates mail into Message Streams, and the distinction is enforced rather than advisory:

• Transactional streams — mail a specific person triggered and expects. Order confirmations, password resets, receipts, shipping notifications.
• Broadcast streams — mail sent to many people who did not individually trigger it. Newsletters, announcements, promotions.

Sending broadcast mail through a transactional stream will get it rejected, and repeated attempts put your account at risk. Postmark is explicit that this is not a guideline.

For a typical WordPress site this is simple: WooCommerce order emails, password resets and form notifications are transactional. If you also send a newsletter, that needs a separate broadcast stream — or, more sensibly, a different tool built for it.

The practical error is subtler than it sounds. A plugin that emails every customer about a sale is broadcast mail, even though it comes from the same store as your order confirmations.

Setting it up

1. Create your account early and complete approval before you need it.
2. Add and verify your domain, publishing the DKIM record and Return-Path record Postmark provides. Publish them at the DNS host your nameservers point to, not necessarily your registrar.
3. Note the Return-Path record. Postmark uses a custom Return-Path for SPF alignment, and skipping it is a common reason DMARC fails on an otherwise correct setup.
4. Use a Server API token scoped to the server you are sending from, rather than an account token.
5. Confirm the stream your integration is using is the transactional one.
6. Test and read the headers — spf=pass dkim=pass dmarc=pass.

What Postmark will not let you send

Worth knowing before you build a workflow around it, because the restrictions are enforced rather than advisory.

• Purchased or scraped lists. Not permitted in any stream. Accounts doing this are suspended.
• Bulk mail through a transactional stream. Rejected, and repeated attempts put the account at risk.
• Mail to addresses that hard-bounced. Suppressed automatically; continuing to try affects your standing.
• High-complaint content. Postmark monitors complaint rates more actively than most and will contact you about them.

For an ordinary WordPress store none of this is a constraint — order confirmations and password resets are exactly what the service is for. It becomes a constraint the moment somebody installs a plugin that emails every customer about a sale, which is broadcast mail regardless of the store it came from.

Getting approved without a delay

Approval is a human reading your description. Vague answers produce follow-up questions and another day, which matters if you have a launch date.

Include, specifically: what the emails are (order confirmations, password resets, shipping notifications), that recipients are your own customers who transacted with you, roughly how many you expect to send, and that you have bounce handling in place. That is usually enough.

What causes delays: describing the mail as “notifications” without saying what triggers them, giving no volume estimate, or anything that reads like it might be marketing.

Where Postmark fits

Choose it if transactional delivery is genuinely important — a store where a missed order confirmation is a support ticket and a refund risk. Its delivery record and its detailed per-message logs are the reason to pay slightly more.

Choose something else if you need to send at high volume cheaply, if you need marketing and transactional in one tool, or if you need to be sending today.

Against the alternatives: Amazon SES is cheaper at volume but has far more setup friction and a per-region sandbox. Resend is quicker to set up with no approval wait. SendGrid sits between them and is more permissive about what you send, which is the trade-off that produces its comparatively weaker reputation.

After setup

Postmark’s logs are among the best in the category — per-message detail on delivery, opens and bounces. Use them before assuming a WordPress problem, because they tell you what happened after Postmark accepted the message.

Their bounce handling is also strict: hard-bounced addresses are suppressed, and continuing to send to them affects your account standing. If a test address fails while customers receive mail normally, check suppressions first.

As with any provider, domain authentication depends on DNS records outside your site. NimblyMail’s weekly audit re-verifies SPF, DKIM, DMARC and connectivity against your configured mailer, so a Return-Path record removed during an unrelated DNS change is reported rather than discovered later.