グレーリスティングとは何ですか？

グレーリスティングは、初めての送信元からのメールを一時的に拒否（450応答）し、再送信を待つスパム対策手法です。正規のメールサーバーは一定時間後に再送信しますが、スパムボットは通常再送信しないため、スパムを効果的にブロックできます。送信元IP、送信者アドレス、受信者アドレスの三つ組で管理されます。

グレーリスティングのデメリットは？

①初回メールの配信遅延（通常5-30分）②大手メールサービスの複数IPからの送信でホワイトリスト管理が必要③緊急メールの遅延リスク④一部の送信元が再送信しないケースがあります。SPF/DKIM/DMARC認証済みメールはグレーリスティングをスキップする設定が推奨されます。

Postfixでのグレーリスティング設定方法は？

Postgrey（Postfix用グレーリスティングデーモン）を使用します。apt install postgreyでインストール後、main.cfにsmtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10023を追加します。--delayオプションで遅延時間、--auto-whitelist-clientsで自動ホワイトリスト回数を設定可能です。

Greylisting（グレイリスティング） | 用語集 | IT/AIエンジニア　野口真一

この用語をシェア

Facebook X (Twitter)

Greylistingとは

Greylisting（グレイリスティング）は、初回接続のメールを一時的に拒否（SMTP応答コード450）するスパム対策手法です。正規のメールサーバーはRFC 5321に準拠して一定時間後に再送信を行いますが、多くのスパムボットや大量送信ツールは再送信機能を実装していないため、この差異を利用してスパムを効果的にフィルタリングします。一般に2003年頃にEvan Harris氏が提唱した手法とされ、その後Postfix向けのPostgrey、Sendmail/Postfix向けのmilter-greylist、OpenBSDのspamdなど、複数の実装が公開・普及してきました。

ブラックリスト（DNSBL/RBL）のように送信元を「悪」と断定するのではなく、「一度目は保留し、正規の挙動を示すかどうかで判断する」という行動観察型の対策である点が最大の特徴です。コンテンツを一切解析しないため、本文の言語や添付ファイル形式に依存せず、暗号化されたメールにも等しく適用できます。

Greylistingの仕組み・動作原理

トリプレット管理

Greylistingは、以下の3つの要素（トリプレット、triplet）を組み合わせてキーとし、受信側のポリシーデーモンがデータベース（SQLite・MySQL・Berkeley DBなど、実装によって異なる）に記録・照会します。

送信元IPアドレス（接続元のSMTPクライアントIP。実装によっては/24単位などIPブロック単位で丸めることもある）
送信者メールアドレス（MAIL FROMコマンドで通知されるエンベロープFrom）
受信者メールアドレス（RCPT TOコマンドで通知されるエンベロープTo）

この3要素が揃って初めて「未知の組み合わせ」か「既知でリトライ待ちの組み合わせ」かを判定できます。送信元IPだけで判定すると、同一サーバーから複数ドメイン宛に送るケース（メーリングリストなど）で不要な遅延が重なるため、実務ではトリプレット単位の管理が基本です。

なぜスパムボットは再送信しないのか

正規のMTA（Postfix、Exim、Sendmailなど）はキュー管理機構を持ち、一時的エラー（4xx系）を受け取ると配送をキューに戻し、指数バックオフ的な間隔で再試行するのがSMTPの基本仕様（RFC 5321）です。一方、スパム配信に使われるボットネットやワンショット型の大量送信ツールは、以下の理由から再送信を行わないケースが多いとされています。

スループット優先の設計: 1台あたり大量の宛先へ一度だけ送りつけることを目的としており、キューイングや再試行のロジックを実装するコストに見合わない
直接配送（direct-to-MX）型の実装: 正規MTAを経由せず、簡易的なSMTPクライアントスクリプトからMXへ直接送信するため、RFC準拠の再送処理が省略されがち
踏み台の使い捨て運用: 感染端末やレンタルサーバーを短時間だけ利用するため、数分〜数時間後の再送信自体が成立しにくい

ただし近年はこの前提が崩れつつある点に注意が必要で、詳細は本ページの「2025-2026年の最新動向」で後述します。

処理フロー

1. 初回接続（未知のトリプレット）
   → SMTP応答 450 4.2.0（一時拒否、Enhanced Status Codeを付与するのが一般的）
   → トリプレット記録 + 受信タイムスタンプ

