Google Postmaster Tools は、DNSレコードで所有権を確認したドメインから大量に送信したメールを、Gmail がどう扱っているかを示す、Google の無料のダッシュボードです。バージョン2はバージョン1に置き換わりつつあり、多くのチームが毎朝確認していた、ドメインとIPのレピュテーションの評価がなくなります。この記事では、v2 でわかること、APIの現状、そして私たちが代わりに毎週確認している項目を紹介します。

この記事のポイント

• v2 には、迷惑メール率、フィードバックループ、認証、暗号化、配信エラーが引き継がれ、新たにコンプライアンス状況（Compliance status）が加わりました。ドメインのレピュテーションとIPのレピュテーションは、ダッシュボードからもAPIからもなくなりました。
• 新しい「到達率の分析」（Deliverability analysis）の判定、たとえば「迷惑メール率が0.1%を超えている」（Your spam rate is above 0.1%）は、v2 の中でレピュテーションのシグナルに最も近いものです。
• Gmail での迷惑メール率は0.1%未満に保ち、決して0.3%に達しないようにしましょう。0.3%に達すると、7日連続で0.3%未満を維持するまで、Google のサポートを受けられなくなります。
• グラフの代わりに、迷惑メール率、バウンスコード、クリックをプロバイダーごとに毎週確認し、DMARCレポート、ブロックリスト、シードテストもあわせてチェックしましょう。
• シードテストは、認証とコンテンツのスモークテストであり、受信トレイへの到達率を示すものではありません。

何が、いつ変わったのか

Spam Resource の Al Iverson 氏は、「2025年9月30日以降、ユーザーは新しいバージョン（v2）にしかアクセスできなくなる」と2025年9月に報じました。Google は2025年11月に移行を一時停止しましたが、2026年8月20日、同氏はその一時停止が解除されたと報じています。「GPT V1 は現在、段階的に廃止されつつある」とのことです。

Gmail APIのリリースノートと Spam Resource にもとづく、タイムラインは次のとおりです。

Google のページの更新は追いついていません。10月上旬の時点でも、廃止に関するお知らせには、日付のないまま「従来の Postmaster Tools のウェブインターフェースの廃止を延期している」と書かれていました。また、送信者のガイドラインには今も、「Postmaster Tools で、ドメインとIPアドレスのレピュテーションを」確認するよう記載されています。しかし、ほとんどのアカウントでは、v1 はすでに使えなくなっています。

Postmaster Tools v2 でわかること

引き継がれたもの、新しく加わったもの、そしてレピュテーションの代わりに注視すべきもの。

Google のダッシュボードのヘルプページによると、どのダッシュボードも対象は個人の Gmail アカウントのみで、約24時間以内に更新され、時刻はUTCで表示されます。また、送信量の少ない日はデータが欠けることがあります。

コンプライアンス状況

すべての送信者に対して、送信者のガイドラインにもとづく5つのチェックが行われます。SPFとDKIM、DNSレコード、メッセージの形式、暗号化、迷惑メール率です。Gmail 宛てに1日あたり約5,000通以上を送る一括送信者には、DMARC、ワンクリック配信停止、配信停止の遵守のチェックが加わります。

各行には、「準拠」（Compliant）、「要対応」（Needs work）、「データなし」（No data found）のいずれかが表示されます。値は移動平均なので、修正が反映されるまで最大7日かかります。レポートの対象はプライマリドメインのみで、email.example.com を確認すると、各行は example.com 全体を対象とします。「配信停止の遵守」（Honor unsubscribe）の行は、配信停止の処理に48時間を超えてかかると「要対応」になります。CDNやファイアウォールがリクエストをブロックした場合でも、Google はそれをリクエストとして数えます。

到達率の分析

APIは、ドメインごとのこの判定を、domains.getComplianceStatus の deliverabilityStatusVerdict として返します。Iverson 氏は、すべてのメッセージとそのAPIの値を一覧にまとめています。

USER_FEEDBACK_LOW には注意しましょう。バウンスはなく、迷惑メール率にも問題がなさそうなのに、受信者には無視されている状態です。v1 では、レピュテーションが High から Medium に下がっていくように見えていました。

引き継がれたダッシュボード

迷惑メール率（Spam rate）は、受信トレイに配信されたDKIM認証済みのメールのうち、受信者が迷惑メールとして報告したものの割合です。フィードバックループ（Feedback Loop）は、それを Feedback-ID ヘッダーごとに分けて、どの配信ストリームが迷惑メール報告を招いているかを示します。認証（Authentication）はSPF、DKIM、DMARCの合格率を、暗号化（Encryption）はTLS経由で送信されたメールの割合を示します。

