Postmarkとは：送信APIとMessage Streams、Webhook受信とMailgunとの選び分けを実装目線で解説

Postmarkは、パスワード再設定や注文確認のようにシステムが1人の宛先へ送るメールに絞ったAPI配信サービスです。2022年にActiveCampaignの傘下に入り、現在も提供されているのは、トランザクションメール専用の製品です。この記事では、配信基盤を用途ごとに分けるMessage Streams、DKIMとReturn-Pathによるドメイン検証と承認前の送信制限、curlとNode.jsでの送信、HMAC署名を持たないWebhookの守り方と約51分で終わる再送、料金とログ保持45日の意味までを公式ドキュメントにもとづいて整理します。MailgunやAmazon SESではなくPostmarkを選ぶ条件も、送信量の試算とあわせて示します。

まとめ｜Postmarkを選ぶ条件と送信・Webhook受信で先に決める3つの設計

Postmarkが向くのは、会員登録や決済の通知など「届かないと業務が止まるメール」が主役で、月の送信が数万通規模の業務システムです。配信ログが標準で45日残るため、問い合わせ対応で送信履歴を確認したい運用とも相性がよい製品です。

実装で先に決めるのは3点あります。送信時にMetadataへ注文番号などの突合キーを入れること、Webhookは署名検証ができないのでBasic認証と内容の検証で受けること、受信側の一時障害には4xxではなく5xxを返して再送させること。再送は1時間足らずで打ち切られるため、受信口の監視は他社より短い間隔で組みます。

メルマガのような一斉配信が中心なら、配信リスト管理の機能が厚いマーケティング向けツールを先に検討してください。

Postmarkの提供元とMessage Streamsで分かれる送信基盤の構成

Postmarkの特徴は、機能の多さではなく用途の絞り込みにあります。何を送るためのサービスなのかを先に押さえると、他製品との比較で迷う場面が減ります。

ActiveCampaign傘下のトランザクション専用APIとしての位置付け

Postmarkは米国のWildbitが開発してきた製品で、Wildbitの告知によると2022年5月3日に、DMARC監視サービスのDMARC Digestsとともに、MAツールを提供するActiveCampaignへ売却されました。取引条件は公表されていません。

提供機能は、HTTP APIとSMTPによる送信、テンプレート、配信イベントのWebhook、受信メールを解析してJSONで渡すInbound処理に分かれます。購読者リストの管理やメール本文のビジュアル編集は主役ではありません。業務システムが決まった文面を自動で送る用途に限ると、機能の過不足を判断しやすくなります。

outboundとbroadcastのストリーム分離が到達率を守る仕組み

公式のMessage Streamsの説明では、1人に向けた優先度の高い通知をtransactional、複数の宛先へ同時に送るお知らせをbroadcastと分類し、それぞれ専用のIPプールから送り出します。APIではMessageStreamにoutboundかbroadcastを指定する形で、IPのレンジも含めて両者の通信は混ざりません。

この分離が効くのは、規約改定のお知らせを一斉に送った結果として苦情が増えても、パスワード再設定メールの送信元IPの評価が巻き添えにならない点です。broadcastには配信停止リンクが必須で、transactionalには不要とされています。社内で「通知」と呼ばれているメールのうち、利用者の操作をきっかけに1人へ送るものだけをoutboundに入れ、それ以外はbroadcastに分けるのが運用の基本です。

Postmarkでメールを送る手順｜ドメイン検証からcurlとNode.jsまで

送信までの流れは、サーバー（送信の管理単位）の作成、送信ドメインの検証、サーバートークンの取得、送信リクエストの4段階です。DNSの反映待ちを除けば1時間かからない作業量ですが、アカウント承認という他社にない工程が1つ挟まります。

DKIMのTXTとReturn-PathのCNAMEを登録して送信ドメインを検証

公式のドメイン検証手順では、管理画面のDNS Settingsに表示されたDKIMのTXTレコードと、Return-Path用のCNAMEレコードを登録します。CNAMEの既定のホスト名はpm_bounces、値はpm.mtasv.netです。

; DKIM: ホスト名と値は DNS Settings の表示をそのまま転記する
<表示されたセレクタ>._domainkey.example.co.jp.  IN TXT    "k=rsa; p=<表示された公開鍵>"
; Return-Path: バウンスの受け口。SPFのドメイン整合もこのレコードで満たす
pm_bounces.example.co.jp.                       IN CNAME  pm.mtasv.net.

公式はReturn-Pathの設定によってPostmarkから送ったメールがSPF認証を通るようになると説明しており、送信ドメイン側のSPFレコードへの追記を必須としていません。既存のSPFがincludeの多さでDNS参照回数の上限（10回）に近い会社では、この作りが助けになります。SPFの参照回数の考え方はSPFレコードの書き方と設定の判断基準で詳しく扱っています。

