WorkspaceのSPAMフィルタがSES系の業務メールを弾く。catch-all SMTP + Fastmailで受信統合する3層構成

弊社はSES事業をやっているので、案件情報や人材登録のメールを大量に受けます。これがGoogle Workspaceでよく届かない。SPAMフォルダに入っているならまだしも、隔離フォルダにすら入らず送信元へバウンスされることもあって、これは気づきにくくて困りました。

WorkspaceのSPAMフィルタは強力で、Googleが日々学習を更新しています。一般的な迷惑メールにはよく効きますが、業務上必要な大量のシステムメール、人材媒体からの自動配信、SES営業の案件メール等を、Workspaceは「広告メール」「自動送信メール」と判定して隔離しがちです。グループメール(group@<own-domain>)に転送する構成にすると、弊社の場合はさらに弾かれる頻度が上がりました。

Workspace内のホワイトリスト追加で粘る手もありますが、人材媒体や派遣会社が数十社になると個別ホワイトリスト運用は破綻します。そこで弊社が組んだのが、業務カテゴリ別の窓口アドレスをWorkspace以外の経路で受ける構成です。誤検知(false positive)を避けたい窓口アドレスを、誤検知しやすい判定系から外す。スパム検査をなくすわけではありません。検査の担保は後半で扱います。

出発点と到達点

Before

[受信]
外部 → MX (Workspace)
       ├─ 個別アカウント (役員 + 業務窓口の混在で増えがち)
       └─ グループメール (営業 / 採用 / SES案件 等)

問題:
- SES案件メール、人材登録メール、媒体配信メールが
  Workspace SPAMフィルタで隔離 or バウンス
- 個別ホワイトリスト運用は媒体数の増加で破綻
- Workspaceアカウント数で月額費用が増える

After

[受信]
外部 → MX (Workspace) ← MXは変えない
       │
       ├─ 個別アカウント (役員/コア従業員のみ)
       │   → Workspaceで通常受信
       │
       └─ 業務カテゴリ別アドレス (sales/contact/partner/recruit/...)
            → Workspace未登録 → Default Routingで
              レンタルサーバーSMTPに転送
            → レンタルサーバーで catch-all 受信
            → Fastmail等のクライアントがPOP3でフェッチ
            → 誤検知の起きにくい経路で原文を確認できる
              (検査はレンタルサーバー + Fastmail側で実施)

[送信]
- 役員/コア従業員アカウント: Workspace SMTP
- 業務カテゴリ別アドレス: Fastmail SMTP
  (DKIM/SPF/DMARC全pass)

この構成で効くところ

狙いは2つです。誤検知を起こす判定系から窓口アドレスを外すこと、そしてWorkspaceのアカウント数を減らすこと。

1. 誤検知の起きにくい受信経路を分ける

Workspace未登録のアドレス宛メールは、WorkspaceのDefault Routingで外部SMTPに転送され、Googleの学習型フィルタによる「広告メール」「自動送信メール」判定を受けません。レンタルサーバー側のスパム・ウイルス検査とFastmail側のスパム検査は引き続き通るので、検査なしの素通しにはなりません。Googleのフィルタを弱めるのではなく、業務メールを誤検知しやすい判定系を、誤検知が許されない窓口アドレスに適用しないということです。

sales@、recruit@、partner@ のようにカテゴリ別のアドレスで受けるので、後から「これは案件メール」「これは採用応募」と分類しやすくなる副次効果もあります。Fastmailの内部フィルタでラベル整理もできます。

引き換えに、Googleのフィルタが担っていたフィッシング・マルウェア検出の強度は下がります。受け側での検査担保と運用ルールをセットで設計する必要があり、後述の「注意点と運用上の落とし穴」で扱います。

2. Workspaceのアカウント数を最小化する

役員と、個別アカウントが要る従業員だけWorkspaceに残し、業務窓口は全部catch-allにすると、Workspaceの月額ライセンス費が下がります。窓口用に増やしていたアカウントの単価(Business Starterで月$7前後) × 削減数がそのまま浮く計算です。

受信経路の詳細

外部から sales@<own-domain> 宛にメールが来た時の経路。