今最も重要なのは、配信エラー（Delivery errors）です。認証済みのメールのうち、Gmail が拒否または遅延させたものの割合を、その理由とともに示します。v2 のAPIでの拒否理由は、bad_attachment、bad_or_missing_ptr_record、ip_in_rbls、low_domain_reputation、low_ip_reputation、spammy_content、stamp_policy_error、other です。レピュテーションは、拒否理由としてしか残っていません。それがわかるのは、すでにメールを失ったあとです。

何がなくなったのか、その理由

以前のダッシュボードは、ドメインとIPのそれぞれを Bad、Low、Medium、High の4段階で評価していました。Google のお知らせによると、このデータは「ほとんどの送信者にとって、具体的な対応につなげにくい」もので、送信者の行動の変化は「反映されるまでに時間がかかり」、ダッシュボードは「レピュテーションは到達率に影響する多くの要因の1つにすぎないため、誤解を招くおそれがある」とのことです。

もっともな理由ですが、それでも失ったものはあります。Iverson 氏が8月に書いたように、このグラフでは、改善策が数週間かけて効いていく様子を確認できました。判定からわかるのは、今日の状態だけです。新しいダッシュボードの提供は約束されていますが、時期は未定です。

Postmaster Tools APIの現状

一般提供されている v2 についての Google の移行ガイドによると、trafficStats は domainStats になり、get と list は1つの domains.domainStats.query メソッドに置き換わりました。domainStats:batchQuery では1回の呼び出しで複数のドメインを扱え、domains.getComplianceStatus は新たに追加されたメソッドです。

v2 の指標は、SPAM_RATE、FEEDBACK_LOOP_ID、FEEDBACK_LOOP_SPAM_RATE、AUTH_SUCCESS_RATE、TLS_ENCRYPTION_RATE、TLS_ENCRYPTION_MESSAGE_COUNT、DELIVERY_ERROR_COUNT、DELIVERY_ERROR_RATE です。Google は、v2 が「ドメインとIPのレピュテーションを除く、既存の v1 のすべての機能」をカバーしており、「現行の v1 APIは廃止される」としています。時期はまだ決まっていません。v1 をもとに新しい仕組みを作るのはやめましょう。

1つのドメインについて、日ごとの迷惑メール率と拒否率を取得する例です。

POST https://gmailpostmastertools.googleapis.com/v2/domains/example.com/domainStats:query
Authorization: Bearer <oauth-token with postmaster.traffic.readonly>
Content-Type: application/json
 
{
  "metricDefinitions": [
    { "name": "spam_rate", "baseMetric": { "standardMetric": "SPAM_RATE" } },
    {
      "name": "reject_rate",
      "baseMetric": { "standardMetric": "DELIVERY_ERROR_RATE" },
      "filter": "error_type = \"reject\""
    }
  ],
  "timeQuery": {
    "dateRanges": {
      "dateRanges": [
        { "start": { "year": 2026, "month": 9, "day": 28 },
          "end": { "year": 2026, "month": 10, "day": 4 } }
      ]
    }
  },
  "aggregationGranularity": "DAILY"
}

開始日と終了日は、どちらも期間に含まれます。データのない日は、迷惑メール報告がゼロだったのではなく、送信量が少なかったことを意味します。社内のダッシュボードが今も v1 のレピュテーションを読み込んでいるなら、そのパネルは削除しましょう。

レピュテーションのグラフに代わる監視計画

レピュテーションの代わりになる単一のシグナルはありません。しかし、次の項目を組み合わせれば、以前のグラフよりも早く異変に気づけます。

プロバイダーごとの迷惑メール率

Google の送信者向けのよくある質問では、迷惑メール率を0.1%未満に保ち、決して0.3%に達しないよう求めています。0.1%を超えた時点で、一括送信者にはすでに悪影響が出ます。0.3%に達すると緩和措置の対象外となり、7日連続で0.3%未満を維持するまで、Google はサポートへの問い合わせに対応しません。

Gmail が数えるのは受信トレイに届いたメールだけなので、迷惑メールフォルダーへの振り分けが多いと、迷惑メール率はかえって健全に見えてしまいます。迷惑メール率とクリックがそろって下がっているなら、悪い兆候です。

