## この記事でわかること

- Microsoft 365 でも、SPFとDKIMの設定はDNS側で自社が責任を持つ必要があること
- SPFレコード追加と、DKIMの2本のCNAME登録・有効化までの具体的な手順
- 設定後に `spf=pass` / `dkim=pass` を確認する方法と、つまずきやすい3つのポイント

「Microsoft 365 を使っていれば、メールの認証はマイクロソフトに任せていれば大丈夫」と思って導入したまま、実は自社のDNSにSPFもDKIMも何も置かれていなかった、という相談を月に何件かいただきます。Microsoft 365（旧 Office 365）の場合、**Exchange Online のサーバーはマイクロソフトが用意してくれますが、SPFとDKIMの公開情報を載せるDNSは自社の管理範囲**です。ここを通さないと、Gmail や他社の受信側で「認証されていない送信者」と判定され、迷惑メール扱いや配信拒否になります。

本記事では、SPFレコードの追加、DKIM の2つのCNAME登録、Defender管理ポータルでの有効化、そして動作確認までを順に整理します。SPF・DKIM・DMARCの違いから押さえたい方は、先に[SPF・DKIM・DMARCの違いをわかりやすく解説](/blog/spf-dkim-dmarc-difference)をご一読ください。

## なぜ Microsoft 365 にも自前のSPF・DKIM設定が必要なのか

Microsoft 365 を使うと、メールの送受信そのものは Exchange Online が処理します。受信者から見た送信元IPはマイクロソフトのサーバーです。それでも、認証のための情報は次の2点を**自社のDNSに公開する**必要があります。

![Microsoft 365 のメール認証で「自社が持つ責任範囲」](/blog/microsoft-365-email-auth/responsibility-split.svg)

- **SPF**: 「`spf.protection.outlook.com` から届くメールは正規」と自社ドメインのTXTレコードで宣言する
- **DKIM**: マイクロソフトが署名する公開鍵情報を、`selector1._domainkey` と `selector2._domainkey` のCNAMEレコードとして自社のDNSに置く

DKIMだけCNAMEで参照する形になっているのは、マイクロソフトが鍵のローテーション（差し替え）を自動で行うためです。CNAMEを置いておけば、参照先の公開鍵が更新されてもDNSの設定変更は不要になります。Google Workspace のようにTXTレコードで公開鍵そのものを置く方式（[Google WorkspaceのDKIM設定手順を解説](/blog/google-workspace-dkim-setup) 参照）とは少し設計思想が違うので、ここで混乱する管理者の方が多い印象です。

なお、SPFとDKIMが揃っていないと、Gmail の送信者ガイドライン（2024年2月から強化された送信者要件）を満たせず、`5.7.26` 系のエラーで配信拒否になることがあります。詳しくは[Gmailエラー5.7.26の対処法](/blog/gmail-550-5726-fix)で解説しています。

## 設定手順｜SPFとDKIMをDNSで揃える

ここから具体的な手順に入ります。SPFはTXTを1本追加、DKIMはCNAMEを2本追加した上で管理ポータルで有効化、という順序で進めます。

### SPFレコードを追加する

Microsoft 365 のSPFは、レジストラ（または DNS ホスティングサービス）の管理画面でTXTレコードを1本追加するだけで終わります。Exchange Online だけを送信メール経路として使う場合、追加するレコードは次の1行です。

```
タイプ: TXT
ホスト名: @  （ルートドメイン。書き方は管理画面に合わせて）
値:     v=spf1 include:spf.protection.outlook.com -all
```

`include:spf.protection.outlook.com` の部分が「Exchange Online のサーバーは正規」を意味し、末尾の `-all`（ハードフェイル）で「ここに書かれていない送信元はすべて拒否」を宣言します。マイクロソフトの公式ドキュメントも `-all` を推奨しています（DKIM・DMARCを併用することが前提）。

レンタルサーバーや別のメール配信サービスを併用している場合、**SPFレコードは1つのドメインにつき1本まで**というRFC 7208 の制約があるため、既存のレコードに `include:` を追記する形で1本にまとめます。

```
v=spf1 include:spf.protection.outlook.com include:_spf.example-mail-service.com -all
```

SPF の DNS lookup を要するメカニズム（include / a / mx / exists / redirect など）の合計が 10 個を超えると、SPF 評価が Permerror になります（RFC 7208 §4.6.4）。詳しくは [SPF レコードの設定方法と書き方](/blog/spf-setup-guide)で扱っています。

### DKIMはCNAMEを2本DNSに置いて有効化する

