Microsoft 365 で SPF・DKIM・DMARC を設定する｜独自ドメインのメールを迷惑メールにされない順番

取引先から「御社のメールが迷惑メールのフォルダーに入っていた」と言われたり、Gmail 宛てのメールが返ってくるようになったりして、送信ドメイン認証（SPF・DKIM・DMARC）を調べ始めた方に向けた記事です。仕組みの説明はたくさん見つかりますが、Microsoft 365 では何がもう設定済みで、何を自分で DNS に入れ、どの画面で何を押すのかは、ほかのメールサービスと違います。この記事では、Microsoft 365 で独自ドメインのメールを送っている会社が、SPF・DKIM・DMARC をどの順に、どんな値で設定し、どう確かめるかを書きます。

3つの仕組みの考え方そのものはSPF・DKIM・DMARC の入門の記事に、DMARC のレポートの XML の読み方はDMARC レポートの読み方の記事にまとめています。この記事では、Microsoft 365 での設定の手順に絞ります。例のドメインは example.co.jp（架空）です。Microsoft 365 と生成 AI の導入を支援している当社が、公式の説明をもとに手順を整理し、画面の名前と表示を当社の検証用の環境で確かめました。

始める前に：どのドメインで送っているかを確かめる

Microsoft 365 では、送っているドメインの種類でやることが変わります。契約したときに付く「〜.onmicrosoft.com」のドメインだけで送っているなら、SPF と DKIM は Microsoft が用意済みで、自分で入れるのは DMARC だけです（SPF の設定・DKIM の設定・DMARC の設定）。

独自ドメイン（Microsoft の公式ドキュメント Microsoft Learn（以下、Learn）での呼び名は「カスタム ドメイン」）で送っている場合は、3つとも自社の DNS で設定します。DKIM の手順のページには「現在、カスタム ドメインからの送信メールに対して DKIM 署名は行われません」とあり、自分で有効にするまで example.co.jp の署名は付きません。SPF と DMARC は、Microsoft 365 の中にそのレコードを管理する画面も PowerShell のコマンドも無いので、ドメインを買った事業者や DNS を預けている事業者（以下、DNS の事業者）の画面で作ります。

メールに使っていないドメインを持っているなら、そのドメインには「このドメインからは誰も送らない」というレコードを置きます。値は、SPF が v=spf1 -all、DMARC が v=DMARC1; p=reject; です。DKIM のレコードは作りません（公開鍵が無いので、偽の署名が通らない）。

次に、そのドメインを差出人にしてメールを出している仕組みを、Microsoft 365 以外も含めて一覧にします。メール配信サービス、Web サイトの問い合わせフォームの自動返信、業務システムの通知、複合機や社内のサーバーなどです。この一覧から漏れた送信元は、DMARC を強めた後に届かなくなるおそれがあります。全部を見つけられなくても、後の DMARC のレポートで見つかるので、まず分かる範囲で書き出します。自社で直接管理していない配信サービスには、本体のドメインではなくサブドメイン（例：mail.example.co.jp）を使います。配信サービス側で起きた問題が、社員が送るメールの評判（受信側がそのドメインのメールをどれだけ信用するか）に響かないようにするためで、SPF の参照の数を抑えることにもなります。

この記事に関連するサービス

M365・Google Workspace の移行と設定の相談移行と設定を、1件から相談できます。詳しく見る →Microsoft 365 導入支援Exchange・SharePoint・Teamsの移行から権限設計・Copilot活用まで詳しく見る →Google Workspace 導入・移行支援Gmail移行から権限設計・Gemini活用まで詳しく見る →AIセキュリティ診断・規約・ルール整備AIを使う前に、出す前に。安全の確認と、規約・ルールの整備を詳しく見る →Notion 導入支援議事録・ナレッジ・タスクを一箇所にまとめる詳しく見る →

手順1：SPF の TXT を1本にまとめる

Microsoft 365 だけから送る場合、example.co.jp に入れる SPF の値は次のとおりです（SPF の設定）。

v=spf1 include:spf.protection.outlook.com -all

種類は TXT で、ホスト名（TXT 名）は例では「@」（ドメインそのもの）です。DNS の事業者によっては、「@」の代わりにドメイン名を入れます。Microsoft 365 にドメインを追加したときに、この値を入れている会社もあります。その場合も、次の3点を見直します。

