BECを防ぐメール認証完全実装ガイド——M365/GWSのSPF・DKIM・DMARC設定とp=none→reject段階移行

Posted at 2026-06-27

ビジネスメール詐欺（BEC: Business Email Compromise）は、経営幹部や取引先になりすましたメールで送金や情報漏洩を引き起こす攻撃手法です。FBI IC3レポートによると、BECによる被害額はフィッシングやランサムウェアを上回り続けています。

BECを技術的に防ぐ最も確実な手段が SPF・DKIM・DMARCの三位一体設定です。本記事では Microsoft 365（Exchange Online）と Google Workspace の両環境における具体的な実装手順を、DNSレコード設定値とともに解説します。

なぜ三種類が必要なのか

プロトコル	役割	対策できること
SPF	送信元IPアドレスの正当性検証	IPアドレスベースのなりすまし
DKIM	電子署名によるメール改ざん検知	転送中の内容改ざん
DMARC	SPF/DKIM失敗時のポリシー指定＋レポート	ドメインなりすまし・ポリシー統制

SPFとDKIMが単体では「認証できない」と判断するだけなのに対し、DMARCは「認証失敗メールをどう扱うか（none/quarantine/reject）」を宣言し、レポートを管理者に送る仕組みを加えます。設定順序は必ず SPF → DKIM → DMARC で行ってください。

Part 1：Microsoft 365（Exchange Online）の設定

1-1. SPFレコードの設定

Microsoft 365 のみでメールを送信する場合、SPFレコードは以下の1行で完結します。

; TXT レコード（ドメインのDNSゾーンに追加）
ホスト名 : @（またはドメイン名）
値       : v=spf1 include:spf.protection.outlook.com -all

注意: 他のサービス（HubSpot、SendGrid等）からも送信する場合は、include: を追加して1つのレコードにまとめます。複数のSPFレコードを作成するとどちらも無効になります。

; 複数サービス例（HubSpot + M365 + SendGrid）
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net -all

~all（ソフトフェイル）と -all（ハードフェイル）の違いは後述のDMARCポリシーで制御できるため、本番環境では -all を推奨します。

1-2. DKIMの有効化

Exchange Online のDKIMはCNAMEレコードを使う点がGWSと異なります。TXTレコードではなくCNAMEを使う理由は、Microsoftがキーを自動管理・ローテーションするためです。

Step 1: Defender ポータルで CNAME値を取得

https://security.microsoft.com/authentication?viewid=DKIM にアクセス
設定したいカスタムドメインを選択
ドメイン詳細ポップアップの「CNAMEの発行」セクションからコピー

または Exchange Online PowerShell で確認：

# Exchange Online PowerShell
Get-DkimSigningConfig -Identity contoso.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Step 2: DNS に CNAME レコードを2件追加

; CNAMEレコード（2件とも必須）
ホスト名 : selector1._domainkey
値       : selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft

ホスト名 : selector2._domainkey
値       : selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft
TTL      : 3600（1時間）

重要: contoso-com の部分はドメインのピリオドをダッシュに置換したもの、contoso は *.onmicrosoft.com のプレフィックスです。必ず PowerShell または Defender ポータルから実際の値を取得してください（上記は例示値）。

Cloudflare利用者へ: DKIM の CNAME レコードは必ず「DNS のみ（グレーのクラウド）」に設定してください。プロキシ（オレンジのクラウド）を有効にすると DKIM 検証が必ず失敗します。

Step 3: DKIM 署名を有効化

# CNAMEがDNSに伝播後（数分〜48時間）に実行
Set-DkimSigningConfig -Identity contoso.com -Enabled $true

# 確認
Get-DkimSigningConfig -Identity contoso.com | Format-List Name,Enabled,Status
# Status: Valid になれば成功

selector2 も必ず作成する理由

Microsoft 365 はキーローテーション時に selector1 と selector2 を交互に使います。selector2 が存在しないと将来のキーローテーションが失敗し、DKIM署名が停止します。

1-3. DMARC の設定

; TXT レコード
ホスト名 : _dmarc
値       : v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com; ruf=mailto:dmarc-forensic@contoso.com; fo=1

タグ	説明	値例
`p`	ポリシー（none/quarantine/reject）	`none`（初期）
`rua`	集計レポートの送信先	`mailto:dmarc@example.com`
`ruf`	フォレンジックレポートの送信先	`mailto:dmarc-forensic@example.com`
`pct`	ポリシー適用率（%）	`100`（デフォルト）
`adkim`	DKIMアライメント（r=relaxed/s=strict）	`r`
`aspf`	SPFアライメント（r=relaxed/s=strict）	`r`
`fo`	フォレンジックレポートの生成条件	`1`（いずれかが失敗時）

