Microsoft 365 / メール用DNSとSPF・DKIM・DMARCの確認方法

Microsoft 365 メールドメインでは、MX が受信サーバーを指定し、SPF・DKIM・DMARC が送信メールの認証と処理ポリシーに関与します。このレコードは互いに代替されません。ドメイン所有権確認を完了した後、実際の送信経路を調査し、Microsoft 365 と外部送信サービスの両方を反映する必要があります。

4 つのレコードの役割

Microsoftのメール認証の展開ガイドは、カスタムドメインにSPF、DKIM、DMARCを設定するよう案内します。DMARCはSPFやDKIMのいずれかが成功しただけで常に通過するわけではなく、表示された送信ドメインとの整合条件も確認します。

SPFはSender Policy Frameworkで、送信サーバの許可範囲を宣言する方式です。DKIMはDomainKeys Identified Mailで、メールに電子署名を付ける方式であり、DMARCはDomain-based Message Authentication, Reporting and Conformanceで、表示された送信ドメインと認証結果を照合し、失敗時の処理・報告ポリシーを伝える方式です。

SPFが確認するアドレスは、ユーザーが読むFromと異なるMAIL FROM（サーバ間送信に使うエンベロープ送信アドレス）の場合があります。DKIMの署名ドメインもサービス提供者のドメインである場合があります。したがって、CRMがサービス提供者自身のドメインでSPF・DKIMを通過しても、画面に表示した会社ドメインと整合していなければ、会社ドメインのDMARCを通過できない場合があります。整合されたSPFまたは整合されたDKIMのいずれか一方以上が通過する必要がある点が重要です。

設定前に送信経路を調査する

• 従業員がExchange Onlineから送るメール
• ウェブサイトのお問い合わせフォーム、CRM、マーケティングサービス、複合機など外部システムが送るメール
• サブドメインを別途使用する送信サービス
• メールセキュリティゲートウェイや中継サーバーを経由する経路

送信元を漏らすと、SPF・DKIM・DMARC強化後に正常なメールが拒否される可能性があります。使用しない送信元は削除し、必要なサービスは該当提供者の公式ガイドに従って認証します。

Microsoft 365で確認する順序

1. Microsoft 365管理センターの[設定] → [ドメイン]で対象ドメインを開きDNS設定状況を確認します。MX値は該当ドメインのウィザードに表示された値を使用します。

2. DNSホスティング業者で現在のSPF TXTレコードを確認します。Microsoft 365以外の送信元を含める場合は既存の値を統合して設計します。
3. Microsoft Defenderポータルのメール認証設定で該当カスタムドメインのDKIM状況と必要なDNSレコードを確認します。提示された値をDNSに追加した後、署名の有効化を確認します。

4. DMARCを段階的に導入します。レポートを通じて実際の送信元と認証失敗を分析した後、ポリシー強化を決定します。ポリシー文言だけを追加しレポートを読まないと、問題を発見することは困難です。
5. 組織外部のアドレスにテストメールを送信し、受信側のヘッダーでSPF・DKIM・DMARCの結果と整合性を確認します。DNSの状態が正常でも、実際の送信経路を試す必要があります。

SPFの例をそのまま使える条件

インターネットDNSを直接管理するカスタムドメインで、Microsoft 365だけを送信元として使用する場合には次のTXT値が基本例になります。ウェブサイトやマーケティングサービスが同じドメインから直接送信する場合は、この例だけで置き換えないでください。実際のウィザードや各送信サービスの公式設定と照らし合わせる必要があります。

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

includeはMicrosoft 365の送信範囲を参照し、-allはこれに合わない送信元をSPF失敗として処理するよう宣言します。同じ名前にSPF TXTを二つ作り、Microsoft 365と外部サービスを別々に入れる方法は間違った構成です。必要な送信元を一つのSPFポリシーで設計し、不要な送信元を整理してください。SPF以外の所有権確認TXTは目的が異なるため、削除対象ではありません。Microsoft SPF設定ガイドの送信シナリオを基準に選択します。

DKIMとDMARCを設定するときに選択する値

Defender ポータルの メールおよび共同作業 → ポリシーとルール → 脅威ポリシー → メール認証設定 → DKIMでカスタムドメインを開きます。必要に応じてキー生成の手順を進め、ドメイン詳細に表示される 二つの CNAME の名前とターゲットを DNS 事業者に入力します。セレクターとターゲット名は現在のテナントが提示する値をコピーし、以前のブログの文字列を組み合わせて作成しません。

DNS 反映後、ドメインの DKIM 署名トグルを有効にし、署名中かどうかを確認します。CNAME が欠落している場合は、入力名、実際の DNS 管理事業者および検出時刻を再確認してください。二つのレコードを保存しただけで署名がオンになったと判断しません。DKIM 公式設定手順で現在の状態別の進め方を確認できます。

DMARC の開始ポリシーは、正常送信元を分析可能なレポート中心の構成に設定できます。以下は example.comを説明用ドメインとして使用した例です。実際のドメインの _dmarc TXT に入れる値は、組織が受け取ることができるレポートアドレスに変更します。

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=noneは、DMARCの失敗自体について隔離・拒否を要求しない開始ポリシーであり、他のスパム・セキュリティフィルターまでは解除しません。ruaは集計レポートを受け取るアドレスです。該当アドレスで実際に受信・分析の準備ができている必要があり、外部のレポートサービスのアドレスを使用する場合は追加のDNS承認条件も確認する必要があります。正常な送信元の整合性と配信経路を確認したうえで、quarantine、rejectの段階で強化します。詳細な条件についてはDMARC導入ガイドラインに従います。

DNSの通過と実際のメール認証を合わせて確認する

社員メール、ウェブ問い合わせフォーム、CRMなどの送信経路ごとに外部テストアドレスへ新しいメールを送信します。受信側でメッセージの原本・インターネットヘッダーを開き、Authentication-ResultsのSPF・DKIM・DMARCの結果を確認し、DKIMの署名ドメインと表示Fromも照合します。「以前のメールは正常」よりも、変更後に新しく送ったメッセージの結果が必要です。

DNSは正常なのに特定のCRMだけ失敗する場合、その経路の送信ドメイン・署名設定から確認します。配信過程で署名された本文が変わったり、送信サーバーが異なると結果が変わることもあります。認証の通過は受信トレイへの配信を保証せず、評判・スパム・コンテンツポリシーも影響します。

レコードの値は、ドメインや設定時点によって異なります。この記事の目的は値を覚えることではなく、管理センターで示された値、DNSの実際の値、受信側の認証結果を比較することです。メールの受信または送信に問題が発生した場合は、変更前のDNSレコードを基準に影響範囲を把握してください。正常なメールに影響がある場合は、直前のポリシーと送信元構成を比較し、問題となった変更のみを復元して再テストします。原因が不明なままSPF・DKIM・DMARCレコードをすべて削除したり、強力なDMARCポリシーを維持し続けたりしません。レポートでは、正常な送信元の失敗と疑わしい偽装送信を区別して、後続の対応を決定してください。