Yahoo の送信者向けベストプラクティスでも、上限は同じ0.3%です。迷惑メールフォルダーに入ったものも含め、配信されたすべてのメールで割って計算するESPでは、どちらの数値よりも低く表示されます。

プロバイダーごとのバウンスと遅延のコード

SMTP応答は、最も直接的なフィードバックです。バウンスと遅延を、毎週プロバイダー別、コード別にまとめましょう。Google のSMTPエラーのリファレンスと各プロバイダーのページから、主なものを挙げます。

コードのあとに続く本文を読みましょう。Google のリファレンスには、PTRレコードの欠落からドメインのレピュテーションの低下まで、10種類の 4.7.0 の応答が載っています。

プロバイダーごとのクリック

Gmail は受信者の行動で送信者を判断するため、到達したメッセージあたりの、人によるユニーククリック数を、プロバイダー別・週別に追跡しましょう。1つのプロバイダーだけで下がっているなら、たいていはそのプロバイダーでのフィルタリングが原因です。すべてのプロバイダーで下がっているなら、たいていはコンテンツかオーディエンスが変わったことが原因です。

開封数は使いません。Apple のメールプライバシー保護は、「メールを操作するかどうかにかかわらず、デフォルトでリモートコンテンツをバックグラウンドでダウンロード」します。セキュリティスキャナーによるクリックも除外しましょう（実際のクリックの数え方）。

落とし穴が1つあります。Google Workspace を使う企業は、独自のドメインを使っています。gmail.com、outlook.com、hotmail.com、yahoo.com、icloud.com はプロバイダーとして集計し、それ以外は業務用メールとして扱いましょう。

シードテストは、できることを踏まえて使う

シードテストは、各プロバイダーの決まったアドレスについて、メールが受信トレイに届いたか、迷惑メールフォルダーに入ったか、届かなかったかを報告します。見つけられるのは、すべての受信者に影響する問題です。壊れたDKIMの鍵、ブロックリストに載ったリンクのドメイン、迷惑メールと判定されやすいコンテンツなどです。シードのアドレスには、あなたとのやり取りの履歴がありません。開封も、返信も、「迷惑メールではない」のクリックもなく、Gmail は受信者ごとに判断する部分もあります。Yahoo のパフォーマンスフィードのページでは、パネルやピクセルを使ったトラッキングは「ユーザーのプライバシーとセキュリティを損ない、当社の規約とポリシーに違反するおそれがある」としています。シードテストは、DNS、ドメイン、テンプレート、リンクのドメインを変更したあとと、大規模な配信の前に実行しましょう。その結果を、受信トレイへの到達率として報告してはいけません。

Yahoo Sender Hub と Microsoft SNDS

Yahoo の Sender Hub の Insights ビューでは、確認済みのDKIMドメインごとに、受信トレイに届いたメールの迷惑メール報告率と到達数が表示されます（1日の送信量が最低基準を上回る場合）。迷惑メール報告ごとのレポートを受け取るには、同じドメインを Yahoo の Complaint Feedback Loop に登録しましょう。IPベースのフィードバックループは廃止されています。

Microsoft のSNDSは、今年から新しいポータルに移り、自社で管理しているIPごとに、送信量、迷惑メール報告率、フィルターの判定結果を表示します。SNDSのよくある質問では、迷惑メールと判定されたメッセージが10%未満なら緑、10〜90%なら黄、90%を超えると赤と定義し、0.3%未満の迷惑メール報告率を「良い目安」としています。アクセス権は承認または移行から10か月で期限が切れるので、再認証の予定をカレンダーに入れておきましょう。共有IPは登録できないため、送信プロバイダーに何を監視しているかを尋ねましょう。

DMARCの集約レポートとブロックリスト

集約レポートには、あなたの From ドメインを使っているすべての送信元と、SPFとDKIMが合格し、アライメントが取れているかが表示されます。形式は現在、2026年5月に公開されたRFC 9990 で定められており、RFC 9989、RFC 9991 とともにRFC 7489 を置き換えています。レポートを解析するツールを宛先にした rua のアドレスを公開しましょう。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

新しい送信元、DKIMのアライメントの低下、見慣れない送信量がないかを確認します。Gmail で数値が急に下がったとき、私たちはまず認証を確認します。たいていは、それが最も早く解決できる問題だからです。

