sales-postmark

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Postmark Platform Help

Postmark平台帮助

Help the user with Postmark (ActiveCampaign) platform questions — from transactional email via the REST API and SMTP relay through Message Streams, Handlebars Templates, Inbound Email, Webhooks, DMARC Monitoring, Bounce Management, Suppressions, Statistics, and integrations. Postmark is laser-focused on transactional email with best-in-class deliverability (98.7% inbox placement), originally built by Wildbit (Natalie & Chris Nagele) and acquired by ActiveCampaign in 2022.

为用户解答Postmark（ActiveCampaign旗下）平台的相关问题，涵盖通过REST API和SMTP中继发送事务性邮件、消息流、Handlebars模板、入站邮件、Webhook、DMARC监控、退信管理、拒收列表、统计数据及集成等全方面内容。Postmark专注于事务性邮件领域，拥有行业领先的投递能力（收件箱到达率98.7%），最初由Wildbit（Natalie & Chris Nagele）开发，2022年被ActiveCampaign收购。

Step 1 — Gather context

步骤1 — 收集上下文

Ask the user:

What area of Postmark do you need help with?
- A) Email API — sending transactional email via REST API (
```
POST /email
```
  ,
```
POST /email/batch
```
  ), SDKs
- B) SMTP relay — traditional SMTP integration for frameworks that don't support API
- C) Message Streams — separating transactional and broadcast (newsletters/announcements) infrastructure
- D) Templates — server-side Handlebars templates, layout inheritance, cross-server pushing
- E) Inbound Email — receiving and parsing incoming emails via webhook
- F) Webhooks — bounce, delivery, open, click, spam complaint, subscription change, inbound events
- G) DMARC Monitoring — free weekly DMARC reports, paid detailed monitoring
- H) Bounce Management / Suppressions — automatic bounce processing, suppression lists
- I) Statistics — opens, clicks, delivery rates, bounce rates, spam complaints
- J) Sender Signatures — verified sender addresses and domains
- K) Account / Billing — plans, pricing, servers, API tokens
- L) Something else — describe it
What's your role?
- A) Developer / engineer
- B) DevOps / infrastructure
- C) Admin / account owner
- D) Founder / solo operator
- E) Agency / freelancer
- F) Other
What are you trying to accomplish? (describe your specific goal or question)

If the user's request already provides most of this context, skip directly to the relevant step. Lead with your best-effort answer using reasonable assumptions (stated explicitly), then ask only the most critical 1-2 clarifying questions at the end — don't gate your response behind gathering complete context.

Note: If the user needs a specialized skill, route them there with a brief explanation of why that skill is a better fit.

询问用户以下信息：

你需要Postmark哪个板块的帮助？
- A) 邮件API — 通过REST API（
```
POST /email
```
  、
```
POST /email/batch
```
  ）、SDK发送事务性邮件
- B) SMTP中继 — 为不支持API的框架提供传统SMTP集成能力
- C) 消息流 — 隔离事务性和广播类（通讯/公告）邮件的底层基础设施
- D) 模板 — 服务端Handlebars模板、布局继承、跨服务器同步
- E) 入站邮件 — 通过webhook接收和解析 incoming 邮件
- F) Webhook — 退信、送达、打开、点击、垃圾邮件投诉、订阅变更、入站事件
- G) DMARC监控 — 免费周度DMARC报告、付费精细化监控
- H) 退信管理/拒收列表 — 自动退信处理、拒收名单
- I) 统计数据 — 打开率、点击率、送达率、退信率、垃圾邮件投诉率
- J) 发件人签名 — 已验证的发件人地址和域名
- K) 账户/账单 — 套餐、定价、服务器、API令牌
- L) 其他 — 请描述具体内容
你的角色是什么？
- A) 开发者/工程师
- B) DevOps/基础设施运维
- C) 管理员/账户所有者
- D) 创始人/独立运营者
- E) 代理商/自由职业者
- F) 其他
你想要实现什么目标？（描述你的具体需求或问题）

**如果用户的请求已经提供了大部分上下文信息，可以直接跳到对应步骤。**优先基于合理假设（需要明确说明假设内容）给出尽可能全面的解答，最后只补充询问1-2个最关键的澄清问题，不要要求用户提供完全部信息才给出回复。

注意：如果用户需要更专业的相关技能支持，引导用户到对应技能入口，并简要说明该技能更适配的原因。

Step 2 — Route or answer directly

步骤2 — 引导到对应技能或直接解答

If the request maps to a specialized skill, route:

General email marketing strategy / best practices ->
```
/sales-email-marketing
```
Cross-platform email deliverability (not Postmark-specific) ->
```
/sales-deliverability
```
Email open/click tracking strategy ->
```
/sales-email-tracking
```
SendGrid-specific questions ->
```
/sales-sendgrid
```
Connecting Postmark to other tools via Zapier or middleware ->
```
/sales-integration
```
Funnel strategy / conversion optimization ->
```
/sales-funnel
```

Otherwise, answer directly from platform knowledge using the reference below.

如果用户请求匹配以下专项技能，引导到对应入口：

通用邮件营销策略/最佳实践 ->
```
/sales-email-marketing
```
跨平台邮件投递能力（非Postmark专属） ->
```
/sales-deliverability
```
邮件打开/点击追踪策略 ->
```
/sales-email-tracking
```
SendGrid专属问题 ->
```
/sales-sendgrid
```
通过Zapier或中间件将Postmark连接到其他工具 ->
```
/sales-integration
```
转化漏斗策略/转化率优化 ->
```
/sales-funnel
```

其他情况直接基于下方的平台知识库直接解答。

Step 3 — Postmark platform reference

步骤3 — Postmark平台参考资料

Provide module-by-module guidance based on the user's area:

根据用户需求的板块提供对应模块的指引：

Email API (transactional)

邮件API（事务性）

Single email:
```
POST /email
```
— send a single transactional email with full control over headers, content, attachments, tracking, and metadata
Batch email:
```
POST /email/batch
```
— send up to 500 messages in a single API call (50MB payload limit)
Bulk API: Newer high-volume sending endpoint for large-scale sends
Payload limits: 10MB per single email, 50MB per batch request
Metadata: Attach custom key-value metadata to messages for tracking and filtering
Tags: Categorize messages with tags for filtering in statistics and Activity
Test token: Use
```
POSTMARK_API_TEST
```
as the server token to test API calls without sending real email — returns a success response but does not deliver