承認前は自ドメイン宛てしか送れない審査とPOSTMARK_API_TEST

Postmarkは新規アカウントを審査制にしています。公式のアカウント承認の解説によると、承認されるまでは、アカウントに追加して検証したドメイン以外の宛先には送れません。API Overviewでも、承認待ちの間は宛先がFromと同じドメインである必要があり、違反するとエラーコード412が返ると定めています。承認申請を出せるのはアカウントオーナーだけです。

リリース直前に申請して審査待ちで止まる、という段取りの事故を避けるため、開発に着手した時点で申請しておきます。リクエストの形式だけを確かめたい段階では、サーバートークンの代わりにPOSTMARK_API_TESTを渡すと、実際の配信なしで本物と同じ形の応答を受け取れます。

curlでemailエンドポイントへPOSTする最小リクエストと応答

公式のEmail APIは、X-Postmark-Server-Tokenヘッダーで認証し、JSONを/emailへPOSTする作りです。宛先はTo・Cc・Bccの合計で50件まで、件名は2000文字までと定められています。差出人と宛先は環境変数で渡し、JSONの組み立てにはjqを使います。

export POSTMARK_SERVER_TOKEN="POSTMARK_API_TEST"  # 疎通確認後に本物のトークンへ差し替える
# MAIL_FROM（検証済みドメインのアドレス）と MAIL_TO も環境変数で設定しておく

curl -s "https://api.postmarkapp.com/email" \
  -X POST \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-Postmark-Server-Token: ${POSTMARK_SERVER_TOKEN}" \
  -d "$(jq -n --arg from "$MAIL_FROM" --arg to "$MAIL_TO" '{
        From: $from, To: $to,
        Subject: "パスワード再設定のご案内",
        TextBody: "30分以内に再設定を完了してください。",
        MessageStream: "outbound",
        Tag: "password-reset",
        Metadata: {user_id: "12345"}
      }')"

応答のJSONはErrorCodeが0なら受付成功で、MessageIDが後でWebhookと突き合わせる値になります。まとめて送る/email/batchは1回500通まで受け付けますが、一部のメッセージが検証で落ちても応答のHTTPステータスは200番台です。結果は送った順に並ぶので、配列の各要素のErrorCodeを1件ずつ確認する処理を必ず書きます。

postmark.js 5.1系でMetadataに突合キーを持たせる送信実装

Node.jsでは公式SDKのpostmark.jsを使います。npmの最新は2026年11月時点で5.1系で、対応はNode.js 18以降です。READMEによると、HTTP通信はNode.js組み込みのFetch APIで行い、実行時の依存パッケージを持ちません。

import { ServerClient } from "postmark";

const client = new ServerClient(process.env.POSTMARK_SERVER_TOKEN);

const res = await client.sendEmail({
  From: process.env.MAIL_FROM,
  To: process.env.MAIL_TO,
  Subject: "ご注文を受け付けました",
  TextBody: "注文番号 A-1024 を受け付けました。",
  MessageStream: "outbound",
  Tag: "order-confirm",
  Metadata: { order_id: "A-1024" },
});
console.log(res.MessageID, res.ErrorCode);

Tagは管理画面での集計用、MetadataはBounceなどのWebhookにそのまま戻ってくるキーと値の組です。注文番号を入れておけば、バウンスが届いたときにどの注文の通知が失敗したかを、メールアドレスで検索せずに特定できます。READMEはNode.js 18〜20でFetch APIの実験的機能の警告が出る場合があると注記しており、これはNode.js側が出す表示で、ライブラリの不具合ではありません。

Webhookで配信結果を受け取る実装｜Basic認証と再送51分の設計

送信APIの応答は「受け付けた」までしか表しません。届いたか、恒久的に弾かれたかを業務データへ反映するには、Webhookの受信口を用意します。公式のWebhooks overviewが挙げる送信側のイベントは、配信・バウンス・スパム苦情・開封・クリック・購読変更の6種類です。

BounceのTypeとInactiveで配信停止の要否を判定する手順

業務システムで最初に受けるべきは、BounceとSpam complaintの2つです。公式のBounce webhookのサンプルでは、RecordTypeがBounce、TypeがHardBounce、Inactiveがtrueという組み合わせで届きます。スパム苦情はBounceのWebhookでは通知されず、別のWebhookとして登録が要る点に注意してください。

判定の軸に置くのは、TypeではなくInactiveです。InactiveはこのバウンスでPostmarkが宛先を無効化したかを示し、無効化された宛先へ送るとAPIはエラーコード406で受付を拒みます。自社のユーザーマスタの配信可否フラグをInactiveに合わせて落としておけば、送信のたびに406で失敗する状態を避けられます。ソフトバウンスでも公式はInactiveを確認するよう案内しているので、種別ごとの分岐を自前で作り込む必要はありません。

