はじめに
みなさん、こんにちは!業務ハックLabのようです。
前回、Google Workspaceでのメール認証設定について記事を書いたんですが(あれも結構大変でしたねw)、今回はMicrosoft 365版をやっていきたいと思います!
「あれ?Google Workspaceでやったんだからもういいじゃん」と思った方、ちょっと待ってください!
Microsoft 365を使っている組織でも、SPF/DKIM/DMARCの設定はめちゃくちゃ重要です。
なぜかというと:
- なりすましメールからドメインを守る(セキュリティ向上!)
- メールの到達率が上がる(大事な通知が迷惑メールフォルダに行かなくなる!)
- Microsoft Secure Scoreが上がる(管理者として誇らしい!)
特に最近は、GmailやYahoo!メールなどの大手メールプロバイダーが「SPF/DKIM/DMARCの設定がないドメインからのメールは受け取りません」という方針を強化してるんですよね。
(もう設定しないという選択肢はないですね…)
今回は私が実際にMicrosoft 365で設定した手順と、ハマりそうなポイントをしっかり共有していきます!
それでは、やっていきましょう!
メール認証の3兄弟: SPF、DKIM、DMARC
まずは簡単におさらいです。 (もう知ってるよ!という方は読み飛ばしてOKです)
SPF (Sender Policy Framework)
「このドメインからメールを送っていいのは、このサーバーだけだよ!」と宣言する仕組みです。
DNSのTXTレコードに、送信を許可するサーバーのIPアドレスやドメインを書いておきます。
受信側はそれを見て「なるほど、このサーバーからの送信はOKなんだな」と判断するわけですね。
DKIM (DomainKeys Identified Mail)
「このメールには私の電子署名が入ってますよ!改ざんされてないですよ!」という証明をする仕組みです。
送信時にメールにデジタル署名を付けて、受信側がその署名を検証します。
途中で誰かが内容を書き換えていたら、署名が一致しなくなるので「怪しいメールだ!」とバレるわけです。
DMARC (Domain-based Message Authentication, Reporting and Conformance)
SPFとDKIMのチェック結果を踏まえて、「認証に失敗したメールをどう扱うか」を受信側に指示する仕組みです。
- そのまま通す(p=none)
- 隔離する(p=quarantine)
- 拒否する(p=reject)
の3つから選べます。
さらに、認証結果のレポートを受け取れるので、自分のドメインを騙ったメールがどれくらい飛んでるかも分かるんです!
(これ、意外と便利なんですよね)
アーキテクチャ: メール送信時の認証フロー
メールが送信されてから受信側で検証されるまでの流れを図にするとこんな感じです。
ポイントは、受信側が送信側のDNSレコードを見に行くというところですね!
だから、私たちは自分のドメインのDNS設定に、SPF/DKIM/DMARCの情報を正しく登録しておく必要があるわけです。
実装手順: 一歩ずつ確実に!
では、実際の設定手順に入っていきます!
ステップ1: カスタムドメインの追加と確認(SPF/DKIMレコードも一緒に取得!)
まず大前提として、Microsoft 365にカスタムドメイン(例: yourcompany.com)を登録して、所有権を証明する必要があります。
(これをやらないと何も始まらないんですよね)
ここがポイント!
ドメイン追加時に詳細オプションを使うと、SPFとDKIMのDNSレコードが一度に表示されるので、後からDefenderポータルに行く手間が省けます!
(この方法、めちゃくちゃ効率的なんですよね!)
手順:
1. Microsoft 365 管理センターにアクセス
https://admin.microsoft.com にアクセスします。
2. ドメインの追加画面へ移動
左メニューの「設定」>「ドメイン」を選択します。
3. 「ドメインの追加」をクリック
所有しているカスタムドメイン名(例: example.com)を入力します。
4. 所有権の確認
「ドメインの DNS レコードに TXT レコードを追加する」を選択するとTXTレコードが表示されます。
ホスト名: @
種類: TXT
値: MS=msXXXXXXXX
このレコードを、お使いのドメインレジストラ(お名前.comやAWS Route53など)のDNS設定画面で追加します。
ドメインレジストラでTXTレコードを追加したら少し待ちましょう。(伝播するまで少し時間がかかるので)
しばらくしたら「確認」をクリックします。
5. 詳細オプションを展開(重要!)
ドメイン名を入力すると、「Exchange と Exchange Online Protection」というメールなどを使用する為に登録が必要なレコードが表示される箇所にSPFのレコードがあります。
また下の方に「詳細オプション」という箇所があるのですがその中にDKIMのCNAMEレコードがあるのでクリックして展開します。
この二つのチェックボックスにチェックを入れておきましょう
- □ Exchange および Exchange Online Protection
- □ ドメインキー識別済みメール (DKIM)
6. レコードをドメインレジストラに登録
所有権確認のTXTレコードを登録した時と同様に下記のレコードを表示された各レコードを登録しましょう。
MXレコード:
ホスト名: @
種類: MX
指定先: <カスタムドメイン（ドットはハイフンに置換）>.mail.protection.outlook.com
優先度: 0autodiscoverCNAMEレコード:
ホスト名: autodiscover
種類: CNAME
値: autodiscover.outlook.comSPF用TXTレコード:
ホスト名: @
種類: TXT
値: v=spf1 include:spf.protection.outlook.com -allDKIM用CNAMEレコード(2つ):
ホスト名: selector1._domainkey
種類: CNAME
指定先: selector1-<ドメインキー>._domainkey.<初期ドメイン>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft
ホスト名: selector2._domainkey
種類: CNAME
指定先: selector2-<ドメインキー>._domainkey.<初期ドメイン>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft※注意: DKIMのCNAMEレコード形式は、ドメイン追加時期により異なります。
2025年5月以降に追加されたドメインは新形式、それ以前のドメインは旧形式(.onmicrosoft.comで終わる形式)を使用します。
基本的には表示されたコードをそのままコピーして利用する方法で問題ないです。
7. DNS伝播を待って検証
レコードを追加したら、数分〜数時間待ちます。 (DNSの伝播には時間がかかるんですよね…)
管理センターに戻って「検証」ボタンをクリックすると、所有権確認が完了します!
はい、これでドメインの追加とDNSレコードの準備は完了です!
重要なポイント:
ドメイン検証が成功しても、CNAMEレコードのDNS伝播が完了していない場合、DKIMは自動的に有効化されません。
この場合は、DNS伝播完了後にDefenderポータルで手動でトグルをオンにする必要がありますので要注意です。
次のステップでは、それぞれが正しく有効化されているか確認していきます。
ステップ2: SPF (Sender Policy Framework) の確認
次はSPFレコードが正しく機能しているか確認します。
SPFは、「どのサーバーがこのドメインからメールを送信していいか」を定義するものでしたね。
実は、ステップ1でもう設定済みです!
ドメイン追加時に詳細オプションで「Exchange および Exchange Online Protection」にチェックを入れたので、SPFレコードは既にDNSに追加されているはずです。
確認手順:
SPFレコードが正しく登録されているか確認
確認するにはGoogle Admin Toolbox Digを使用すると楽に調べることができます。
Dig（DNS ルックアップ）
- https://toolbox.googleapps.com/apps/dig/ にアクセス
- 「Domain name」に自分のドメイン名(例: example.com)を入力
- 「Type」のプルダウンから「TXT」を選択
- 「Dig」ボタンをクリック
結果の中に v=spf1 include:spf.protection.outlook.com -all が含まれていればOKです!
(このツール、ブラウザだけで使えるので便利なんですよね!)
重要ポイント:
- SPFレコードは1ドメインにつき1つだけです!
- 既にSPFレコードがある場合は、
include:spf.protection.outlook.comを既存レコードに追加します - もし社内にオンプレミスのExchangeサーバーや、他の配信サービス(SendGridなど)を使っている場合は、それらも追加する必要があります
例:
v=spf1 include:spf.protection.outlook.com include:_spf.google.com -allステップ3: DKIM (DomainKeys Identified Mail) の有効化確認
ステップ1でドメイン検証が成功し、かつCNAMEレコードのDNS伝播が完了していれば、 DKIMは自動的に有効化されているはずです!
(詳細オプションで「ドメインキー識別済みメール (DKIM)」にチェックを入れたおかげですね!)
ここでは、実際に有効化されているかをMicrosoft Defender ポータルで確認します。
手順:
1. Microsoft Defender ポータルにアクセス
https://security.microsoft.com にアクセスします。
2. DKIM設定画面へ移動
「メールとコラボレーション」>「ポリシーとルール」>「脅威ポリシー」>「メールの認証の設定」を選択します。
上部のタブで「DKIM」を選びます。
3. ドメインを選択して有効化状態を確認
設定したドメインをクリックします。
すると、右側のパネルに「このドメインのメッセージをDKIM署名で署名する」というトグルが表示されます。
トグルがオン(有効)になっていることを確認してください!
(ステップ1のドメイン検証時に自動的にオンになっているはずです!)
はい、これでDKIMが正しく有効化されていることが確認できました!
もしトグルがオフになっている場合:
DNS伝播が完了していないか、CNAMEレコードに問題がある可能性があります。
Google Admin Toolbox Digを使用してチェックしましょう。
CNAME構文エラーで困った時のチェックポイント:
DNS管理画面によっては、ホスト名の入力形式が異なるので注意！！
もしCNAMEレコードが正しく登録されていない場合は、DNS管理画面に戻って修正してください。
ステップ4: DMARC の設定
最後の仕上げ、DMARCです!
DMARCは、SPFとDKIMの認証結果を受けて、「認証失敗したメールをどう扱うか」を指示するポリシーでしたね。
手順:
1. DMARCポリシーを決める
最初は監視モード(p=none)から始めるのが鉄則です!
(いきなりp=rejectにすると、正規のメールまで弾かれる可能性があるんですよね…)
まずは様子を見て、レポートを確認してから徐々に強化していきます。
2. TXTレコードを追加
ドメインレジストラのDNS管理画面で、以下のTXTレコードを追加します。
ホスト名: _dmarc
種類: TXT
値: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
パラメータの意味:
v=DMARC1: DMARCのバージョンp=none: ポリシー(noneは監視のみ、何もしない)rua=mailto:メールアドレス: 集約レポートの送信先
3. しばらく運用して様子を見る
p=none で数週間〜1ヶ月ほど運用します。
rua で指定したメールアドレスに、毎日レポートが届きます。
(XMLファイルで来るので、ちょっと読みづらいんですけどね…)
レポートを確認して、SPF/DKIMが正しく通っていることを確認できたら、次のステップへ!
4. ポリシーを強化する
レポートで問題がなければ、徐々にポリシーを強化します。
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.comp=quarantine: 認証失敗したメールを迷惑メールフォルダに隔離pct=10: 10%のメールにだけポリシーを適用(段階的導入)
さらに様子を見て、問題なければ:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.comp=reject: 認証失敗したメールを完全に拒否
ここまで来たら、かなり強固な防御になります!
(なりすましメールはほぼ届かなくなりますね!)
トラブルシューティング:ハマりそうなポイント
実際に設定してみて、いくつかハマりそうかなというポイントがあったので共有します!
1. ドメイン検証時にDKIMが自動有効化されなかった
症状: ドメイン検証は成功したのに、DefenderポータルでDKIMのトグルがオフのままになっている。
原因: ドメイン検証時に、CNAMEレコードのDNS伝播がまだ完了していなかった!
解決策:
- ドメイン検証の前に、CNAMEレコードのDNS伝播を確認する
- Google Admin Toolbox Dig (https://toolbox.googleapps.com/apps/dig/) で確認:
- Domain name:
selector1._domainkey.example.com - Type:
CNAME - 正しい指定先が返ってくることを確認
- Domain name:
- または
nslookup -type=cname selector1._domainkey.example.comで確認 - CNAMEレコードが確認できてから検証ボタンをクリック
- もし既に検証済みの場合は、Defenderポータルで手動でトグルをオンにする
- それでもダメなら、数時間〜1日待ってから再トライ
(ドメイン検証は、全てのDNSレコードが伝播してから実行するのがベストですね!)
2. CNAME構文エラー
症状: ドメイン追加時に表示されたCNAMEレコードを追加したはずなのに、nslookupやGoogle Admin Toolbox Digで見つからない。
原因: DNS管理画面ごとに、ホスト名の入力形式が違う!
解決策:
お使いのDNS管理サービスのヘルプドキュメントを確認してください。
入力後は必ず確認!
レコードを追加したら、Google Admin Toolbox Dig (https://toolbox.googleapps.com/apps/dig/) で確認するクセをつけると良いです!
(ブラウザで簡単に確認できるので、コマンドラインより楽ですよね!)
3. ドメイン追加時に詳細オプションを見逃した
症状: 詳細オプションを展開せずにドメインを追加してしまい、後からDefenderポータルでCNAMEレコードを探す羽目になった。
原因: 詳細オプションのリンクが目立たない場所にあって、見逃しやすい!
解決策:
- ドメイン追加時は、必ず「詳細オプション」を展開する
- 「Exchange および Exchange Online Protection」と「ドメインキー識別済みメール (DKIM)」の両方にチェックを入れる
- これで必要なDNSレコードが一度に表示される
(この方法を知ってるだけで、作業時間が半分以下になりますよ!)
もし既に詳細オプションを使わずにドメインを追加してしまった場合でも、Defenderポータルから後でCNAMEレコードを確認できるので安心してください。
4. SPFレコードが2つ存在してしまった
症状: 既にSPFレコードがあることに気づかず、新しいSPFレコードを追加してしまった。
原因: SPFレコードは1ドメインに1つだけという制約を忘れていた!
解決策:
- 既存のSPFレコードに
include:spf.protection.outlook.comを追加する形に修正 - 例:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all
ドメインレジストラに登録する時にエラーが既存のレコードがある場合はエラーが出るとは思いますがまずは確認してから追加するクセをつけましょう！
5. DMARCレポートが読めない
症状: DMARCレポートが毎日届くけど、XMLファイルで何が書いてあるか分からない…
解決策: Microsoft 365を使っているなら、Microsoft Copilot Chatを使うのがベストです!
(組織のメール情報を外部サービスにアップロードするのは、セキュリティ・ガバナンス的にNGですからね…)
手順:
- DMARCレポート(XMLファイル)が添付されたメールを開く
- Microsoft Copilot Chatを起動
- XMLファイルをアップロードして、以下のようにプロンプトを投げる:
このDMARCレポートを分析して、以下を教えてください:
- 総メール送信数
- SPF/DKIM認証の成功率
- 認証失敗の原因
- なりすましメールの検出有無- Copilotが分かりやすく要約してくれます!
【画像14: Copilot ChatでのDMARCレポート分析例】 ※CopilotにXMLファイルをアップロードして、分析結果が表示されている画面
これなら組織のデータを外部に出すことなく、安全にレポートを解析できます。
(しかもMicrosoft 365のライセンスがあれば追加費用もかからないですしね!)
まとめ: これでメールセキュリティは万全!
はい、いかがでしたでしょうか?
Microsoft 365でのSPF/DKIM/DMARC設定、結構やることが多くて大変でしたよね。
でも、一度設定してしまえば、以下のメリットが得られます:
✅ なりすましメールからドメインを守れる
✅ 送信したメールが迷惑メールフォルダに入りにくくなる
✅ Microsoft Secure Scoreが上がる
✅ 大手メールプロバイダーのポリシーに準拠できる
✅ メール配信の信頼性が向上する
(焦らず、一つひとつ確認しながら進めるのがコツですね!)
DMARCは最初 p=none で様子を見て、徐々に p=quarantine → p=reject と強化していくのがベストプラクティスです。
みなさんも、ぜひこの機会にメール認証設定を見直してみてください!
(Secure Scoreが上がると、何だか達成感がありますよね…!)
それでは皆さん、良い業務ハックライフを〜
コメント