キャッチオールメールは、ドメイン内の未登録の宛先を扱うサーバー設定です。ghost@yourdomain.com へのメールは通常、宛先エラー 550 で拒否されます。接続を必ず閉じる必要はなく、SMTP の制御通信はすでに行われています。キャッチオールは宛先に 250 OK を返し、メール全体の最終受信後に指定した受け皿へ送る場合があります。
これが便利な点です。ただし 2026 年も、不要な受信量、評判、個人データの扱いを確認する必要があります。有効化するだけで必ず評判が傷つき、GDPR 違反になるわけではありません。
この記事では SMTP の動作、五つの運用リスク、認証、管理しやすい代替策を説明します。
キャッチオールメールとは
キャッチオールメールは accept-all やワイルドカードルーティングとも呼ばれ、未登録の宛先へのメールを指定したメールボックスに送ります。550 で拒否する代わりに宛先を受諾できますが、メール全体の最終受信には完全な転送後の確認が必要です。他の検査やポリシーは引き続き適用され得ます。
管理画面では accept-all と catch-all が同様の機能を表すことがあります。RCPT TO の宛先確認で未登録の宛先に受け皿を指定します。TrekMail ではドメインごとの Domains → Routing → Catch-all Inbox を確認してください。旧画面では Connection と呼ばれる場合があります。権限のある有効な宛先を選び、実際の動作を検証します。
1990 年代末の手作業によるメールと自動スパムの比率は現在とは異なります。2026 年もアドレス収集やボットネットを考慮しなければなりません。キャッチオールは試行を後続処理へ通す可能性がありますが、すべての防御を解除する設定ではありません。
キャッチオールを有効にする理由
二つの理由は、問い合わせを失う不安と追加ライセンスの費用です。どちらも対策が必要です。キャッチオールは入力ミスを拾える反面、受信範囲と処理負担を広げます。スパムの洪水や評判悪化が必ず生じるわけではありません。
問い合わせを逃したくない
顧客が suport@ と書き、support@ に届かないことがあります。キャッチオールは拾える場合がありますが、数千の不要なメールで検索が難しくなる可能性もあります。正当なメールとの比率は実際の通信によります。
よくある入力ミスは明示的なエイリアスで対応できます。support@ に加えて suport@ を同じメールボックスへ送る設定にします。未登録の宛先の受信を限定できますが、スパムがなくなるわけではありません。
追加利用者の費用
Google Workspace と Microsoft 365 の過去の例では、利用者ごとに月額 $6-30 です。support@、billing@、jobs@、marketing@ に実際に四つの別ライセンスが必要なら、例では最大月額 $120 になります。現在の料金、エイリアス、共有メールボックス、既存ライセンスでは別の選択肢もあります。一つのメールボックスとキャッチオールだけが節約策ではありません。
料金とともに検査、配送、データ管理を比較しましょう。別のプラン構成が必要な宛先権限を提供する場合もあります。TrekMail の現在のプランを実際の要件で評価してください。
SMTP レベルの動作
RCPT TO で送信サーバーが宛先を指定します。まだメール本体は転送されていません。適切な宛先検査は不要な処理を防ぎますが、安全性を決める唯一の条件ではありません。
宛先を検査する流れ
S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 550 5.1.1 User unknown
(connection closed - zero bytes of message body transferred)
ghost が見つからず、550 を返します。例にある接続終了は必須ではありません。この宛先のために本文を受信・検査する必要はありませんが、SMTP の通信と処理は発生しています。
キャッチオールの流れ
S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 250 OK
(full message body, headers, attachments transferred)
→ routed to catchall-bucket@yourdomain.com
まず未登録の宛先を受諾し、他の検査を行う場合があります。メール全体の最終受信後に、不要な内容も含めて指定した受け皿へ送ります。
大量の通信では保存、検査、索引の負荷が変わります。早い宛先拒否は無効な宛先への本文転送を防ぎ、キャッチオールはより多くの内容を処理し得ます。ただし最終受信前の SMTP フィルターも使えます。実際の負荷は実装によります。
本番環境の 5 つのリスク
キャッチオールは受諾する宛先を広げます。DNS 変更後の固定時間に必ず攻撃されると考えず、通信量、経路、エラー処理を監視しましょう。以下の問題が起こり得ます。
リスク 1：アドレス探索による不要な受信
ディレクトリ収集攻撃（DHA）は admin、david、invoice、hr、webmaster、noreply を大量に試し、実在する宛先や配送できる先を探します。
キャッチオールなしでは無効な宛先に 550 を返せますが、攻撃者が停止するとは限りません。キャッチオールは応答からの宛先判別を難しくする一方、余分な受信を許し得ます。通常一日 50 通のドメインが負荷例で 50,000 通受け取り、容量や検索に影響することも考えられます。
リスク 2：バックスキャッターと送信評判
次のような不適切な処理でバックスキャッターが生じ得ます。
- 攻撃者がキャッチオールのある
random-gibberish@yourdomain.comに送ります。 - SMTP エンベロープ送信者を偽造します。後の
Return-Pathが示し得る被害者の宛先はvictim@gmail.comです。 - サーバーがメールを最終的に受信します。
- 後の迷惑メール検査で内部配送を止めます。
- サーバーが
Return-Pathに反映されたエンベロープ送信者へ Non-Delivery Report（NDR）を送ります。宛先はvictim@gmail.comです。 - 無関係な人が不要な通知を受け取ります。
大量の通知は評判や ips.backscatterer.org への掲載に影響し得ます。ただし掲載や正当なメールの迷惑メール化は自動的な結果ではありません。受信側の不適切な処理が送信にも影響する例です。メールドメインの評判ガイドで評価と回復を説明しています。
リスク 3：担当者が不明になる
partnerships@company.com に届いたメールが受け皿に入っても、担当者が決まっていなければ、経営者、営業、総務が互いの返事を待つ可能性があります。重要な問い合わせが放置されかねません。
明示的なエイリアスなら、作成時に担当と配送先を決められます。partnerships@ の経路を記録し、代理担当と定期確認も用意します。
リスク 4：MSP のサポート負荷
50+ の顧客ドメインを管理する代理店では、次の相談が考えられます。
- 「メールボックスがいっぱいで遅い」。受け皿の容量を確認します。
- 「迷惑メールが多すぎる」。追加の受信経路と検査負荷を調べます。
- 「顧客のメールが見つからない」。例では受信トレイの 400 ページ目にあります。
- 「送信が迷惑メールに入る」。バックスキャッターなどの原因を調べます。
明確な宛先は仕分けを助け得ます。初月のメールボックス相談を 30-40% 減らすという値は計画上の仮定で、測定結果や性能保証ではありません。変更前後の自社の実績を比較してください。
リスク 5：データ保護と法令対応
GDPR 第 5(1)(c) 条はデータ最小化を求めます。キャッチオールだけで自動的に違反にはなりませんが、余分な個人情報を集める可能性があります。実際の目的、必要な情報、アクセス、保存期間を確認します。
たとえば 500,000 通の迷惑メールがあると、削除請求への対応は複雑になります。患者が doctor@yourclinic.com に送る場合には HIPAA の評価も必要になり得ます。IT 担当者のアクセス自体が常に違法というわけではなく、承認された役割、データフロー、契約、保護策を具体的に検討します。
キャッチオールと SPF・DKIM・DMARC
キャッチオールが直接これらを変更するわけではありません。実際の転送経路、署名された部分、安全な失敗処理が重要です。余分な通信は診断を難しくし得ますが、必ず認証が継続的に悪化するわけではありません。
| プロトコル | 確認対象 | 注意点 |
|---|---|---|
| SPF | 実際の MAIL FROM の識別子が接続 IP を許可するか | キャッチオール自体は変更せず、元のエンベロープでの転送は失敗し得る |
| DKIM | 選択したヘッダーと対象本文の署名 | 署名対象の変更は影響し得るが、すべての変更が署名を壊すわけではない |
| DMARC | SPF または DKIM の成功と表示上の From とのアラインメント | 有効でアラインメントを満たす DKIM が転送後も使える場合あり |
中継 IP は受信側の評判評価に関係しますが、DMARC レポートは表示上の From に基づき、常に自分のドメインに帰属するわけではありません。Google Postmaster Toolsは、権限と通信量の条件を満たす場合に個人向け Gmail の集計情報を示します。全メールの完全な監視ではありません。迷惑メール報告は利用者の報告で、認証失敗そのものではありません。
転送の問題
すべてのキャッチオールを個人用 Gmail に送るなら、認証、データ管理、失敗経路を確認しましょう。慣れた受信トレイでも拒否、遅延、振り分けは起こり得ます。ただし定期的な損失が必ず発生するわけではありません。
転送メールが認証に失敗する理由
受信側は自分の IP を見ますが、表示上の From: はたとえば bank@chase.com です。SPF はこのヘッダーではなく実際のエンベロープを調べます。各仕組みを分けて確認してください。
- SPF：MAIL FROM が元のままなら元のドメインを検査します。中継 IP が許可されなければ失敗し得ます。
- DKIM：対象の件名や本文を変更すれば署名が無効になり得ます。すべての変更が署名対象に影響するわけではありません。
- DMARC：成功してアラインメントを満たす SPF または DKIM が少なくとも一つ必要です。どちらもなければ、ポリシーと受信側が処理を決めます。
受信側の破棄が利用者に通知されない場合もありますが、SMTP エラーや隔離も考えられます。p=reject は常に無通知で削除するという意味ではありません。転送の設定・診断ガイドで具体的な確認方法を説明しています。
必要な転送と SRS・ARC
移行や既存の業務では外部転送が必要な場合があります。SRS のエンベロープ書き換えと ARC の認証情報を検討しましょう。適切な場面で役立ちますが、すべての有効な転送に両方が必須とは限りません。
SRS（Sender Rewriting Scheme）
SRS はエンベロープ送信者を書き換えます。受信側は新しい識別子、場合によっては自分のドメインを確認します。その SPF が実際の中継 IP を許可する必要があります。
SRS の前
Envelope From:alice@example.comSRS の後
Envelope From:SRS0=HASH=TT=example.com=alice@your-forwarder.com
your-forwarder.comの SPF を検査し、IP が正しく許可されていれば通過し得ます。
SRS はDMARC アラインメントを保証しません。表示上の From: は alice@example.com、エンベロープは your-forwarder.com です。この例のドメインはアラインメントを満たしませんが、有効で整合する DKIM が DMARC を満たせる場合があります。署名対象の変更は検証を妨げ得ます。詳しくはSRS 転送ガイドをご覧ください。
ARC（Authenticated Received Chain）
ARC は転送経路の以前の認証について署名付きの情報を追加します。中継者は受信時の結果を記録し、対応するヘッダーの組に署名します。
Gmail や Microsoft は実際のチェーンを検証し、確認済みの署名者を信頼する場合に結果を考慮できます。RFC 8617 が ARC を説明しています。DMARC 成功や配送の保証ではありません。
良い評判だけで有効な ARC チェーンは証明できません。署名、中継者、受信側の判断を確認します。不要な受信の安全な扱いやバックスキャッター防止も重要ですが、特定の一日あたりのスパム量だけで ARC がすべて無効になるわけではありません。
キャッチオールの適切な設定
既存システム、移行、入力ミス回復には保護策が必要です。業務用受信トレイへの直接配送にも担当を決めます。三つの戦略を比較しましょう。
戦略 A：独立した確認用メールボックス
想定外の受信を、権限と業務手順の両面で通常の処理から分けます。
catchall-quarantine@yourdomain.comを作り、アクセスを制限します。Send As、転送、自動返信は許可しません。- 未登録の宛先だけを送り、検査と保存期間を確認します。
- Microsoft 365 で SCL 9 を指定するルールは高確度のスパム分類を意図します。実際の分類とポリシーが迷惑メールや隔離を決め、通知が必ず停止するわけではありません。正当な可能性のあるメールすべてに無検討で適用しないでください。
- たとえば毎週確認し、宛先間違いの相談には検索します。頻度は業務上の必要性に合わせます。
TrekMail は受け皿の検索・フィルター表示を案内しています。表示を分けるだけで安全な隔離やサンドボックスにはなりません。アクセス、実際の検査、共有容量を確認しましょう。
戦略 B：Microsoft 365 の DBEB と Internal Relay
完全な宛先ディレクトリを持つ Authoritative ドメインでは、DBEB（Directory-Based Edge Blocking）が無効な宛先を早期拒否できます。現在のモードと一覧の完全性を確認します。
Internal Relay Mode は DBEB を無効にしますが、それだけでキャッチオールを実装しません。宛先一覧、コネクター、経路構成を把握し、承認された変更としてループと負荷を確認します。入ってくるメールがすべて自動的に受信確定されると考えないでください。
戦略 C：Postfix の限定的なパターン
特定の接頭辞には適切な正規表現マップを使えます。以下を通常の hash マップで動作する glob としてそのまま使うことはできません。
# /etc/postfix/virtual
sales-*@yourdomain.com sales-bucket@yourdomain.com
Hash マップでは文字どおりのキーになります。sales-q1@、sales-webinar@、sales-2026@ を扱うなら、対応する regexp または PCRE マップに適切な境界を設け、ドメインと経路を確認します。admin@、hr@ を誤って許可せず、ループと宛先制限も調べましょう。
| 戦略 | 不要な受信 | 管理 | 適した目的 |
|---|---|---|---|
| 完全なキャッチオール → 業務受信トレイ | 追加の通信量が発生し得る | 定期的な仕分けが必要 | 意図的な要件と保護策がある場合 |
| 確認用メールボックス | 管理された受信、検査は必要 | 計画的な確認 | 入力ミスと移行 |
| Internal Relay + SCL=9（M365） | 実際のポリシーで評価 | コネクターと分類を確認 | 適切に計画した旧 Exchange 環境 |
| Postfix の限定パターン | 一致する宛先だけ。完全な防御ではない | パターンと経路を保守 | キャンペーンと一時アドレス |
| キャッチオールなし、明示的エイリアス | 登録済みの宛先に限定 | 一覧の保守 | 既知の業務宛先 |
エイリアスと明示的な経路
既知の宛先には明示的なエイリアスで配送先と担当を決められます。未登録の名前への受信は減らせますが、すべてのスパム、認証、データ保護のリスクを消すものではありません。
エイリアス、メールボックス、キャッチオールの選択
| 明示的エイリアス | 専用メールボックス | キャッチオールの受け皿 | |
|---|---|---|---|
| 専用の保存 | 通常なし。宛先や中継で保存する場合あり | あり | あり |
| スパム受信 | 登録した宛先 | 設定済み宛先 | 未登録も対象。他の検査は適用可能 |
| 認証 | 実際の転送を確認 | 適切な設定は引き続き必要 | 転送を重点確認 |
| 利用者費用 | 権限と料金を確認 | 過去のライセンス例で月額 $6-30 | 保存と運用費も考慮 |
| データ保護 | 目的とアクセスを確認 | 保存とアクセスを管理 | 想定外の追加情報を考慮 |
| 担当 | 経路で定義可能 | 明示的に割り当て | 別途決めて確認 |
無料に見える受け皿でも検査ライセンス、容量、サポート時間が必要になる場合があります。評判への問題は可能性であって必須の結果ではありません。メールエイリアスのガイドで専用メールボックスと比較できます。
作成する宛先の例
実際に必要な一覧を作りましょう。以下の五つの役割は例であり、すべての会社の完全な一覧ではありません。
hello@またはinfo@：経営者や運用担当への一般的な問い合わせ。support@：ヘルプデスクや共有サポート受信箱。billing@：財務担当への請求と支払い。jobs@またはcareers@：人事担当や承認された ATS 接続。noreply@：許可された通知送信。正当な返信を無差別に消さず、明確な処理手順を設けます。
適切な五つのエイリアスで必要を満たせる場合があります。helo@ と書いて hello@ に届かなければ 550 が返ることもありますが、送信者が再送するとは限りません。よくある入力ミスを登録する方法もあり、問い合わせを三週間放置することは避けましょう。
TrekMail のキャッチオール方式
現在の各プランのキャッチオール権限を確認します。別の料金構成は明示的な宛先を作りやすくする場合がありますが、すべての受け皿の必要性を自動的に消すわけではありません。
過去の利用者ライセンス例
独立したアカウントごとに月額 $6-30 なら、support@、billing@、jobs@ の三つの追加ライセンスで最大 $90 の例になります。現在のエイリアス、共有メールボックス、既存ライセンスも比較してください。キャッチオールが必須の対策とは限りません。
TrekMail のプラン方式
TrekMail はプラン権限内の共有容量とアドレスを案内しており、無制限の資源ではありません。過去の Starter は月額 $3.50 と 50 ドメイン、Pro は月額 $10 と 100 ドメインです。計画前に現在の価格、上限、追加アドレスの費用を確認します。
必要な受け皿はドメインごとに指定できます。独立したメールボックスは業務を分けられますが、保存や安全性の完全な隔離を保証しません。Catch-all Inbox の文書で現在の権限と保護策を確認してください。
さらに二つの機能を確認できます。メールボックスから複数の宛先への転送と任意のローカルコピー、そしてドメイン内のメールボックスではなく外部の受け皿を使う方式です。Pro と Agency の外部宛先は現在の権限と実際の経路を確認します。メールボックスを作らずにドメインをルーティングするガイドで取得済み・未運用ドメインの用途とリスクを説明しています。
明示的な宛先へ切り替えるなら、14 日間の試用の現在の条件、カード登録、プラン権限を確認しましょう。説明された Nano BYO SMTP モデルではすべての送信と返信に自分の外部 SMTP が必要です。
よくある質問
初めての評価や、既存の受け皿を適切に停止する際に役立つ質問です。
キャッチオールメールとは何ですか？
ドメインの未登録の宛先を扱うサーバー設定です。550 で拒否せず、他の検査後に受け皿へ送れる場合があります。Accept-all やワイルドカードルーティングは関連する名前で、全内容の受信保証ではありません。
安全に使えますか？
目的と保護策によります。通信量、バックスキャッター、転送認証、データを確認します。アクセスを制限した確認用メールボックス、検査、保存期間、適切な確認は管理に役立ちますが、最大スパム評価やまれな確認だけで安全にはなりません。
送信の配送に影響しますか？
不適切な NDR、中継の評判、実際の転送失敗を通じて影響し得ます。設定自体で必ず評判が落ちるわけではありません。DMARC レポートは表示上の From に基づくため、常に自分のドメインの結果とは限りません。具体的な失敗と受信側の判断を調べます。
エイリアスとの違いは何ですか？
エイリアスは住所と配送先を明示します。キャッチオールは任意の未登録の宛先に受け皿を指定します。五つのエイリアスで一部の要件を満たせますが、すべての合理的なキャッチオール用途を置き換えるわけではありません。
Google Workspace や Microsoft 365 でも使えますか？
Google Workspace の適切な Routing で未登録の宛先を扱える場合があります。既存の旧ルールは Default routing にある場合もあります。現在の機能と条件を確認します。Microsoft 365 の Internal Relay は DBEB を無効にするだけで、単独のキャッチオール実装ではありません。完全な宛先一覧、コネクター、ループ検査が必要で、遅延や負荷は設定によります。
無効にするにはどうしますか？
cPanel/WHM の Email → Default Address では SMTP エラーによる拒否を選び、詳細設定の無通知削除を同じ機能と考えないでください。Google Workspace の Apps → Google Workspace → Gmail → Routing で対象のルールを無効にし、旧ルールは Default routing も確認します。Microsoft 365 の Authoritative への変更は有効な宛先一覧とコネクターの確認後に行います。TrekMail の Domains → [domain] → Routing → Catch-all Inbox で "No catch-all" を選び、動作を検証します。24-48 時間は観察の計画例で、安定化の固定期限ではありません。
代わりに何を使えばよいですか？
既知の宛先には明示的なエイリアスと経路を使います。五つ以下で足りる会社もありますが、実際の業務が必要な一覧を決めます。高い費用が理由ならライセンス、共有メールボックス、プランを比較してください。絶対的な節約や、認証・評判問題の完全な解消は保証されません。