Part 2：Google Workspace の設定

2-1. SPFレコードの設定

; TXT レコード
ホスト名 : @（またはドメイン名）
値       : v=spf1 include:_spf.google.com ~all

HubSpotなど外部サービスも送信に使う場合：

v=spf1 include:_spf.google.com include:41hpk5.share-na2.hsforms.com ~all

2-2. DKIMの設定

GWS の DKIM は TXT レコードで設定します。

Step 1: 管理コンソールで DKIMキーを生成

管理コンソール → アプリ → Google Workspace → Gmail → メール認証
ドメインを選択 → 「新しいレコードを生成」をクリック
キーのビット長：2048ビットを推奨（互換性問題がなければ）
「生成」をクリック

Step 2: DNSにTXTレコードを追加

管理コンソールに表示された値をそのままDNSに追加：

; TXT レコード（管理コンソールから生成した値を使用）
ホスト名 : google._domainkey
値       : v=DKIM1; k=rsa; p=<管理コンソールで生成された公開キー文字列>
TTL      : 3600

Step 3: DKIM署名を有効化

DNSへの反映後（最大72時間）、管理コンソールに戻り「認証を開始」をクリック。

# DNS伝播確認（Linux/macOS）
dig TXT google._domainkey.yourdomain.com +short

# Windows
nslookup -type=TXT google._domainkey.yourdomain.com

2-3. DMARC の設定（GWS）

GWSもM365と同じDMARCレコード形式です：

; TXT レコード
ホスト名 : _dmarc
値       : v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100; adkim=r; aspf=r

Part 3：p=none → quarantine → reject 段階移行

DMARCはいきなり p=reject に設定しないことが重要です。正規メール（ERP、CRMなどの社内システム）が意図せず遮断されるリスクがあります。

推奨移行スケジュール

Week 1-4：p=none（モニタリング）
  ↓ RUAレポートで送信元を全洗い出し
Week 5-6：p=quarantine; pct=10（10%に適用）
  ↓ 迷惑メールフォルダを確認し、誤検知がないことを確認
Week 7-8：p=quarantine; pct=100（全件に適用）
  ↓ 問題なければrejectへ
Week 9以降：p=reject; pct=100（完全拒否）

レポート分析ツール

RUAレポートはXMLで届くため、可視化ツールの利用を推奨します：

dmarcian（有料、GUIが分かりやすい）
DMARC Analyzer（無料プランあり）
Google Postmaster Tools（GWS利用者向け、無料）

移行チェックリスト

□ SPFレコード：送信元IPをすべて include: でカバーしているか
□ DKIMレコード：selector が正しく応答するか（nslookup で確認）
□ DMARC p=none でレポート受信を確認（1週間以上）
□ rua宛先のメールボックスが受信可能か
□ 社内システム・SaaS（CRM/MA/ERP）のSPF/DKIMアライメントを確認
□ p=quarantine への切り替え後、誤検知がないか48時間監視
□ p=reject への切り替えを経営・メール担当者に告知済みか

設定確認コマンド集

# SPF確認
dig TXT yourdomain.com +short | grep spf

# DKIM確認（M365: selector1、GWS: google）
dig TXT selector1._domainkey.yourdomain.com +short
dig TXT google._domainkey.yourdomain.com +short

# DMARC確認
dig TXT _dmarc.yourdomain.com +short

# メールヘッダー確認用ツール（Webブラウザ）
# https://mha.azurewebsites.net（Microsoft Message Header Analyzer）

メールを実際に送信し、受信側のヘッダーで以下を確認します：

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector1;
  spf=pass smtp.mailfrom=yourdomain.com;
  dmarc=pass action=none header.from=yourdomain.com

dkim=pass、spf=pass、dmarc=pass がすべて確認できれば設定完了です。

まとめ

作業	M365	GWS
SPF	`include:spf.protection.outlook.com`	`include:_spf.google.com`
DKIM	CNAMEレコード×2（自動管理）	TXTレコード×1（管理コンソールで生成）
DMARC	`_dmarc` TXTレコード（共通）	`_dmarc` TXTレコード（共通）

BEC対策としてのメール認証は「設定して終わり」ではありません。DMARCレポートを定期的に確認し、新規の送信サービス追加時にSPFを更新する運用フローを組み込むことが重要です。

中小企業のIT環境でSPF/DKIM/DMARC設定から運用まで迷ったら、情シス365 にご相談ください。設計・設定・監視を一貫してサポートしています。

著者

亀田英佑
株式会社BTNコンサルティング代表取締役
情シス365（中小企業向けITアウトソーシング）運営

メール認証設定・BEC対策・M365/Google Workspace 管理について無料でご相談いただけます。

▶ 無料相談はこちら

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up