灯台下暗し。Microsoft 365 のカスタムドメイン設定で DMARC / DKIM を設定し忘れていた話

はじめに

以前に Microsoft 365 テナントに カスタムドメインを割り当てる方法の記事を投稿していました。

この記事に設定漏れが発覚したため、追加で必要な設定について共有したいと思います。

本記事の全体像

以前に投稿していた記事とは？

以下の2つの記事が該当しており、どちらも 最終章「Microsoft 365 サービス のための DNS 設定を行う」が該当しています。

カスタムドメインの状態ステータスが 正常 (グリーン) になっていたため、必要な設定はすべて完了しているものと思い込んでいました。しかし、後から確認すると DMARC および DKIM の設定が漏れていたことが分かりました。

App Service ドメインを使って Microsoft Entra テナントに カスタムドメインを構成する
https://qiita.com/carol0226/items/5e01ea76a2581c6810b4#6-microsoft-365-サービス-のための-dns-設定を行う

無料サービス (MyDNS) を使って Microsoft Entra テナントに カスタムドメイン を構成する
https://qiita.com/carol0226/items/cbbe32006d26080847f7#7-microsoft-365-サービス-のための-dns-設定を行う

漏れていた設定とは？

DMARC と DKIM という設定です。

以下のサイトで確認をすることができます。
https://dmarcian.com/

（上記より抜粋）

• DMARC
  お客様のドメインにはDMARCレコードが設定されていません。フィッシング詐欺やスパム送信者による悪用リスクに晒されています。
  　
• DKIM
  一般的なメール送信元に関連付けられるDKIMレコードが見つかりませんでした。特定のセレクターがわかっている場合は、対象を絞った検索が可能です。

DMARC や DKIM が構成されていない場合、単に診断サイトで警告が表示されるだけではありません。

第三者が自分のドメインを詐称した「なりすましメール」を送信しやすくなり、フィッシングメールやスパムメールに悪用されるリスクが高まります。

また、影響を受けるのは受信者側だけではありません。自分のドメインから送信した正規のメールであっても、受信側のメールシステムが送信ドメインの信頼性を十分に評価できないため、迷惑メールとして判定される可能性が高まったり、メールサーバーのポリシーによっては受信を拒否されたりする可能性があります。

近年では Microsoft 365 や Google Workspace をはじめとする主要なメールサービスが、SPF・DKIM・DMARC を利用した送信ドメイン認証を重視しています。そのため、これらの設定が不足しているとメールの到達性 (Deliverability) に影響を与える場合があります。

つまり、DMARC や DKIM は「なりすましメール対策」のためだけの設定ではなく、「自分が送信した正規のメールを確実に届けるため」の設定でもあるということです。

Microsoft 365 では、カスタムドメインの追加や Exchange Online の利用が可能になった時点でメールの送受信自体は行えます。しかし、それだけでは SPF・DKIM・DMARC を利用した現代的なメール認証の構成としては不十分であり、なりすまし対策やメール到達性の観点では改善の余地が残ります。

これは早めに対応することをおすすめします。

実際にメールの送受信ができていたため私自身も気付いていませんでしたが、DMARC および DKIM が未構成のまま運用していたことになります。

まさに「灯台下暗し」でした。

Microsoft 365 における DMARC / DKIM の設定とは？

以下の公開情報で DMARC と DKIM の設定ページへのリンクが説明されています。
ここが設定の起点となります。

公開情報：適切な DNS レコードを追加することで、メール スパム (Outlook、Exchange Online) を防ぐのに役立ちます
https://learn.microsoft.com/ja-jp/microsoft-365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider?wt.mc_id=MVP_407731&tabs=domain-connect#help-prevent-email-spam-outlook-exchange-online-by-adding-appropriate-dns-records
（上記より抜粋）

DKIM の設定について

上記の赤枠のリンクが以下の URL となっています。
本章では、この URL で解説されている手順を実施しています。

公開情報：クラウド ドメインからメールに署名するように DKIM を設定する
https://learn.microsoft.com/ja-jp/defender-office-365/email-authentication-dkim-configure?wt.mc_id=MVP_407731

公開情報：Defender ポータルを使用して、カスタム ドメインを使用して送信メッセージの DKIM 署名を有効にする
https://learn.microsoft.com/ja-jp/defender-office-365/email-authentication-dkim-configure?wt.mc_id=MVP_407731#use-the-defender-portal-to-enable-dkim-signing-of-outbound-messages-using-a-custom-domain

DKIM の設定手順

1．以下の URL を開きます。
https://security.microsoft.com/authentication?viewid=DKIM

2．DKIM タブの カスタムドメイン の行で、トグル の値を 無効 から 有効 にスライドしてみてください。

3．すると、以下の画面が表示されますが、OK を押して閉じます。

4．行内の任意の場所をクリックして、ドメインの詳細ポップアップを開きます。

