Office 365 向け DMARC 設定ガイド (2026)

このステップバイステップガイドに従って、Office 365 の DMARC を設定してください。コンプライアンスに関する変更点、一般的なトラブルシューティング方法、そしてメールセキュリティにおいて Microsoft 365 だけでは不十分な理由について学びましょう。

マイクロソフトは、Office 365（Microsoft 365 または M365 とも呼ばれる）における DMARC の設定を推奨・支援しています。これにより、登録済みのすべてのドメインでメール認証プロトコルを統一的に導入することが可能になります。認証プロトコルの専門家として、本ブログでは、以下の条件を満たすメールを検証するために、Office 365 で DMARC を設定する手順について解説します：

• マイクロソフトのオンライン・Eメール・ルーティング・アドレス
• 管理センターに追加されたカスタムドメイン
• パークされている、またはアクティブではないが登録されているドメイン

このガイドを読んで、Microsoft 365 における DMARC の仕組み、設定手順、認証要件の変更方法、そして PowerDMARC などのツールが、段階的な適用を進める上でいかに必要不可欠であるかを理解してください。

簡単な回答

手短にまとめると、Microsoft 365 の DMARC 設定手順は以下の通りです：

1. SPFの設定：DNSに「v=spf1 include:spf.protection.outlook.com -all」を追加してください
2. DKIM を有効にするには、Microsoft 365 Defender → [メールとコラボレーション] → [ポリシーとルール] → [脅威ポリシー] → [DKIM] の順に移動し、ドメインを選択して [有効にする] をクリックします（2 つの CNAME レコードが必要です）。
3. DMARCを公開する：_dmarc.yourdomain.com に、v=DMARC1; p=none; rua=mailto:[email protected] で始まる TXT レコードを作成してください。
4. 2～4週間、レポートを監視した後、徐々に p=quarantine → p=reject へと移行する

より詳しい手順については、このブログを最後までお読みください。
注：この簡易手順は、すべての正規の Microsoft 365 およびサードパーティの送信元が正しく認証され、設定が整合している場合にのみ機能します。CRM、マーケティングオートメーションツール、ヘルプデスクシステム、請求ツールなどのプラットフォームを使用している場合は、適用に移行する前にそれらを特定してください。

DMARCとは何か、そしてMicrosoft 365にとってなぜ重要なのか

DMARC は、Domain-based Message Authentication, Reporting, and Conformance（ドメインベースのメッセージ認証、報告、および適合性）の略称です。これは、ドメインをなりすまし、フィッシング、および不正利用から保護するための電子メール認証プロトコルです。

DMARCは、SPFおよびDKIMを基盤として機能します。メッセージがSPFまたはDKIMの検証に合格しているか、また、合格したドメインが「From」フィールドに表示されているドメインと一致しているかを確認します。その後、認証に失敗したメッセージに対して、受信メールサーバーがどのように処理すべきかを指示します。

Microsoft 365 ユーザーにとって、DMARC が重要な理由は 2 つあります。

• これにより、攻撃者があなたのドメインをなりすますのを防ぐことができます。
• これにより、正当な送信メールに対する信頼性と配信率が向上します。

Exchange Online Protection は受信メールの DMARC を確認しますが、それだけでは自ドメインが他所でなりすまされるのを自動的に防ぐことはできません。送信時の身元を保護するには、ドメインの SPF、DKIM、および DMARC レコードを公開する必要があります。

より広範な導入に関する参考情報については、以下をご覧ください。 PowerDMARCのDMARCガイドを参照してください。

DMARC 2026：RFC 9989、9990、および9991の更新

2026年5月、DMARCは3つのIETF RFCを通じて更新されました：

RFC 9989 は RFC 7489 および RFC 9091 を廃止し、DMARC を「提案標準」のステータスに移行させます。ドメイン所有者にとって、実務上最も重要な変更点は、パブリックサフィックスリストに基づく組織ドメインの検出から、DNS ツリーウォークへの移行です。

既存のDMARCレコードは、依然として次のように始まります：

txt

v=DMARC1

つまり、ほとんどの Microsoft 365 管理者は すぐに DNSレコードを直ちに再構築する必要はありません。ただし、以下の点を確認してください：

• sp= サブドメインポリシーの動作
• どのような複雑な委任サブドメイン構造であっても
• Microsoft 365 またはサードパーティのプラットフォームを介してメールを送信するドメインおよびサブドメイン
• ロックダウンすべき、メール送信を行っておらず、非アクティブなドメイン