HMAC署名が無い前提でBasic認証とIP制限を組む受信コード

公式のWebhooks overviewは、HMACによる署名検証に対応していないと明記しています。代わりの守り方として示されているのは、WebhookのURLにユーザー名とパスワードを含めるBasic認証、送信元IPの許可リスト、HTTPSの3つです。IPは試行ごとに変わり得るとされているため、許可リストだけに頼らず、Basic認証とペイロードの検証を組み合わせます。

import hmac
import os

from flask import Flask, request

app = Flask(__name__)
HOOK_USER = os.environ["POSTMARK_HOOK_USER"]
HOOK_PASS = os.environ["POSTMARK_HOOK_PASS"]


def authorized(auth):
    if auth is None:
        return False
    ok_user = hmac.compare_digest(auth.username or "", HOOK_USER)
    ok_pass = hmac.compare_digest(auth.password or "", HOOK_PASS)
    return ok_user and ok_pass


@app.post("/postmark/bounce")
def postmark_bounce():
    if not authorized(request.authorization):
        return "", 401  # 4xxは再送されない。認証情報の更新時は新旧両方を受け付ける
    event = request.get_json(silent=True)
    if not isinstance(event, dict) or event.get("RecordType") != "Bounce":
        return "", 400
    try:
        enqueue(event)  # 保存はキューに逃がして即応答する
    except Exception:
        return "", 503  # 自社側の一時障害は5xxで返して再送させる
    return "", 200

比較に使うのはhmac.compare_digestで、文字列の==は避ける方針です。Mailgunは共有鍵のHMAC、SendGridは公開鍵の署名で送信元を確かめられるのに対し、Postmarkは受信側の認証情報が漏れると第三者が偽のイベントを送り込めます。Basic認証の資格情報はAPIのトークンと分けて保管し、偽のバウンスで顧客の配信が止まらないよう、無効化の処理を行う条件は、MessageIDが自社の送信記録に存在すると確認できた場合だけです。署名方式の違いはMailgunのHMAC-SHA256による署名検証やSendGrid Event Webhookの署名検証と再送設計と見比べると分かりやすくなります。

4xxは再送されず約51分で打ち切られる仕様に合わせた応答コード設計

公式のWebhooks overviewによると、再送の対象は5xx、408、429、タイムアウトなどの通信失敗だけで、それ以外の4xxは恒久的な失敗としてイベントを破棄します。再送の間隔は1分・5分・10分・10分・10分・15分の6回で、表の値を足し合わせると最初の失敗から約51分で打ち切られる計算です。各リクエストには残りの試行回数を示すX-PM-Retries-Remainingヘッダーが付きます。

この仕様から、応答の方針は次のように決まります。成功は200で返す。データベースの停止など自社側の一時障害は503で返し、再送に回させる。401や400は「二度と送ってこなくてよい」という意味になるので、資格情報のローテーション漏れで401を返し続けると、その間のイベントは戻ってきません。Mailgunの再送は8時間、SendGridは最大24時間なので、Postmarkを併用するシステムでは受信口の死活監視を1時間より短い間隔で組みます。あるイベント種別で48時間すべての配信が失敗すると、そのWebhookは無効化されて再検証が必要になる点も覚えておいてください。

Postmarkの料金プランとMailgun・SendGrid・SESとの選び分け

送信APIとイベント通知の基本機能は、どの製品も揃っています。差が出るのは、ログを誰がどれだけ持つか、配信基盤をどう分けるか、システムがどのクラウドで動いているかの3点です。

Free月100通からPlatformまで4プランの実額と保持45日の差

Postmarkの料金ページで2026年11月1日時点の表記を確認すると、月1万通の段で比べたプランは次の4つです。料金ページは送信量を選んで価格が変わる作りなので、1万通以外の段では月額が異なります。

BasicとProの差は月1.50ドルで、超過単価の差は1,000通あたり0.50ドルです。月1万3,000通を超えるとProのほうが安くなり、月3万通ならBasicは15ドルに超過2万通分の36ドルが乗って51ドル、Proは42.50ドルになります。受信メールの解析（Inbound）がプランの機能として載っているのもProとPlatformです。専用IPは月30万通以上の送信者向けで、Pro以上に1つ月50ドルからとされています。Mailgunはログ保持がBasicで1日なのに対し、Postmarkは全有料プランで45日残るため、Webhookの保存処理を作り込む前でも管理画面で履歴を追えます。

MailgunやSESに対してPostmarkを選ぶ場面と見送る場面

Postmarkを選ぶのは、通知メールの到達を最優先にしたいうえで、一斉配信と同じIPから送りたくない案件です。ストリームの分離が標準で組み込まれており、ログも45日残るので、配信事故の調査を管理画面だけで始められます。送信量が月数万通に収まるなら、料金差も数十ドルの範囲です。