5．開いたドメインの詳細ポップアップで、次の手順を実行します。

• [最後にチェックされた日付] の値をメモします。
• CNAME の発行 セクションで必要な CNAME レコード値をメモするか、コピー を選択します。 これらの値は、次の手順で使用します。

そして、ドメインの詳細ポップアップは開いたままにします。

6．別のブラウザー タブまたはウィンドウで、ドメインのドメイン レジストラーに移動し、前の手順の情報を使用して 2 つの CNAME レコードを作成します。
※下図は、Azure パブリック DNS を使って カスタムドメイン を構成していた場合です。
① ドメイン名を開きます。

② ＋追加 を押します。

③ selector1._domainkey の CNAME レコードを追加します。

④ selector2._domainkey の CNAME レコードを追加します。

⑤ 追加が完了すると、以下のようになっています。

7．Microsoft 365 側が DNSで作成した新しい CNAME レコードを検出するには、数分 (または場合によってはそれ以上) かかります。

8．しばらくしてから、手順 5 で開いたままにしたドメインの詳細ポップアップに戻り、このドメインのメッセージに DKIM 署名を追加します トグルを選択します。すると、以下のウィンドウが表示されます。

9．以下のステータスになっていれば OK です。

DKIM の確認手順

以下の公開情報に DKIM の確認手順が記載されています。

公開情報：Microsoft 365 からの送信メールの DKIM 署名を確認する
https://learn.microsoft.com/ja-jp/defender-office-365/email-authentication-dkim-configure?wt.mc_id=MVP_407731#verify-dkim-signing-of-outbound-mail-from-microsoft-365
（上記より抜粋）
以下で説明されている方法が簡単でした。

上記の赤枠のボタンを押すと、以下の表示になります。ドメイン名を入力して テストの実行 を押します。

以下の通り、「DKIM 署名構成が正常に作成され、有効になりました。」と表示されれば OK です。

さらに、冒頭で紹介した https://dmarcian.com を使うことでも確認できます。
DKIM が グリーンになれば OK です。

なお、この段階では DMARC は、イエローステータスのままです。

DKIM キーのローテーションについて

以下の公開情報では、「パスワードを定期的に変更する必要があるのと同じ理由で、DKIM 署名に使用される DKIM キーを定期的に変更する必要があります」と説明されています。

公開情報：Defender ポータルを使用してカスタム ドメインの DKIM キーをローテーションする
https://learn.microsoft.com/ja-jp/defender-office-365/email-authentication-dkim-configure?wt.mc_id=MVP_407731#use-the-defender-portal-to-rotate-dkim-keys-for-a-custom-domain

なお、Microsoft Learn では DKIM キーのローテーション手順は説明されていますが、実施頻度についての明確な推奨値は記載されていません。

そのため、実際の運用では組織のセキュリティポリシーに従って実施することになります。本記事のような検証テナントでは頻繁なローテーションは必須ではありませんが、本番環境では定期的な実施を検討するとよいでしょう。

環境	一般的な目安
個人利用・検証テナント	基本的に不要（設定確認時のみ）
小規模組織	年1回～半年に1回
一般的な企業	半年に1回
高セキュリティ環境	3か月～半年に1回
キー漏洩の疑いがある場合	即時実施

※上記は一般的な運用例としての目安であり、Microsoft が公式に推奨している頻度ではありません。

DKIM キーのローテーション手順

1．DKIM キーのローテーション のボタンを押します。

2．以下の画面の状態になったら OK です。右上の × を押して閉じます。

4 日後 (96 時間) に、新しい DKIM キーによってカスタムドメインの送信メッセージが署名されます。 それまでは、現在の DKIM キーが使用されます。

DMARC の設定について

本章では、以下の URL で解説されている手順を実施していきます。

公開情報：クラウド送信者の差出人アドレス ドメインを検証するように DMARC を設定する
https://learn.microsoft.com/ja-jp/defender-office-365/email-authentication-dmarc-configure?wt.mc_id=MVP_407731

公開情報：Microsoft 365 でアクティブなカスタム ドメインの DMARC を設定する
https://learn.microsoft.com/ja-jp/defender-office-365/email-authentication-dmarc-configure?wt.mc_id=MVP_407731#set-up-dmarc-for-active-custom-domains-in-microsoft-365

DMARC が評価する内容について
DMARC は単独でメールを認証する仕組みではありません。
実際には、SPF および DKIM の認証結果を利用して差出人ドメインの正当性を評価します。

DMARC の評価では、「SPF の認証が成功する」または「DKIM の認証が成功する」のいずれかを満たしている必要があります（正確にはドメインアラインメントも考慮されます）。

そのため、DMARC レコードを作成しただけでは十分ではなく、DMARC が正しく機能するためには SPF または DKIM が正しく構成されていることが重要です。

DMARC の設定手順

※下図は、Azure パブリック DNS を使って カスタムドメイン を構成していた場合です。
① ドメイン名を開きます。