組織で複雑なドメイン階層構造を採用している場合は、メールを送信するすべてのドメインおよびサブドメインについて、明示的なDMARCレコードを公開してください。これにより、受信側が従来のDMARC処理からRFC 9989に準拠した動作に移行する際の曖昧さを軽減できます。

詳細については、PowerDMARCの DMARC RFC 9989、9990、および9991の更新をご参照ください。

Microsoft 365 は DMARC を自動的に処理してくれますか？

Microsoft 365 は受信メールに対して DMARC 検証を実行しますが、カスタムドメインに対する送信ドメイン保護は完全に設定されていません。

Exchange Online Protection は、組織が受信するメッセージの SPF、DKIM、および DMARC を自動的に評価します。これにより、なりすましされた受信メールからユーザーを保護することができます。

送信メールの場合、責任の所在は異なります。各送信ドメインについて、SPFを設定し、DKIMを有効にし、DNSにDMARCレコードを公開する必要があります。

この違いを理解する最も簡単な方法は、次の通りです。MicrosoftはMicrosoft 365の受信トレイを保護し、DMARCはより広範なメールエコシステム全体においてドメインの信頼性を保護します。

Microsoft 365 のネイティブコントロールだけに頼っている場合、次のような機能が不足している可能性があります：

• 人間が読みやすいDMARCレポート
• サードパーティの送信者に関する可視性
• p=none から強制適用への移行に関するガイダンス
• ドメインを横断した一元的な監視
• SPFルックアップ制限の管理
• ベンダーやDNSレコードの整合性が崩れた際にアラートを発行する

詳細な内訳については、以下をご覧ください。 Microsoft 365 ユーザーが依然として DMARC を必要とする理由。

前提条件：Microsoft 365 用の SPF および DKIM を設定する

DMARCレコードを公開する前に、ドメインに対してSPFとDKIMの両方が正しく設定されていることを確認してください。DMARCは単独ではメールの認証を行わず、SPFおよび/またはDKIMの結果に完全に依存しています。これらが欠落していたり、設定が一致していなかったりすると、DMARCは失敗し、強制適用が有効になった際に正当なメールに影響が出る可能性があります。

手順 1: Microsoft 365 の SPF を設定する

SPF（Sender Policy Framework）は、どのメールサーバーがあなたのドメインのメール送信を許可されているかを定義するものです。

Microsoft 365 専用のドメインの場合、標準的な SPF レコードは次のとおりです：

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

サードパーティの送信元を使用する場合は、それらを同じSPFレコードに含めてください：

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

重要： 1つのドメインにつき、SPF TXTレコードは1つしか存在できません。複数のSPFレコードが存在すると、SPF PermErrorが発生し、認証に失敗する可能性があります。

また、SPFにはDNSルックアップが10回という厳格な制限があります。これを超えるとSPF PermErrorが発生し、DMARCではこれを失敗と解釈します。複数のSaaSサービスを利用している場合は、 PowerSPFのマクロ対応ホステッドSPF を利用すれば、手動でDNSを編集することなく、常に制限値を下回った状態を維持できます。また、 現在のSPFレコードを確認する したり、こちらの SPFジェネレーター を無料でご利用いただけます。

手順 2: Microsoft 365 で DKIM を有効にする

DKIM（DomainKeys Identified Mail）は、メールに暗号署名を追加する仕組みです。これにより、受信サーバーは、メッセージが改ざんされておらず、実際にあなたのドメインから送信されたものであることを確認できます。

⚠️  Microsoft 365 の DKIM は、カスタムドメインの場合、デフォルトでは有効になっていません。管理センターで明示的に有効にする必要があります。

DKIMの手動設定：DNS ＋ 管理センター

1. Microsoft 365 Defender ポータルにアクセスする
2. 「メールとコラボレーション」→「ポリシーとルール」→「脅威対策ポリシー」→「メール認証設定」→「DKIM」の順に選択します。
3. ドメインを選択してください。

有効化する前に、Microsoft から 2 つの CNAME レコードを追加するよう求められます。

selector1._domainkey
selector1-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

selector2._domainkey
selector2-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

1. これらのCNAMEレコードを公開したら、Defenderポータルに戻り、DKIMの「有効にする」を切り替えてください。

有効化されると、Microsoftは送信されるすべてのメールにDKIM署名を付与し始めます。PowerDMARCの 無料のDKIMチェッカーを使用して設定を確認してください。

