sales-postmark

Postmark プラットフォームのヘルプ

REST API や SMTP リレーを使ったトランザクションメールから、Message Streams、Handlebars Templates、Inbound Email、Webhooks、DMARC Monitoring、Bounce Management、Suppressions、Statistics、各種連携まで、Postmark（ActiveCampaign）プラットフォームに関する質問に対応します。Postmark はトランザクションメールに特化し、業界最高水準の到達率（受信トレイへの到達率 98.7%）を実現しています。Wildbit（Natalie & Chris Nagele）が創業し、2022 年に ActiveCampaign に買収されました。

ステップ 1 — 背景を確認する

references/learnings.md が存在する場合は、蓄積された知識を確認するために、まず読んでください。

ユーザーに次の質問をします。

1. Postmark のどの分野についてサポートが必要ですか？

   • A）メール API — REST API（POST /email、POST /email/batch）や SDK を使ったトランザクションメールの送信
   • B）SMTP リレー — API に対応していないフレームワーク向けの従来型 SMTP 連携
   • C）Message Streams — トランザクションメールと一斉配信（ニュースレター／お知らせ）のインフラを分離
   • D）テンプレート — サーバーサイド Handlebars テンプレート、レイアウトの継承、サーバー間でのプッシュ
   • E）Inbound Email — Webhook を使った受信メールの受信と解析
   • F）Webhooks — バウンス、配信、開封、クリック、迷惑メール報告、サブスクリプション変更、受信イベント
   • G）DMARC Monitoring — 無料の週次 DMARC レポート、有料の詳細モニタリング
   • H）Bounce Management / Suppressions — バウンスの自動処理、抑制リスト
   • I）Statistics — 開封数、クリック数、配信率、バウンス率、迷惑メール報告
   • J）Sender Signatures — 検証済みの送信者アドレスとドメイン
   • K）アカウント／請求 — プラン、料金、サーバー、API トークン
   • L）その他 — 内容を説明してください

2. あなたの役割は何ですか？

   • A）開発者／エンジニア
   • B）DevOps／インフラ担当
   • C）管理者／アカウント所有者
   • D）創業者／個人事業主
   • E）代理店／フリーランサー
   • F）その他

3. 何を達成しようとしていますか？（具体的な目標や質問を説明してください）

ユーザーの依頼ですでに背景の大部分がわかる場合は、該当するステップに直接進んでください。 妥当な前提を明示したうえで、できる範囲で最善の回答を先に提示し、最後に最も重要な確認事項を 1～2 個だけ質問してください。必要な情報をすべて集めるまで回答を保留しないでください。

注：ユーザーが専門的なスキルを必要としている場合は、そのスキルのほうが適している理由を簡潔に説明し、そちらに案内してください。

ステップ 2 — 適切な窓口へ案内する、または直接回答する

依頼が専門スキルに該当する場合は、次のように案内してください。

• 一般的なメールマーケティング戦略／ベストプラクティス -> /sales-email-marketing
• プラットフォームを問わないメール到達率の向上 -> /sales-deliverability
• メールの開封／クリック追跡戦略 -> /sales-email-tracking
• SendGrid 固有の質問 -> /sales-sendgrid
• Zapier やミドルウェアを介した Postmark と他のツールとの連携 -> /sales-integration
• ファネル戦略／コンバージョン最適化 -> /sales-funnel

それ以外の場合は、以下の参考情報を使って、プラットフォームの知識に基づき直接回答してください。

ステップ 3 — Postmark プラットフォームの参考情報

モジュールの詳細なドキュメント、料金、連携、データモデルについては、references/platform-guide.md を読んでください。

プラットフォームガイドの詳細を確認する必要はありません。ユーザー固有の状況に集中してください。

ステップ 4 — 実行可能なガイダンス

ユーザーの具体的な質問に基づいて、以下を案内します。

1. API 経由でトランザクションメールを送信する:

   1. Postmark UI でサーバーを作成します（またはデフォルトのサーバーを使用します）
   2. サーバーの認証情報ページから Server API Token をコピーします
   3. Sender Signature を追加して認証します。単一のメールアドレスまたはドメイン全体を指定できます（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 を使用します

