入力ミスを拾うため、ドメインのキャッチオールを有効にすることがあります。例えば、saels@と誤入力された宛先を、本来のsales@への問い合わせとして回収したい場合です。未知の宛先も処理しますが、迷惑メール対策や他の受信検査を省く設定ではなく、宛先の受け付けはメッセージ全体の最終受け付けとは別です。偽造送信者へのエラー通知、自動返信のループ、外部転送による配信問題は管理すべきリスクで、必ず起こる結果ではありません。
「キャッチオールを有効にして受信箱へ送る」だけでは運用を説明しきれません。本記事では隔離用メールボックス、Postfixのパターンによる振り分け、ループ防止、外部転送の認証上の注意点を扱います。基本はメール転送の設定ガイドで確認してください。ここではキャッチオールを詳しく見ていきます。
ドメインのキャッチオールとは
キャッチオールは、メールボックス、エイリアス、グループなどの有効な宛先に一致しないドメイン内のアドレスを処理するメールサーバーの規則です。未知の宛先に550 User Unknownを返す代わりに、宛先指定への応答として250 OKを返し、代替の宛先へ振り分ける場合があります。宛先の受け付けは、メッセージデータの最終的な受け付けとは別です。キャッチオールはSMTPエンベロープの宛先を扱い、それ自体が送信者認証を壊すわけではありません。
エンベロープとヘッダーを区別する理由
二つの層を区別すると、振り分けと認証を理解しやすくなります。原因が分かれば二分で直せるというのは一例で、解決時間の約束ではありません。別の問題では調査に数日かかる場合もあります。
RFC 5321はSMTPエンベロープと、セッション中のRCPT TO、MAIL FROMを定義します。RFC 5322は、メールソフトに表示されるTo:やFrom:などのメッセージヘッダーを定義します。
キャッチオールは未知のエンベロープ宛先を別の宛先へ対応付け、ヘッダーは維持できます。SPFはMAIL FROMのドメイン、または適用されるHELOの識別名について接続元IPの許可を確認します。DKIMは署名対象のヘッダーと本文部分を暗号学的に検証します。DMARCには、SPFまたはDKIMの少なくとも一方が成功し、そのドメインが表示されるFromと整合していることが必要です。宛先の変更だけでこれらが失敗するわけではありません。一方、外部転送や署名対象部分の変更は認証結果に影響する場合があります。
外部転送で起こり得る問題
キャッチオールをGmailやOutlook.comへ転送するとSMTPの段階が増えます。次の例は起こり得る失敗で、すべての転送に共通する結果ではありません。
- 元の送信者：
client@bank.com（IP: 1.2.3.4） - サーバーが
typo@yourdomain.comを受け付け、you@gmail.comへ転送する - Gmailには中継サーバーのIPから接続するが、エンベロープ送信者はbank.comのまま
- bank.comのSPFが中継IPを許可していなければSPFが失敗する
DMARC p=rejectで整合した有効なDKIMもなければ拒否される可能性がある。ただし配信エラーが送信者へ返される場合もある
キャッチオールで入力ミスの宛先を拾えても、転送が別の問題を加える可能性があります。転送が必要ならSRS（Sender Rewriting Scheme）や、書き換えを管理するサービスを検討してください。SRSは元のFromとの整合性を回復せず、配送も保証しません。紹介するTrekMailのメールエイリアス転送は、対応するプランと経路でサーバー側の処理を提供します。現在の条件を確認してください。
キャッチオールの三つのリスク
主な注意点は、バックスキャッター、自動返信ループ、転送時のSPF/DMARC問題です。設定変更前にまとめて検討してください。一つだけ対処すると、五分で終える予定の作業が一週間の後始末につながる場合もあります。これは所要時間の例で、固定の期間ではありません。
1. バックスキャッターと評判への影響
メッセージデータの後に250 OKで最終的に受け付け、その後配信せずMAIL FROMへエラー通知を送ると、バックスキャッターになる場合があります。送信者が偽造されていれば、無関係な人へ通知が届きます。こうした不要なメールは評判を損ない、ブロックリスト登録につながる可能性がありますが、数日で必ず登録されるわけではありません。
許可しない宛先はSMTPセッション中の該当する250 OKより前に拒否するか、受け付けたメールを管理された隔離先で処理します。偽造された、または確認できない送信者へ不要な通知を送らないようにしてください。これは正当な配信エラー通知を一律禁止する意味でも、正常なメールを標準で無通知削除する意味でもありません。
2. 自動返信ループ（Exchangeエラー5.4.14）
キャッチオールの受け取り先で不在通知が有効だと、random@yourdomain.comへのスパムに偽造送信者宛ての返信が発生する場合があります。経路によってはエラー通知や返信がrandom@yourdomain.comへ戻り、ループになることがあります。Exchangeは550 5.4.14 Hop count exceeded - possible mail loopと記録する場合がありますが、自動返信がすべてこの経路を作るわけではありません。
対応するExchange環境では、キャッチオールのメールにX-Auto-Response-Suppress: Allを付ける方法を検討できます。返信、配信通知、開封確認のどれが実際に抑制されるか検証してください。動作は全システム共通ではなく、このヘッダーだけでループを防げるとは限りません。
3. アドレス収集攻撃（DHA）
すべての宛先に250 OKを返すと、攻撃者はadmin@、hr@、ceo@、invoice@など数千の組み合わせを試せます。キャッチオールが示すのはサーバーが受け付けることだけで、実在するメールボックスの一覧ではありません。迷惑メールが増え、何年も続く可能性はありますが、実在アドレスの確認や一定の攻撃期間を意味するわけではありません。
対策の一つは、後述の戦略2のように特定パターンだけを受け付けることです。
戦略1：専用の隔離メールボックス
未知の宛先のメールを主な受信箱とは別のメールボックスへ集め、アクセス、フィルター、保存期間を管理する方法があります。個別に検証して承認した場合を除き、自動転送や不在通知は無効にします。専用メールボックスはセキュリティ上のサンドボックスではなく、それだけで安全や評判を保証しません。正当なメールを確認して回収できる運用を用意してください。
処理の例：
- 受け付け：規則に従って
*@domain.comを処理する - 識別：未知の宛先を、メールボックス、エイリアス、グループなどの有効な宛先と区別する
- 分離：
catchall_sink@domain.comなどの専用メールボックスへ送る - 抑制：適切なExchange環境でスパム信頼レベル（SCL）9により高確度のスパムとしての処理を要求し、
X-Auto-Response-Suppress: Allも検討する。実際の分類と動作を検証する
週次の確認を予定し、量や緊急性に合わせて頻度を調整できます。正当なメールを適切な受信箱へ移し、残りは規則に従って処理します。容量、保存期間、アクセスも確認してください。放置された隔離先では、回収したかった問い合わせが失われる可能性があります。
Microsoft 365 / Exchange Onlineのトランスポートルール
M365では、権限を持つ管理者による確認が必要です。Internal RelayはDirectory Based Edge Blocking（DBEB）を無効にしますが、それだけでキャッチオールを実装できず、全宛先がクラウド内にあるドメインには適しません。他の宛先を扱うには、承認済みの自社管理サーバーへ向けたコネクタを検証します。配送経路とループ、メールボックス、エイリアス、グループなど全有効宛先の一覧を確認してください。グループのメンバー条件だけでは一覧を代用できません。以下は実際の構成に合わせて調整する概念例です。
| 条件 | 値 | 目的 |
|---|---|---|
| 送信者の場所 | 組織外 | 例を外部からのメールに限定する |
| 宛先が次のメンバーではない | All Valid Users | 設定済みのメールボックス、エイリアス、グループ、経路を維持する |
| リダイレクト先 | catchall_sink@domain.com | 選択したメールを専用の場所へ送る |
| SCLを設定 | 9 | 高確度のスパムとしての処理を要求する。実際の分類、動作、通知は他の検査、ポリシー、クライアントにも依存する |
| ヘッダーを設定 | X-Auto-Response-Suppress: All | 対応する自動返信を抑制し、別途ループ対策も行う |
ドメインの種類を変える前に、規則と経路を計画し検証します。順序と方法は既存構成によります。Internal Relayへの移行で、必要な保護がない時間帯を作らないようにしてください。
戦略2：Postfix PCREでパターンを限定する
限定したパターンなら、辞書攻撃のすべての候補を受け付けずに特定のアドレス群を処理できます。想定するパターンを定義し、それ以外の宛先がSMTPの宛先検証で拒否されるか確認します。マップにワイルドカードがないだけでは拒否は保証されません。受け付け範囲を減らせても、大多数の攻撃を阻止する保証ではありません。
Postfixのvirtual alias mapでPCRE（Perl Compatible Regular Expression）を使う例です。対応するマップ機能がインストールされているか確認し、回収したい入力ミスも含めてパターンをテストしてください。
# /etc/postfix/virtual_pcre
# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/ sales-team@yourdomain.com
# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/ support@yourdomain.com
# No wildcard below = hard 550 reject for everything else/etc/postfix/main.cfとの連携を確認します。以下の行は既存の値を置き換えるため、設定をバックアップし、既存マップと適切に統合してください。確認せず上書きしてはいけません。
virtual_alias_maps = pcre:/etc/postfix/virtual_pcreテストと承認後に再読み込みを計画します：postfix reload
範囲を広げるなら、グローバルなキャッチオールより既知のアドレスを保守的に指定する方法を検討します。
/^(info|contact|hello|team)@yourdomain\.com$/ info@yourdomain.com想定するアドレスを処理しつつ、すべての組み合わせを有効とは示さない構成にできます。ただし結果は、宛先クラス、他のマップ、検証規則にも依存します。
キャッチオールが適している場面
キャッチオールは範囲を定めた用途に適する場合があります。理由と管理が明確なら継続利用も選択肢です。三つの例と、別途検討したい理由を示します。
妥当な用途：
- 短期間のキャンペーン：
promo-jan@、promo-feb@、promo-mar@を一つずつ作らずに処理する - 顧客の初期設定：アドレスの正式な設定が終わるまでメールを回収する
- 旧システムからの移行：切り替え中、まだ把握できていない有効なアドレスのメールを拾う
この三例では利用期間を限定して計画します。必要なアドレスが分かったらメールボックスやエイリアスを作り、キャッチオールを終了できるか検討します。構成の判断にはドメインのエイリアスとメールボックスの比較を参照してください。
再検討したい理由：三つのエイリアスのために一人あたり月額$6を払いたくないという場合です。エイリアスが必ず有料ライセンスを必要とするわけではありません。提供側の条件を確認し、費用の問題を直接解決してください。例えば六か月続く運用負担を増やしてまで費用を隠すのは、適切な解決とは限りません。
TrekMailでアドレス管理を設計する
利用者単位の料金が、明示的なアドレスの代わりにキャッチオールを選ぶ理由になる場合があります。TrekMailはアカウント単位の共有容量とドメイン・メールボックスの上限を持つプランを提供し、個別のメールボックスにも容量制限が適用される場合があります。一律のドメイン単位料金や無制限のアドレスを意味しません。実際の条件でメールボックスとエイリアスの費用を比較してください。
| 利用者単位料金の例 | TrekMailのプランに応じた構成 | |
|---|---|---|
| sales@、support@、info@のメールボックス | 各ボックスに別ライセンスが必要なら月額の3× | 選択したプランの上限内で利用 |
| エイリアスの代わりのキャッチオール | 節約額はエイリアスの実際の料金次第 | 費用とは別に検討する配送上の選択 |
| GmailやOutlookへ転送 | SPF/DMARC問題を追加する場合がある | 対応するプランと経路でSRSを管理。配送の保証ではない |
| 旧ホストから移行 | 手動のIMAP同期が必要な場合がある | 権限と対応状況を確認してIMAP移行を行い、バックアップ、フォルダー、メール、DNS切り替え前の最終差分を検証する。連絡先や予定表は別途移行する |
元記事で紹介したStarterプランは月額$3.50でした。現在の料金、上限、利用条件を確認してください。ここで説明するNanoの構成では、返信を含むすべての送信に自分で用意したSMTPが必要です。有料プランの管理型SMTPは実際の利用権限と設定を確認します。対応するキャッチオールを有効にしても、日常のメールボックスやエイリアスの代わりにはなりません。ドメインのメール設定ガイドはDNS、SPF/DKIM/DMARC、メールボックスを説明しています。
キャッチオール有効化前のチェックリスト
有効化前に以下を確認します。制御の不足は配信問題や追加作業につながる可能性があります。
- SMTPの宛先検証：許可パターン外の宛先をセッション中に拒否する。受け付けたメールから偽造送信者へ不要な通知を送らない。
- 自動返信の制御：対応環境で
X-Auto-Response-Suppress: Allを検討し、実際の動作を確認する。ヘッダーに依存しないループ対策も用意する。 - 隔離先の準備：未知の宛先用の専用メールボックスを業務用受信箱と分け、容量とアクセスを整える。
- 分類と確認方法：慎重な規則で処理し、正当なメールを回収するため意図的に確認する。
- SPF/DMARCの検証：転送するならSRSと、書き換え後のドメインが接続元IPをSPFで許可しているか確認する。DMARCには有効で整合したSPFまたはDKIMが必要で、SRSだけでは元のFromとの整合性を回復しない。
- 全体指定より限定パターン：対応する環境では特定の一致規則を検討し、宛先検証をテストする。
- バックスキャッターの回避：偽造送信者へ不要な通知を出さない。正当な可能性のあるメールは規則に従って保存・確認し、標準で無通知削除しない。
まとめ
キャッチオールは、管理された配送先、SMTP検証、ループ防止、適切なエラー処理があれば役立つ場合があります。無対策で有効にするとリスクが増えますが、一定期間内に必ず問題が起こるわけではありません。容量、確認方法、運用責任を先に決めましょう。
利用者単位料金を避けるためなら、まず実際の料金と条件を比較してください。TrekMailのプランでは上限内のメールボックスとエイリアスを使い、キャッチオールを意図的に選べる場合があります。無料試用を検討し、現在の条件と適切な制御を確認してください。