Office 365 で DMARC を設定する方法

SPF と DKIM の設定が完了したら、DMARC を公開できます。ほとんどのカスタムドメインの場合、Microsoft 365 の DMARC 設定は、Microsoft 365 管理センター内ではなく、DNS で行われます。

ステップ1：すべてのメール送信元を特定する

DMARCレコードを公開する前に、自社のドメインを名乗ってメールを送信している送信者を完全に把握しておく必要があります。正当な送信者を見落としてしまうと、適用が有効化された際に配信エラーが発生する可能性があります。

Microsoft 365 の一般的な送信元には、次のようなものがあります：

• Microsoft 365（Exchange Online）
• マーケティングプラットフォーム（Mailchimp、HubSpot、Klaviyo）
• CRMシステム（Salesforce、HubSpot CRM）
• サポートツール（Zendesk、Freshdesk、Intercom）
• 社内向けアプリケーションまたはオンプレミスのメールサーバー
• サードパーティ製のメールゲートウェイまたはセキュリティアプライアンス

多くのDMARC導入がここで失敗に終わります。ドメインは一見「Microsoft 365専用」のように見えるかもしれませんが、請求書、ニュースレター、パスワードのリセット通知、チケットの更新情報、人事関連の通知などは、Microsoft 365の外部から送信されることがよくあります。

どのシステムが自分の代わりにメールを送信しているか分からない場合は、まず p=none を指定し、DMARCの集計レポートを利用してそれらを特定してください。

ステップ2：DMARCレコードを作成する

DMARCレコードとは、DNSの _dmarc.yourdomain.comに公開されるTXTレコードです。PowerDMARCの DMARCレコードジェネレーター を使用すれば、数秒で有効かつエラーのないレコードを作成できます。

推奨される初期レコードは、次のようなものです：

v=DMARC1; p=none; rua=mailto:[email protected];

これを詳しく見てみると：

• v=DMARC1 — DMARCのバージョンを指定します
• p=none — 監視モード（強制なし、データ収集のみ）
• rua=mailto:… — 集計（RUA）レポートの送信先

ステップ3：DNSにDMARCレコードを登録する

ご利用のDNSホスティングプロバイダーで、以下のTXTレコードを追加してください：

注：公開後、レコードが全世界に反映されるまで、多少の時間（通常は数分から数時間）かかる場合があります。

公開後、DMARCチェッカーを使用してレコードを確認し、構文エラーがなく、レコードが正しく解決されていることを確認してください。

ステップ4：DMARCレポートの監視

p=none ポリシーで DMARC を有効にすると、 DMARC集計レポート（RUA） を受信サーバーから受け取るようになります。これらのレポートにより、どの送信者が貴社のドメインを使用してメールを送信しているか、どのメッセージが認証に合格または失敗したか、およびSPFとDKIMの整合状況が把握できます。

DMARCレポートは生のXML形式で届き、ツールなしでは解釈が困難です。 PowerDMARCのレポート解析ツールは は、それらを人間が読みやすいダッシュボードに変換するため、問題を特定し、安全に適用に向けて進めることができます。

 

ステップ5：段階的に実施に移す

すべての正当な送信者が適切に認証されていることを確認したら、DMARCポリシーを段階的に厳格化してください：

ステージ1 — 経過観察（p=なし）：

v=DMARC1; p=none; rua=mailto:[email protected]

ステージ2 — 隔離（不審なメールはスパムフォルダへ振り分けられます）：

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25; t=y

ステージ3 — 強制適用（認証されていないメールを拒否する）：

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

ヒント： 急いで拒否設定を行わないでください。導入期間中に正当なメールがブロックされてしまう最も一般的な原因は、時期尚早な強制適用です。

ステップ 6: ドメインの種類ごとに DMARC を設定する

設定するドメインによって、その手順は異なります。

ステップ 7: Microsoft 365 の DMARC 設定の検証と維持

DMARCの設定は一度行えば終わりというものではありません。メール環境の変化に合わせて、設定も適宜更新する必要があります。p=rejectに設定した後も、配信率とセキュリティを維持するためには、継続的な監視が不可欠です。

定期的に以下のことを行うべきです：

• DMARCレポートを確認する
• 新しい送信者を追加する際は、SPFを更新してください
• DKIMが有効な状態を維持し、設定が整合していることを確認してください
• 不正な活動を監視する

DMARCポリシーの導入：段階的な適用が重要な理由

