送信者レピュテーション（Sender Reputation）
概要
送信者レピュテーション（Sender Reputation） は、メール送信元の IP アドレスやドメインに対してメールボックスプロバイダーが付与する信頼度スコアです。受信サーバーはこのスコアをもとに、受信したメールを受信トレイに配信するか、迷惑メールフォルダに振り分けるか、拒否するかを判断します。
レピュテーションの評価要素は複数あります。バウンス率、スパム報告率、DNSBL（DNS-based Blocklist）への登録状況、SPF・DKIM・DMARC の認証設定、FCrDNS の成否、送信量の安定性、エンゲージメント指標（開封・クリック）などが組み合わさって総合的に判定されます。
2024 年 2 月に Google（Gmail）と Yahoo がバルクセンダー（1 日 5,000 通以上）に対するガイドラインを厳格化し、SPF・DKIM・DMARC の設定、ワンクリック購読解除（RFC 8058）、スパム報告率 0.3% 未満の維持を義務化しました。2025 年 5 月には Microsoft（Outlook、Hotmail、Live）も同等の要件を導入しています。レピュテーションはこれらの要件を満たしているかどうかのシグナルとして機能し、メール配信の成否を左右します。
仕組み
レピュテーションは IP アドレスとドメインの 2 軸で評価され、バウンス率やスパム報告率など複数の指標を組み合わせて算出されます。
IP レピュテーションとドメインレピュテーション
送信者レピュテーションには 2 つの軸があります。
IP レピュテーションは、メールを送信するサーバーの IP アドレスに紐づくスコアです。送信量、バウンス率、スパムトラップへの送信有無、DNSBL への登録状況が評価されます。専用 IP を使っている場合は自社の送信行動だけが反映されますが、共有 IP（メール配信サービスの共有プール等）の場合は他の送信者の行動にも影響を受けます。
ドメインレピュテーションは、送信ドメイン（ヘッダー From のドメイン）に紐づくスコアです。DKIM 署名の d= ドメインや SPF のエンベロープ From ドメインも評価対象になります。Google は 2025 年 10 月に Postmaster Tools v2 へ移行し、従来の IP / ドメインレピュテーションダッシュボードを廃止して「Compliance Status」と「Spam Rate」の 2 つのダッシュボードに集約しました。
評価要素
受信サーバーがレピュテーションを算出する際に参照する主要な指標は以下の通りです。
| 指標 | 評価内容 | 目安 |
|---|---|---|
| バウンス率 | 無効アドレスへの送信割合 | 2% 未満 |
| スパム報告率 | 受信者がスパム報告した割合 | 0.3% 未満（Google 要件） |
| DNSBL 登録 | Spamhaus、Barracuda 等のブロックリストへの掲載 | 未登録であること |
| 認証設定 | SPF・DKIM・DMARC の pass 率 | 全メールで pass |
| FCrDNS | 送信 IP の逆引き・正引きの一致 | pass であること |
| スパムトラップ | 無効化されたアドレスやハニーポットへの送信 | 送信しないこと |
| エンゲージメント | 開封率・クリック率・返信率 | プロバイダーが独自に評価 |
Gmail はスパム報告率を最重要指標として扱い、0.1% 未満を推奨、0.3% を超えると配信に影響が出始めます。
DNSBL とレピュテーション
DNSBL（DNS-based Blocklist）は、スパムやマルウェアの送信元として報告された IP アドレスやドメインをリスト化したデータベースです。RFC 5782（2010年）が DNSBL の構造を定義し、RFC 6471（2012年）が運用のベストプラクティスを示しています。
受信サーバーは SMTP 接続時に送信元 IP を DNSBL に照会します。照会は DNS クエリで行われ、IP アドレスを逆順にしてリストのゾーンに問い合わせる形式です。
# Spamhaus ZEN に 198.51.100.25 が登録されているか確認する
dig +short 25.100.51.198.zen.spamhaus.orgA レコードが返れば登録されています。127.0.0.2 は SBL（Spamhaus Block List）、127.0.0.4 は XBL（Exploits Block List）など、返される IP アドレスによってリスティングの種別がわかります。レスポンスがなければ（NXDOMAIN）、そのリストには登録されていません。
代表的な DNSBL を以下に示します。
| リスト名 | 対象 | 用途 |
|---|---|---|
| Spamhaus SBL | IP アドレス | スパム送信元のブロック |
| Spamhaus DBL | ドメイン | スパムに使用されたドメインのブロック |
| Barracuda BRBL | IP アドレス | Barracuda ユーザー向けフィルタリング |
| SORBS | IP アドレス | オープンリレー・スパムソースのブロック |
プロバイダーごとの評価基準の違い
レピュテーションの算出方法はプロバイダーごとに異なり、仕様は公開されていません。ただし、各プロバイダーが提供するモニタリングツールで自社の送信状況を確認できます。
Google は Postmaster Tools でスパム率、認証ステータス、配信エラーのデータを提供しています。1 日あたり 100 通以上を Gmail ユーザーに送信するとデータが生成されます。Microsoft は Smart Network Data Services（SNDS）で、Outlook.com への送信に関する IP ごとのレピュテーション、スパム率、送信量、トラップヒット率を提供しています。SNDS は専用 IP を使用している送信者のみが利用可能です。
確認方法
送信元 IP が DNSBL に登録されているかは dig コマンドで直接確認できます。
# Spamhaus ZEN への照会（IP を逆順にして問い合わせる）
dig +short 25.100.51.198.zen.spamhaus.org# Barracuda BRBL への照会
dig +short 25.100.51.198.b.barracudacentral.orgNXDOMAIN（応答なし）であれば登録されていません。A レコードが返った場合は、そのリストに掲載されています。
送信元 IP の逆引き（PTR レコード）と FCrDNS の状態も確認します。
# 逆引き
dig -x 198.51.100.25# PTR の結果を正引きで再検証
dig A mail.example.com外部の視点からも確認したい場合は、Labee Dev Toolbox の IP API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/ip?ip=198.51.100.25"レスポンスは次の形式で返ります。
{
"success": true,
"data": {
"ip": "198.51.100.25",
"type": "IPv4",
"isPrivate": false,
"ptr": "mail.example.com"
},
"error": null,
"meta": { "responseTime": 42 }
}data.ptr が null の場合、PTR レコードが未設定であり、FCrDNS が成立しません。レピュテーションに悪影響を与える要因の 1 つです。
メール認証全体の設定状況は、Mail Auth API でも確認できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"レスポンスは次の形式で返ります。
{
"success": true,
"data": {
"spf": {
"record": "v=spf1 include:_spf.google.com ~all",
"exists": true
},
"dkim": {
"record": null,
"exists": false,
"selector": "default"
},
"dmarc": {
"record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
"exists": true
},
"bimi": {
"record": null,
"exists": false
}
},
"error": null,
"meta": { "responseTime": 120 }
}data.spf.exists、data.dkim.exists、data.dmarc.exists が全て true であれば、認証レコードが外部から参照可能な状態です。data.dmarc.record の p= タグでポリシーの強度も確認できます。認証が不十分な状態はレピュテーション低下の直接的な原因になります。
よくある問題
レピュテーション低下の原因は、スパム報告率の上昇、DNSBL 登録、バウンス率超過、新規 IP からの急激な送信量増加に集中しています。
スパム報告率が高い
受信者がメールを「スパム」として報告する割合が高いと、レピュテーションは急速に低下します。Google は 0.3% を超えると配信制限を適用し始めます。原因として多いのは、購読を明示的に承諾していない受信者への送信、配信停止の導線が分かりにくい、送信頻度が受信者の期待と合っていない、といったケースです。
対策として、ダブルオプトインの導入、メールヘッダーへの List-Unsubscribe と List-Unsubscribe-Post の設定（RFC 8058 準拠のワンクリック購読解除）、配信頻度の最適化を行います。Google Postmaster Tools の Spam Rate ダッシュボードで継続的にモニタリングし、0.1% 未満を維持するのが目標です。
DNSBL に登録された
DNSBL に登録されると、そのリストを参照している受信サーバーからのメール受信が拒否されます。Spamhaus SBL に登録された場合の影響は大きく、多くの受信サーバーが Spamhaus を参照しています。
登録原因を特定するには、リストの運営元が提供するルックアップページで登録理由を確認します。スパムトラップへの送信、オープンリレーの悪用、マルウェア感染による不正送信が代表的な原因です。原因を解消したうえで、リスト運営元に解除（delisting）を申請します。Spamhaus の場合は自動解除の仕組みがあり、原因が解消されていれば一定期間後に自動で削除されます。
バウンス率が高い
無効なメールアドレスへの送信が多いと、送信者がリストの衛生管理を怠っていると判断され、レピュテーションが下がります。バウンス率は 2% 未満が目安です。
ハードバウンス（SMTP 5xx）が返ったアドレスは即座にリストから除外します。ソフトバウンス（SMTP 4xx）が繰り返し発生するアドレスも、一定回数を超えたらサプレッションリストに追加します。定期的なリストクリーニングと、新規登録時のメールアドレス検証（ダブルオプトイン）が有効です。
新規 IP / ドメインからの大量送信
新しい IP アドレスやドメインには送信履歴がなく、レピュテーションが確立されていません。この状態で大量のメールを一度に送信すると、スパム送信者と同様のパターンと見なされ、受信サーバーにブロックされます。
IP ウォームアップと呼ばれる手法で、送信量を段階的に増やしてレピュテーションを構築します。初日は数百通から始め、2〜4 週間かけて目標送信量まで引き上げるのが一般的です。ウォームアップ期間中はエンゲージメントの高い受信者（過去に開封やクリックの実績がある宛先）を優先的に送信先に含め、pass 率とエンゲージメント率を高く保ちます。
共有 IP でレピュテーションが低下した
メール配信サービスの共有 IP プールを使っている場合、同じ IP を使う他の送信者の行動がレピュテーションに影響します。他の送信者がスパムを送信したり、DNSBL に登録されたりすると、共有 IP 全体のレピュテーションが下がります。
送信量が十分にある場合（月 5 万通以上が目安）は、専用 IP に移行することで他の送信者の影響を排除できます。ただし専用 IP は自社の送信行動がそのままレピュテーションに反映されるため、リスト管理や認証設定を自社で責任を持って運用する必要があります。
レピュテーションと認証設定の関係
SPF・DKIM・DMARC の認証設定は、レピュテーションを構成する基盤です。認証が pass しているだけではレピュテーションが高くなるわけではありませんが、認証が fail している状態ではレピュテーションの回復は見込めません。
| 認証方式 | レピュテーションへの影響 |
|---|---|
| SPF | エンベロープ From の送信許可 IP を宣言。fail するとなりすましの疑いでスコア低下 |
| DKIM | メール改ざんがないことを署名で証明。fail すると信頼性が低下 |
| DMARC | SPF / DKIM の結果をポリシーで制御。p=reject はドメインの保護意思を示す |
| FCrDNS | 送信 IP の正当性を DNS レベルで証明。fail すると基礎的な信頼が欠如 |
DMARC ポリシーを p=none から p=quarantine、p=reject へ段階的に強化することは、ドメインオーナーとして自ドメインの送信を管理している意思表示になります。認証設定の整備は、レピュテーション改善の第一歩です。