Notes / 仕事の設計

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

SESや人材紹介の業務で、案件情報や人材登録メールがGoogle Workspaceの強力なSPAMフィルタに弾かれる現象に遭遇しました。Workspaceの個別アカウントやグループメールで受けると、Googleの感度高い判定が業務メールを誤検知して隔離します。Workspaceを主受信に残しつつ、業務カテゴリ別の窓口アドレスはレンタルサーバーのcatch-all SMTPで受けて、Fastmail等のサードパーティクライアントで受信統合する3層構成の手順。

Google Workspace email DNS Fastmail SES

SESや人材紹介の業務でメール運用に困っている企業からよく聞く話です。案件情報や人材登録メールがGoogle Workspaceで届かない。SPAMフォルダに入っているわけでもなく、隔離フォルダにすら入らずに送信元へバウンスされているケースもあります。

Workspaceは強力なSPAMフィルタを持っていて、Googleが日々学習を更新しています。一般的な迷惑メールには有効ですが、業務上必要な大量のシステムメール、人材媒体からの自動配信、SES営業の案件メール等は、フィルタが「広告メール」「自動送信メール」と判定して隔離する確率が高いです。Workspaceのグループメール(group@<own-domain>)に転送する構成だと、感度がさらに上がる印象があります。

Workspace内のホワイトリスト追加で改善する案件もありますが、人材媒体や派遣会社が数十社になると個別ホワイトリスト運用が破綻します。本筋の解決策として、業務カテゴリ別の窓口アドレスはWorkspace以外の経路で受けるという3層構成を実装しました。

出発点と到達点

Before

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

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

After

[受信]
外部 → MX (Workspace) ← MXは変えない

       ├─ 個別アカウント3個 (役員/コア従業員のみ)
       │   → Workspaceで通常受信

       └─ 業務カテゴリ別6アドレス (sales/contact/partner/recruit/...)
            → Workspace未登録 → Default Routingで
              レンタルサーバーSMTPに転送
            → レンタルサーバーで catch-all 受信
            → Fastmail等のクライアントがPOP3でフェッチ
            → SPAMフィルタを通さず原文を確認できる

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

なぜこの構成が効くか

業務メールがGoogleのSPAMフィルタで隔離される問題に対して、3つの観点で効く構成です。

1. SPAMフィルタを通さない経路を作る

Workspace未登録のアドレス宛メールは、WorkspaceのDefault Routingで外部SMTPに転送される時点で、Googleの本格的なSPAMフィルタを通りません。レンタルサーバー側のSPAMフィルタは通りますが、一般的なレンタルサーバー(Xサーバー等)のSPAMフィルタはGoogleほど強くなく、業務メールの誤判定が少ない。

2. 業務カテゴリ別の受け箱で文脈分離

sales@recruit@partner@ 等の業務カテゴリ別アドレスで受けると、後で「これは案件メール」「これは採用応募」と分類しやすい。Fastmailの内部フィルタで個別のラベル整理もできる。

3. Workspaceのアカウント数を最小化

役員と確実に個別アカウントが必要な従業員のみWorkspace、業務窓口は全部catch-allにすると、Workspaceの月額ライセンス費が下がります。アカウント数を5から3に減らすだけで月額¥3,000程度の削減になる。

受信経路の詳細

外部から 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更新)。

TypeNameContent備考
CNAMEfm1._domainkeyfm1.<own-domain>.dkim.fmhosted.comDNSのみ (プロキシ無効)
CNAMEfm2._domainkeyfm2.<own-domain>.dkim.fmhosted.comDNSのみ
CNAMEfm3._domainkeyfm3.<own-domain>.dkim.fmhosted.comDNSのみ
TXT (SPF)@v=spf1 include:_spf.google.com include:spf.messagingengine.com ~allWorkspace + 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受信を維持。

実装の順序 (15ステップ前後)

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

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

クライアント案件への横展開価値

この構成が刺さる業種を整理します。

業種課題本構成の効果
SES / 人材紹介案件メール / 人材媒体配信がWorkspace SPAMフィルタで隔離catch-allで受けてFastmailで確認、SPAM判定なし
不動産仲介物件情報の自動配信メールがフィルタリング同上
採用業務求人媒体からの応募者メールが届かない同上
EC / 卸売仕入先 / メーカーからの納期連絡が誤判定同上
一般のコーポレートサイト問い合わせ窓口アドレスが多数必要だがWorkspaceアカウントを増やしたくないアカウント費削減

提案フレーズの例: 「Workspaceアカウントは役員と従業員のみ最小限。問い合わせ系の窓口アドレスはレンタルサーバーのcatch-allで受けて、Fastmailに統合する3層運用」。

月額コスト

参考までに、規模感を整理します。

項目BeforeAfter
Workspace 5アカウント¥4,250 (Business Starter $7×5×為替)
Workspace 3アカウント¥2,550
Fastmail Individual¥600〜800 ($5/月程度)
レンタルサーバー (catch-all継続)¥1,100 (X10プラン等)¥1,100
合計¥5,350¥4,250〜4,450

3層化することでアカウント数削減 + Fastmail課金が発生するけれど、Workspace月額の差分内で収まります。さらに5アドレス以上の業務窓口を扱う規模なら、Workspaceアカウント増設の代替として大きく節約になる。

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

catch-all宛メールがSPAMだった場合

Fastmailで受けたメールがSPAMの場合、Fastmailの判定基準でフィルタされます。Workspaceほど強力ではないので業務メールの誤判定は減りますが、本物のSPAMが受信箱に届く頻度は上がります。Fastmailのフィルタルールで運用調整します。

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の強力なSPAMフィルタを業務メールに適用しないために、受信経路を分離する3層構成は実装の工数が比較的小さく、月額費用も範囲内に収まります。SESや人材紹介、不動産、採用業務のようにシステムメールや配信メールを大量に受ける業種で特に効きます。

メール経路設計のご相談はお問い合わせから、業務領域の詳細はServicesへ。