次はブロックリストです。Spamhaus の Domain Blocklist は、本文中のリンクや画像のドメインを含め、ドメインを対象としています。SBLが対象とするのはIPです。Gmail は、こうしたリストへのIPの掲載を ip_in_rbls として報告します。

毎週のチェックリスト

0.1%、0.3%、SNDSの数値は、Google、Yahoo、Microsoft が示しているものです。バウンスとクリックのしきい値は私たちが決めたものなので、自社のベースラインに合わせて調整してください。

Brew での対応方法

Brew は、自社の送信データにもとづくチェックをカバーしています。Postmaster Tools、Sender Hub、SNDSも、あわせて開いておきましょう。

get_domain_health（MCPツール、または GET /v1/domains/{domainId}/health）は無料です。healthy、at_risk、critical のいずれかの判定、SPF、DKIM、DMARCの状態、推移付きの0〜100のスコア、修正案付きのシグナルを返します。スコアのうち「レピュテーション」の項目には、キャンペーンとオートメーションの送信から Brew が算出したバウンス率と迷惑メール報告率を使います。送信量が十分ならドメインごと、そうでなければワークスペース全体の数値です。この項目はスコアの25%を占め、同じ0.1%と0.3%の基準を使います。迷惑メール報告率が0.3%以上で、かつ迷惑メール報告が3件以上ある場合、スコアの上限は40になります。include=scoreHistory を指定すると、最大50件のスナップショットが返されるので、推移のグラフを取り戻せます。

create_inbox_placement_test は、認証済みのドメインから、Gmail、Outlook、Yahoo、Apple などのシード受信トレイに実際のメールを送信します。費用は10クレジットと、少量の送信分です。マーケティング用のドメインを認証すると、「シンプルな文面」から「プロモーション型」まで、5種類のテンプレートのパターンによる無料のテストも1回実行されます。上で説明したシードテストの注意点は、ここでも当てはまります。

プロバイダー別のクリックを調べるには、イベントフィードを2回使います。まず GET /v1/analytics/events?eventType=clicked&groupBy=recipientDomain&bucket=week を呼び出し、次に eventType=delivered で同じ呼び出しを行います。ドメインごと、週ごとに、前者を後者で割りましょう。ボットによるクリックは、デフォルトで除外されます。これはイベントの件数なので、2回クリックした人は2回と数えられます。1つのプロバイダーで20%の低下を見つけるにはこれで十分ですが、配信レポートに表示されるユニーククリック率とは異なります。グループ化した集計では最新の20,000件のイベントが読み込まれるため、送信量の多いリストでは、from と to で1週間ずつ指定し、truncated フラグを確認しましょう。問題を調べるときは、bounced、complained、delivery_delayed に置き換えます。ステータスコードは、引き続きバウンスログで確認します。

よくある質問

Google Postmaster Tools では、今もドメインのレピュテーションを確認できますか？

いいえ。v2 にも、そのAPIにも、レピュテーションの指標はありません。レピュテーションの低さは配信エラーの拒否理由としてしか表示されず、最も近い代わりになるのは、到達率の分析の判定です。

Gmail で許容される迷惑メール率はどのくらいですか？

Google は、0.1%未満に保ち、決して0.3%に達しないよう求めています。0.1%を超えた時点で一括送信者にはすでに悪影響が出ており、0.3%に達すると、7日連続で0.3%未満を維持するまで、Google のサポートを受けられません。

Postmaster Tools v1 のAPIは、まだ使えますか？

Google は、v1 のAPIは廃止されるとして、2026年2月3日から一般提供されている v2 への移行を求めていますが、廃止の時期は決まっていません。v2 は、レピュテーション以外のすべてをカバーしています。

Postmaster Tools のダッシュボードが空なのはなぜですか？

Postmaster Tools では、個人の Gmail アカウント宛ての送信量が少ない日のデータは表示されません。迷惑メール率はDKIM認証済みのメールだけを対象とし、確認済みのドメインが、メールのDKIMまたはSPFのドメインと一致している必要があります。Gmail がまだドメインを判断できない場合、到達率の分析には「送信メールが足りない」（Not enough outgoing email）と表示されます。

シードを使った受信トレイ到達テストは、Gmail について正確ですか？

認証の失敗やブロックリストに載ったリンクなど、すべての受信者に影響する問題については正確です。ただし、購読者のエンゲージメントは反映されないため、実際の到達状況は、迷惑メール率、プロバイダー別のクリック、Gmail の判定から判断しましょう。より広い背景については、到達率ガイドと9月の State of Email で解説しています。