2. 再送信（数分〜数十分後）
   → トリプレット照合
   → 「最小遅延時間」を超えていれば受信許可し、以後はホワイトリスト（自動許可リスト）に登録
   → 「最大遅延時間」を超えて再送された場合は、期限切れとして再度拒否されることが多い

3. 以降の接続（ホワイトリスト登録済み・保持期間内）
   → トリプレット照合のみで即座に受信（遅延なし）

典型的な設定パラメータと実装ごとの既定値

遅延時間やホワイトリスト保持期間は実装ごとにデフォルト値が異なります。以下は公開ドキュメント上でよく参照される代表的な設定例です（環境や運用ポリシーにより調整が前提）。

実装	対応MTA	初回拒否後の最小遅延	ホワイトリスト保持期間の目安
Postgrey	Postfix（policyサービス経由）	300秒（既定値）	数十日程度（--max-age等で調整）
milter-greylist	Sendmail / Postfix（milterインターフェース）	設定ファイルのgreylistディレクティブで指定	設定ファイルで個別指定可能
OpenBSD spamd	汎用（PF/pfをMTA前段に配置）	PFのgreylistルールとpasstimeで制御	spamdb内で管理・期限切れ削除
Rspamd greylistモジュール	Postfix / Exim等（proxy/milter経由）	timeout設定値（例: 300秒）	expire設定値（例: 30日）

SMTP応答コードについても補足すると、一時拒否には450（Mailbox unavailable）が最も一般的ですが、実装によっては451（Requested action aborted）や421（Service not available、接続そのものを切断）を使うものもあります。エンハンストステータスコード（4.2.0や4.7.1など）を付与すると、送信側のログで「一時的な措置である」ことが判別しやすくなり、運用上のトラブルシューティングに役立ちます。

具体例・ユースケース

ケース1: 小規模〜中規模の自社メールサーバー

社員数十名規模のメールサーバーをPostfix + Dovecotで自前運用している場合、Postgreyを前段に配置することで、後段のRspamdやSpamAssassinに到達するメール数自体を減らせます。コンテンツフィルタはCPU負荷が高くなりがちなため、Greylistingで「明らかに再送しない送信元」を先に排除しておくと、サーバー全体の処理負荷を抑えられます。実務では、まずGreylistingとRBL照会のような軽量な対策をsmtpd_recipient_restrictionsの前段に置き、コンテンツ解析は最後段に回す多層構成が定石です。

ケース2: ISP・大規模プロバイダでのIPベース運用

受信メール数が膨大なISPやホスティング事業者では、送信者・受信者アドレスまで含めたトリプレット管理はデータベース負荷が大きくなりがちです。OpenBSD spamdのように、パケットフィルタ（PF）と連携してIPアドレス単位でグレーリスティングを行い、正規のMTAらしい挙動（複数回の接続試行、適切な間隔での再送）を示したIPだけをホワイトリストに昇格させる運用がよく採られます。この場合、判定粒度が粗くなる代わりに、大量トラフィックでも現実的な処理コストで運用できます。

ケース3: 認証済み送信元を除外する選択的運用

Google WorkspaceやMicrosoft 365など、SPF/DKIM/DMARCで送信元が明確に認証できる大手クラウドメールサービスからの送信は、そもそも再送信されないリスクを抱えたまま遅延を強いる意味が薄い場合があります。そのため実務では、認証済みかつ送信元レピュテーションが良好な相手には最初からGreylistingをスキップし、未認証・低レピュテーションの送信元にのみ適用する選択的グレーリスティングが広く行われています。Postgreyであればクライアントホワイトリストファイルに主要な送信元ドメインやIPレンジを登録することで実現できます。

# /etc/postgrey/whitelist_clients（クライアントホワイトリスト例）
# コメント行は#で開始。ドメイン名またはIPアドレス/CIDRを1行ずつ記載
mail.google.com
outbound.protection.outlook.com
# 自社の取引先ドメインなど、個別に信頼できる相手を追記

ケース4として、緊急連絡系のメール（パスワードリセット通知やワンタイムパスワードなど）を送る自社SaaSがある場合は、そのSaaSの送信元IPを個別にホワイトリスト登録し、初回配送の遅延によるユーザー体験の悪化を防ぐ、という運用も実務でよく行われます。

メリットとデメリット

メリット