外部メールサーバー (例: 案件配信元)
   ↓ MX解決 → SMTP.GOOGLE.COM
Google Workspace (受信)
   ↓ アドレス判定 → 「sales@は未登録」
   ↓ Default Routing 設定で
   ↓ レンタルサーバーSMTPへリレー
レンタルサーバーSMTP (sv<NNNNN>.<provider>.jp)
   ↓ catch-all設定でメールボックス受信
レンタルサーバーのメールボックス
   ↓ Fastmailから POP3 でフェッチ
Fastmailの受信箱

ポイント: MXレコードはWorkspaceのままです。これによりWorkspaceに登録された個別アカウント宛のメールはWorkspaceで通常通り受信されます。Workspaceに未登録のアドレス宛だけがDefault Routingに乗ってレンタルサーバーへ転送される動きです。

送信経路の詳細

Fastmailからsales@<own-domain>名で送信する時の経路。

Fastmail送信画面
   ↓ FromアドレスをFastmailのエイリアスから選択
Fastmail SMTP (flow-a*.smtp.messagingengine.com)
   ↓ DKIM署名 (selector: fm1、ドメイン: <own-domain>)
   ↓ SPFはFastmail IPがレコードに含まれている
受信側 (例: Gmail)
   ↓ SPF: pass (Fastmail IPが<own-domain> SPFに登録)
   ↓ DKIM: pass (fm1.<own-domain>のDKIM公開鍵で検証)
   ↓ DMARC: pass (SPF aligned + DKIM aligned)
受信者の受信箱に正規メールとして到達

外部SMTP経由ではなく、Fastmail SMTPで直接送ることがポイント。DKIM/SPF/DMARCの3点セットが揃うので、受信側のスパム判定リスクが小さい。

落とし穴: Fastmailの「外部アドレス」モード

Fastmailで業務カテゴリ別アドレスを追加する時、デフォルトで 「外部アドレス」モード に判定されることがあります。このモードだと送信時に「外部SMTPサーバー経由送信」設定が有効化され、レンタルサーバーSMTPに接続を試みます。

レンタルサーバーSMTPはFastmailサーバーのIPを信頼するリレークライアントとして登録していないので、554 5.7.1 Access denied で拒否されます。送信失敗。

正解: 「エイリアス」モードで追加する。Fastmailの設定で Settings → Users & Sharing → User Management → Aliases タブから新規エイリアスとして追加します。これでFastmail内部エイリアス扱いになり、送信時はFastmail SMTPで直接送られて全認証pass。

「外部アドレス」と「エイリアス」は同じ画面で追加できるように見えて、挙動が真逆。実装時の最大の落とし穴です。

DNS設定(Cloudflare等のDNS)

3つのCNAME (Fastmail DKIM) + 1つのTXT (SPF更新)。DKIMセレクタ fm1〜fm3 はFastmailが全ユーザー共通で使う標準セレクタで、ドメイン追加時に管理画面で指示されます。

Type	Name	Content	備考
CNAME	`fm1._domainkey`	`fm1.<own-domain>.dkim.fmhosted.com`	DNSのみ(プロキシ無効)
CNAME	`fm2._domainkey`	`fm2.<own-domain>.dkim.fmhosted.com`	DNSのみ
CNAME	`fm3._domainkey`	`fm3.<own-domain>.dkim.fmhosted.com`	DNSのみ
TXT (SPF)	`@`	`v=spf1 include:_spf.google.com include:spf.messagingengine.com ~all`	Workspace + Fastmail両方をinclude

ポイント: SPFは既存のinclude:_spf.google.comを残してFastmail分を追加。新規TXT行を作らず、既存のSPF TXT 1行を編集する。SPFは1ドメインに1行のみで、複数行があると壊れます。

DKIM CNAMEは既存のWorkspace DKIM (default._domainkey / google._domainkey)と別selector名なので衝突しません。共存可能。

MXは触りません。Workspace受信を維持。

実装の順序(10ステップ)