DKIMは「CNAMEを2本DNSに置く」「Defender管理ポータルで有効化を押す」の2段階で完了します。Google Workspace と違って、自社で公開鍵を生成・コピーする必要はありません。

![Microsoft 365 DKIM 設定の3段階](/blog/microsoft-365-email-auth/dkim-setup-flow.svg)

#### CNAMEの値を取得する

正確なCNAMEターゲットの文字列はテナントごとに異なります。**必ず管理ポータルかPowerShellから取得した値をそのまま使ってください**。Webの解説記事の例をコピーすると、テナントIDや初期ドメインが一致せず動かないことがほとんどです。

**Defender管理ポータルから取得する場合**:

1. ブラウザで `https://security.microsoft.com/authentication` にアクセス
2. 左メニューが見当たらない場合は「メール&コラボレーション → ポリシー&ルール → 脅威ポリシー → メール認証設定」と進む
3. 「DKIM」タブで対象のカスタムドメインを選択
4. 表示されたフライアウトに「次のCNAMEレコードを発行する」と2本のホスト名・ターゲットが表示されるので控える

**PowerShell（Exchange Online Management）から取得する場合**:

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

`Selector1CNAME` と `Selector2CNAME` のフィールドに、登録すべきターゲットがそのまま表示されます。

#### DNS にCNAMEを2本登録する

レジストラの DNS 管理画面で次の2本を追加します。値はテナントごとに異なるため、ここでは形式の例を示します。

| 項目 | レコード1 | レコード2 |
|---|---|---|
| タイプ | CNAME | CNAME |
| ホスト名 | `selector1._domainkey` | `selector2._domainkey` |
| 値（ターゲット） | `selector1-example-co-jp._domainkey.<initial>.onmicrosoft.com` 形式、または新方式の `...n-v1.dkim.mail.microsoft` 形式 | `selector2-example-co-jp._domainkey.<initial>.onmicrosoft.com` 形式、または新方式の `...n-v1.dkim.mail.microsoft` 形式 |
| TTL | 既定値（3600 など） | 既定値 |

ホスト名のうち `example-co-jp` の部分は、自社ドメインのドット (.) をハイフン (-) に置き換えた形に**自動で変換された値**が入ります。マイクロソフトはテナント新設のタイミングで2025年5月以降に新しいCNAME形式（`dkim.mail.microsoft` を末尾に持つ形式）に切り替えており、古いテナントは `onmicrosoft.com` を末尾に持つ形式が引き続き有効です。**いずれの形式でも、管理ポータルが指示してきた値をそのまま貼るのが安全です**。

セレクタが2本ある理由は、マイクロソフトがDKIM鍵のローテーションを自動化するためです。鍵を入れ替えるとき、新しい鍵を片方のセレクタで先行公開し、署名の参照先を切り替える、という動作をします。CNAMEで参照しておけば、自社のDNSに手を加えなくても鍵の差し替えに追従できます。

#### 「DKIM署名を有効化」する

CNAMEがDNSに反映されたら、もう一度Defender管理ポータルのDKIM画面に戻ります。対象ドメインを選び、「**このドメインに対してメッセージにDKIM署名を行う**」のトグルを「有効」に切り替えます。マイクロソフト公式ドキュメントは、CNAMEを検出するまで**数分以上かかることがある**としており、有効化ボタンを押してすぐにエラーが出ても、しばらく待ってから再試行すれば通る場合がほとんどです。

PowerShellで有効化する場合は次のコマンドです。

```powershell
Set-DkimSigningConfig -Identity example.co.jp -Enabled $true
```

ここで「CNAMEレコードが見つかりません」と出る場合は、DNSの反映が間に合っていないか、ホスト名の指定（特に末尾にドメイン名を二重に書いていないか）を疑ってください。

## 動作確認とよくあるつまずき

設定が反映されているかは、必ず複数の経路で確認します。

![Microsoft 365 メール認証の動作確認パス](/blog/microsoft-365-email-auth/verification-paths.svg)

### 経路1｜`dig` でレコードが返るか

ターミナルから次のコマンドを実行します。

```
dig TXT example.co.jp +short
dig CNAME selector1._domainkey.example.co.jp +short
dig CNAME selector2._domainkey.example.co.jp +short
```

SPFのTXT値と、DKIMの2つのCNAMEターゲットが返ってくれば、DNS側は正しく公開できています。何も返ってこない、または別のレコードしか返ってこない場合は、ホスト名の指定ミスかDNS反映待ちが疑われます。

### 経路2｜Gmail の `Authentication-Results` ヘッダー

自社ドメインからGmail宛にテストメールを送り、受信メールの「メッセージのソースを表示」から `Authentication-Results` 行を確認します。次のように両方が `pass` になっていれば成功です。