DMARCの導入において、いきなり拒否ポリシーに移行してしまうことは、最もよくある間違いの一つです。メールの送信状況を把握せずに強制適用を行うと、正当な通信に支障をきたす恐れがあります。

段階的な導入を行うことで、厳格なポリシーを適用する前に問題を監視・修正することができます。多くの組織では、監視から隔離、そして最終的に拒否へと段階を踏んで進めています。各段階の期間は、メール環境の複雑さによって異なりますが、手順を省略すると、意図しない配信失敗のリスクが高まるだけです。

Exchange Online による受信 DMARC の処理方法

Exchange Online Protection は、すべての受信メッセージに対して DMARC を自動的に評価します。 2023年7月以降、Microsoft はデフォルトで送信者が公開したポリシーを順守しています。受信ドメインの MX レコードが Microsoft 365 を直接指している場合、p=reject ポリシーに対して DMARC 検証に失敗したメッセージはゲートウェイで拒否されます。同様に、p=quarantine ポリシーに違反したメッセージは隔離領域に送られます。これは「「メッセージがなりすましと検出された場合にDMARCレコードポリシーを順守する」という設定によって制御され、デフォルトで有効になっています。

この設定および関連するすべてのオプションの設定方法に関する詳細な手順については、PowerDMARCのガイド「 Office 365 フィッシング対策ポリシーを参照してください。

出典： マイクロソフト

「oreject」の挙動について

これ以前は、Microsoft は、送信者の p=reject ポリシーに違反した受信メッセージに対して、action=oreject（オリジン・リジェクト）と呼ばれる内部的なオーバーライドを適用していました。EOP は、ゲートウェイでメールを即座に拒否するのではなく、受信者の迷惑メールフォルダに転送し、ヘッダーに oreject アクションを付与していました。

マイクロソフトはこれを意図的に行った。転送されたメールやメーリングリストの通信は、転送中にSPFやDKIMの検証に失敗することが頻繁にあり、p=rejectで完全に拒否してしまうと、正当なメールも大量に削除されてしまう恐れがあった。迷惑メールフォルダへの振り分けは、その妥協案であった。これにより、受信者は必要に応じてメールを取り戻すことができ、技術的には送信者のポリシーも尊重されることとなった。

今日「oreject」が表示される場合

デフォルト設定が変更されたため、EOPでは現在、直接MXフローにおいて「p=reject」を真の拒否として扱うようになりました。しかし、以前の動作が完全に消えたわけではありません。以下の3つのシナリオでは、依然として「oreject」が表示されることがあります：

1. フィッシング対策ポリシーで「Honor DMARC」が無効になっています。Microsoft 365 Defender → メールとコラボレーション → 脅威対策ポリシー → フィッシング対策 → なりすまし設定 を確認してください。
2. メールは、Microsoft 365 に到達する前にサードパーティのゲートウェイ（Proofpoint、Mimecast）を経由します。Defender ポータルで、コネクタの「拡張フィルタリング」を有効にしてください。
3. テナントレベルの許可ルールによりフィルタリングがバイパスされています。許可リストに登録された送信者、信頼された受信コネクタ、またはSCL -1のルールは、DMARCの適用を完全にスキップします。

compauth と複合認証について

マイクロソフトは、「複合認証（compauth）」と呼ばれるシステムを通じて、DMARCの結果の上にレピュテーション信号を重ね合わせています。つまり、技術的には、メッセージが DMARCの検証に失敗しても、 。逆に、メッセージが DMARCに合格しても、compauthが失敗すれば迷惑メールとして処理される される可能性があります。M365でDMARCの配信問題をトラブルシューティングする際は、必ずAuthentication-Resultsヘッダーのreason=コードを確認してください。 compauthの失敗および複合認証 に関する詳細については、こちらの完全ガイドを参照してください。

輸送規則による輸入取り締まりの強化

DMARCに準拠していないメールを確実に拒否したい組織にとって、Exchange Onlineのトランスポートルールが最も信頼性の高い仕組みとなります：

1. 次の場所へ移動 Exchange 管理センター → メールの送信経路 → ルール → 新しいルールの作成
2. 条件の設定：メッセージヘッダーに以下のいずれかの単語が含まれていること。ヘッダー名：Authentication-Results。ヘッダー値：dmarc=fail action=oreject
3. アクションの設定：「メッセージはDMARC認証に失敗したため、組織のポリシーに基づき拒否されました」という説明を添えて、メッセージを拒否する