Step	内容	所要
1	Fastmailで `<own-domain>` を独自ドメインとして追加、DKIM/SPF設定値を取得	5分
2	CF DNSにDKIM 3 CNAMEを追加(プロキシ無効)、SPFに `include:spf.messagingengine.com` を追加	5分
3	Fastmail管理画面でDNS確認を実行(DKIM ✓ / SPF ✓ になることを確認)	5分
4	Workspaceから削除予定のアドレスの過去メールをPOP3で取得済アカウントに最終取込(削除直前)	5分
5	レンタルサーバーでcatch-all用のメールアカウントを業務カテゴリの数だけ作成(`sales` / `contact` / `partner` / …)	15分
6	Workspaceで削除対象アカウントを削除(業務時間外推奨)	5分
7	catch-all経路の動作確認(個人アドレスから存在しないアドレスに送信、レンタルサーバーで受信確認)	5分
8	Fastmailで必要なアドレス分のエイリアスを作成(「エイリアス」タブから新規追加)	20分
9	各エイリアスから送信テスト(個人Gmailで受信、Authentication-ResultsでSPF/DKIM/DMARC pass確認)	30分
10	Fastmailの各エイリアスでPOP3フェッチ設定(レンタルサーバーから受信)	15分

合計2 〜 3時間 + バックアップ取得時間。

この構成が向く場面

弊社が組んだのはSES事業のためでした。案件メールや人材媒体の自動配信がWorkspaceのSPAMフィルタで隔離される、という同じ症状を抱えていれば素直に効きます。人材紹介や、求人媒体から応募者メールを大量に受ける採用業務も同じ構図です。

業種を問わず効くのは、もう一つの軸のほう。問い合わせ窓口アドレスが何個も要るのにWorkspaceアカウントを増やしたくない、というケースです。窓口を全部catch-allに寄せればアカウント費が下がります。

月額コストの考え方

実額は組織規模で変わるので、損益分岐の構造だけ整理します。

項目	単価の目安
Google Workspace Business Starter	$7前後/アカウント/月
Fastmail Individual	$5前後/月
レンタルサーバー (catch-all継続)	月¥1,000前後

「削減できるWorkspaceアカウント数 × 単価」が「Fastmail + レンタルサーバー継続費」を上回るかが分岐点です。窓口アドレスを個別のWorkspaceアカウントやグループで賄っていた組織なら、窓口が数個ある時点で削減側に倒れるケースが多い。窓口が増えるほどcatch-all側はコストが変わらないので、差は開きます。

注意点と運用上の落とし穴

スパム・フィッシング検査の担保

Fastmailで受けたメールはFastmailのスパム検査でフィルタされます。Workspaceほど強力ではないので業務メールの誤判定は減りますが、本物のSPAMが受信箱に届く頻度は上がります。検査の最終防衛線が機械からヒトに一部移ることを理解した上で、次の補完をセットにします。

Fastmailのフィルタルールで送信元ドメイン・件名パターンの振り分けを整備する
窓口アドレス宛の添付ファイルとURLは「開く前に送信元を確認する」運用ルールを明文化する
窓口アドレスでは認証情報の入力やファイルの実行を伴う操作をしない(閲覧と転送に限定する)

DMARC強化のタイミング

新しい送信経路(Fastmail)を追加した直後はDMARCを p=none (観測モード)で運用します。1〜2週間運用してdmarcレポートでFastmail経由送信が確実にpassすることを確認してから、p=quarantine に強化します。

Fastmail Trial制限

Fastmail Trialプランでも個別エイリアス追加は可能ですが、「別のアドレスに配信」等の一部機能が制限されます。本番運用するならStandard以上に切替えます。

MX変更との混同を避ける

Fastmailのドメイン認証画面で「MXレコードを向けてください」というガイドが必ず出ます。これに従ってMXをFastmailに向けると、Workspace受信が止まります。今回の構成ではMXは絶対に変更しません。Fastmailは送信と外部からのPOP/IMAP取込専用です。

業務メールの誤検知を避けつつスパム検査は別系統で担保する。この構成は実装の工数が小さく、弊社では月額費用も下がりました。システムメールや配信メールを大量に受ける現場ほど、Workspace単体で粘るより楽になるはずです。

自社のメール経路を組み替えたい時の設計と移行は、お問い合わせで相談を受け付けています。