• 1本だけか：SPF のレコードは、1つのドメイン（サブドメインも同じ）に1本だけです。同じドメインに v=spf1 で始まる TXT が2本あると、SPF は permerror（設定の誤り）になります。前のメールサービスの SPF が残っているなら、新しい1本を作らず、今ある1本に include:spf.protection.outlook.com を書き足します。前のメールサービスの値は消しません（DNS レコードを追加する）。
• ほかの送信元が入っているか：配信サービスはその案内にある include: を、社内のサーバーは ip4: でその IP アドレスを足します。include: などの参照が、入れ子の先も含めて10を超えると permerror になります。足りなくなったら、配信サービスをサブドメインに分けます。Microsoft 365 の include:spf.protection.outlook.com は IP アドレスに置き換えません。Microsoft が送信に使う IP アドレスは、よく変わるためです。
• 最後が -all か：Microsoft 365 のドメインでは -all（載っていない送信元は拒否してよい）にします。~all でも DMARC は SPF の失敗として数えます。ただ、DKIM の署名も無いメールでは、~all の失敗に対して DMARC のポリシーが実際には効かなくなります。

サブドメインから送るなら、サブドメインごとに SPF が1本要ります。example.co.jp の SPF は mail.example.co.jp をカバーしません。TTL（DNS に値を覚えさせておく時間）は3600秒（1時間）以上にします。

手順2：DKIM を有効にする（Defender ポータルと DNS）

DKIM は、Microsoft 365 が送るメールに電子署名を付け、受け取った側が DNS の公開鍵で確かめる仕組みです。Microsoft 365 では鍵の組を Microsoft が作り、自社は DNS に CNAME を2本入れて、その公開鍵を指すだけです。手順は Microsoft 365 側と DNS 側を行き来します（DKIM の設定）。

Defender ポータルで DKIM の画面を開く

Microsoft Defender ポータル（security.microsoft.com）の左のメニューで［メールとコラボレーション］>［ポリシーとルール］を開き、［脅威ポリシー］から［メールの認証の設定］を選んで、［DKIM］のタブを開きます。直接 https://security.microsoft.com/authentication を開いても同じ画面です。Learn の日本語版では、このページが「メール認証設定」「Email認証設定」など、切り替えが「トグル」と訳されていますが、画面の表示は「メールの認証の設定」と「切り替え」でした。この画面のタブは ARC と DKIM の2つで、DMARC のタブはありません。DMARC は手順3で DNS に作ります。

一覧には、Microsoft 365 に追加済みのドメインが並びます。当社の検証用の環境で onmicrosoft.com のドメインの行を見ると、「既定の署名ドメイン」と出ていて、状態は「NoDKIMKeys」、切り替えは「無効」でした。これは、送るメールに署名が無いという意味ではありません。Learn は、最初の onmicrosoft.com のドメインから送るメールは自動で DKIM 署名されるとし、この画面で手動で設定する前の状態を「切り替えが無効、状態が NoDKIMKeys」としています。onmicrosoft.com のドメインの行は、一覧の表示と、送るメールの署名の有無を分けて読みます。独自ドメインの行で同じ表示なら、そのドメインではまだ署名されていません。

CNAME の値を受け取り、DNS に入れて、署名を有効にする

独自ドメインの行で、次の順に進めます。キーを作って署名を有効にする操作は設定を変えるため画面の写真は無く、公式の手順で書いています。

1. 独自ドメインの行の切り替えを「有効」に動かします。CNAME がまだ無いので、エラーのダイアログが開きます。ダイアログに CNAME の値が出ますが、［OK］で閉じて先に進みます。状態は「CnameMissing」に変わり、切り替えは無効のままです。
2. ドメインの行（チェックボックスと切り替え以外）を開き、詳細パネルの「CNAME の発行」にある2本の値を控えるか、［コピー］で写します。パネルは開いたままにします。
3. 別のタブで DNS の事業者の画面を開き、CNAME を2本作ります。ホスト名は selector1._domainkey と selector2._domainkey、値は控えたものです。
4. しばらく待ちます。Microsoft 365 が新しい CNAME を見つけるまで、「数分 (または場合によってはそれ以上)」かかります。
5. 開いたままの詳細パネルに戻り、「DKIM 署名を使用してこのドメインのメッセージに署名する」の切り替えを入れます。数秒後に「状態の変更を同期するには数分かかる場合があります。」というダイアログが開くので、［OK］で閉じます。CNAME が見つかっていれば、状態が「このドメインに対して DKIM 署名を付与しています」（Learn の訳）に変わります。