高い効果: 単体でも一定割合のスパムをブロックできるとされ、他対策と組み合わせるとさらに効果が高まる
低負荷: トリプレットの照合のみで判定が完結するため、ベイズ推定や機械学習ベースのフィルタに比べて処理が軽量
誤検知（正規メールの喪失）が起きにくい: 正規のMTAは再送信を行うため、最終的には必ず配送される（遅延はするが、メールそのものを失うリスクは低い）
コンテンツ非依存: 本文やヘッダーを解析しないため、暗号化メールや添付ファイル形式に関わらず一律に適用できる
導入コストが低い: Postgreyやmilter-greylistのように、既存のPostfix/Sendmail環境に軽量なポリシーデーモンを追加するだけで導入できる

デメリット

初回配送の遅延: 新規の送信元からの初回メールは、実装の遅延設定に応じて数分〜数十分程度遅れて到着する
一部の正規サーバーとの相性問題: 大規模メールサービスの中には、送信元IPを送信のたびにローテーションするものがあり、トリプレットのIP部分が毎回変わると再送が「未知の送信元」として扱われ続け、配送がさらに遅れることがある（この対策として送信元をホワイトリスト登録するか、IP部分をサブネット単位で緩く判定する設定が使われる）
緊急メールの遅延リスク: パスワードリセットや二段階認証コードなど、即時性が求められる初回メールが遅延すると業務影響が大きい
運用・管理コスト: ホワイトリストの継続的なメンテナンスや、遅延に対する問い合わせ対応など、導入後も一定の運用コストが発生する
単体では有効性が低下傾向: 後述のとおり、再送信に対応したスパムボットの増加により、単独運用での効果は相対的に下がってきている

混同されやすい用語・類似技術との違い

Greylistingは名称や仕組みが似た他のスパム対策・SMTP制御技術と混同されやすいため、代表的なものとの違いを整理します。

技術	判定の考え方	Greylistingとの違い
ブラックリスト（RBL/DNSBL）	既知の悪性IP・ドメインを事前登録し照会	ブラックリストは「即座に断定して拒否」する静的判定。Greylistingは未知の相手を「保留」して挙動で判定する動的な手法で、初回は誰でも一律に遅延させる点が異なる
ホワイトリスト	信頼済み送信元を事前登録し優先許可	ホワイトリストはGreylisting運用を補完する仕組みであり、対立概念ではない。Greylistingを通過した送信元が自動的にホワイトリスト化される、という関係にある
レートリミッティング（帯域・接続数制限）	単位時間あたりの接続数・送信数を制限	レートリミッティングは「量」を制限する対策で、正規送信元でも大量送信時は制限にかかる。Greylistingは量ではなく「初回かどうか」で判定する点が根本的に異なる
Tarpitting（SMTPタールピット）	SMTPセッション内で応答を意図的に遅延させる	Tarpittingは接続を保持したまま応答を遅らせて送信側のリソースを消耗させる手法。Greylistingは接続を一旦切断（450応答）し、再接続を要求する点が異なり、両者は併用も可能
Nolisting	MXレコードのプライオリティ最上位に、あえてメールを受け付けないダミーサーバーを設定する手法	Nolistingは接続不可を利用して同様に再送有無を判別する発想が近いが、DNS（MXレコード）側の設定で完結し、専用のポリシーデーモンやトリプレット管理を必要としない点が異なる
コンテンツベースフィルタ（SpamAssassinのベイズ推定など）	本文・ヘッダーの内容をスコアリングして判定	コンテンツフィルタはメールが実際に受信されてから内容を解析する。Greylistingはメールを受信する前（SMTPセッション段階）でブロックするため処理コストが低く、両者は補完関係にある

特に混同されやすいのが「Greylisting」と「Blacklisting／Whitelisting」の呼び名の類似性です。Greylistingという名前は、黒（拒否）でも白（許可）でもない「灰色（保留）」の判定を下すことに由来しており、最終的にはトリプレットが確認され次第「白」に移行する一時的な状態を表しています。恒久的な判定を行うブラックリストやホワイトリストとは設計思想そのものが異なる点を押さえておくと、他のスパム対策との組み合わせ方も理解しやすくなります。

自社メールサーバー運用への応用

Postgrey（Postfix用）

# main.cf
smtpd_recipient_restrictions = 
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  check_policy_service inet:127.0.0.1:10023

# Postgrey起動
postgrey --inet=127.0.0.1:10023 --delay=300

Rspamdでの設定

Rspamdには、Greylisting機能が統合されています：