見送るのは3つの場面です。システムがAWS上で完結しているなら、IAMでの権限管理とCloudWatchへの統合が効くAmazon SESの送信の仕組みとサンドボックス解除を先に検討します。EU域内でのデータ処理が契約条件にあるなら、EUリージョンを選べるMailgunの送信APIとリージョン設計が候補です。ReactのコンポーネントでHTMLメールを組みたいフロントエンド中心のチームなら、ResendとReact Emailでの送信実装のほうが開発体験の面で合います。

Postmark導入で詰まりやすい設計ミスと外部に相談する分岐点

失敗パターンとして多いのは、マーケティング部門の一斉配信までoutboundストリームに流してしまう使い方です。broadcastの苦情がトランザクション用の評価に響かない、というPostmarkの利点を自ら崩す結果になります。もう1つは、Webhookの受信口で認証エラーを401で返したまま気付かず、1時間足らずで再送が尽きてバウンス情報を取りこぼすケースです。

判断を言い切ります。月の送信が数千通で、失敗は担当者が管理画面で確認すれば足りるなら、Webhookは作らず45日のログで運用してください。配信結果をユーザーマスタの配信可否や業務画面の状態に反映するなら、受信・認証・冪等な保存・5xxによる再送依頼まで一式で設計します。複数のSaaSや基幹システムとイベントをやり取りする構成になる場合は、API開発・システム連携のページに、外部サービス連携の設計から実装までの対応範囲をまとめています。

よくある質問

Postmarkの導入検討で質問が多い論点を5つ取り上げます。

Postmarkは無料でどこまで使えますか？

2026年11月時点の料金ページでは、Freeプランは月100通までで、超過分の購入はできません。利用期限はなく、開発環境の動作確認や社内向けの少量の通知なら収まります。ただし新規アカウントは承認されるまで検証済みドメイン宛てにしか送れないため、無料のまま本番の会員へ送るには承認申請が別途必要です。料金体系は改定されることがあるので、契約前に公式ページで最新の表記を確かめてください。

PostmarkでメルマガやマーケティングEメールは送れますか？

broadcastストリームを使えば、複数の宛先へのお知らせも送れます。トランザクション用とは別のIPプールから送られ、配信停止リンクの設置が必須です。一方で、公式のMessage Streamsのページは購読者リストの管理をPostmarkの外で行う前提を示しており、配信停止の結果はWebhookで自社のリストへ同期する形になります。セグメント配信や配信予約を画面で操作したい運用なら、メール配信の専用ツールのほうが手間は少なく済みます。

Webhookの受信サーバーが止まっていた間のイベントは取り戻せますか？

5xxやタイムアウトで失敗した配信は、約51分の間に6回まで再送されます。その時間内に受信口を復旧させれば、止まっていた間のイベントも後から受け取ることが可能です。それを過ぎた分や4xxで拒否した分は再送されないため、APIの検索機能や管理画面のログから取り直すことになります。ログは有料プランなら45日残るので、他社に比べると取り直しの余地は広めです。

サーバートークンとアカウントトークンはどう使い分けますか？

サーバートークンはX-Postmark-Server-Tokenヘッダーで渡し、メール送信やそのサーバーのバウンス照会など、サーバー単位の操作に使います。アカウントトークンはX-Postmark-Account-Tokenで渡し、サーバーやドメインの作成といったアカウント全体の管理に使う鍵です。アプリケーションに持たせるのはサーバートークンだけにして、アカウントトークンは構成管理の作業者に限ると、漏えい時の影響範囲を1サーバーに抑えられます。

日本の宛先への到達率はSendGridやSESと比べて差がありますか？

到達率はサービスの名前よりも、送信ドメインのSPF・DKIM・DMARCの設定、バウンスと苦情の処理、送信量の増やし方で決まります。Postmarkはトランザクション専用のIPプールを分けている点を強みとしていますが、日本の宛先に限った到達率を他社と比べた公式データは各社とも出していません。乗り換えで改善を期待するより、先に認証設定と無効化済み宛先への送信停止を点検するほうが確実です。

関連記事

• センドグリッド（SendGrid）とは：直販と国内版の違いと最初の1通を送る実装手順
• SendGrid料金の実額と落とし穴：Freeプラン終了後の円建てプランと代替サービスの比較
• Amazon SESとは：SMTPとAPIの送信方式、サンドボックス解除と料金の考え方
• メール配信システムの自作・構築とは：SaaSに頼らずSMTP基盤を持つ場合の設計と到達率の確保
• DMARCのquarantineとrejectの違い：送信ドメインのなりすまし対策と設定状況の調査結果