CNAME の値は、ドメインごとに違います。値を手で組み立てず、Defender ポータルか Exchange Online PowerShell に出る値をそのまま使います。形は次の2通りです。2025年5月から、新しく追加する独自ドメインには新しい形が使われ、既存のドメインは古い形のままです。同じセレクターに2つの形を混ぜることはできません。2025年5月より前の形（…onmicrosoft.com で終わる値）を例にした解説記事の値は、新しく追加したドメインの画面に出る値と形が違います。

ホスト名：selector1._domainkey
値（新しい形の例）：selector1-example-co-jp._domainkey.example.n-v1.dkim.mail.microsoft
値（古い形の例）　：selector1-example-co-jp._domainkey.example.onmicrosoft.com

値のうち「example-co-jp」は独自ドメインのピリオドをハイフンにしたもの、「example」は onmicrosoft.com のドメインの前の部分、新しい形の「n」は Microsoft が割り当てる1文字です（上の値は架空です）。selector2 も同じ形です。PowerShell で確かめるなら、Exchange Online PowerShell で次のコマンドを実行し、Selector1CNAME と Selector2CNAME の値を見ます。

Get-DkimSigningConfig -Identity example.co.jp | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

切り替えが入らず CnameMissing のままなら、DNS の入力を見直します。CnameMissing のまま残るときによくある入力の誤りには、ホスト名にドメイン名まで入っている（DNS の事業者によっては selector1._domainkey.example.co.jp.example.co.jp のように二重になる）、CNAME ではなく TXT で入れた、値（ターゲット）の形が正しくない（ピリオドとハイフンの置き換えなど）、などがあります。なお、selector2 を入れ忘れた場合は、署名は有効になっても後で鍵の切り替えに失敗します。

PowerShell の New-DkimSigningConfig で DKIM の設定を作る場合、鍵の長さの既定は1024ビットで、作るときか、Rotate-DkimSigningConfig で鍵を替えるときに2048ビットを選べます。鍵を替えると、新しい鍵で署名が始まるまで4日（96時間）かかります。

手順3：DMARC を p=none で公開し、段階的に強める

DMARC は、SPF か DKIM のどちらかが「差出人（From）に見えているドメインとそろって」通ったかを受信側が確かめ、通らなかったメールをどう扱ってほしいかを伝える仕組みです。DMARC の前に、送信に使うすべての独自ドメインとサブドメインで SPF と DKIM を済ませておきます（DMARC の設定）。

DNS の事業者の画面で、ホスト名 _dmarc、種類 TXT のレコードを作ります。最初の値は次の形です。

ホスト名：_dmarc
値：v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.jp

• p=none：DMARC に失敗したメールについて、受信側に何も求めません。DMARC のポリシーを試して調整するための値で、公開しただけでは、なりすましは止まりません。
• rua=mailto:：集計レポートの宛先です。レポートを送る受信側のメールサービスから、通常1日に1回、前日の結果がまとめて届きます。宛先は個人のメールボックスにせず、共有メールボックス（例：dmarc-reports@example.co.jp）を作ります。
• ruf=mailto:（失敗レポート）は、最初は付けません。rua だけで始めます。なお、Microsoft 365 自身は失敗レポートを送りません。

onmicrosoft.com のドメインの DMARC は、DNS の事業者ではなく Microsoft 365 管理センターで作ります。［設定］>［ドメイン］で onmicrosoft.com のドメインを開き、［DNS レコード］のタブの［レコードの追加］から、TXT 名に _dmarc、TXT 値に DMARC の値を入れます。値の例は v=DMARC1; p=reject です。onmicrosoft.com のドメインからメールを送っていなくても、このレコードは追加します。

p=none から quarantine、reject へ上げる時期を決める

強める順番は次のとおりです。メールの少ないサブドメインから始め、親のドメイン（example.co.jp）は最後にします。

1. p=none でレポートを見ます。知らない送信元から大量に失敗しているならなりすましの可能性、知っている送信元が失敗しているなら設定漏れの可能性があります。漏れていた送信元は、SPF に足すか、その送信元で example.co.jp の DKIM 署名を設定します。
2. p=quarantine（受け取るが迷惑メール扱いなどにしてよい）に上げます。pct= で一部のメールだけに当てることもでき、Learn は 10・25・50・75・100 と上げる例を示しています。pct= を書かなければ100です。
3. p=reject（拒否してよい）に上げます。

それぞれの段階にどれだけ置くかを、Learn は日数では示していません（「十分に監視した後」）。そのため、段階を上げる目安は日数ではなく、レポートで知っている送信元の失敗が残っていないかで決めます。レポートは、始めたばかりの間は毎週、落ち着いたら月1回見ます。すべての受信側がレポートを送るわけではないので、レポートに出ない送信元が残ることもあります。

