# Postmaster Tools v2：レピュテーションに代わる監視指標

正規URL：https://brew.new/ja/blog/postmaster-tools-v2-what-to-monitor
執筆：Thomas Park
公開日：2026-10-08
更新日：2026-10-08

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月に報じました](https://www.spamresource.com/2025/09/google-changes-coming-to-gpt.html)。Google は2025年11月に移行を一時停止しましたが、2026年8月20日、同氏は[その一時停止が解除されたと報じています](https://www.spamresource.com/2026/08/gpt-v1-retirement-and-important-updates.html)。「GPT V1 は現在、段階的に廃止されつつある」とのことです。

[Gmail APIのリリースノート](https://developers.google.com/workspace/gmail/release-notes)と Spam Resource にもとづく、タイムラインは次のとおりです。

| 日付 | 出来事 |
| --- | --- |
| 2024年 | Postmaster Tools v2 が、v1 と並行して提供開始 |
| 2025年12月2日 | v2beta APIがデベロッパープレビューとして公開 |
| 2026年2月3日 | API v2 の一般提供が開始 |
| 2026年6月24日 | APIでドメインとユーザーの管理が可能に。コンプライアンス状況で、到達率の判定が返されるように |
| 2026年8月20日 | v1 へのアクセスがアカウントごとに削除されていると、Spam Resource が報道 |

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

## Postmaster Tools v2 でわかること

![Postmaster Tools v1、v2 のダッシュボード、v2 のAPIを1行ずつ比較した表。ドメインとIPのレピュテーションの行には廃止の印が付き、それぞれの代わりとなるシグナルが記載されている。](/images/blog/postmaster-tools-v2-what-to-monitor-v1-vs-v2.png)

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

Google の[ダッシュボードのヘルプページ](https://support.google.com/mail/answer/14668346)によると、どのダッシュボードも対象は個人の 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の値を一覧にまとめています](https://www.spamresource.com/2026/09/gpt-lets-talk-deliverability-analysis.html)。

| ダッシュボードのメッセージ | APIの理由コード | 対応 |
| --- | --- | --- |
| ユーザーがメールの受信を望んでいる（Users signal they want to get your email messages） | `USER_FEEDBACK_POSITIVE` | 対応は不要です。これが目指す状態です。 |
| 送信メールが足りない（Not enough outgoing email） | `MESSAGE_VOLUME_LOW` | 安定して送信し、送信量はゆっくり増やします。 |
| 送信者の要件を満たしていない（You don't meet our sender requirements） | `SENDER_NOT_COMPLIANT` | コンプライアンス状況で「要対応」になっている行を修正します。 |
| 配信エラーのあるメッセージが多い（Many messages with delivery errors） | `SMTP_ERRORS_HIGH` | Gmail の4xxと5xxの応答を読み、送信ペースを落とします。 |
| ユーザーがメールの受信を望んでいない（Users signal that they don't want to get your email messages） | `USER_FEEDBACK_NEGATIVE` | 誰に、どのくらいの頻度で、何を送っているかを見直します。 |
| ユーザーがメッセージに反応していない（Users don't take action on your messages） | `USER_FEEDBACK_LOW` | 長期間反応のない受信者を除外し、コンテンツを変えます。 |
| 迷惑メール率が0.1%を超えている（Your spam rate is above 0.1%） | `SPAM_RATE_HIGH` | 緊急です。迷惑メール報告を招いているリストの入手元への送信を止めます。 |

`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 の[移行ガイド](https://developers.google.com/workspace/gmail/postmaster/guides/migration-v2)によると、`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つのドメインについて、日ごとの迷惑メール率と拒否率を取得する例です。

```http
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 の[送信者向けのよくある質問](https://support.google.com/mail/answer/14229414)では、迷惑メール率を0.1%未満に保ち、決して0.3%に達しないよう求めています。0.1%を超えた時点で、一括送信者にはすでに悪影響が出ます。0.3%に達すると緩和措置の対象外となり、7日連続で0.3%未満を維持するまで、Google はサポートへの問い合わせに対応しません。

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

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

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

SMTP応答は、最も直接的なフィードバックです。バウンスと遅延を、毎週プロバイダー別、コード別にまとめましょう。Google の[SMTPエラーのリファレンス](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes)と各プロバイダーのページから、主なものを挙げます。

| プロバイダー | 応答 | 意味 |
| --- | --- | --- |
| Gmail | `421 4.7.0` 「very low reputation of the sending IP address」または「sending domain」 | レピュテーションの問題による遅延。どちらが原因かは本文に書かれている |
| Gmail | `550 5.7.1` 「likely unsolicited」または「very low reputation」 | 迷惑メールとして拒否 |
| Gmail | `421 4.7.28` 「unusual rate of unsolicited email」 | IP、ドメイン、またはURLのドメイン単位でのレート制限 |
| Gmail | `4.7.27`、`4.7.30`、`4.7.31`、`4.7.32` | 順に、SPFの失敗、DKIMの失敗、DMARCレコードなし、From のアライメントなし |
| Microsoft | `550 5.7.515` | 1日5,000通を超えて送信するドメインが、Outlook の[認証要件](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730)を満たしていない |
| Yahoo | `421` または `451` | 一時的なエラー。迷惑メール報告や異常なトラフィックによるものを含む（[Yahoo のエラーコード](https://senders.yahooinc.com/smtp-error-codes/)） |
| Yahoo | `553` または `554` | 恒久的なエラー。DMARCの失敗や Spamhaus への掲載によるものを含む。再試行しないこと |

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

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

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

開封数は使いません。Apple の[メールプライバシー保護](https://www.apple.com/legal/privacy/data/en/mail-privacy-protection/)は、「メールを操作するかどうかにかかわらず、デフォルトでリモートコンテンツをバックグラウンドでダウンロード」します。セキュリティスキャナーによるクリックも除外しましょう（[実際のクリックの数え方](/ja/blog/email-metrics-that-matter)）。

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

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

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

### Yahoo Sender Hub と Microsoft SNDS

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

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

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

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

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

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

次はブロックリストです。Spamhaus の [Domain Blocklist](https://www.spamhaus.org/blocklists/domain-blocklist/) は、本文中のリンクや画像のドメインを含め、ドメインを対象としています。SBLが対象とするのはIPです。Gmail は、こうしたリストへのIPの掲載を `ip_in_rbls` として報告します。

## 毎週のチェックリスト

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

| チェック項目 | 確認する場所 | 健全な状態 | 対応が必要なとき | 最初の対応 |
| --- | --- | --- | --- | --- |
| Gmail の迷惑メール率 | Postmaster Tools v2 またはAPI | 0.1%未満 | いずれかの日に0.1%以上 | フィードバックループで該当する配信ストリームを特定し、一時停止する |
| Gmail の判定 | 到達率の分析 | `USER_FEEDBACK_POSITIVE` | ほかの判定が2週間続く | 上の表にある、その判定への対応に従う |
| Gmail のコンプライアンス | コンプライアンス状況 | すべて「準拠」 | 「要対応」が1つでもある | 修正し、反映まで7日待つ |
| Yahoo の迷惑メール報告 | Sender Hub の Insights | 0.3%を大きく下回る | 2週連続で上昇 | フィードバックループのレポートをキャンペーンごとに確認する |
| Outlook のIP | SNDS（自社のIPのみ） | 緑 | 黄か赤の日が1日でもある | その日の送信量とオーディエンスを比較する |
| バウンスと遅延 | バウンスログ（プロバイダー別） | ハードバウンスが1%未満 | 2%を超える、またはレピュテーションやレート制限に関する本文がある | 送信ペースを落とし、応答の全文を読む |
| プロバイダー別のクリック | 自社の分析データ | 8週間の平均から20%以内 | 1つのプロバイダーで20%以上低下 | 次の配信でシードテストを行い、そのプロバイダーで反応のない受信者を減らす |
| 認証 | DMARCの集約レポート | 既知の送信元が合格し、アライメントも取れている | 新しい送信元がある、またはアライメントが低下 | 送信前に、DNSかベンダーのDKIMを修正する |
| ブロックリスト | Spamhaus での検索 | 掲載なし | 掲載が1件でもある | 原因を特定してから、掲載の解除を依頼する |
| シードテスト | 到達テストのツール | 主要なプロバイダーすべてで受信トレイに到達 | いずれかのプロバイダーで迷惑メールフォルダーに入る | 前回合格したバージョンとの差分を確認する |

## Brew での対応方法

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

[`get_domain_health`](https://docs.brew.new/api-reference/public-v1/domains/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回実行されます。上で説明したシードテストの注意点は、ここでも当てはまります。

プロバイダー別のクリックを調べるには、[イベントフィード](https://docs.brew.new/api-reference/public-v1/analytics/unified-events-feed)を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 の判定から判断しましょう。より広い背景については、[到達率ガイド](/ja/blog/email-deliverability)と[9月の State of Email](/ja/blog/state-of-email-september-2026) で解説しています。