Microsoft 365のメールセキュリティ対策（DMARC編）｜SPF・DKIMを整えてp=rejectまで段階的に強める
Microsoft 365 に独自ドメインを追加しただけでは、送信するメールにそのドメインの DKIM 署名は付きません。この状態のまま DMARC を「拒否」まで強めると、自社の正当なメールまで相手に届かなくなるおそれがあります。
DMARC は、SPF と DKIM の結果を、画面に表示される差出人のドメインと突き合わせ、なりすましメールの扱いを受信側に伝える仕組みです。監視（p=none）から始め、レポートで正規の送信元を洗い出してから、隔離（quarantine）、拒否（reject）へと段階的に強めるのが、Microsoft の推奨する進め方です。
SPF のレコードは、Microsoft 365 の導入時に作成済みという組織がほとんどです。そのうえで、Microsoft の公開情報を読むと、見落とされやすい点が3つあります。
- 独自ドメインの DKIM 署名は、管理者が有効にするまで行われない
- SPF の末尾が
~allのままだと、DKIM 署名のないメールには DMARC の指示が実質的に効かない - onmicrosoft.com のドメインは、SPF と DKIM は設定済みでも、DMARC だけは自分で追加する必要がある
この記事では、DMARC の仕組みと SPF・DKIM との役割分担、Microsoft 365 で最初に確かめる前提、DMARC を段階的に強める手順と、レポートの読み方を、Microsoft Learn の公開情報をもとに解説します。
目次
株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。
DMARCとは：SPF・DKIMだけでは防げないなりすまし
メールには、差出人を表す情報が2つあります。メールサーバーどうしが受け渡しに使う「MAIL FROM」（封筒の差出人）と、メールソフトの画面に表示される「From」（便箋の差出人）です。受信者が目にするのは From だけで、MAIL FROM は普段は見えません。
| 差出人の情報 | 役割 | 確かめる仕組み |
|---|---|---|
| MAIL FROM | サーバー間の受け渡しと、届かなかったときの返送先に使う。受信者には見えない | SPF（送ってきたサーバーが、このドメインの正規の送信元か） |
| From | メールソフトに差出人として表示される | DMARC（SPF または DKIM で確かめたドメインと一致するか） |
| DKIM 署名の d= | メールに電子署名したドメイン。受信者には見えない | DKIM（署名が正しく、途中で書き換えられていないか） |
SPF を設定していても、DMARC は必要か
必要です。SPF が確かめるのは MAIL FROM のドメインだけで、画面に表示される From のドメインは見ていません。DKIM も、署名したドメインが From と同じかどうかは問いません。
そのため攻撃者は、自分で取得したドメインに SPF と DKIM を正しく設定し、From にだけ自社のドメインを書いて送ることができます。このメールは SPF にも DKIM にも合格します。Microsoft Learn も、SPF だけでは不十分であり、SPF・DKIM・DMARC はそろって初めて十分な保護になると説明しています。
DMARC は、この穴を埋めます。SPF で確かめた MAIL FROM のドメイン、または DKIM で署名したドメインのどちらかが、From のドメインと一致していれば合格、どちらも一致しなければ不合格とします。そのうえで、不合格のメールをどう扱ってほしいかを、ドメインの持ち主が受信側に伝えます。
SPF・DKIM・DMARCの役割分担
3つの仕組みは、どれも送信側のドメインの DNS にレコードを置き、受信側がそれを参照して確かめる、という点で共通しています。違いは、何を確かめるかです。
| 仕組み | 確かめること | DNS のレコード | 苦手なこと |
|---|---|---|---|
| SPF | MAIL FROM のドメインにとって、送ってきたサーバーが正規の送信元か | TXT（ドメインごとに1つ） | 転送されると、転送元のサーバーが正規の送信元でなくなり不合格になる |
| DKIM | 電子署名が正しく、署名した部分が途中で書き換えられていないか | CNAME（Microsoft 365 の場合） | 署名したドメインと From のドメインが違っていても合格する |
| DMARC | SPF または DKIM のドメインが From と一致するか。不合格のときの扱いと、レポートの送り先 | TXT（_dmarc というホスト名） | 途中でメールを書き換えるサービスを経由すると、正当なメールでも不合格になりうる |
「一致」の判定は、既定では緩やかな方式（relaxed）です。From が contoso.com で、MAIL FROM が bounces.contoso.com のように同じ組織のドメインのサブドメインであれば、一致とみなされます。完全に同じ名前でなければ一致としない厳格な方式（strict）も選べますが、まずは既定のままで始めるのが一般的です。
Microsoft 365で最初に確かめる3つの前提
DMARC のレコードを作る前に、SPF と DKIM が正しく動いている必要があります。Microsoft Learn も、送信に使うすべての独自ドメインとサブドメインで、SPF と DKIM を先に設定するよう求めています。
独自ドメインの DKIM は、有効にするまで署名されない
Microsoft Learn は、独自ドメインから送るメールには現状 DKIM 署名が行われない、と明記しています。DMARC で DKIM の一致を得るには、From と同じドメインで署名する必要があるため、独自ドメインごとに DKIM を有効にします。
- Microsoft Defender ポータルのメール認証の設定で、対象のドメインの DKIM の画面を開き、作成すべき2つの CNAME レコード（selector1 と selector2）の値を確かめる
- ドメインの DNS を管理している事業者の画面で、2つの CNAME レコードを作成する
- Microsoft 365 がレコードを検出したら、DKIM 署名を有効にする
CNAME の値はドメインやテナントによって異なるため、Web で見かけた例をそのまま写さず、必ずポータルに表示される値を使います。また、送信に使うサブドメインは、それぞれ個別に DKIM の設定が必要です。
SPF は -all で締める
Microsoft 365 だけからメールを送る場合、独自ドメインの SPF レコードは次のとおりです。社内のメールサーバーや外部の配信サービスからも送る場合は、その送信元を追加します。
v=spf1 include:spf.protection.outlook.com -all末尾の -all は「ここに書いた送信元以外は認めない」という意味です。Microsoft は、DKIM と DMARC もあわせて設定する前提で -all を推奨しています。~all（ソフトフェイル）のままだと、DKIM 署名のないメールについては、DMARC の指示が事実上無視されるためです。
SPF のレコードは1つのドメインに1つだけです。2つあると、受信側はどちらで判定すべきか決められず、エラーになります。また、include などで DNS の参照が10回を超えると、SPF は不合格になります。外部のサービスを足していくうちに上限を超えやすいため、追加のたびに参照回数を確かめます。
onmicrosoft.com のドメインは、DMARC だけが未設定
テナントの作成時に付く「〇〇.onmicrosoft.com」のドメインは、Microsoft が DNS を管理しており、SPF と DKIM は最初から設定されています。一方、DMARC のレコードは自分で追加する必要があります。追加は、Microsoft 365 管理センターのドメインの画面から、このドメインの DNS レコードとして行えます。
onmicrosoft.com のドメインをメールの送信に使っていない場合は、後述する「使っていないドメイン」と同じく、p=reject で塞いでおきます。
DMARCを段階的に強める手順
DMARC のレコードは、ドメインの DNS に _dmarc というホスト名の TXT レコードとして作ります。独自ドメインの DMARC を Microsoft 365 の画面や PowerShell で管理する方法はなく、DNS を管理している事業者の画面で作成します。
| 項目 | 意味 |
|---|---|
p=none | 不合格のメールについて、特に扱いを指示しない。レポートを集めて様子を見る段階で使う |
p=quarantine | 受け取ったうえで、不審なメールとして扱うよう求める。迷惑メールフォルダーへの振り分けなど、実際の扱いは受信側が決める |
p=reject | 受け取りを拒否するよう求める |
pct= | 不合格のメールのうち、何％に指示を当てるか。省略すると100 |
rua=mailto: | 集計レポート（1日ごとの合否のまとめ）の送り先 |
Microsoft が推奨する進め方は、次のとおりです。メールの量が少なく、送信元の少ないドメインやサブドメインから始めます。
- p=none で監視する：集計レポートで、正規のメールがどこから送られ、どれが不合格になっているかを確かめる
- p=quarantine に上げる：
pct=を 10、25、50、75、100 と段階的に上げ、影響を確かめながら対象を広げる - p=reject に上げる：ここでも必要に応じて
pct=で段階的に広げる - 残りのサブドメインに広げる：量と送信元の多いものへ順に進め、親のドメインは最後にする
v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@contoso.com
v=DMARC1; p=reject; rua=mailto:dmarc-reports@contoso.com
サブドメインは、自分の DMARC レコードを持たない限り、親のドメインの設定を引き継ぎます。存在しないサブドメインも対象です。SPF や DKIM と違い、DMARC は親のドメインに1つ置くだけで、使っていないサブドメインまで守れるのが利点です。
Microsoft は各段階の期間を定めていませんが、導入の初期は集計レポートを毎週、安定してからは毎月確かめることを勧めています。正当なメールが不合格になっている送信元が残っている間は、次の段階へ進めないのが原則です。
集計レポートの読み方と、つまずきやすい送信元
集計レポートは、メールを受け取った各社のメールサービスから、通常1日に1回、XML の添付ファイル（多くは圧縮済み）で届きます。中身は、送ってきたサーバーの IP アドレスと通数、SPF・DKIM・DMARC の合否です。量が多く読みにくいため、レポートを集計して見せる外部のサービスを使う方法も、Microsoft は紹介しています。
読むときの勘どころは、「認証には合格しているが、一致では不合格」という行を探すことです。SPF や DKIM そのものには合格していても、ドメインが From と一致していなければ、DMARC では不合格になります。正規の送信元なのに設定が足りていない、という典型的な状態です。
レポートの受け取りには、担当者個人のメールボックスではなく、専用の共有メールボックスや Microsoft 365 グループを使います。担当者を決めて、定期的に確かめる体制にしておきます。
外部の配信サービスから自社のドメインで送っている
メールマガジンの配信サービスや、請求書・予約通知を送る業務システムが、From に自社のドメインを使っていることはよくあります。こうしたサービスは、MAIL FROM や DKIM の署名に、サービス側のドメインを使っている場合が多く、そのままでは DMARC で不合格になります。
対処は、サービス側で自社のドメインによる DKIM 署名を設定するか、MAIL FROM を自社のドメインに変えることです。Microsoft は、直接管理できない配信サービスには、メインのドメインではなく専用のサブドメイン（例：marketing.contoso.com）を使うことも勧めています。サービス側の問題が、社員が送るメールの評判に響かないようにするためです。
転送やメーリングリストを経由したメール
メールが転送されると、送信元のサーバーが変わるため、SPF は不合格になります。DKIM は、本文や署名した部分が書き換えられなければ転送後も合格するので、DKIM を設定しておくことが転送への備えになります。件名や本文に文字を足すメーリングリストを経由すると、DKIM も不合格になり、レポートでは不合格として現れます。
失敗レポートは届かないものと考える
DMARC には、不合格のたびに送られる「失敗レポート」（ruf= で送り先を指定）もあります。ただし Microsoft 365 は、受信側として失敗レポートを送りません。他社のメールサービスでも送らないところが多いため、原因の調べ方は集計レポートが中心になります。
なお、集計レポートの送り先を、外部のレポート集計サービスなど別のドメインのアドレスにする場合は、受け取る側のドメインに、レポートの受け取りを認めるレコードが必要です。集計サービスを使うときは、サービスの案内に従って設定します。
使っていないドメインを塞ぐ
ブランドを守るために取得したものの、メールにもWebにも使っていないドメインは、なりすましに悪用されやすい対象です。メールを一切送らないことを宣言するレコードを置いておきます。
（ホスト名なし） v=spf1 -all
_dmarc v=DMARC1; p=reject;メールを送らないドメインには、DKIM の CNAME レコードは作りません。正当なメールが無いので、段階を踏まずに最初から p=reject にでき、レポートの送り先も省略して構いません。先に触れたとおり、送信に使っていない onmicrosoft.com のドメインも、この対象に含めます。
受信側：Microsoft 365は他社のDMARCをどう扱うか
ここまでは自社のドメインを守る「送信側」の話でした。取引先を装ったメールを受け取る「受信側」では、Microsoft 365 は送信元のドメインが公開している DMARC の指示を参考に、届いたメールを判定します。
送信元の DMARC の指示に従う設定
この扱いを決めるのが、フィッシング対策ポリシーの「Honor DMARC record policy when the message is detected as spoof」という設定です。有効にすると、送信元が p=quarantine のメールで不合格のものは迷惑メールフォルダー（設定で隔離にも変更可能）へ、p=reject のものは受け取りを拒否します。実際の設定値は、自社のポリシーで確かめておきます。
DMARC を公開していないドメインからのメールも、素通りするわけではありません。Microsoft 365 は、送信元の評判や過去のやり取りなども加味した独自の判定（複合認証）を行い、なりすましの疑いがあるメールを見分けます。取引先や役員を装うメールへの備えは、Microsoft 365のメールセキュリティ対策（Defender for Office 365編）で解説しています。
他社のメールゲートウェイを前段に置いている場合
注意したいのは、MX レコードが Microsoft 365 以外のメールゲートウェイを向いている構成です。この場合、送ってきたサーバーが正しく判別できず、SPF や DMARC の判定が狂います。Exchange Online のコネクタの拡張フィルター（Enhanced Filtering for Connectors）で、本来の送信元を判別させる必要があります。また、この構成では Microsoft 365 から集計レポートも送られません。
Outlook.comの大量送信者の要件
DMARC は、もはや「設定しておくと望ましいもの」ではなくなりつつあります。Microsoft は、Outlook.com・Hotmail.com・Live.com など個人向けのメールサービスに大量のメールを送る送信者に、送信ドメインの認証を求める要件を発表しました。
- 対象：同じドメインを From に使い、5,000通以上を送る送信者
- 要件：SPF と DKIM に合格し、少なくとも
p=noneの DMARC レコードを公開し、SPF か DKIM のどちらかが From のドメインと一致していること - 時期：2025年5月5日から、要件を満たさないメールは迷惑メールフォルダーに振り分けられ、将来は受け取りの拒否も予定されている
メールマガジンや通知メールを顧客の個人アドレスへ送っている企業は、自社の Microsoft 365 からの送信だけでなく、外部の配信サービスからの送信も含めて、SPF・DKIM・DMARC がそろっているかを確かめておく必要があります。
DMARC導入の進め方
ここまでの内容を、作業の順番にまとめます。最初の棚卸しで送信元を漏らさないことが、段階を進めるときの手戻りを減らします。
Microsoft 365 での DMARC 導入の手順
- 自社のドメインで送っているメールの送信元を洗い出す（Microsoft 365、社内のサーバー、外部の配信サービス・業務システム）
- SPF を整え、末尾を
-allにする - 独自ドメインとサブドメインごとに DKIM を有効にし、外部サービスにも自社ドメインでの署名を設定する
- DMARC を
p=noneで公開し、集計レポートを専用のメールボックスで受け取る - レポートで不合格の正規の送信元を直しながら、quarantine、reject へと段階的に上げる
- 使っていないドメインと onmicrosoft.com のドメインは
p=rejectで塞ぐ
弊社の支援
弊社は、Microsoft 365 の導入とセキュリティ設定を支援しています。DMARC の導入で時間がかかるのは、レコードを書く作業よりも、自社のドメインで送っているメールの送信元を漏れなく洗い出し、外部のサービスの設定を一つずつ直していく作業です。
送信元の棚卸しから、SPF・DKIM の整備、集計レポートを読みながらの段階的な引き上げ、受信側のフィッシング対策ポリシーの見直しまでをご一緒に進めます。メール以外も含めたセキュリティ対策の全体像は、ゼロトラストとはで解説しています。
資料のご案内
Microsoft 365 セキュリティ対策ガイド【メール編】
SPF・DKIM・DMARC の設定と、なりすましやフィッシングから受信メールを守る Defender for Office 365 の設定をまとめています。
よくあるご質問
こちらをクリックして「よくある質問」を表示
DMARC を設定すれば、なりすましメールは届かなくなりますか？
自社のドメインを From にそのまま使うなりすましは、受信側が DMARC の指示に従う限り防げます。ただし、自社に似た別のドメインや、表示名だけを偽るなりすましは DMARC の対象外です。受信側のフィッシング対策や、利用者への注意喚起と組み合わせます。
いきなり p=reject にしてもよいですか？
メールを送っているドメインでは、お勧めしません。外部の配信サービスなど、把握していない正規の送信元があると、そのメールが相手に届かなくなります。p=none で集計レポートを確かめてから、段階的に上げるのが Microsoft の推奨です。メールを送らないドメインなら、最初から p=reject で構いません。
Microsoft 365 の画面で DMARC を設定できますか？
onmicrosoft.com のドメインは、Microsoft 365 管理センターから DMARC のレコードを追加できます。独自ドメインは、Microsoft 365 の画面や PowerShell では管理できず、ドメインの DNS を管理している事業者の画面で TXT レコードを作成します。
SPF の末尾は ~all と -all のどちらがよいですか？
Microsoft は、DKIM と DMARC もあわせて設定する前提で -all を推奨しています。~all のままだと、DKIM 署名のないメールについては DMARC の指示が事実上無視されるためです。送信元の洗い出しが済むまでは ~all で始め、整ってから -all に変える進め方もあります。
集計レポートは、どこから届きますか？
自社のドメインからのメールを受け取った、各社のメールサービスから届きます。受け取った相手が多いほど、届くレポートも増えます。レポートを送らないメールサービスもあるため、すべてのメールの結果がそろうわけではありません。
サブドメインにも DMARC のレコードが必要ですか？
必須ではありません。サブドメインは、自分のレコードを持たない限り、親のドメインの DMARC を引き継ぎます。段階導入の途中でサブドメインだけ先に強めたい場合に、個別のレコードを置きます。一方、SPF と DKIM は、送信に使うサブドメインごとに設定が必要です。
なりすましメール対策は、自社のドメインを守る送信側の設定と、取引先を装うメールを見分ける受信側の設定の両方がそろって効果を発揮します。現在のドメインの構成や、外部の配信サービスの使い方をお聞かせいただければ、進め方をご提案します。お問い合わせよりお気軽にご相談ください。
関連サービス・関連コラム
- セキュリティ強化支援（ゼロトラスト）
- クラウド導入支援（Microsoft 365）｜安全で生産性の高い働き方の基盤を構築
- ゼロトラストとは｜中小企業がMicrosoft 365で始めるセキュリティ
- プロンプトインジェクション対策｜Copilot・AIエージェントを乗っ取る攻撃を、Microsoft 365で防ぐ
- Microsoft 365のメールセキュリティ対策（Defender for Office 365編）｜標準の保護とPlan 1・Plan 2の違いと、なりすまし対策の設定
まずは無料トライアルで、効果をご確認ください
「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）・電話対応（AI-Voice）・計画づくり（AI-Enhance）の自動化から、クラウド（Azure・Microsoft 365）・DXのご相談まで、お気軽にどうぞ。
