バウンスしてからではなく、Postmarkが送信する前に検証
Postmarkは、ハードバウンスや迷惑メール報告が発生した時点でそのアドレスを自動的に配信除外にするため、無効と判明したアドレスには最初の失敗以降は送信しません。ただし、最初の送信より前にアドレスを判断することはできません。また、Postmarkはトランザクションメール・API向けの送信サービスです。アドレスは自社の登録フォーム、購入手続き、API呼び出しから直接届くため、エクスポートしてクリーニングできるホスト型のオーディエンスがありません。その最初の送信は、パスワード再設定、領収書、確認メールなど、たいてい最も重要なメッセージです。そして一度も検証していない入力ミスや存在しないメールボックスがバウンスするのも、まさにそのタイミングです。Qualisendはこのギャップを埋めます。アドレスの取得時点と一括送信の前にすべてのアドレスを検証し、不良アドレスを配信除外にすることで、不要なアドレスがそもそもPostmarkの送信を引き起こさないようにします。以下で、現在利用できるワークフローと、API・ノーコードでの方法を紹介します。
Postmarkコネクターは近日提供予定
ワンクリックで使えるPostmarkのネイティブコネクター（連携、Postmark上でのリストの直接クリーニング、新しいコンタクトの自動検証）を現在開発中です。提供終了ではなく、提供開始に向けて準備を進めています。それまでの間も、Postmarkのリストをクリーンに保つために必要な機能はすでにすべて利用できます。
下記のCSVでのエクスポート→検証→再インポートの手順と、登録時に検証するためのAPIは、どちらも正式にサポートされ、本番環境で稼働しています。Postmarkを使うチームは現在、この方法でリストをクリーンに保っています。
Postmarkが標準でクリーニングするもの
Postmarkに標準で備わるリストメンテナンス機能は、Message StreamごとのSuppression Listです。ハードバウンス、迷惑メール報告、配信停止、手動での配信除外のいずれかが発生するとアドレスがリストに追加され、配信除外になったアドレスは自動的に無効化されます。そのストリームでの次回以降の送信では、そのアドレスは単に無視されます。これにより、メールプロバイダーに対するレピュテーションが守られ、存在しないアドレスに何度も送信し続けることを防げます。再有効化は意図的に行う必要があります。ハードバウンスと配信停止は、ストリームのSuppressionsタブから、またはSuppressions APIで配信除外を削除することで再有効化できますが、迷惑メール報告は自分では取り消せません。メールを迷惑メールとして報告したアドレスは、サポートに連絡しない限りPostmarkでは再有効化できません。Postmarkが実際に送信したアドレスについては、この仕組みで確実かつ自動的にリストメンテナンスが行われます。
検出できないもの
問題は、これらの仕組みがすべて事後対応型で、作動するには送信と失敗が必要なことです。Postmarkがアドレスを配信除外にするのは、ハードバウンスや報告がすでに発生した後だけです。つまり、リストがきれいになる前に、送信クレジットは消費され、レピュテーションにも悪影響が出ています。しかもPostmarkはマーケティングプラットフォームではなくトランザクションメールの送信サービスなので、見落としは見た目以上に大きくなります。事前にチェックできる独自の登録リストがないため、登録時の入力ミス（jane@gmial.com）、購入手続きで受け付けた使い捨てアドレス、info@、support@ などの役割アドレス、いつの間にか使われなくなったメールボックスは、どれも問題のないアドレスとしてアプリから届きます。そしてコードが最初のメッセージを送信するまで、Postmarkにはそれらを判断する手がかりがありません。最も顕著なのは、Broadcastストリーム向けに用意した受信者リストです。バウンス履歴がまったくない状態で届くため、他のサービスですでに失敗していたアドレスもまったく新しく見え、Postmarkは律儀に1件ずつ送信し、そのままハードバウンスさせてしまいます。
Postmarkのリストをクリーンに保つべき理由
Postmarkでは、影響が非常に具体的です。Postmarkは明確な数値で到達率を管理しており、すべてのMessage Streamでバウンス率10%未満、迷惑メール率0.1%未満を求めています。上限に近づくとストリームの指標をオレンジ色で、超えると赤色で表示し、率が高いまま改善しないサーバーについては送信を一時停止または停止する権利を留保しています。ストリームを最も早く赤色に追い込むのが、一度も検証していない無効なアドレスへの大量送信です。しかもトランザクションメールのアカウントでは、そのバウンスはユーザーが受信を待っている領収書、パスワード再設定、確認メールに直撃します。最も停止されては困るメールです。料金面の影響もあります。Postmarkは保存しているコンタクト数ではなく送信したメール数に応じて課金し、繰り越しはありません。そのため、ハードバウンスに終わるメッセージはすべて、届くはずのないメールのために有料の送信枠（または超過料金）を消費することになります。送信前に検証すれば、両方の問題を同時に解決できます。バウンス率をPostmarkの基準値を大きく下回る水準に保ち、存在しないメールボックスへの送信に料金を払うこともなくなります。これは、GmailとYahoo!が2024年に導入した送信者ガイドラインで直接評価されるのと同じ、バウンスと迷惑メール報告の数値です。
現在利用できるワークフロー
Postmarkには、エクスポートして再インポートできるホスト型のコンタクトリストがありません。アドレスは自社のアプリとAPIから届くため、確実な対策は、Postmarkが送信する前に検証し、不良アドレスを配信除外にすることです。
アドレスの取得時点で検証
アドレスがシステムに入る場所、つまり登録、購入手続き、アカウントのフォームで、保存したりPostmarkでの最初の送信を引き起こしたりする前に検証します。その時点でQualisend APIを1回呼び出すだけで、入力ミスや使い捨てアドレスが受信者になることを防げます。トランザクションメールの送信サービスでは、ここが最も効果の高い検証ポイントです。
受信者リストは送信前にまとめて検証
Broadcastストリームで配信したり、APIで一括送信したりする場合は、先に受信者リストを検証します。ファイルをQualisendの一括クリーニングにアップロードするか（1回の処理あたり最大100万件、重複アドレスの課金は1回のみ）、アドレスを直接貼り付けます。Freeプランの100クレジット（初回のみ、有効期限なし）で、本格的に使い始める前に最初のサンプルを検証できます。
結果を確認
すべてのアドレスに、配信可能・要注意・配信不可・不明のいずれかの判定と、理由コード、0～100のスコア、サブフラグ（キャッチオール、使い捨て、役割アドレス、容量超過）が返され、根拠としてMXプロバイダーとメールボックス確認の詳細も表示されます。クリーニング済みのファイルをダウンロードするか、APIのレスポンスから判定を直接読み取ります。
不良アドレスをPostmarkで配信除外に
配信不可と判定されたアドレスはすべて、送信を引き起こさないようにします。該当するMessage StreamのSuppression Listに手動の配信除外として追加し（ストリームのSuppressionsタブから、またはSuppressions APIで一度に最大50件）、判定を自社のデータベースにも記録して、アプリが再びキューに入れないようにします。こうすることで、バウンスの後ではなく送信の前に、レピュテーションを守る対策ができます。
または登録時に自動で検証
アドレスの取得時点での検証は、自動化を前提にしています。登録や購入手続きの処理の中でQualisendのREST API（スコープ付きキー、レート制限、Webhook）を呼び出せば、アドレスを保存したりPostmarkに渡したりする前に検証できます。また、Zapier、Make、n8nでノーコードのフローを組めば、新しいリードが届いた瞬間に検証できます。同じ方法で最後まで自動化することも可能です。配信不可の判定をそのままPostmarkのSuppressions APIにつなげれば、アプリがPostmarkにそのアドレスへの送信を依頼する前に、手動の配信除外として自動的に登録されます。
Qualisendがすべてのアドレスで検出するもの
- 一度も検証されておらず、Postmarkでの最初の送信（多くはパスワード再設定や領収書）でハードバウンスする無効なアドレス
- 登録時や購入手続きで受け付けた、期限切れになる前提で作られた使い捨てドメイン
- Broadcastストリームで迷惑メール報告を招き、エンゲージメントをゆがめる役割アドレス（info@、support@ など）
- キャッチオールドメイン。フラグを付けるので、別のストリームに振り分けて慎重に送信できます
- すべてのアドレスに付く0～100の信頼度スコアと、機械判読可能な理由コード。そのまま手動の配信除外として反映できます
ワンクリックで使えるPostmarkのネイティブコネクターを現在開発中です（提供終了ではありません）。提供開始までは、上記のCSVでの手順とAPIが正式にサポートされた方法で、Postmarkのどのプランでも利用できます。
結果ごとの対処法
各アドレスには判定とサブフラグが返されます。まだ届くコンタクトを失わずにPostmarkのリストをクリーンに保つための対処法は次のとおりです。
配信可能トランザクションメールでもBroadcastでも、通常どおり送信します。配信可能 + 役割アドレスフラグアカウント関連のメールやトランザクションメールには問題ありません。エンゲージメントで評価されるBroadcast配信からは外します。要注意 + キャッチオールフラグ別のストリームに振り分けて慎重に送信します。ドメインがすべての宛先を受け付けるため、メールボックスが実在するかは確認できません。要注意 + 使い捨てフラグ手動の配信除外として追加します。期限切れになる前提で作られたメールボックスです。不明そのまま通して、次回に再検証します。多くはグレーリスティングやレート制限によるもので、メールボックス自体の判定ではありません。配信不可すぐにストリームのSuppression Listに追加します。領収書のメールでバウンスさせて、バウンス率をPostmarkの上限である10%に近づけないようにします。関連記事
受信者のクリーニングは到達率対策の半分です。Postmarkの送信ドメイン認証もあわせて設定してください。
アドレスの取得時点で検証し、不要なアドレスがPostmarkの送信を引き起こさないようにします。
APIを組み込む前に、受信者の一部を抜き取りで確認できます。
Postmarkはストリームごとにバウンス率の上限を10%と定めています。この数値が重要になる理由を解説します。
トランザクションメールのストリームでは、不良アドレスへの1回の送信が無駄なクレジット以上の損失になる理由。
Postmarkからの配信が評価される、2024年導入のバウンス率・迷惑メール率の基準。
Postmarkのメールアドレス検証に関するよくある質問
Postmarkのリストを数分でクリーニング
有効期限のない100クレジットで無料で始められます。クレジットカード登録は不要です。連携して検証するだけで、次のキャンペーンを守れます。