单封邮件：
```
POST /email
```
— 发送单封事务性邮件，可完全自定义头部、内容、附件、追踪规则和元数据
批量邮件：
```
POST /email/batch
```
— 单次API调用最多发送500封邮件（请求体上限50MB）
批量API：面向大规模发送场景的新高并发发送端点
请求体限制：单封邮件上限10MB，批量请求上限50MB
元数据：可以为邮件附加自定义键值对元数据，用于追踪和筛选
标签：为邮件添加标签分类，方便在统计数据和活动日志中筛选
测试令牌：使用
```
POSTMARK_API_TEST
```
作为服务器令牌测试API调用，不会实际发送邮件，仅返回成功响应

SMTP relay

SMTP中继

Host:
```
smtp.postmarkapp.com
```
Port: 587 (STARTTLS) or 2525 (alternative)
Authentication: Username and password are both your server API token
Use case: Drop-in replacement for frameworks and applications that only support SMTP (WordPress, legacy apps, etc.)
Headers: Use custom headers (
```
X-PM-Message-Stream
```
,
```
X-PM-Tag
```
,
```
X-PM-Metadata-*
```
) to control stream, tagging, and metadata via SMTP

主机地址：
```
smtp.postmarkapp.com
```
端口：587（支持STARTTLS）或2525（备用端口）
认证：用户名和密码均为你的服务器API令牌
适用场景：为仅支持SMTP的框架和应用（WordPress、遗留应用等）提供开箱即用的替换方案
自定义头部：使用自定义头部（
```
X-PM-Message-Stream
```
、
```
X-PM-Tag
```
、
```
X-PM-Metadata-*
```
）通过SMTP控制消息流、标签和元数据

Message Streams

消息流

Transactional stream: Default stream for password resets, order confirmations, receipts, alerts — messages recipients expect and need
Broadcast stream: Separate stream for newsletters, announcements, product updates — messages recipients opted into but are not time-sensitive
Why it matters: Broadcast email has inherently lower engagement than transactional. Separating streams keeps broadcast reputation issues (unsubscribes, spam complaints) from impacting transactional delivery speed and inbox placement
Default behavior: Every server starts with a default transactional stream. Broadcast streams must be created explicitly
Stream ID: Pass the
```
MessageStream
```
field in API requests to route messages to the correct stream
Limits: Up to 10 message streams per server (configurable)

事务性流：默认流，用于发送密码重置、订单确认、收据、告警等用户预期且需要的邮件
广播流：独立流，用于发送通讯、公告、产品更新等用户订阅但非时效性要求的邮件
设计价值：广播类邮件的天然参与度低于事务性邮件，隔离流可以避免广播邮件的声誉问题（退订、垃圾邮件投诉）影响事务性邮件的投递速度和收件箱到达率
默认行为：每个服务器初始自带默认事务性流，广播流需要手动创建
流ID：在API请求中传入
```
MessageStream
```
字段将邮件路由到对应流
限制：每个服务器最多支持10个消息流（可申请调整）

Templates

模板

Handlebars syntax: Use

{{variable}}