# /etc/rspamd/local.d/greylist.conf
enabled = true;
timeout = 300s;  # 5分
expire = 30d;    # 30日間保持

Docker Mailserverでの有効化

services:
  mailserver:
    environment:
      - ENABLE_RSPAMD=1
      - RSPAMD_GREYLISTING=1

ホワイトリスト設定

特定の送信者（銀行、クラウドサービスなど）は、Greylistingをスキップするようホワイトリスト登録を推奨します。

逆引きDNS（PTRレコード）との連携チェック

Greylisting単体はDNSレコードを直接参照しませんが、実務では前段でPTRレコード（逆引き）の存在確認と組み合わせるのが定石です。PTRレコードが存在しない、あるいはIPアドレスとホスト名の対応が取れていない送信元は、そもそも正規のメールサーバーではない可能性が高いため、Greylistingの判定に入る前に足切りできます。

# 送信元IPの逆引きを確認する例
$ dig -x 203.0.113.10 +short
mail.example.com.

# 正引きと突き合わせて整合性を確認
$ dig mail.example.com +short
203.0.113.10

Postfixでは、smtpd_recipient_restrictionsにreject_unknown_reverse_client_hostnameやreject_unknown_client_hostnameを、Greylistingの check_policy_service より前段に配置することで、「PTRレコードが存在しない接続」を先にリジェクトし、ポリシーデーモン（Postgrey）への問い合わせ自体を減らせます。ただし、reject_unknown_reverse_client_hostnameは正規サーバーでもPTR未設定のケースを誤って弾く場合があるため、まずはログのみで様子を見る運用や、warn_if_reject（警告のみ）から段階的に有効化することが推奨されます。

他のスパム対策との組み合わせ

Greylistingは単独で完結させるのではなく、多層防御の一部として以下の対策と組み合わせることで効果を最大化するのが実務上の定石です。

SPF/DKIM: 送信元ドメインの認証。認証に成功した送信元はGreylistingをスキップする選択的運用と相性が良い
RBL: 既知の悪性IPをブラックリスト照会で即座に拒否し、Greylistingの処理対象そのものを減らす
SpamAssassin/Rspamd: 受信後の本文・ヘッダー解析によるコンテンツフィルタリング。GreylistingとRBLで一次選別した後、最終防衛ラインとして機能させる
逆引きDNS（PTR）チェック: 送信元の正当性を接続段階で確認し、Greylistingの前段フィルタとして機能させる

実装順序の目安としては、①PTR/RBLなど接続レベルの軽量チェック → ②SPF/DKIM認証チェック（認証成功ならGreylistingをスキップ） → ③Greylisting（未認証・未知の送信元に適用） → ④コンテンツフィルタ（Rspamd/SpamAssassin）という段階構成が、処理負荷とスパムブロック率のバランスが取りやすい構成として実務でよく採用されます。

類似技術との違い（Greylisting vs RBL vs コンテンツフィルタ）

スパム対策には複数のアプローチがあり、それぞれ判定基準・処理タイミング・誤検知リスクが異なります。多くの現場ではこれらを多層的に組み合わせて運用します。

技術	判定基準	処理タイミング	誤検知リスク
Greylisting	送信元・再送挙動（トリプレット）	SMTP接続時（一時拒否）	低い（正規メールは遅延するが必ず到達）
RBL	送信元IPの既知スパム評判	SMTP接続時（DNS照会）	中程度（共有IP等で誤登録の可能性）
コンテンツフィルタ（SpamAssassin/Rspamd）	本文・件名・ヘッダーの内容分析	受信後（本文解析）	中〜高（正規メールが誤検知されることがある）

Greylistingは軽量でCPU負荷が小さく即座に導入できる反面、単独では高度なスパムボット（再送信に対応したもの）に対する効果が薄れつつあります。RBLは送信元の評判という「実績」に基づく判定、コンテンツフィルタは「内容」に基づく判定であり、性質が異なるため、Greylisting→RBL→コンテンツフィルタの順に多層防御として組み合わせるのが効果的です。

実務での活用シーン・導入時の注意点

2024年以降のGmail・Yahoo!送信者ガイドライン施行により、正当な送信者はSPF/DKIM/DMARCを適切に設定していることが前提となったため、Greylistingは未認証メールにのみ適用し、認証済みメールはスキップする選択的運用が主流です。自社Postfixサーバーでは、smtpd_recipient_restrictionsの中でSPF/DKIM検証の後段にcheck_policy_serviceを配置することで、認証済み送信者への影響を最小化できます。また、クラウド型の一斉配信サービス（Amazon SES等）からのメールは複数の送信IPを使い回すため、Greylistingのトリプレット判定と相性が悪く、ホワイトリスト登録が実務上ほぼ必須になります。

