せっかく取得したカスタムドメインでメールを送っても、相手の迷惑メールフォルダに直行していたり、最悪の場合は配信そのものが拒否されてしまう——
その根本原因のほとんどは、SPF・DKIM・DMARC という3つの「送信ドメイン認証」が未設定、あるいは不完全であることです。
この記事では、Microsoft 365（Exchange Online）環境を例に、これら3つを正しくセットアップし、Microsoft 365 管理センター上でステータスが「正常」と表示されるゴールまでを、丁寧に解説します。
なぜ今、送信ドメイン認証が「必須」なのか
Google・Yahoo!・Microsoft が必須化？
2024年以降、世界の主要メールプロバイダーは、特に大量送信者に対して送信ドメイン認証（SPF・DKIM・DMARC）を事実上必須となる配信要件として強化しました。
| プロバイダー | 施行時期 | 対象 |
|---|---|---|
| Gmail（Google） | 2024年2月〜 | 1日5,000通以上の一括送信者。22025年以降はポリシーがさらに強化され、要件を満たさないメールは迷惑メール扱いや一部配信拒否（5xxエラー）となる可能性が高まっています |
| Yahoo! Mail | 2024年2月〜 | 大量送信者（具体的な通数しきい値は未公表） |
| Outlook.com / Hotmail / Live | 2025年5月〜 | 2025年5月より段階的に導入開始。2025年7月以降は、1日5,000通以上の一括送信者に対して未対応メールの拒否を本格化。 |
Microsoft については、2025年4月2日に公式ブログ「Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders」にてこの要件が発表されました。
エラーコード 550 5.7.515 Access denied, sending domain does not meet the required authentication level が返却されるようになりました。
小規模送信者（5,000通未満/日）であっても、Microsoft は SPF・DKIM・DMARC の導入を すべての送信者にとって望ましいベストプラクティス と述べています。
規模を問わず、今すぐ対応することが推奨されます。
なりすましメール被害の深刻化
SPF だけでは不十分です。
メール転送によって SPF チェックが失われる場合があり、攻撃者は自分のインフラから送信しつつ表示名だけ偽装することができます。DKIM と DMARC はこのギャップを埋めます。
3つを組み合わせることで、以下のような多層防御が実現します。
- SPF：「このドメインからメールを送っていい IP アドレスはここだ」を DNS で宣言
- DKIM：送信メールに電子署名を付与し、内容の改ざんを検知
- DMARC：SPF と DKIM の結果を総合して、失敗したメールの処理方針（受信・隔離・拒否）をポリシーとして宣言し、レポートを受け取る
参考: クラウド組織でのEmail認証
3つの技術を理解する
SPF（Sender Policy Framework）
SPF は、ドメインのメールを送信する権限を持つソースメールサーバーを指定します。
仕組みはシンプルで、DNS の TXT レコードに「このドメインからメールを送ることを許可された IP アドレスのリスト」を公開します。
受信サーバーがそのリストと送信元 IP を照合し、一致しなければ不審なメールと判断します。
Microsoft 365（Exchange Online）向け SPF レコードの基本形：
v=spf1 include:spf.protection.outlook.com -all- include:spf.protection.outlook.com：Exchange Online の送信 IP をまとめて許可
- -all：リスト外の送信元はハードフェイル（fail）と判定され、受信側のポリシーによっては拒否や迷惑メール扱いの対象となる
注意点：
SPF レコードはドメインにつき1つのみ。
複数記述すると競合しエラーになります。
Salesforce や Marketo など外部サービスも使っている場合は、それらの include をひとつのレコードにまとめてください。
また SPF は DNS ルックアップ回数が10回以内という制限があります。
DKIM（DomainKeys Identified Mail）
DKIM は、ドメインを使用してメッセージの重要な要素にデジタル署名し、メッセージが転送中に変更されないようにします。
仕組みとしては、送信サーバーが「秘密鍵」でメールに署名し、受信サーバーが DNS に公開された「公開鍵」で署名を検証します。
署名が一致すれば、そのメールは正当な送信元から届き、かつ改ざんされていないことが証明されます。
Microsoft 365 はメール送信インフラを提供しますが、SPF レコード自体はお客様側で DNS に設定する必要があります。
DKIM はデフォルトで無効になっており、管理センターの設定と DNS レコードの両方が必要です。
Microsoft 365 で DKIM を有効化するステップ：
- Microsoft Defender ポータル（security.microsoft.com/dkimv2）にアクセス
- カスタムドメインを選択し、表示される2つの CNAME レコード値をコピーする
selector1._domainkey.yourdomain.com → selector1-yourdomain-com._domainkey.<テナント名>.onmicrosoft.com
selector2._domainkey.yourdomain.com → selector2-yourdomain-com._domainkey.<テナント名>.onmicrosoft.com- DNS プロバイダーのダッシュボードに上記 2 件の CNAME レコードを登録する
- DNS が伝播したら（数分〜数時間）、Defender ポータルに戻り「有効化」ボタンを押す
- 緑のチェックが表示されれば完了
DKIM キーのローテーション：
Microsoft 365では、DKIMの設定が完了するとシステムによって自動的にキーがローテーションされます。 管理者が手動でボタンを押す必要は原則ありませんが、セキュリティ上の懸念がある場合は手動での即時更新も可能です。
DMARC（Domain-based Message Authentication, Reporting & Conformance）
DMARC は SPF の結果を利用して、MAIL FROM ドメインと From ヘッダーのドメインが一致しているか（アライメント）を検証し、DKIM の結果を利用してメッセージに署名したドメインが From アドレスのドメインと一致しているかを検証します。
メッセージは SPF または DKIM のいずれかのチェックをパスすれば DMARC をパスします。
DMARC には3つのポリシーがあります：
| ポリシー | 動作 | 推奨フェーズ |
|---|---|---|
| p=none | 何もしない（モニタリングのみ） | 導入初期（必須） |
| p=quarantine | 迷惑メールフォルダへ隔離 | 中間段階 |
| p=reject | 完全に拒否 | 最終目標 |
DMARC レコードの記述例（初期設定）：
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@yourdomain.com"- _dmarc. というプレフィックスを付けて DNS に TXT レコードを登録します
- rua= に集計レポートの送信先メールアドレスを指定します（省略可ですが強く推奨）
- pct= を省略すると既定値の100（全メールが対象）になります
重要：
DMARC の設定は SPF・DKIM の設定が完了してから行います。
SPF・DKIM の設定と動作確認を行ったうえで DMARC を設定することが推奨されます（必ずしも待機時間は必須ではありませんが、DNS 反映後に確認してから追加すると安全です）。
Microsoft 365 管理センターで「正常」を確認するまでの手順
ここからは実際の操作手順を整理します。
ゴールは Microsoft 365 管理センターおよび Defender ポータルで、各項目が正常と表示されることです。
Step 1：SPF レコードを DNS に登録する
- Microsoft 365 管理センター（https://admin.cloud.microsoft/）にサインイン
- 「設定」→「ドメイン」→ 対象ドメインをクリック
- 「DNS レコード」タブを開き、「Microsoft Exchange」セクションの TXT レコード値をコピー
- 例：v=spf1 include:spf.protection.outlook.com -all
- ご利用の DNS プロバイダー（お名前.com、さくらインターネット、Cloudflare など）の管理画面にログインし、上記 TXT レコードを登録
- 既存の SPF レコードがある場合は、既存レコードを編集してマージ（SPF レコードは1つのみ）
確認ツール：
MXToolbox SPF Lookup や Google Admin Toolbox で設定を検証できます。
Step 2：DKIM を有効化する
- Microsoft Defender ポータル（security.microsoft.com/dkimv2） にアクセス
- カスタムドメインを選択 → 2つの CNAME レコードをコピー
- DNS プロバイダーに CNAME を登録（TTL は 3600 推奨）
- 伝播後、Defender ポータルで「有効化」をクリック
- 緑のチェック「有効」が表示されれば完了
Step 3：DMARC レコードを DNS に登録する
- _dmarc.yourdomain.com という名前で TXT レコードを DNS に追加
- 値は以下の初期設定から始める：
v=DMARC1; p=none; rua=mailto:あなたのメールアドレス@yourdomain.com- DNS に登録後、伝播を待つ（数時間〜最大72時間）
Step 4：Microsoft 365 管理センターで確認
- Microsoft 365 管理センター（https://admin.cloud.microsoft/）にサインイン→「設定」→「ドメイン」→ 対象ドメインをクリック
- 「DNS レコード」タブで各項目にチェックマークが表示されているか確認
- Microsoft Defender ポータル（security.microsoft.com/dkimv2） にアクセス→「メールと共同作業」→「ポリシーとルール」→「脅威のポリシー」→「メール認証の設定」でも確認可能
3つすべてにチェックが表示されればゴール達成です。
DMARC ポリシーを段階的に強化する
p=none で設定した後、レポートを分析しながら段階的にポリシーを強化していきます。
推奨ロードマップ
p=none（モニタリング） ↓ 数週間〜数カ月、レポートを確認 p=quarantine; pct=10 ← 10%のみ隔離（テスト） ↓ 問題なければ徐々にpctを引き上げ p=quarantine; pct=100 ↓ メールが正常に届いていることを確認 p=reject; pct=100 ← 完全な拒否ポリシー（最終目標）
DMARC レポートの読み方
rua タグで指定したアドレスに集計レポート（XML形式）が届きます。
主要な確認ポイントは以下の通りです。
- SPF 認証結果：pass か fail か
- DKIM 認証結果：pass か fail か
- DMARC アライメント：From ドメインと SPF/DKIM ドメインが一致しているか
- 外部サービス（Salesforce、Mailchimp など）から自社ドメインで送信されているメールが正しく認証されているか
XMLを人が読むのは大変なため、商用ツール（PowerDMARC等）のほか、「DMARC Report Analyzer」などの無料Web解析ツールや、Google Admin Toolboxの解析機能の利用を検討してください。
Gmail や Microsoft 365 などの主要サービスがフォレンジックレポート（ruf= タグ）の送信に対応していないため、ruf タグはあまり参考になる情報が得られない可能性が高いです。
集計レポート（rua=）を中心に監視しましょう。
よくあるハマりポイントと対処法
ハマり1
SPF の DNS ルックアップが10回を超える
include: を多用すると DNS ルックアップ数が10回の上限を超え、SPF 認証が失敗します。
対処としては：
- 不要な include: を削除する
- SPF Flattening ツールで複数の include を1つの IP リストに変換する
ハマり2
DKIM の CNAME レコードが伝播しない
- DNS プロバイダーによっては伝播に最大72時間かかる場合があります
- CloudFlare を使っている場合は プロキシ（オレンジ雲）をオフにしてください（DNS のみモード）
- TTL を 3600（1時間）に設定することが Microsoft の推奨です
ハマり3
外部メール配信サービスを使っている場合の DMARC アライメント失敗
Salesforce、HubSpot、Mailchimp などの外部サービスから自社ドメインでメールを送ると、DMARC アライメントが崩れることがあります。
DMARC は DMARC アライメントとして From ヘッダーのドメインが SPF ドメインまたは DKIM ドメインのいずれかと一致することを求めます。
Microsoft 365 では、標準構成では From ドメインに対して DKIM 署名が行われるため、結果として DMARC アライメントが満たされやすい設計になっていますが、サブドメイン設定には追加の注意が必要です。
対処法：
- 外部サービスの送信ドメイン設定で、自社ドメインの DKIM 署名を設定する
- サブドメイン（例：marketing.yourdomain.com）を使って外部サービスを分離する
ハマり4
メール転送時の SPF 失敗
メールが別のサーバーを経由して転送されると、SPF が元の IP で設定されているため失敗します。
ARC（Authenticated Received Chain）は主に転送サービス側で実装される仕組みですが、転送経路が多い場合は ARC 対応サービスの利用を検討することが有効です。
ARC は転送中のメッセージを変更する既知のサービスによる元の電子メール認証情報を保持します。
宛先電子メールサーバーは、この情報を使用して DMARC に失敗するメッセージを認証できます。
未使用ドメイン・駐車ドメインの設定も忘れずに
メールを使っていないドメインも、なりすましの踏み台にされる可能性があります。
登録済みで未使用のドメイン（駐車ドメイン）をお持ちの場合は、そのドメインからメールが送信されないよう SPF TXT レコードを設定してください。
未使用ドメイン向けの推奨レコード：
# SPF（送信なし宣言）
v=spf1 -all
# DMARC（拒否ポリシー）
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-report@yourdomain.com
（サブドメイン対策やレポート取得も含めるのが望ましい）
設定後の継続的なモニタリング
メール認証は「一度設定したら終わり」ではありません。
DNS の変更、メールホスティングプロバイダーの変更、SPF レコードに含まれていない新しいメール送信サービスの追加、DKIM キーの期限切れ、ポリシーの誤設定——これらがあとから認証失敗を引き起こします。
継続的に確認すべき事項：
- DMARC 集計レポートを定期的に確認する（週次または月次）
- 新しい外部サービスを導入したら SPF/DKIM を更新する
- DKIM キーを1〜2年ごとにローテーションする（Defender ポータルの「DKIM キーのローテーション」から実施）
- MXToolbox などのツールで定期的に設定値を検証する
まとめ
セットアップが完了したら、以下をすべて確認しましょう。
- SPF：DNS に TXT レコード v=spf1 include:spf.protection.outlook.com -all が設定されている
- DKIM：2つの CNAME レコードが DNS に設定され、Defender ポータルでチェックが有効になっている
- DMARC：_dmarc.yourdomain.com に TXT レコードが設定されている（最低 p=none; rua=…）
- Microsoft 365 管理センターの「ドメイン」→「DNS レコード」でレコードが正常（チェック）と表示されている
- 外部サービス（Salesforce、Mailchimp 等）からの送信も DMARC アライメントが通っている
- 未使用ドメインにも SPF -all と DMARC p=reject を設定している
- DMARC レポートの受信先メールアドレスを定期的に確認している
- DKIM キーのローテーション計画がある
SPF・DKIM・DMARCは“セキュリティ対策”であると同時に、“メール到達率を維持するための必須インフラ”です！
免責事項：Microsoft 365の機能や仕様は変更される可能性がありますので、実施前には最新の公式ドキュメントをご確認ください。