1. （任意）信頼できる社内の送信者や、正当な転送元として確認済みの送信者に対する例外を追加する
2. 最初の1週間は、ルールモードを「ポリシーなしでのテスト」または「ポリシーヒント付きテスト」（利用可能な場合）に設定し、適用モードに切り替える前に、メッセージトレースで一致したメッセージを確認してください。

このアプローチは、規制や社内ポリシーにより、配信に失敗したメールを確実に拒否することが求められる場合、組織がスプーフィングの標的となりやすい分野（金融、法務、経営陣間の通信など）に属する場合、あるいはダイレクトMXとサードパーティのゲートウェイを介した通信の流れにおいて一貫した動作を実現したい場合に利用してください。

マイクロソフトによる2025年5月のDMARC適用強化：変更点

2025年5月、マイクロソフトは、外部送信者からの認証されていない電子メールの取り扱い方法について、大幅な変更を導入しました。この変更は主に大量送信者に影響を及ぼしますが、すべての組織にとって広範な影響をもたらします。

メールボックスプロバイダーごとの適用状況の比較

マイクロソフトが導入した主な要件

• 大量送信者に対するDMARCの適用義務： Microsoftのコンシューマー向けサービスに対して1日あたり5,000通以上のメールを送信するドメインは、有効なDMARCレコードを設定する必要があります
• Microsoftの一般ユーザー向けメールボックス・エコシステムに適用されます： Outlook.com、Hotmail.com、および Live.com
• 最低要件： DMARCのp=none設定 — 監視ポリシーであっても許容されますが、DMARCレコードが全く存在しない状態は、大規模な環境ではもはや許容されません
• ドメインの一致を強く重視： 認証だけでは不十分であり、SPFおよびDKIMは、表示される「From」ドメインと一致していなければならない
• 準拠していない場合の完全拒否： 550 5.7.515 アクセス拒否。送信ドメインが要求される認証レベルを満たしていません

この変更により、マイクロソフトはアップルと同等の対応をとるようになった。 GoogleやYahooのメール認証要件に準拠することになりますに準拠することになり、これにより、主要なメールプロバイダーはいずれも、大量送信者に対する認証を義務付けることになった。詳細は MicrosoftのDMARC Outlook要件 を参照してください。

なぜMicrosoft 365だけでは不十分なのか

Microsoft 365 は強力な受信メール保護機能を提供していますが、DMARC を大規模に管理・監視する機能は限定的です。

人間が読み取れる形式のレポートがない

Microsoftは現在、 MXレコードがOffice 365を直接指している場合、 。しかし、これらの生のXMLファイルは、専用のツールなしでは解釈が困難です。適切な分析が行われない限り、組織は誰が自組織の名義でメールを送信しているのか、またそれらの送信元が適切に認証されているのかについて、可視性を得ることができません。

施行に関する指針なし

マイクロソフトは、監視から強制措置への移行に関する自動化されたガイダンスを提供していません。そのため、管理者は手動でデータを解釈し、メールの配信に影響を与える可能性のある判断を下さなければなりません。

継続的な管理には適していません

専用のDMARCソリューションは、単なる生データを分析可能な知見に変換するだけではありません。継続的な監視を可能にし、ポリシー管理を簡素化し、Microsoft 365では到底実現できない規模で、組織が安全に完全な適用に向けて前進できるよう支援します。

Office 365 における一般的な DMARC の問題のトラブルシューティング

また、以下のコミュニティに参加することもできます Microsoftの学習コミュニティ に参加して、Office 365 やその認証プロトコルの要件に関する最新情報を入手することもできます。

Microsoft 365 での DMARC の導入を進める

Microsoft 365におけるDMARCは、両面的な課題です。Exchange Online Protectionが受信メールの検証を自動的に行いますが、送信メールの保護については完全にユーザー自身の責任となります。 2025年5月の適用変更により、大量のメールを送信するすべての組織にとって、この責任は差し迫ったものとなっています。また、2026年5月に予定されているDMARCbisの公開は、メール業界がDMARCを恒久的かつ正式なインフラとして位置づけていることを示しています。

最も安全な方法は、時間はかかりますが効果的です。まず「p=none」を設定して公開し、2～4週間レポートを監視し、問題が見つかった送信者を修正してから、「p=quarantine」へ移行し、最終的には「p=reject」に移行します。これらの手順を省略すると、導入時に正当なビジネスメールの配信が妨げられてしまいます。