まとめ

Greylistingは、シンプルかつ効果的なスパム対策手法です。初回配送の遅延というデメリットはありますが、高いスパムブロック率と低い誤検知率により、多くのメールサーバーで採用されています。重要な送信者をホワイトリスト登録することで、デメリットを最小化できます。

AIエンジニアとしての実務経験

Greylistingを導入した当初、「なぜメールがすぐ届かないのか」というユーザーからの問い合わせが殺到しました。特に問題になったのは、パスワードリセットメールやアカウント確認メールなど、即時性が求められるトランザクションメールでした。

解決策として、主要なサービス（Gmail、Microsoft、AWS SES、SendGrid等）のIPレンジをホワイトリストに事前登録しました。また、SPF/DKIM認証がpassするメールはGreylistingをスキップする設定（Rspamdではwhitelist_symbols）を追加し、認証済み送信者の遅延を回避しました。

興味深い発見として、Greylistingの統計を分析したところ、一時拒否されたメールの約85%が再送信されませんでした。これらはほぼ確実にスパムボットからのメールで、Greylistingの有効性を実証するデータとなりました。この統計はAIによるスパム判定モデルの訓練データとしても活用しています。

Greylistingの最新動向（2025年）

インテリジェント・グレイリスティング: 送信者レピュテーションと組み合わせた動的判断
IPプールサポート: クラウド送信者の複数IPプールへの対応
SPF/DKIM連携: 認証成功メールの自動ホワイトリスト化
リアルタイムホワイトリスト: 主要送信者リストの自動更新
遅延時間の最適化: 機械学習による最適な遅延時間の動的調整

よくあるトラブルと失敗例

遅延時間が長すぎる: 30分以上の遅延設定でユーザーの不満増大。5-10分推奨
ホワイトリスト不足: 重要なサービスからのメールが遅延。主要送信者を事前登録
IPプール問題: 大規模送信者の複数IPからの再送で別のトリプレットと認識。IPレンジでホワイトリスト
DBサイズ肥大化: トリプレット情報が蓄積しディスク圧迫。有効期限と定期クリーンアップ設定
Postgrey設定ミス: Postfixとの連携ポート不一致。netstatで確認
自動リトライ失敗: 一部送信サーバーが規定時間内に再送しない。ホワイトリスト対応

権威ある外部リソース

2025-2026年の最新動向

グレーリスティングの有効性低下が指摘されています。高度なスパムボットが再送信に対応するようになり、グレーリスティング単独でのスパム対策効果が減少しています。他の対策と組み合わせた多層防御が必須です。

認証ベースのスキップルールが標準化され、SPF/DKIM/DMARC認証済みメールにはグレーリスティングを適用せず、未認証メールのみに適用する選択的運用が推奨されています。

レピュテーションベースの判定への移行が進み、送信者の評判（レピュテーション）に基づいてグレーリスティングの適用を判断する高度なアプローチが採用されています。

外部リンク

よくある質問（FAQ）

Q. グレーリスティングとは？

初回メールを一時拒否（450応答）して再送信を待つスパム対策です。スパムボットは通常再送信しないため効果的です。

Q. デメリットは？

初回メールの遅延（5-30分）やホワイトリスト管理の手間があります。認証済みメールのスキップ設定が推奨されます。

Q. Postfixでの設定方法は？

Postgreyをインストールし、main.cfでcheck_policy_serviceを設定します。遅延時間や自動ホワイトリストの調整が可能です。

Q. GreylistingとRBLはどちらを先に導入すべき？

まずRBL（Spamhaus ZEN等）の導入が手軽で即効性があります。Greylistingは初回配送の遅延という副作用があるため、RBLやSPF/DKIM検証など他の対策と組み合わせて補完的に導入するのが実務的です。

Q. Rspamd環境でもGreylistingは必要ですか？

Rspamdはコンテンツフィルタとして高精度な判定が可能ですが、Greylistingを併用することでRspamdの処理負荷自体を減らせます。Rspamdには標準でGreylistingモジュールが統合されています。

この用語についてもっと詳しく

Greylistingに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。

お問い合わせサービス一覧

Greylisting（グレイリスティング）