{{#if}}

{{#each}}

{{#unless}}

{{#unless}}

for dynamic content

Layout inheritance: Create a base layout template (header, footer, wrapper) and have content templates inherit from it — change the layout once, all templates update
Template validation: Postmark validates templates at save time — catches missing variables and syntax errors before you send
Cross-server pushing: Push templates from one server to another (e.g., staging to production) via the API or UI
Template API: Full CRUD operations — create, read, update, delete templates programmatically
Sending with templates: Pass
```
TemplateId
```
or
```
TemplateAlias
```
plus
```
TemplateModel
```
(data object) in the send request instead of raw HTML/text
Preview: Render a template with test data via the API (
```
POST /templates/{id}/validate
```
) before sending

Handlebars语法：使用
```
{{variable}}
```
、
```
{{#if}}
```
、
```
{{#each}}
```
、
```
{{#unless}}
```
实现动态内容
布局继承：创建基础布局模板（头部、底部、外层容器），内容模板可以继承该布局，只需修改一次布局即可同步更新所有关联模板
模板校验：Postmark在保存模板时会自动校验，在发送前就能发现缺失变量和语法错误
跨服务器同步：可以通过API或UI将模板从一个服务器同步到另一个（比如从 staging 到生产环境）
模板API：完整的CRUD操作，可程序化创建、读取、更新、删除模板
使用模板发送：在发送请求中传入
```
TemplateId
```
或
```
TemplateAlias
```
加上
```
TemplateModel
```
（数据对象），无需传入原始HTML/文本内容
预览：发送前可以通过API（
```
POST /templates/{id}/validate
```
）使用测试数据渲染模板预览效果

Inbound Email

入站邮件

What it is: Receive email at your domain and have Postmark parse it into structured JSON (from, to, subject, HTML body, text body, attachments) delivered to your webhook URL
Setup: Add an MX record for your receiving domain pointing to
```
inbound.postmarkapp.com
```
, then configure the webhook URL in the Postmark UI under Inbound
Inbound rules: Define rules to control which recipient addresses trigger webhook delivery
Attachments: Included as base64-encoded content in the webhook JSON payload
Use cases: Reply parsing, support ticket creation, forum comments via email, lead capture from email replies
Plan requirement: Inbound Email is available on Pro plan and above

功能说明：接收发送到你域名的邮件，Postmark会将其解析为结构化JSON（发件人、收件人、主题、HTML正文、文本正文、附件）推送到你的webhook地址
配置流程：为你的接收域名添加指向
```
inbound.postmarkapp.com
```
的MX记录，然后在Postmark UI的入站邮件板块配置webhook地址
入站规则：定义规则控制哪些收件人地址会触发webhook推送
附件：在webhook JSON payload中以base64编码的形式包含附件内容
适用场景：回复解析、支持工单创建、邮件触发论坛评论、邮件回复获客等
套餐要求：入站邮件功能仅在Pro及以上套餐可用

Webhooks

Webhook

7 webhook types: Bounce, Delivery, Open, Click, Spam Complaint, Subscription Change, Inbound
Configuration: Set webhook URLs per server in the Postmark UI — select which event types to receive
Payload: JSON object with event-specific fields (message ID, recipient, metadata, timestamps)
Retry schedule: Postmark retries failed webhook deliveries with increasing backoff — retry schedule varies by webhook type
Message Stream filtering: Configure webhooks to fire for specific message streams (e.g., only transactional, only broadcast)
Open/Click tracking: Must be enabled per server for Open and Click webhooks to fire

7种webhook类型：退信、送达、打开、点击、垃圾邮件投诉、订阅变更、入站
配置方式：在Postmark UI中为每个服务器设置webhook地址，选择需要接收的事件类型
Payload：包含事件专属字段的JSON对象（消息ID、收件人、元数据、时间戳）
重试机制：Postmark会对投递失败的webhook进行指数退避重试，不同类型webhook的重试策略不同
消息流筛选：可以配置webhook仅触发特定消息流的事件（比如仅事务性流、仅广播流）
打开/点击追踪：需要为对应服务器开启打开/点击追踪功能，对应webhook才会触发

DMARC Monitoring

DMARC监控

Free tier: Weekly DMARC digest reports summarizing who is sending email using your domain — available to all Postmark users
Paid monitoring: $14/mo per domain at
```
dmarc.postmarkapp.com
```
— detailed daily reports, failure alerts, source identification
Separate API: DMARC monitoring uses a separate API at
```
https://dmarc.postmarkapp.com/api/
```
with its own authentication
Setup: Add a DMARC DNS record with Postmark's reporting address as the
```
rua
```
recipient
Use case: Detect unauthorized senders using your domain, track SPF/DKIM alignment, monitor DMARC policy enforcement

免费版：所有Postmark用户均可使用，提供周度DMARC摘要报告，汇总哪些主体在使用你的域名发送邮件
付费监控：每个域名每月14美元，访问
```
dmarc.postmarkapp.com
```
开通，提供精细化日报、失败告警、发送源识别能力
独立API：DMARC监控使用独立的API地址
```
https://dmarc.postmarkapp.com/api/
```
，有独立的认证体系
配置流程：添加DMARC DNS记录，将Postmark的报告地址设为
```
rua
```
接收方
适用场景：检测未授权使用你的域名发送邮件的主体，追踪SPF/DKIM对齐情况，监控DMARC策略执行效果

Bounce Management (Rebound)

退信管理（Rebound）

Automatic processing: Postmark automatically categorizes bounces (hard bounce, soft bounce, DNS error, spam notification, etc.)
Suppression: Hard-bounced addresses are automatically added to the suppression list — future sends are blocked
Reactivation: Soft bounces are retried automatically. Hard-bounced addresses can be manually reactivated if the issue is resolved
Bounce API: Query, manage, and reactivate bounced addresses programmatically
Bounce tags: Bounces inherit the tag from the original message for filtering

自动处理：Postmark会自动对退信分类（硬退信、软退信、DNS错误、垃圾邮件通知等）
自动拒收：硬退信地址会被自动加入拒收列表，后续发送会被拦截
重新激活：软退信会自动重试，硬退信地址如果问题已解决可以手动重新激活
退信API：可程序化查询、管理和重新激活退信地址
退信标签：退信会继承原邮件的标签，方便筛选

Suppressions

拒收列表

Automatic suppression: Addresses that hard-bounce or file spam complaints are automatically suppressed
Manual suppression: Add addresses to the suppression list manually via the API or UI
Per-stream suppressions: Suppression lists are maintained per message stream — a suppression in the broadcast stream does not affect the transactional stream
Reactivation: Remove suppressions via the API (
```
DELETE /message-streams/{stream}/suppressions/delete
```
) or UI when the underlying issue is resolved
Dump endpoint: Export the full suppression list via the API

自动拒收：硬退信或提交垃圾邮件投诉的地址会被自动加入拒收列表
手动拒收：可以通过API或UI手动将地址加入拒收列表
按流隔离：拒收列表按消息流独立维护，广播流的拒收不会影响事务性流的投递
移除拒收：问题解决后可以通过API（
```
DELETE /message-streams/{stream}/suppressions/delete
```
）或UI移除拒收状态
导出接口：可以通过API导出完整的拒收列表

Statistics

统计数据

Per-stream stats: View delivery rates, bounce rates, open rates, click rates, and spam complaint rates broken down by message stream
Per-tag stats: Filter statistics by message tag to compare performance across different email types
Outbound overview: Aggregate sent, bounced, spam complaints, and tracked (opens/clicks) counts
Bounce breakdown: See bounces categorized by type (hard bounce, soft bounce, DNS error, etc.)
Time-series: View stats over custom date ranges with daily or hourly granularity
Activity: Searchable log of all sent and received messages with full delivery details

按流统计：可以按消息流查看送达率、退信率、打开率、点击率、垃圾邮件投诉率
按标签统计：可以按邮件标签筛选统计数据，对比不同类型邮件的表现
出站概览：汇总发送量、退信量、垃圾邮件投诉量、追踪（打开/点击）量
退信分类：按类型查看退信分布（硬退信、软退信、DNS错误等）
时间维度：支持自定义日期范围查看统计数据，支持按天或按小时粒度
活动日志：可搜索所有已发送和接收的邮件，包含完整的投递详情

Sender Signatures

发件人签名

Verified senders: Every From address or domain must be verified before sending — Postmark sends a confirmation email to the address
Domain-level verification: Verify an entire domain (via DNS records) to send from any address at that domain
DNS records: Add DKIM (CNAME) and Return-Path (CNAME) records for full authentication
SPF: Postmark handles SPF automatically via the Return-Path domain — no manual SPF record needed
Multiple signatures: Add multiple sender signatures per server for different From addresses

已验证发件人：所有发件人地址或域名必须经过验证才能发送邮件，Postmark会向对应地址发送确认邮件
域名级验证：通过DNS记录验证整个域名后，可以使用该域名下的任意地址作为发件人
DNS记录：添加DKIM（CNAME）和Return-Path（CNAME）记录完成完整认证
SPF：Postmark会通过Return-Path域名自动处理SPF，无需手动添加SPF记录
多签名支持：每个服务器可以添加多个发件人签名，适配不同的发件人地址需求

Data model

数据模型

Object	Description	Key fields
Server	Isolated sending environment	id, name, api_tokens, message_streams, color
Message Stream	Transactional or broadcast channel	id, server_id, type (transactional/broadcast), name
Sender Signature	Verified from address or domain	id, domain, from_email, confirmed, dkim_verified, return_path_verified
Template	Reusable Handlebars email design	template_id, alias, name, subject, html_body, text_body, layout_template
Message	Sent or received email	message_id, to, from, subject, status, tag, metadata, stream_id
Bounce	Failed delivery record	id, type, message_id, email, bounced_at, can_activate, tag
Suppression	Suppressed address per stream	email_address, stream_id, suppression_reason, created_at
Webhook	Event notification configuration	id, url, message_stream, triggers (bounce, delivery, open, click, etc.)
Inbound Rule	Inbound email routing rule	id, rule
Tag	Message categorization label	name (string attached to messages for filtering)

对象	描述	关键字段
Server	隔离的发送环境	id, name, api_tokens, message_streams, color
Message Stream	事务性或广播类邮件通道	id, server_id, type (transactional/broadcast), name
Sender Signature	已验证的发件人地址或域名	id, domain, from_email, confirmed, dkim_verified, return_path_verified
Template	可复用的Handlebars邮件设计	template_id, alias, name, subject, html_body, text_body, layout_template
Message	已发送或接收的邮件	message_id, to, from, subject, status, tag, metadata, stream_id
Bounce	投递失败记录	id, type, message_id, email, bounced_at, can_activate, tag
Suppression	按流隔离的拒收地址	email_address, stream_id, suppression_reason, created_at
Webhook	事件通知配置	id, url, message_stream, triggers (bounce, delivery, open, click, etc.)
Inbound Rule	入站邮件路由规则	id, rule
Tag	邮件分类标签	name (附加到邮件上用于筛选的字符串)

API quick reference

API快速参考

Base URL:
```
https://api.postmarkapp.com
```
Authentication:
```
X-Postmark-Server-Token: <SERVER_TOKEN>
```
header for server-level operations;
```
X-Postmark-Account-Token: <ACCOUNT_TOKEN>
```
header for account-level operations
Test token:
```
POSTMARK_API_TEST
```
— use as server token for API testing without sending real email
Rate limits: No strict published rate limits; excessive requests receive HTTP 429. Spam complaint rate must stay below 0.1%, bounce rate below 10%
Key endpoints:
- ```
POST /email
```
  — send a single email
- ```
POST /email/batch
```
  — send up to 500 emails (50MB payload)
- ```
POST /email/withTemplate
```
  — send using a template
- ```
POST /email/batchWithTemplates
```
  — batch send using templates
- ```
GET /bounces
```
  — list bounces
- ```
PUT /bounces/{id}/activate
```
  — reactivate a bounced address
- ```
GET /messages/outbound
```
  — search outbound message activity
- ```
GET /messages/inbound
```
  — search inbound message activity
- ```
GET /stats/outbound
```
  — outbound statistics
- ```
GET /templates
```
  — list templates
- ```
POST /templates
```
  — create a template
- ```
GET /message-streams
```
  — list message streams
- ```
GET /suppressions/dump
```
  — export suppression list
- ```
POST /webhooks
```
  — create a webhook
SDKs: Official — Ruby (
```
postmark
```
), C#/.NET (
```
Postmark
```
), PHP (
```
wildbit/postmark-php
```
), Node.js (
```
postmark
```
). Community — Python (
```
postmarker
```
), Java, Go, Elixir
Docs: postmarkapp.com/developer

基础地址：
```
https://api.postmarkapp.com
```

认证：服务器级操作使用

X-Postmark-Server-Token: <SERVER_TOKEN>

请求头；账户级操作使用

X-Postmark-Account-Token: <ACCOUNT_TOKEN>

请求头

测试令牌：
```
POSTMARK_API_TEST
```
— 作为服务器令牌使用，可测试API调用但不会实际发送邮件
速率限制：没有公开的严格速率限制，过量请求会返回HTTP 429。垃圾邮件投诉率必须低于0.1%，退信率低于10%
核心端点：
- ```
POST /email
```
  — 发送单封邮件
- ```
POST /email/batch
```
  — 最多发送500封邮件（请求体上限50MB）
- ```
POST /email/withTemplate
```
  — 使用模板发送邮件
- ```
POST /email/batchWithTemplates
```
  — 使用模板批量发送邮件
- ```
GET /bounces
```
  — 列出退信记录
- ```
PUT /bounces/{id}/activate
```
  — 重新激活退信地址
- ```
GET /messages/outbound
```
  — 搜索出站邮件活动日志
- ```
GET /messages/inbound
```
  — 搜索入站邮件活动日志
- ```
GET /stats/outbound
```
  — 出站统计数据
- ```
GET /templates
```
  — 列出模板
- ```
POST /templates
```
  — 创建模板
- ```
GET /message-streams
```
  — 列出消息流
- ```
GET /suppressions/dump
```
  — 导出拒收列表
- ```
POST /webhooks
```
  — 创建webhook
SDK：官方SDK — Ruby（
```
postmark
```
）、C#/.NET（
```
Postmark
```
）、PHP（
```
wildbit/postmark-php
```
）、Node.js（
```
postmark
```
）。社区SDK — Python（
```
postmarker
```
）、Java、Go、Elixir
文档：postmarkapp.com/developer

Integrations

集成

Category	Tools
Automation	Zapier (3 triggers: inbound message, bounce, open; 2 actions: send email, send email with template)
CRM	No native CRM integrations — API-first approach; connect via Zapier or custom API integration
Frameworks	Any framework with HTTP or SMTP support (Rails, Django, Express, Laravel, Spring, Phoenix, WordPress, etc.)
ActiveCampaign	Shared parent company (acquired 2022) but no direct product integration as of March 2026
Community	Community-maintained libraries and plugins for various languages and frameworks

Postmark is an API-first platform — integrations are built via the REST API or SMTP relay rather than pre-built native connectors.

分类	工具
自动化	Zapier（3个触发器：入站消息、退信、打开；2个动作：发送邮件、使用模板发送邮件）
CRM	无原生CRM集成，API优先的设计理念，可以通过Zapier或自定义API集成连接
框架	支持所有支持HTTP或SMTP的框架（Rails、Django、Express、Laravel、Spring、Phoenix、WordPress等）
ActiveCampaign	同属一家母公司（2022年收购），但截至2026年3月暂无直接产品集成
社区	社区维护的多语言、多框架库和插件

Postmark是API优先的平台，集成主要通过REST API或SMTP中继实现，而非预构建的原生连接器。

Pricing (USD, as of March 2026 — verify current pricing at postmarkapp.com)

定价（美元，截至2026年3月 — 请访问postmarkapp.com确认最新定价）

Plan	Price	Volume	Key gated features
Developer (Free)	$0/mo	100 emails/mo	Never expires, basic API access, single server
Basic	$15/mo	10,000 emails/mo	$1.80/1K overage, 5 custom domains, 45-day message retention
Pro	$16.50/mo	10,000 emails/mo	$1.30/1K overage, 10 custom domains, inbound email, customizable retention (up to 365 days)
Platform	$18/mo	10,000 emails/mo	$1.20/1K overage, unlimited domains/users/streams

Add-ons:

Dedicated IP: $50/mo (requires 300K+ emails/mo sending volume)
DMARC Monitoring: $14/mo per domain (detailed daily reports at dmarc.postmarkapp.com)

Key pricing note: Unlike SendGrid, Postmark does not separate transactional and marketing billing — all email (transactional and broadcast streams) is billed under a single plan. The Developer free tier never expires, unlike SendGrid's 60-day trial.

套餐	价格	额度	核心专属功能
开发者版（免费）	0美元/月	每月100封邮件	永久有效、基础API访问、单服务器
基础版	15美元/月	每月10,000封邮件	超量每千封1.8美元、5个自定义域名、45天消息留存
专业版	16.5美元/月	每月10,000封邮件	超量每千封1.3美元、10个自定义域名、入站邮件、自定义留存（最多365天）
平台版	18美元/月	每月10,000封邮件	超量每千封1.2美元、无限域名/用户/流

附加服务：

独立IP：每月50美元（要求每月发送量超过30万封）
DMARC监控：每个域名每月14美元（访问dmarc.postmarkapp.com获取精细化日报）

定价注意事项：和SendGrid不同，Postmark不会分开计算事务性和营销类邮件的费用，所有邮件（事务性和广播流）都在同一个套餐下计费。开发者免费版永久有效，不同于SendGrid的60天试用期。

Step 4 — Actionable guidance

步骤4 — 可落地的操作指引

Based on the user's specific question:

Sending transactional email via the API:
1. Create a server in the Postmark UI (or use the default server)
2. Copy the Server API Token from the server's credentials page
3. Add and verify a Sender Signature — either a single email address or an entire domain (add DKIM and Return-Path CNAME records to DNS)
4. Install the SDK for your language (e.g.,
```
npm install postmark
```
  for Node.js)
5. Initialize the client:
```
const client = new postmark.ServerClient("YOUR_SERVER_TOKEN")
```
6. Send an email: set
```
From
```
  ,
```
To
```
  ,
```
Subject
```
  ,
```
HtmlBody
```
  /
```
TextBody
```
  (or use
```
TemplateId
```
  +
```
TemplateModel
```
  )
7. Handle the response — check for
```
ErrorCode: 0
```
  (success) or specific error codes
8. Use
```
POSTMARK_API_TEST
```
  as the server token during development to test without sending real email
Setting up Message Streams for transactional and broadcast:
1. Navigate to your server in the Postmark UI
2. The default transactional stream already exists — use it for password resets, receipts, alerts
3. Create a new broadcast stream: Servers > [Your Server] > Message Streams > Add Stream > Broadcast
4. Name the stream (e.g., "Newsletter", "Product Updates")
5. In your API calls, pass
```
"MessageStream": "your-broadcast-stream-id"
```
  to route to the broadcast stream
6. Configure separate webhooks per stream if needed
7. Monitor each stream's statistics independently to track reputation health
Setting up Handlebars templates with layout inheritance:
1. Create a layout template first: Templates > Add Template > Layout
2. Define the layout with
```
{{{@content}}}
```
  placeholder where content templates will be injected
3. Include shared elements in the layout: header, footer, styles, unsubscribe links
4. Create content templates that reference the layout via the
```
LayoutTemplate
```
  field
5. Use Handlebars syntax in content templates:
```
{{variable}}
```
  ,
```
{{#if condition}}
```
  ,
```
{{#each items}}
```
6. Validate templates via the API (
```
POST /templates/{id}/validate
```
  ) with sample data
7. Push templates between servers (staging to production) via the Template Push API
Processing inbound email:
1. Upgrade to Pro plan or above (inbound email is not available on Developer or Basic plans)
2. Add an MX record for your receiving domain:
```
10 inbound.postmarkapp.com
```
3. Configure the inbound webhook URL in the Postmark UI under your server's Inbound settings
4. Optionally set up inbound rules to filter which recipient addresses trigger webhooks
5. Implement your webhook endpoint to receive JSON payloads with parsed fields (From, To, Subject, HtmlBody, TextBody, Attachments)
6. Handle attachments — they arrive as base64-encoded content in the JSON payload
7. Return a 200 status code from your endpoint to acknowledge receipt
Setting up DMARC monitoring:
1. Add a DMARC DNS record for your domain:
```
v=DMARC1; p=none; rua=mailto:re+YOUR_TOKEN@dmarc.postmarkapp.com
```
2. Free weekly digests start arriving automatically — summarize who is sending email as your domain
3. For detailed monitoring ($14/mo/domain), sign up at dmarc.postmarkapp.com
4. Review reports to identify unauthorized senders and SPF/DKIM alignment failures
5. Gradually tighten your DMARC policy:
```
p=none
```
  ->
```
p=quarantine
```
  ->
```
p=reject
```
  as you confirm all legitimate senders are authenticated

根据用户的具体问题提供对应指引：

通过API发送事务性邮件：
1. 在Postmark UI中创建服务器（或使用默认服务器）
2. 从服务器凭证页面复制服务器API令牌
3. 添加并验证发件人签名 — 可以是单个邮箱地址或整个域名（在DNS中添加DKIM和Return-Path CNAME记录）
4. 安装对应语言的SDK（比如Node.js使用
```
npm install postmark
```
  ）
5. 初始化客户端：
```
const client = new postmark.ServerClient("YOUR_SERVER_TOKEN")
```
6. 发送邮件：设置
```
From
```
  、
```
To
```
  、
```
Subject
```
  、
```
HtmlBody
```
  /
```
TextBody
```
  （或使用
```
TemplateId
```
  +
```
TemplateModel
```
  ）
7. 处理响应 — 检查
```
ErrorCode: 0
```
  （成功）或对应错误码
8. 开发阶段使用
```
POSTMARK_API_TEST
```
  作为服务器令牌测试，不会实际发送邮件
为事务性和广播类邮件配置消息流：
1. 在Postmark UI中进入对应的服务器
2. 默认事务性流已存在，用于发送密码重置、收据、告警类邮件
3. 创建新的广播流：服务器 > [你的服务器] > 消息流 > 添加流 > 广播
4. 为流命名（比如「通讯」、「产品更新」）
5. 在API调用中传入
```
"MessageStream": "your-broadcast-stream-id"
```
  将邮件路由到广播流
6. 按需为不同流配置独立的webhook
7. 独立监控每个流的统计数据，跟踪声誉健康度
配置支持布局继承的Handlebars模板：
1. 先创建布局模板：模板 > 添加模板 > 布局
2. 定义布局，使用
```
{{{@content}}}
```
  占位符标注内容模板注入的位置
3. 在布局中加入通用元素：头部、底部、样式、退订链接
4. 创建内容模板，通过
```
LayoutTemplate
```
  字段关联对应布局
5. 在内容模板中使用Handlebars语法：
```
{{variable}}
```
  、
```
{{#if condition}}
```
  、
```
{{#each items}}
```
6. 用示例数据通过API（
```
POST /templates/{id}/validate
```
  ）校验模板
7. 通过模板推送API将模板在服务器间同步（从staging到生产）
处理入站邮件：
1. 升级到Pro及以上套餐（开发者版和基础版不支持入站邮件功能）
2. 为接收域名添加MX记录：
```
10 inbound.postmarkapp.com
```
3. 在Postmark UI的服务器入站设置中配置入站webhook地址
4. 按需设置入站规则，筛选触发webhook的收件人地址
5. 实现webhook端点，接收包含解析字段（发件人、收件人、主题、HTML正文、文本正文、附件）的JSON payload
6. 处理附件 — 附件以base64编码的形式存在于JSON payload中
7. 端点返回200状态码确认接收成功
配置DMARC监控：
1. 为域名添加DMARC DNS记录：
```
v=DMARC1; p=none; rua=mailto:re+YOUR_TOKEN@dmarc.postmarkapp.com
```
2. 自动开始接收免费周度摘要，汇总使用你域名发送邮件的主体
3. 如需精细化监控（每个域名每月14美元），访问dmarc.postmarkapp.com开通
4. 查看报告识别未授权发送源和SPF/DKIM对齐失败问题
5. 逐步收紧DMARC策略：确认所有合法发送源都完成认证后，从
```
p=none
```
  ->
```
p=quarantine
```
  ->
```
p=reject
```
  逐步升级

Gotchas

注意事项

Best-effort from research — verify details against current Postmark documentation.

Dedicated IPs require a minimum sending volume of 300K emails/month. Unlike SendGrid or Mailchimp where you can buy a dedicated IP at lower volumes, Postmark requires sustained high volume to maintain IP reputation. If you send fewer than 300K/month, Postmark's shared IP pools actually deliver better results — their sender vetting process keeps shared IP reputation exceptionally high. Don't assume dedicated = better.
Inbound Email is only available on Pro plan and above. If you need to receive and parse incoming email (reply processing, support tickets, email-to-app workflows), the Developer and Basic plans will not work. Budget for at least Pro ($16.50/mo) if inbound email is part of your architecture.
Transactional and broadcast streams have separate suppression lists but share a single bill. While Message Streams isolate sending reputation, suppressions are per-stream — an address suppressed in your broadcast stream can still receive transactional email, and vice versa. This is intentional (a user unsubscribing from your newsletter should still get password resets) but can surprise teams expecting a single global suppression list.
Postmark has a sender vetting process — you cannot send immediately at high volume. New accounts go through an approval process. Postmark reviews your use case and may ask about your sending patterns, audience, and content. This vetting is why their shared IP reputation is so high, but it means you cannot sign up and blast 100K emails on day one. Plan for 1-2 business days of approval time for new accounts.
The DMARC monitoring API is completely separate from the main Postmark API. The DMARC service lives at
```
dmarc.postmarkapp.com
```
with its own authentication tokens and endpoints. Do not try to use your Postmark server or account token for DMARC API calls — they are different systems with different credentials, even though both are Postmark products.

基于调研的最佳实践 — 请对照Postmark最新官方文档验证细节。

**独立IP要求每月最低发送量30万封。**和SendGrid或Mailchimp低发送量即可购买独立IP不同，Postmark要求持续的高发送量来维护IP声誉。如果月发送量低于30万，使用Postmark的共享IP池实际投递效果更好 — 他们严格的发件人审核机制让共享IP的声誉极高，不要默认独立IP效果更好。
**入站邮件仅在Pro及以上套餐可用。**如果你需要接收和解析入站邮件（回复处理、支持工单、邮件转应用工作流），开发者版和基础版无法满足需求，需要至少Pro套餐（16.5美元/月）。
**事务性和广播流有独立的拒收列表，但共享同一个账单。**虽然消息流隔离了发送声誉，但拒收列表按流独立维护 — 广播流中被拒收的地址仍可以接收事务性邮件，反之亦然。这是有意设计的（用户退订通讯仍应该收到密码重置邮件），但可能会让预期有全局统一拒收列表的团队意外。
**Postmark有发件人审核流程 — 无法注册后立即高量发送。**新账户需要走审核流程，Postmark会审核你的使用场景，可能询问你的发送模式、受众和内容。这套审核机制是他们共享IP声誉极高的原因，但也意味着你无法注册第一天就发送10万封邮件，新账户预留1-2个工作日的审核时间。
**DMARC监控API和主Postmark API完全独立。**DMARC服务部署在
```
dmarc.postmarkapp.com
```
，有独立的认证令牌和端点，不要使用Postmark服务器或账户令牌调用DMARC API — 虽然都是Postmark的产品，但属于不同系统，凭证不通用。

Step 5 — Related skills

步骤5 — 相关技能

```
/sales-email-marketing
```
— Email marketing strategy and best practices (platform-agnostic)
```
/sales-deliverability
```
— Cross-platform email deliverability — SPF/DKIM/DMARC, warmup, inbox placement
```
/sales-email-tracking
```
— Email open and click tracking strategy
```
/sales-sendgrid
```
— SendGrid platform help — if you need SendGrid-specific guidance instead
```
/sales-integration
```
— Connect Postmark to other tools via Zapier, Make, or API
```
/sales-do
```
— Not sure which skill to use? The router matches any sales objective to the right skill. Install:
```
npx skills add sales-skills/sales --skills sales-do
```

```
/sales-email-marketing
```
— 邮件营销策略和最佳实践（平台无关）
```
/sales-deliverability
```
— 跨平台邮件投递能力 — SPF/DKIM/DMARC、预热、收件箱到达率
```
/sales-email-tracking
```
— 邮件打开和点击追踪策略
```
/sales-sendgrid
```
— SendGrid平台帮助 — 如果你需要SendGrid专属指引
```
/sales-integration
```
— 通过Zapier、Make或API连接Postmark到其他工具
```
/sales-do
```
— 不确定使用哪个技能？路由工具会将任何销售目标匹配到对应的技能。安装命令：
```
npx skills add sales-skills/sales --skills sales-do
```

Examples

示例

Example 1: Setting up transactional email for a Rails app

示例1：为Rails应用配置事务性邮件

User says: "I need to send order confirmation and shipping notification emails from my Rails app using Postmark." Skill does:

Guides creating a Postmark server and copying the Server API Token
Walks through adding and verifying a Sender Signature — adding DKIM and Return-Path CNAME records to DNS
Shows how to configure Action Mailer to use Postmark's SMTP relay (
```
smtp.postmarkapp.com
```
, port 587, token as username and password)
Alternatively, recommends the
```
postmark-rails
```
gem for native API integration instead of SMTP for better error handling
Creates two Handlebars templates with a shared layout (header/footer) — one for order confirmation (with
```
{{order_number}}
```
,
```
{{items}}
```
) and one for shipping notification (with
```
{{tracking_url}}
```
)
Recommends setting up Delivery and Bounce webhooks to track failures and trigger customer service alerts Result: User has production-ready transactional email with templates, shared layout, proper authentication, and delivery monitoring

用户说：「我需要用Postmark从我的Rails应用发送订单确认和物流通知邮件。」 技能处理流程：

引导创建Postmark服务器并复制服务器API令牌
演示添加和验证发件人签名的流程 — 在DNS中添加DKIM和Return-Path CNAME记录
展示如何配置Action Mailer使用Postmark的SMTP中继（
```
smtp.postmarkapp.com
```
、端口587、令牌作为用户名和密码）
或者推荐使用
```
postmark-rails
```
gem实现原生API集成，比SMTP有更好的错误处理能力
创建两个共享同一布局（头部/底部）的Handlebars模板 — 一个用于订单确认（包含
```
{{order_number}}
```
、
```
{{items}}
```
），一个用于物流通知（包含
```
{{tracking_url}}
```
）
推荐配置送达和退信webhook，追踪投递失败并触发客服告警结果：用户获得生产可用的事务性邮件能力，包含模板、共享布局、合规认证和投递监控

Example 2: Separating newsletter from transactional email

示例2：隔离通讯和事务性邮件

User says: "We're sending both password resets and a weekly newsletter through Postmark. Our newsletter unsubscribes are hurting our transactional delivery." Skill does:

Explains Message Streams — broadcast email reputation is infecting their transactional stream because they are likely sending everything through the default transactional stream
Walks through creating a new broadcast stream for the newsletter
Updates their newsletter sending code to include
```
"MessageStream": "newsletter"
```
in API calls
Configures separate webhooks for each stream — bounce/delivery for transactional, plus subscription change for broadcast
Explains that suppressions are per-stream, so newsletter unsubscribers will still receive transactional email (password resets, receipts)
Reviews their broadcast stream statistics after migration to confirm spam complaint rate drops below 0.1% Result: User's transactional delivery speed recovers as broadcast reputation issues are isolated to the newsletter stream

用户说：「我们通过Postmark同时发送密码重置邮件和每周通讯，通讯的退订正在影响我们事务性邮件的投递效果。」 技能处理流程：

解释消息流的作用 — 他们大概率将所有邮件都通过默认事务性流发送，导致广播邮件的声誉污染了事务性流
演示为通讯创建新的广播流
修改通讯发送代码，在API请求中加入
```
"MessageStream": "newsletter"
```
为不同流配置独立的webhook — 事务性流配置退信/送达通知，广播流额外加订阅变更通知
解释拒收列表按流隔离，所以通讯的退订用户仍可以收到事务性邮件（密码重置、收据）
迁移后查看广播流的统计数据，确认垃圾邮件投诉率降到0.1%以下结果：广播邮件的声誉问题被隔离到通讯流，用户的事务性邮件投递速度恢复正常

Example 3: Setting up inbound email for a support ticketing system

示例3：为支持工单系统配置入站邮件

User says: "We want customers to reply to support emails and have those replies automatically create or update tickets in our system." Skill does:

Confirms user is on Pro plan or above (inbound email requirement) — if not, recommends upgrading from Basic ($15) to Pro ($16.50)
Guides adding an MX record for their support domain (e.g.,
```
support.company.com
```
) pointing to
```
inbound.postmarkapp.com
```
Configures inbound webhook URL in the Postmark server settings
Sets up an inbound rule to accept email only to specific addresses (e.g.,
```
*@support.company.com
```
)
Designs the webhook endpoint: parse the JSON payload to extract From, Subject, TextBody, and the original ticket ID from the In-Reply-To header or a tag in the To address
Maps inbound emails to existing tickets (update) or creates new tickets when no match is found Result: User has a working reply-to-ticket pipeline where customer email replies automatically flow into their support system

用户说：「我们希望客户回复支持邮件时，回复内容可以自动创建或更新我们系统中的工单。」 技能处理流程：

确认用户使用Pro及以上套餐（入站邮件要求） — 如果不是，推荐从基础版（15美元）升级到Pro（16.5美元）
引导为支持域名（比如
```
support.company.com
```
）添加指向
```
inbound.postmarkapp.com
```
的MX记录
在Postmark服务器设置中配置入站webhook地址
设置入站规则，仅接收发送到特定地址的邮件（比如
```
*@support.company.com
```
）
设计webhook端点：解析JSON payload提取发件人、主题、文本正文，从In-Reply-To头部或收件人地址的标签中提取原始工单ID
将入站邮件匹配到现有工单（更新），无匹配时创建新工单结果：用户获得可用的回复转工单流程，客户的邮件回复自动流入支持系统

Troubleshooting

故障排查

Emails rejected with error code 406 (Inactive Recipient)

邮件被拒绝，返回错误码406（收件人未激活）

Symptom: API calls return error code 406 "You tried to send to a recipient that has been marked as inactive" for addresses that should be valid Cause: The recipient previously hard-bounced or filed a spam complaint, and Postmark automatically added them to the suppression list for that message stream. Postmark blocks further sends to protect your sender reputation. Solution: Check the suppression list for the relevant message stream via the API (

GET /message-streams/{stream}/suppressions/dump

) or in the UI under Suppressions. If the underlying issue has been resolved (e.g., the recipient's mailbox was full but is now fixed), reactivate the address by deleting the suppression (

POST /message-streams/{stream}/suppressions/delete

with the email address in the body). For hard bounces, verify the address is valid before reactivating — sending to an address that bounces again will re-suppress it.

症状：API调用返回错误码406「你尝试发送到的收件人已被标记为未激活」，但地址应该是有效的原因：收件人之前有过硬退信或提交过垃圾邮件投诉，Postmark自动将其加入了对应消息流的拒收列表，拦截后续发送以保护你的发件人声誉。 解决方案：通过API（

GET /message-streams/{stream}/suppressions/dump

）或UI的拒收列表板块查看对应消息流的拒收列表。如果底层问题已解决（比如收件人邮箱之前已满现在恢复正常），删除拒收记录即可重新激活地址（请求体中传入邮箱地址调用

POST /message-streams/{stream}/suppressions/delete

）。如果是硬退信，重新激活前请确认地址有效 — 再次发送到仍会退信的地址会被再次拒收。

Webhook endpoint receiving duplicate events

Webhook端点收到重复事件

Symptom: Your webhook endpoint processes the same event multiple times, causing duplicate records or actions in your system Cause: Postmark retries webhook delivery if your endpoint does not return a 2xx status code within the timeout window, or if there is a network interruption during delivery. The retry fires the same event payload again. Solution: Make your webhook handler idempotent — use the

MessageID

field in the webhook payload as a deduplication key. Before processing, check if you have already handled an event for that MessageID and event type. Store processed event IDs in a cache or database. Ensure your endpoint returns a 200 status code quickly (within a few seconds) — move heavy processing to a background queue. If you are seeing excessive retries, check your endpoint's response time and error rate.

症状：你的webhook端点多次处理同一个事件，导致系统中出现重复记录或重复操作原因：如果你的端点在超时窗口内没有返回2xx状态码，或者投递过程中出现网络中断，Postmark会重试webhook投递，重试会发送相同的事件payload。 解决方案：让你的webhook处理逻辑具备幂等性 — 使用webhook payload中的

MessageID

字段作为去重键。处理前检查你是否已经处理过该MessageID和对应事件类型的请求，将已处理的事件ID存储在缓存或数据库中。确保你的端点可以快速返回200状态码（几秒内），将 heavy 处理逻辑移到后台队列。如果重试次数过多，检查你的端点响应时间和错误率。

Templates not rendering variables (showing raw Handlebars tags)

模板不渲染变量（显示原始Handlebars标签）

Symptom: Sent emails show literal

{{variable_name}}

text instead of the rendered values Cause: The template model data is not being passed correctly in the API call, or the variable names in the template do not match the keys in the

TemplateModel

object. Another common cause is using

POST /email

(raw send) instead of

POST /email/withTemplate

(template send). Solution: Verify you are using the template send endpoint (

POST /email/withTemplate

) and passing

TemplateId

(or

TemplateAlias

) plus

TemplateModel

with the correct variable names. Variable names are case-sensitive —

{{OrderNumber}}

requires

"OrderNumber"

in the model, not

"orderNumber"

. Use the template validation endpoint (

POST /templates/{id}/validate

) to test rendering with sample data before sending. Check the Postmark Activity log for the rendered message to see what was actually sent versus what you expected.

症状：发送的邮件显示字面量

{{variable_name}}

文本，而非渲染后的值原因：API请求中没有正确传入模板模型数据，或者模板中的变量名和

TemplateModel

对象中的键不匹配。另一个常见原因是使用了

POST /email

（原始发送）而非

POST /email/withTemplate

（模板发送）。 解决方案：确认你使用的是模板发送端点（

POST /email/withTemplate

），并且传入了

TemplateId

（或

TemplateAlias

）和变量名正确的

TemplateModel

。变量名区分大小写 —

{{OrderNumber}}

要求模型中使用

"OrderNumber"

而非

"orderNumber"

。发送前使用模板校验端点（

POST /templates/{id}/validate

）和示例数据测试渲染效果。查看Postmark活动日志中的已渲染邮件，对比实际发送内容和预期内容的差异。