適用段階に達すると、作業は設定から監視へと移行します。新しい送信者が追加されたり、サードパーティベンダーがインフラを変更したりしますが、レポートを誰も監視していなければ、こうした変化によって知らぬ間に整合性が崩れてしまう可能性があります。現在のDMARCレコードを確認して現状を把握し、メールセキュリティを最優先事項としてください。

すべてのDMARCタグ、ポリシー、および実装オプションに関する完全なリファレンスについては、PowerDMARCの DMARCガイドをご参照ください。

よくあるご質問

Microsoft 365 では DMARC が自動的に設定されますか？

Microsoft は受信メールに対して DMARC の検証を行いますが、お客様のカスタムドメインについては DMARC の設定を行いません。送信メール用の DMARC TXT レコードは、お客様ご自身で手動で公開する必要があります。ドメイン保護を行うには、SPF、DKIM、および DMARC レコードを DNS に自ら公開する必要があります。

マイクロソフトはDMARCを必須としていますか？

はい。マイクロソフトは、2025年より、Outlook.com、Hotmail.com、およびLive.com宛てに1日あたり5,000通以上のメールを送信するドメインに対し、DMARC（少なくともp=none）の適用を義務付けました。この要件を満たさない送信元からのメールは、受信トレイに届くことなく、サーバーレベルで拒否されます。また、マイクロソフトは、送信量にかかわらず、すべての送信元に対してDMARCの導入を強く推奨しています。

「550 5.7.515」エラーとは何ですか？

この Microsoft 365 のエラーは、送信ドメインが認証要件を満たしていないため、メールが拒否されていることを意味します。この問題を解決するには、有効な DMARC レコード（少なくとも p=none）を公開し、SPF と DKIM の両方が設定されており、送信元ドメインと一致していることを確認してください。

なぜメールが依然として「p=reject」のステータスで配信されているのですか？

一般的な理由は4つあります：(1) フィッシング対策ポリシーで「DMARCを尊重する」が無効になっている；(2) Microsoft 365 の前にサードパーティ製のゲートウェイが配置されている； (3) 「コネクタ向けの強化フィルタリング」が有効になっていない；(4) Microsoftの複合認証（compauth）がDMARCの失敗結果を無効化している；(5) テナントの許可ルールによりフィルタリングが完全にバイパスされている。Microsoftは送信量の多い送信者に対してより厳格な「真の拒否」へと移行していますが、設定が誤っている環境では、これらの無効化が引き続き有効なままとなっています。

「検疫」と「拒否」のどちらを使うべきでしょうか？

まずは「モニタリング（p=none）」から始めて送信元を把握し、次に「隔離」に移行し、すべての正当な送信元が適切に識別されていると確信できた段階で初めて「拒否」を使用してください。 監視を行わずにいきなり「拒否」に移行することは、DMARC導入時に正当なメールが失われる主な原因となります。

DMARCbisは、Microsoft 365の管理者にとってどのような意味を持つのでしょうか？

DMARCbis（RFC 9989、2026年5月公開）により、DMARCは正式に「提案標準（Proposed Standard）」へと移行しました。 ほとんどの M365 管理者にとって、直ちに DNS の変更を行う必要はなく、既存の DMARC レコードは引き続き有効です。留意すべき主な変更点は、組織ドメインを特定するための「DNS ツリーウォーク」アプローチが、パブリックサフィックスリストに取って代わることです。sp=（サブドメインポリシー）タグを確認し、新しいロジックの下でも正しく適用されているかを確認してください。

DMARCは onmicrosoft.com ドメインにも適用されますか？

はい。onmicrosoft.com ドメイン（MOERA）は見過ごされがちですが、攻撃者はこれをなりすましに積極的に利用しています。MOERA ドメインについては、SPF は Microsoft によって自動的に設定されますが、DKIM および DMARC は手動で公開する必要があります。これらのドメインは通常、正当な送信メールには使用されないため、p=reject という厳格なポリシーを適用してください。

PCI DSSへの準拠には、DMARCが必要ですか？

2025年3月31日より、PCI DSS v4.0のセクション5.4.1に基づき、支払いカードデータを扱うすべての組織に対し、DMARC、SPF、DKIMを含むフィッシング対策が完全に義務付けられました。2026年のすべての評価は、猶予期間を設けずにPCI DSS v4.0.1に基づいて実施されます。貴組織がカード決済を処理し、Microsoft 365を利用している場合、DMARCの導入は厳格なコンプライアンス要件となります。