② ＋追加 を押します。

③ 以下の情報を記載して 追加 を押します。

④ 以下のように追加されれば OK です。

DMARC の確認手順

冒頭で紹介した https://dmarcian.com を使うことで確認できます。
ひとまず、ここでは ステータスが イエローに変わっていれば OK です。

DMARC ポリシー (none / quarantine / reject) について

DMARC には、認証に失敗したメールをどのように扱うかを指定する ポリシー (p) が用意されています。

ポリシー	動作
none	監視のみ。メールは拒否せず、認証結果の確認を行う
quarantine	認証に失敗したメールを隔離 (Quarantine) するよう受信側へ推奨する
reject	認証に失敗したメールを拒否するよう受信側へ推奨する

本記事では、まず以下の設定で DMARC が正しく動作することを確認しました。

v=DMARC1; p=none;

これは DMARC の動作確認を目的としたサンプル設定です。検証テナントにおいて SPF および DKIM の設定が完了していることを確認できたため、最終的には p=reject まで変更して確認しています。

この設定では DMARC による検査結果を確認できますが、認証に失敗したメールであっても受信側で拒否されることはありません。

DMARC は本来、なりすましメール対策を目的とした仕組みであり、最終的には reject を適用することで高い保護効果を得ることができます。

本番環境では、業務で利用しているメールシステムや外部サービスからのメールが SPF や DKIM を正しく構成できていない場合、正規のメールまで拒否されてしまう可能性があります。そのため、多くの組織では以下のように段階的に導入します。

Step 1 : p=none
         ↓
Step 2 : p=quarantine
         ↓
Step 3 : p=reject

つまり、Step を段階的に進める際に、正規のメールが拒否されたり隔離されたりするような事象が発生した場合には、送信元となっているシステムやサービスを特定し、SPF や DKIM の設定が正しく構成されるように対応する必要があります。

例えば、問い合わせフォーム、複合機、業務システム、SaaS 製品、外部のメール配信サービスなどが送信元となっているケースでは、DMARC の強化に伴いメール配送へ影響が発生する可能性があります。

特に、取引先と連携して利用しているメールサービスや、各種クラウドサービスから送信される通知メールなどは見落とされやすいため注意が必要です。

一方で、本記事のような検証テナントや個人利用の環境では、メールフローを十分に把握できているケースも少なくありません。そのような環境であれば、p=none で動作確認を行った後に、比較的早い段階で p=reject へ移行してしまっても問題ないでしょう。

本記事では動作確認を目的として p=reject までを設定した結果を掲載しています。本番環境ではメール配送への影響を確認しながら段階的な移行を推奨します。一方、検証テナントや個人利用の環境では影響範囲を把握しやすいため、早期に p=reject を適用することも選択肢の一つです。

p=quarantine を構成した場合です。

ステータスはイエローのままですが、記載内容に変更が確認できます。

p=reject を構成した場合です。

dmarcian の評価上は、以下のようにオールグリーンになりました。

なお、dmarcian の評価は参考情報であり、必ずしもオールグリーンでなければ運用できないという意味ではありません。

まとめ

以前に公開した Microsoft 365 テナントへのカスタムドメイン構成手順を見直したところ、DMARC および DKIM の設定が漏れていることに気付きました。

カスタムドメインの追加や Microsoft 365 の基本的な DNS レコード (MX、TXT、CNAME など) を構成しただけでは、メール認証に関する設定は十分ではありません。特に DKIM および DMARC が未構成の場合、なりすましメール対策という観点では改善の余地が残ります。

今回あらためて確認した結果、Microsoft Learn にも記載があるとおり、DMARC は SPF または DKIM の認証結果を利用して評価を行うため、実運用では以下の 3 つを組み合わせて構成することが重要であることを再認識しました。

• SPF
• DKIM
• DMARC

また、DMARC については単にレコードを作成するだけでなく、none、quarantine、reject の違いを理解した上で運用することも重要です。本番環境ではメール配送への影響を確認しながら段階的にポリシーを強化し、最終的には reject を目指すことが推奨されます。

一方で、検証テナントや個人利用の環境では影響範囲を把握しやすいため、SPF と DKIM の設定が正しく完了していることを確認した上で、比較的早い段階で p=reject を適用することも選択肢の一つです。

私自身、Microsoft 365 のカスタムドメインを構成してからしばらく経過してから今回の設定漏れに気付きました。「カスタムドメインの追加が完了したから終わり」ではなく、一度 DMARC や DKIM の設定状況も確認してみることをおすすめします。

今回の記事が、過去に Microsoft 365 のカスタムドメインを構成された方の見直しのきっかけになれば幸いです。

もし私と同じようにカスタムドメインの状態が「正常」と表示されているだけで安心していた方は、この機会にぜひ確認してみてください。まさに「灯台下暗し」でした。

参考 (2026/9/4 追加)