強める前に知っておくことが一つあります。DMARC を p=quarantine か p=reject にしたドメインでは、Microsoft 365 から送ったメールが受信側の DMARC の確認で失敗すると、そのメールは「高リスク配信プール」（質の低いメールを送るために分けてある、送信用の IP アドレスの集まり）を通って送られます。この動作は上書きできません。このプールからのメールは受け取らない受信側も多いとされ、届く保証はありません（アウトバウンド配信プール）。Microsoft 365 から送っているのに DMARC に失敗するメールが残っている状態で強めると、そのメールは届きにくくなります。

サブドメインは、自分の DMARC を持たなければ親のドメインの設定を受け継ぎます。親を reject にすると、DMARC を持たないサブドメインから送るメールにも同じ扱いが求められます。

設定が効いたかを、ヘッダー・画面・レポートで確かめる

DNS に入れたら、社外のメールアドレス（Gmail や Outlook.com の個人のアドレスなど）に1通送り、受け取った側でメッセージのヘッダーを開きます。同じ組織の宛先に送ると DKIM の署名が省かれ、dkim=none (message not signed) と出ます。これは失敗ではありません。

Authentication-Results の欄で spf=pass、dkim=pass、dmarc=pass がそろい、DKIM-Signature の d= が example.co.jp になっていれば、3つとも効いています。Microsoft 365 で受け取った側のヘッダーなら、dmarc=pass action=none header.from=example.co.jp のような形で出ます（メッセージ ヘッダー）。pass にならないときは、下の表で原因の見当を付けます（電子メール認証のトラブルシューティングの表から抜き出し）。

あわせて、Defender ポータルの DKIM の一覧で、独自ドメインの切り替えが有効になり、状態が CnameMissing でないことを見ます。DMARC を公開すると、早ければ翌日から rua の宛先にレポートが届き始めます（レポートを送らない受信側もあります）。レポートの XML の読み方はDMARC レポートの読み方の記事に書いています。

3つとも pass なのに迷惑メールに入るときは

SPF・DKIM・DMARC がそろって pass でも、迷惑メールに入らないとは言えません。受信側は、メールの内容、送り手の評判、受け取る人の設定なども見ています。SPF は pass なのに迷惑メールと判定される例もあります（電子メール認証のトラブルシューティング）。それでも届かないときの見方は入門の記事の「すべて pass でもスパム判定される原因」に、受け取る側の Outlook と Microsoft 365 で許可リストを使う方法はOutlook の迷惑メールと許可リストの記事に書いています。

Gmail 宛てに多く送る会社は、Google の送信者のガイドラインも見ておきます。Google は、Gmail に送るすべての送信者に SPF か DKIM を、1日に5,000件を超えて送る送信者には SPF・DKIM・DMARC のすべてを求めていて、後者の DMARC は p=none でもよいとしています（Google の「メール送信者のガイドライン」）。SPF・DKIM・DMARC の要件は、この記事の3つの手順で設定するものです。PTR レコード、TLS の接続、迷惑メール率など、認証以外の要件もあります。

この記事の確かめ方

画面の名前と表示は、当社の検証用の環境の Microsoft Defender ポータルと Microsoft 365 管理センターで2026年10月28日に開いて確かめました。画面は開いて表示を確かめるところまでで、DKIM キーの作成や DNS レコードの保存はしていません。写真のドメイン名は伏せています。値の形と手順は Learn の日本語版で、Gmail の要件は Google の管理者ヘルプで、2026年10月28日に確かめました。Defender ポータルの画面と DKIM の値の形は変わることがあるため、設定の前に各ページの最新を確かめてください。

次にやること：DKIM の一覧で自社のドメインの状態を見る

まず Defender ポータルの［メールの認証の設定］で DKIM のタブを開き、自社の独自ドメインの状態と切り替えを見てください。NoDKIMKeys・無効なら、手順2から始めます。同時に、DNS の事業者の画面で example.co.jp の TXT に v=spf1 が何本あるかと、_dmarc があるかを見ます。送信元の一覧が作れたら、DKIM、DMARC の p=none の順に進めます。これから Microsoft 365 にメールを移す場合、ドメインの追加と、MX・SPF を切り替える日までの流れはMicrosoft 365 導入の手順の記事に書いています。

送信元の洗い出しや DMARC を強める時期の判断から一緒に進めたい場合は、Microsoft 365 の導入支援でお手伝いしています。