Microsoft 365 の DMARC 設定手順
目次
Microsoft 365（Exchange Online）で独自ドメインを使ってメールを送っているなら、なりすまし対策の総仕上げとして DMARC の設定は欠かせません。この記事では、SPF と DKIM がすでに整っている状態を前提に、Microsoft 365 の独自ドメインで DMARC を設定する具体的な手順だけに絞って解説します。
DMARC とは何かという用語そのものの説明は DMARC とは何か にゆずり、ここでは「Microsoft 365 でどこに何を書けば動くのか」を Web 担当者の手元作業レベルで追っていきます。
前提: SPF と DKIM が整っているか確認する
DMARC は、SPF と DKIM の検証結果を使って「送信元ドメインと From アドレスのドメインが一致しているか（アライメント）」を判定する仕組みです。つまり、SPF と DKIM が正しく設定されていないと DMARC は機能しません。Microsoft の公式ドキュメントでも、DMARC を設定する前に独自ドメインの SPF と DKIM を先に整えるよう明記されています。
DMARC 設定に入る前に、最低限つぎの 2 点を確認してください。
SPF レコードに Microsoft 365 が含まれているか
独自ドメインの SPF（TXT レコード）に、Microsoft 365 の送信サーバーを示す include:spf.protection.outlook.com が入っていることを確認します。標準的には次のような値になります。
v=spf1 include:spf.protection.outlook.com -all
DKIM の CNAME が 2 本公開されているか
Microsoft 365 の DKIM は、selector1 と selector2 という 2 つのセレクタを使ってキーをローテーションします。独自ドメインの DNS に、つぎの形の CNAME レコードを 2 本公開し、管理センターで DKIM 署名を有効化しておく必要があります。
selector1._domainkey CNAME selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey CNAME selector2-contoso-com._domainkey.contoso.onmicrosoft.com
ここで重要なのは、CNAME の参照先（contoso-com や contoso.onmicrosoft.com の部分）がテナントごとに異なる点です。上記はあくまで Microsoft の例（contoso）で、自分のテナント固有の値は管理センターに表示されるものをそのまま使ってください。推測で値を作ってはいけません。
この SPF と DKIM のセットアップ手順そのものは Microsoft 365 のメール認証（SPF・DKIM・DMARC）まとめ で詳しく扱っています。まだ整っていない場合は、先にそちらを済ませてからこの記事に戻ってきてください。
DMARC レコードは管理センターでは設定できない
ここで Web 担当者がまずつまずきやすいポイントを先に押さえておきます。Microsoft 365 には、独自ドメインの DMARC レコードを管理するための管理画面や PowerShell コマンドが存在しません。
DMARC レコードは、DNS の TXT レコードとして「ドメインを管理しているレジストラ、または DNS ホスティングサービス」側で作成します。Cloudflare、お名前.com、Xserver、Route 53 など、自社のドメインの DNS を管理している場所での作業になります。
なお、*.onmicrosoft.com ドメイン（Microsoft Online Email Routing Address）の DMARC だけは例外的に Microsoft 365 管理センターで追加できますが、独自ドメイン（例: contoso.com）は必ず外部の DNS 側で設定します。この記事で扱うのは独自ドメインのケースです。
DMARC の TXT レコードを追加する
それでは実際のレコードを見ていきます。Microsoft が示す DMARC TXT レコードの基本構文は次のとおりです。
| 項目 | 値 |
|---|---|
| ホスト名（Name） | _dmarc |
| タイプ | TXT |
| TTL | 1 時間（3600 秒）推奨 |
| 値（Value） | v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<集計レポート宛先>; ruf=mailto:<失敗レポート宛先> |
ホスト名は _dmarc で固定です。実際のレコードは、対象ドメインが contoso.com なら _dmarc.contoso.com という名前で公開されることになります。
各タグの意味
v=DMARC1: この TXT レコードが DMARC レコードであることを示します。必須です。p=: DMARC に失敗したメールの扱いを指定するポリシーです。none（何もしない）、quarantine（迷惑メール扱い）、reject（拒否）の 3 段階があります。pct=: ポリシーを適用するメールの割合です。pct=100で失敗メール全件に適用、省略時の既定値も 100 です。rua=mailto:: 集計レポート（Aggregate report）の送付先メールアドレスです。ruf=mailto:: 失敗レポート（Forensic report）の送付先です。対応する受信側が少ないため、まずはruaだけで始めるのが現実的です。
まずは p=none で開始する
Microsoft が推奨するのは、いきなり強いポリシーをかけず段階的に強化するやり方です。最初からメールを拒否する設定にすると、設定漏れのある正規のメールまで届かなくなり、業務に直接ダメージを与えてしまうためです。
そこで、最初は監視専用の p=none で始めます。Web 担当者が最初に公開するレコードはこの形になります。
ホスト名: _dmarc
値: v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@contoso.com
p=none は「失敗しても何もしないが、結果はレポートで教えてほしい」という意味です。配信に影響を与えずに、自分のドメインから出ているメールの実態を可視化できます。これにより、見落としていた送信元（社内システム、外部の配信サービスなど）を洗い出せます。
集計レポートの宛先は専用メールボックスにする
rua=mailto: で指定したアドレスには、世界中の受信メールサーバーから、あなたのドメインのメールの認証結果が XML 形式の集計レポートとして届きます（多くは 1 日 1 回、GZIP 圧縮された添付ファイル）。
このレポートは量も多く、そのままでは読みにくいため、Microsoft も次の運用を推奨しています。
- 個人のメールボックスではなく、
dmarc-reports@contoso.comのような専用の共有メールボックスで受け取る - 量が多く解析しづらいため、必要に応じて DMARC レポート可視化サービスを併用する
なお、レポート宛先を別ドメインのアドレスにする場合は、その受信側ドメインに承認用の TXT レコードが追加で必要になる点も覚えておくとよいでしょう。
レポートを確認しながら段階的に強化する
p=none で数週間ほどレポートを観察し、「正規のメールがすべて認証を通っている」と確認できたら、ポリシーを一段階ずつ引き上げます。流れは次のとおりです。
p=none: 監視のみ。送信元の実態を把握するp=quarantine: 失敗メールを迷惑メール扱いにするp=reject: 失敗メールを拒否する（最終目標）
quarantine 以降では pct= を使い、pct=10 → pct=25 → pct=50 → pct=100 のように適用範囲を少しずつ広げて様子を見る方法も有効です。複数のサブドメインがある場合は、送信量の少ないドメインから着手し、最後にメインドメインを強化するのが安全です。
段階強化の最終形（例）
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@contoso.com
各段階でどのくらい監視期間を置くか、どう判断して次に進むかといった段階強化の具体的な進め方は DMARC ポリシーの段階的強化（none → quarantine → reject） で詳しく解説しています。あわせてご覧ください。
ここで Web 担当者が注意したいのは、急いで reject まで上げないことです。レポートで正規メールの取りこぼしがないことを確認しないまま reject にすると、取引先へのメールが届かなくなるおそれがあります。DMARC は「設定して終わり」ではなく「レポートを見ながら育てる」設定だと考えてください。
よくあるつまずきと確認方法
最後に、Microsoft 365 環境で DMARC を設定する際に起こりがちな問題を整理します。
_dmarcの TXT レコードが 2 つ存在する: 1 ドメインにつき DMARC レコードは 1 つだけにします。重複するとエラー（permerror）になります。- SPF・DKIM はパスするのに DMARC が失敗する: 認証は通っていてもドメインが一致していない「アライメント不一致」が原因です。外部の配信サービスから送る場合に多く、その送信元で自社ドメインによる DKIM 署名を設定すると解決します。
- 集計レポートが届かない: 自社の MX レコードが Microsoft 365 を直接指しているか、宛先メールボックスが正しく受信できるかを確認します。
公開したレコードが正しく引けるかは、_dmarc.<ドメイン> の TXT レコードを DNS で問い合わせて確認できます。
よくある質問
Microsoft 365 の管理センターで DMARC を設定できますか？
独自ドメインの DMARC レコードは Microsoft 365 管理センターや PowerShell では設定できません。ドメインの DNS を管理しているレジストラや DNS ホスティング側で、_dmarc の TXT レコードとして作成します。
DMARC は最初からどのポリシーで始めるべきですか？
まず監視専用の p=none で始めます。配信に影響を与えず送信元の実態をレポートで可視化し、正規メールがすべて認証を通ると確認できてから quarantine、reject へ段階的に引き上げます。
SPF と DKIM がパスするのに DMARC が失敗するのはなぜですか？
認証は通っていてもドメインが一致しない「アライメント不一致」が原因です。外部の配信サービスから送る場合に多く、その送信元で自社ドメインによる DKIM 署名を設定すると解決します。
自社の DMARC 状態を確認する
DMARC のポリシー設定が「いまどの段階にあり、安全に強化できる状態か」を一度きちんと棚卸ししたいときは、無料のメール認証診断をご利用ください。お使いのドメインの SPF・DKIM・DMARC の状態をまとめて確認し、つぎに何をすべきかが整理できます。設定の最終確認は人の手で行うため、安心してお試しいただけます。