```
Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.co.jp;
       dkim=pass header.i=@example.co.jp header.s=selector1
```

`header.s=selector1` または `selector2` の値が、DKIMの2つのセレクタのどちらかと一致していることを確認してください。詳しい読み解き方は[DKIM設定の確認方法](/blog/dkim-verification)に整理しています。

### 経路3｜PowerShell でステータスを確認

```powershell
Get-DkimSigningConfig -Identity example.co.jp | Format-List Name,Enabled,Status
```

`Enabled : True` と `Status : Valid` が並んでいれば、Microsoft 365 側はDKIM署名を実際に付け始めている状態です。`Status : CnameMissing` などのエラーが出た場合は、DNS側のCNAMEを `dig` で再確認します。

### つまずきポイント1｜CNAMEの末尾にドメイン名が二重になる

レジストラによっては、ホスト名にFQDNを書く画面と、サブドメイン部分だけを書く画面があります。後者の画面で `selector1._domainkey.example.co.jp` のようにフルで書くと、結果として `selector1._domainkey.example.co.jp.example.co.jp` になり、`dig` で何も返らなくなります。既存のSPFレコードと同じ書式に揃えるのが確実です。

### つまずきポイント2｜DKIM有効化を押し忘れる

CNAMEをDNSに置いただけでは、Microsoft 365 側はまだDKIM署名を行いません。**Defender管理ポータルの有効化トグル、またはPowerShellの `Set-DkimSigningConfig -Enabled $true` を必ず実行**してください。これを忘れると、DNS上は完璧でもメールに署名が付かず、`dkim=none` のままになります。

### つまずきポイント3｜複数ドメインを送信元にしている

Microsoft 365 に複数ドメインを登録して送信元として使っている場合、DKIMはドメインごとに個別の有効化が必要です。プライマリドメインだけ設定しても、子会社・別ブランド用のドメインから送ったメールには署名が付きません。送信に使っているすべてのドメインで `Get-DkimSigningConfig` の `Enabled : True` を確認してください。

## DMARC追加で完成形にする

SPFとDKIMが揃ったら、最後にDMARCを必ず追加します。Microsoft 365 にはDMARCを管理する管理ポータルもPowerShellコマンドもありません。**レジストラのDNS管理画面で、`_dmarc.<ドメイン>` の TXTレコードを直接追加します**。

```
タイプ: TXT
ホスト名: _dmarc
値:     v=DMARC1; p=none; rua=mailto:postmaster@example.co.jp; ruf=mailto:postmaster@example.co.jp
```

最初は必ず `p=none`（観察モード）から始め、レポートで自社の送信状況を確認してから `quarantine` → `reject` と段階的に強化します。Microsoft 365 に特化した DMARC の追加手順は[Microsoft 365 の DMARC 設定手順](/blog/microsoft-365-dmarc-setup)で、レコード配置から段階強化まで具体的に解説しています。レポートの読み方は[DMARCレポートの見方と集計](/blog/dmarc-report-reading)で解説しています。

DMARCを追加することで、SPFとDKIMの「アラインメント（送信ドメインとの一致）」が初めて受信側に評価されるようになり、なりすましメールを実効的に止められる状態になります。

## まずは自社のメール認証状況を確認しましょう

要点を整理します。

- Microsoft 365 のSPFは `v=spf1 include:spf.protection.outlook.com -all` を1本、自社のDNSにTXTで追加する
- DKIMはCNAMEを2本（`selector1._domainkey` / `selector2._domainkey`）DNSに置き、Defender管理ポータルかPowerShellで有効化する
- CNAMEターゲットの正確な文字列はテナントごとに違うため、必ず管理ポータルかPowerShellの出力をそのまま使う
- 設定後は `dig` / Gmailの `Authentication-Results` ヘッダー / PowerShell の3経路で確認し、SPFとDKIMの両方が `pass` になることを見届ける
- SPF・DKIMが揃ったら DMARC を `p=none` から段階的に強化する

[無料のドメイン診断ツール](/diagnose)に自社ドメインを入力すると、SPF・DKIM・DMARCの各レコードがDNSから見えているか、設定が抜けていないかをまとめて確認できます。「PowerShellの実行環境がない」「DNSの管理画面が手元にない」といった場合は、[お問い合わせフォーム](/contact)から状況をお知らせください。設定内容を整理し、必要な手順を専門家がわかりやすくご案内します。

SSL 証明書、Web セキュリティヘッダ、サブドメイン棚卸しの単発チェックも合わせて [無料ツール一覧](/tools) にまとめています。