2. トランザクションメールとブロードキャスト用の Message Streams を設定する:

   1. Postmark UI でサーバーに移動します
   2. デフォルトのトランザクションストリームはすでに存在します。パスワードリセット、領収書、アラートに使用します
   3. 新しいブロードキャストストリームを作成します: Servers > [Your Server] > Message Streams > Add Stream > Broadcast
   4. ストリームに名前を付けます（例: 「Newsletter」、「Product Updates」）
   5. API 呼び出しで "MessageStream": "your-broadcast-stream-id" を渡し、ブロードキャストストリームに振り分けます
   6. 必要に応じて、ストリームごとに個別の Webhook を設定します
   7. 各ストリームの統計を個別に監視し、レピュテーションの健全性を追跡します

3. レイアウト継承を使用した Handlebars テンプレートを設定する:

   1. まずレイアウトテンプレートを作成します: Templates > Add Template > Layout
   2. コンテンツテンプレートを挿入する場所に {{{@content}}} プレースホルダーを含めて、レイアウトを定義します
   3. ヘッダー、フッター、スタイル、配信停止リンクなど、共有する要素をレイアウトに含めます
   4. LayoutTemplate フィールドでレイアウトを参照するコンテンツテンプレートを作成します
   5. コンテンツテンプレートで Handlebars 構文を使用します: {{variable}}、{{#if condition}}、{{#each items}}
   6. サンプルデータを使って API (POST /templates/{id}/validate) 経由でテンプレートを検証します
   7. Template Push API を使って、サーバー間でテンプレートを（ステージングから本番環境へ）プッシュします

4. 受信メールを処理する:

   1. Pro プラン以上にアップグレードします（Developer プランと Basic プランでは受信メールを利用できません）
   2. 受信ドメインに MX レコードを追加します: 10 inbound.postmarkapp.com
   3. Postmark UI のサーバーの Inbound 設定で、受信 Webhook URL を設定します
   4. 必要に応じて、Webhook をトリガーする受信者アドレスを絞り込む受信ルールを設定します
   5. 解析済みフィールド（From、To、Subject、HtmlBody、TextBody、Attachments）を含む JSON ペイロードを受信する Webhook エンドポイントを実装します
   6. 添付ファイルを処理します。JSON ペイロード内の base64 エンコードされたコンテンツとして届きます
   7. 受信を確認するため、エンドポイントから 200 ステータスコードを返します

5. DMARC 監視を設定する:

   1. ドメインに DMARC DNS レコードを追加します: v=DMARC1; p=none; rua=mailto:[email protected]
   2. 無料の週次ダイジェストが自動的に届き始めます。自分のドメインを使用してメールを送信している送信者の概要が記載されます
   3. 詳細な監視（月額 14 ドル／ドメイン）を利用するには、dmarc.postmarkapp.com で登録します
   4. レポートを確認し、未承認の送信者や SPF／DKIM のアライメント失敗を特定します
   5. 正当な送信者がすべて認証されたことを確認しながら、DMARC ポリシーを段階的に厳格化します: p=none -> p=quarantine -> p=reject

注意点

調査に基づくベストエフォートの情報です。詳細は最新のPostmarkドキュメントで確認してください。

1. 専用IPの利用には、月間30万通以上の送信量が必要です。 SendGridやMailchimpとは異なり、PostmarkではIPレピュテーションを維持するために、継続的な大量送信が必要です。月間30万通未満の場合、Postmarkの共有IPプールのほうが実際には良い結果を得られます。送信者の審査プロセスにより、共有IPのレピュテーションは非常に高く保たれています。専用IPのほうが優れているとは限りません。
2. 受信メール機能はProプラン以上でのみ利用できます。 受信メールの受信と解析（返信処理、サポートチケット、メールからアプリへのワークフローなど）が必要な場合、DeveloperプランとBasicプランでは対応できません。受信メールがアーキテクチャに含まれる場合は、少なくともPro（月額16.50ドル）の予算を確保してください。
3. トランザクション用ストリームと一斉配信用ストリームでは抑制リストが別々ですが、請求は一括です。 メッセージストリームによって送信レピュテーションは分離されますが、抑制対象はストリームごとに管理されます。一斉配信用ストリームで抑制されたアドレスでも、トランザクションメールは受信できます。その逆も同様です。これは意図的な仕様です（ニュースレターの配信を解除したユーザーにも、パスワードリセットメールは送信する必要があります）。ただし、全体で共通の抑制リストを想定しているチームにとっては、予想外となることがあります。
4. Postmarkには送信者の審査プロセスがあり、すぐに大量送信することはできません。 新規アカウントは承認プロセスを経る必要があります。Postmarkは用途を審査し、送信パターン、対象者、コンテンツについて質問する場合があります。この審査によって共有IPのレピュテーションが高く保たれていますが、登録初日に10万通のメールを一斉送信することはできません。新規アカウントの承認には、1～2営業日かかることを見込んでください。
5. DMARC監視APIは、PostmarkのメインAPIとは完全に別のサービスです。 DMARCサービスは独自の認証トークンとエンドポイントを使用し、dmarc.postmarkapp.comで提供されています。PostmarkのサーバートークンやアカウントトークンをDMARC API呼び出しに使わないでください。どちらもPostmarkの製品ですが、認証情報の異なる別のシステムです。

• 自己改善：ここに記載されていない内容を見つけた場合は、今日の日付とともにreferences/learnings.mdに追記してください。

ステップ5 — 関連スキル

• /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 --skill sales-do

例

例1：Railsアプリ向けのトランザクションメールを設定する

ユーザーの発言：「Railsアプリから注文確認メールと発送通知メールをPostmarkで送信したいです。」 スキルの動作：

1. Postmarkサーバーの作成方法と、Server API Tokenのコピー方法を案内します
2. Sender Signatureの追加と検証の手順を説明します。これには、DNSへのDKIMレコードとReturn-Path CNAMEレコードの追加が含まれます
3. Action MailerをPostmarkのSMTPリレー（smtp.postmarkapp.com、ポート587、トークンをユーザー名とパスワードとして使用）に設定する方法を説明します
4. または、エラー処理を改善するために、SMTPの代わりにネイティブAPI統合用のpostmark-rails gemを推奨します
5. 共通レイアウト（ヘッダー／フッター）を使用する2つのHandlebarsテンプレートを作成します。1つは注文確認用（{{order_number}}、{{items}}を使用）、もう1つは発送通知用（{{tracking_url}}を使用）です
6. 配信失敗の追跡とカスタマーサービスへのアラート送信のために、DeliveryおよびBounce webhookの設定を推奨します 結果：テンプレート、共通レイアウト、適切な認証、配信監視を備えた、本番環境ですぐに使えるトランザクションメールが整います

例 2：ニュースレターとトランザクションメールを分離する

ユーザーの発言：「Postmark を使って、パスワードリセットと週刊ニュースレターの両方を送信しています。ニュースレターの配信停止によって、トランザクションメールの配信にも悪影響が出ています。」 スキルの動作：

1. メッセージストリームについて説明します。すべてのメールをデフォルトのトランザクションストリーム経由で送信している可能性が高いため、ブロードキャストメールのレピュテーションがトランザクションストリームに悪影響を与えています
2. ニュースレター用の新しいブロードキャストストリームの作成を案内します
3. API 呼び出しに "MessageStream": "newsletter" を含めるよう、ニュースレターの送信コードを更新します
4. ストリームごとに個別の Webhook を設定します。トランザクション用にはバウンス／配信、ブロードキャスト用には配信登録状況の変更も設定します
5. 抑制リストはストリームごとに管理されるため、ニュースレターの配信を停止した人にもトランザクションメール（パスワードリセット、領収書）は引き続き届くことを説明します
6. 移行後にブロードキャストストリームの統計情報を確認し、スパム苦情率が 0.1% 未満に低下したことを確かめます 結果：ブロードキャストのレピュテーションに関する問題がニュースレターストリームに限定されることで、トランザクションメールの配信速度が回復します

例 3：サポートチケットシステム向けに受信メールを設定する

ユーザーの発言：「お客様がサポートメールに返信すると、その返信によってシステム内のチケットが自動的に作成または更新されるようにしたいです。」 スキルの動作：

1. ユーザーが Pro プラン以上であることを確認します（受信メールの要件）。該当しない場合は、Basic（$15）から Pro（$16.50）へのアップグレードを提案します
2. サポートドメイン（例：support.company.com）の MX レコードを追加し、inbound.postmarkapp.com を参照するよう案内します
3. Postmark のサーバー設定で受信 Webhook URL を設定します
4. 特定のアドレス（例：*@support.company.com）宛てのメールのみを受け付ける受信ルールを設定します
5. Webhook エンドポイントを設計します。JSON ペイロードを解析して、From、Subject、TextBody、および In-Reply-To ヘッダーまたは To アドレス内のタグから元のチケット ID を抽出します
6. 受信メールを既存のチケットに対応付けて更新するか、一致するチケットが見つからない場合は新しいチケットを作成します 結果：お客様からのメール返信が自動的にサポートシステムに取り込まれる、返信からチケットへの連携フローが実現します

トラブルシューティング

エラーコード 406（Inactive Recipient）でメールが拒否される

症状：有効なはずのアドレスに対する API 呼び出しで、エラーコード 406「非アクティブとしてマークされた受信者に送信しようとしました」が返されます 原因：その受信者は以前にハードバウンスを起こしたか、スパムとして報告したため、Postmark がそのメッセージストリームの抑制リストに自動的に追加しました。Postmark は送信者のレピュテーションを守るため、それ以降の送信をブロックします。 解決策：API（GET /message-streams/{stream}/suppressions/dump）または UI の Suppressions から、該当するメッセージストリームの抑制リストを確認します。根本的な問題が解決している場合（例：受信者のメールボックスが満杯だったものの、現在は解消している場合）は、抑制を削除してアドレスを再び有効にします（本文にメールアドレスを含めて POST /message-streams/{stream}/suppressions/delete を実行します）。ハードバウンスの場合は、再び有効にする前にアドレスが有効であることを確認してください。再度バウンスするアドレスに送信すると、再び抑制リストに追加されます。

Webhook エンドポイントでイベントが重複して受信される

症状：Webhook エンドポイントが同じイベントを複数回処理し、システム内でレコードやアクションが重複して作成されます 原因：エンドポイントがタイムアウト時間内に 2xx ステータスコードを返さない場合や、配信中にネットワークが中断した場合、Postmark は Webhook の配信を再試行します。再試行によって同じイベントのペイロードが再度送信されます。 解決策：Webhook ハンドラーを冪等にし、Webhook ペイロードの MessageID フィールドを重複排除キーとして使用してください。処理する前に、その MessageID とイベントタイプのイベントをすでに処理済みか確認してください。処理済みのイベント ID はキャッシュまたはデータベースに保存します。エンドポイントが数秒以内に 200 ステータスコードをすばやく返すようにしてください。負荷の大きい処理はバックグラウンドキューに移します。再試行が過剰に発生している場合は、エンドポイントの応答時間とエラー率を確認してください。

テンプレートの変数がレンダリングされない（Handlebars タグがそのまま表示される）

症状：送信したメールに、レンダリング後の値ではなく {{variable_name}} というテキストがそのまま表示されます 原因：API 呼び出しでテンプレートモデルのデータが正しく渡されていないか、テンプレート内の変数名が TemplateModel オブジェクト内のキーと一致していません。もう 1 つよくある原因は、POST /email/withTemplate（テンプレート送信）ではなく POST /email（通常の送信）を使用していることです。 解決策：テンプレート送信エンドポイント（POST /email/withTemplate）を使用していることを確認し、正しい変数名を設定した TemplateId（または TemplateAlias）と TemplateModel を渡してください。変数名では大文字と小文字が区別されます。{{OrderNumber}} を使う場合、モデルには "OrderNumber" が必要であり、"orderNumber" ではありません。送信前にテンプレート検証エンドポイント（POST /templates/{id}/validate）を使用し、サンプルデータでレンダリングをテストしてください。Postmark のアクティビティログでレンダリング済みメッセージを確認し、実際に送信された内容と想定していた内容を照合してください。