Office 365のDMARC：ステップバイステップのセットアップとベストプラクティス

⚠️重要なお知らせ（2025年5月）：Microsoftは現在、大量送信者に対してDMARCを適用しています。DMARCを設定せずにOutlook、Hotmail、またはLiveユーザーへ1日あたり5,000通以上のメールを送信すると、メッセージが「550 5.7.515」エラーで拒否される可能性があります。

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

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

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

DMARCは、ドメインをなりすましやフィッシングから保護する電子メール認証プロトコルです。（Domain-based Message Authentication, Reporting, and Conformance）は、SPFおよびDKIMを基盤として機能し、認証結果をドメインポリシーと照合するとともに、これらのチェックに失敗したメッセージをどのように処理すべきかを受信サーバーに指示します。

Microsoft 365 環境において、DMARC は 2 つの役割を果たします。攻撃者によるドメインのなりすましから保護するだけでなく、正当なメールが外部の受信者に信頼されるよう支援します。

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

管理者たちの間で最もよくある誤解の一つは、Microsoft 365がDMARCの設定を自動的に行ってくれるというものです。

Microsoft 365 では DMARC 検証が行われますが、これは受信メールのみを対象としています。Exchange Online Protection (EOP) は、組織が受信するメッセージに対して SPF、DKIM、および DMARC を自動的にチェックします。つまり、ユーザーはある程度、なりすましメールから保護されることになります。

ただし、送信メールに関しては、設定を行わない限り、Microsoftは何も行いません。ドメインを保護し、最新のコンプライアンス要件を満たすためには、DNSにDMARCレコードを公開する必要があります。

この違いは非常に重要です。Microsoftは受信トレイを保護しますが、DMARCはドメインのレピュテーションを保護します。そのため、EOPを導入していても、Microsoft 365にはDMARCが必要です。これから実施する設定は、送信メールの保護に適用されます。

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

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

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

SPF（Sender Policy Framework）は、どのメールサーバーがあなたのドメインを代表してメールを送信する権限を持っているかを定義します。Microsoft 365の環境では、これには通常、Microsoft自身のメールサーバーや、利用しているサードパーティのサービスが含まれます。

SPFの手動設定（DNS方式）

SPFを手動で設定するには：

1. ご利用のDNSホスティングプロバイダー（GoDaddy、Cloudflareなど）にアクセスしてください
2. ルートドメインのTXTレコードを作成または更新する

次の標準的な Microsoft 365 SPF レコードを使用してください：

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

その他のサービス（MailchimpやSalesforceなど）を利用している場合は、それらも必ず含めてください。例：

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

💡ヒント：複数のSPFレコードを作成しないようにしてください。ドメインごとにSPF TXTレコードは1つだけ存在させる必要があります。複数のサービスを利用する場合は、それらを1つのレコードに統合する必要があります。

SPFの自動設定（PowerDMARCを使用）

SPFレコードを手動で作成するのは、特に複数のサービスが関与している場合、複雑になりがちです。DNS検索の制限を超過したり、設定ミスが発生したりといったエラーはよく見られます。

PowerDMARCのSPFツールを使用すれば、このプロセスが簡素化されます。SPFジェネレーターは、送信元に基づいて有効なレコードを自動的に作成します。

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

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

SPFとは異なり、Microsoft 365 の DKIM では、DNS の設定と管理センターでの有効化の両方が必要です。

DKIMの手動設定（DNS + 管理センター）

DKIMを手動で有効にするには：

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

画像出典

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

これらは通常、次のような形をしています：

selector1._domainkey.yourdomain.com → selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

selector2._domainkey.yourdomain.com → selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

これらのレコードを公開した後、管理ポータルに戻り、DKIMの「有効にする」をクリックしてください。有効化されると、Microsoftは送信されるすべてのメールにDKIM署名を付与し始めます。

DKIMの自動設定（PowerDMARCを使用）

DKIMの設定は、特にCNAMEレコードやセレクタの形式に慣れていない管理者にとっては、分かりにくい場合があります。

PowerDMARCは、ドメイン用に適切なDKIMレコードを自動的に生成し、手動入力によるミスを防ぐための自動DNS公開機能を提供し、DKIMが正しく有効化されているかを確認するためのDKIMチェッカーを提供することで、このプロセスを簡素化します

Office 365 で DMARC を設定するには？

SPFとDKIMが適切に設定されたら、次はDMARCの設定に進むことができます。Microsoft 365では、この設定はDNSレベルで行われますが、正しく実施するには、自社のメール環境を理解し、適切なポリシーを選択し、適用前に結果を監視する必要があります。

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

DMARCレコードを公開する前に、自ドメインを名乗ってメールを送信している送信者を完全に把握しておく必要があります。正当な送信者を見落としてしまうと、後で配信エラーが発生する可能性があるため、これは最も重要な手順の一つです。

送信元としては、通常次のようなものがあります：

• Microsoft 365（Exchange Online）
• マーケティングプラットフォーム（Mailchimp、HubSpotなど）
• CRMシステム（Salesforce）
• サポートツール（Zendesk、Freshdesk）
• 社内向けアプリケーションまたはサーバー

これらのいずれかがSPFまたはDKIMによって適切に認証されていない場合、DMARCの適用が有効になると、DMARC検証に失敗します。

💡ヒント：すべての送信元について確信が持てない場合は、まず監視ポリシー（p=none）から始め、DMARCレポートを活用して未知の送信元を特定してから、より厳格なポリシーを適用するようにしてください。

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

DMARCレコードとは、DNSに公開されるTXTレコードのことです。これはポリシーを定義し、認証に失敗したメールをどのように処理すべきかを受信サーバーに指示します。PowerDMARCの即時DMARCレコード生成ツールを使用すれば、ドメインごとに独自のOffice 365用DMARCレコードを作成できます。

基本的なDMARCレコードは次のようになります：v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

順を追って説明しましょう：

v=DMARC1 – DMARCのバージョンを指定します
p=none – 監視モード（強制適用なし）
rua=mailto:[email protected] – 集計レポートの送信先
fo=1 – 失敗レポート機能を有効にします

メールの配信に影響を与えることなくデータを収集できるため、これが推奨される最初のステップです。

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

レコードの準備ができたら、それをDNSに追加する必要があります。

以下の設定を使用してください：

レコードタイプ:TXT
ホスト/名前:_dmarc
値:あなたのDMARCレコード
TTL:1時間（またはデフォルト）

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

💡ヒント：公開後は必ずDMARCチェッカーを使ってレコードを確認し、構文エラーがないことを確認してください。

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

p=none ポリシーで DMARC を有効にすると、受信サーバーからレポートが届き始めます。これらのレポートにより、どの送信者があなたのドメインを使用してメールを送信しているか、どのメッセージが認証を通過したか、あるいは失敗したか、そして SPF および DKIM の整合性ステータスを把握することができます。

DMARCレポートは通常XML形式で送信されるため、手作業での解析は困難な場合があります。適切な分析を行わなければ、設定ミスや不正な送信者を見逃してしまう恐れがあります。

💡ヒント： DMARCレポート解析ツールを使用して、生のレポートを読みやすい分析結果に変換しましょう。これにより、問題の特定が容易になり、安全にポリシー適用へと進めるようになります。

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

レポートを確認し、正当な送信元がすべて適切に認証されていることを確認したら、DMARCポリシーの厳格化を開始できます。

典型的な進行は次のようなものです：

まずは監視から始めましょう：v=DMARC1; p=none; rua=mailto:[email protected]

↓

隔離に移動（不審なメールはスパムフォルダへ）：v=DMARC1; p=quarantine; rua=mailto:[email protected];

↓

最後に、拒否を強制します：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 レコード ポリシーを順守する」設定によって制御され、この設定はデフォルトで有効になっています。

画像出典

「oreject」の動作について

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

マイクロソフトがこのような措置を講じたのは、転送メールやメーリングリストの通信において、転送中にSPFやDKIMの検証に失敗することが頻繁に発生するためです。つまり、送信元では認証を通過した正当なメッセージであっても、二次的な受信者が受け取る段階では認証に失敗してしまう可能性があるのです。もしp=rejectで厳格に拒否していた場合、なりすましメールだけでなく、正当なメールも大量に削除されてしまっていたでしょう。スパムフォルダへの振り分けは、その折衷案でした。これにより、受信者は必要に応じてメールを復元できる一方で、送信者のポリシーも技術的には遵守されることとなったのです。

その代償として、本来は拒否されるべき偽装メッセージが依然としてユーザーの受信箱（迷惑メールフォルダ）に届いてしまい、うっかりした受信者がそれらを開いてしまう可能性があった。セキュリティチームにとって、これはDMARCの適用が、ポリシーが示唆するほど厳格には機能していないことを意味していた。

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

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

1. フィッシング対策ポリシーにおいて、「DMARCを尊重する」設定が無効になっています。

この問題を解決するには、Microsoft 365 Defender → [メールとコラボレーション] → [脅威対策ポリシー] → [フィッシング対策] → [なりすまし設定] の設定を確認してください。このトグルはデフォルトでオンになっていますが、以前の構成から移行したテナントではオフになっている場合があります。

2. メールは、Microsoft 365に到達する前に、サードパーティのゲートウェイを経由します。

MXレコードがセキュリティアプライアンス（Proofpoint、Mimecastなど）を指し、そこからEOPへ転送されている場合、Defenderポータルでコネクタの「拡張フィルタリング」を有効にしない限り、MicrosoftはDMARCを再評価できません。これを有効にしない場合、EOPは上流のゲートウェイの判定を信頼し、検証に失敗したメールに対してはデフォルトで拒否する動作をとります。

3. テナントレベルの許可ルールがフィルタリングをバイパスしています。

ホワイトリストに登録された送信者、信頼された受信コネクタ、またはスパム信頼度（SCL -1）が設定された転送ルールについては、DMARCの適用が完全にスキップされ、ポリシーにかかわらずメッセージは受信トレイに配信されます。

より厳格な対応を行うには、Defender ポータルで「Honor DMARC」と併せて「Spoof Intelligence」を有効にしてください。Spoof Intelligence は、DMARC とは別に送信者のレピュテーションを評価し、技術的には認証に合格している場合でも、なりすましの試みと見なされるメッセージを隔離します。

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

DMARC検証に失敗したメールを確実に拒否したい組織にとって、Exchange Onlineのトランスポート ルールが最も信頼性の高い仕組みです。

ルールの作成方法：

1. Exchange 管理センター → メール フロー → ルールに移動し、新しいルールを作成します。
2. 条件を設定します：メッセージヘッダーに以下のいずれかの単語が含まれていること。ヘッダー名：Authentication-Results。ヘッダー値：dmarc=fail action=oreject。
3. アクションを設定する：説明を添えてメッセージを拒否する — 「メッセージはDMARC認証に失敗したため、組織の方針に基づき拒否されました」といった内容を入力してください。
4. （任意）誤検知を防ぐため、信頼できる社内の送信者や既知の正当な転送元に対する例外を追加してください。
5. 最初の1週間は、ルールモードを「ポリシーヒント付きテスト」に設定してください。「適用」に切り替える前に、メッセージトレースで一致したメッセージを確認してください。

詳細については、Microsoftのメールフロー規則に関する詳細なドキュメントをご参照ください。

このアプローチを使うべき場面：

転送ルールは、規制や社内ポリシーにより失敗したメールを確実に拒否する必要がある場合、組織が標的型攻撃の主要な標的となっている場合（金融、法務、経営陣間の通信など）、あるいはdirect-MXとサードパーティ製ゲートウェイの双方で一貫した動作を求めるときに有効です。

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

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

大まかに言えば、マイクロソフトのメール送信者に対する要件は、認証の厳格化や送信者の説明責任を求める業界全体の動きと一致しています。今回の更新により、これまで比較的緩やかに適用されていた明確な基準、執行措置、および期待される対応が導入されました。

マイクロソフトによる主な変更点

• 大量送信者に対するDMARCの義務化：Microsoftのコンシューマー向けサービスに対して1日あたり5,000通以上のメールを送信するドメインは、有効なDMARCレコードを設定する必要があります。
• Outlook.com、Hotmail.com、およびLive.comに適用されます：この措置は、企業向けテナントだけでなく、特にマイクロソフトの一般ユーザー向けメールボックス環境を対象としています。
• 最低要件：DMARC（p=none）：監視ポリシーのみの設定でも許容されますが、DMARCレコードが設定されていない状態は、大規模な環境ではもはや許容されません。
• ドメインの一致をより重視：認証だけでは不十分であり、DMARCを通過させるためには、SPFおよびDKIMが「From」フィールドに表示されるドメインと一致している必要があります。
• 要件を満たさない場合の完全な拒否：要件を満たさないメールは、次のようなエラーでブロックされる場合があります：550 5.7.515 アクセス拒否。送信ドメイン [SendingDomain] は、必要な認証レベルを満たしていません。

この変更により、マイクロソフトは2024年2月に同様の要件を導入したグーグルやヤフーと同様の対応をとることになり、これにより、主要なメールプロバイダー3社すべてが一斉送信者に対する認証を義務付けることになった。

PowerDMARCのようなプラットフォームは、すべての送信元においてメールボックスプロバイダーの要件に準拠するための専用のコンプライアンスプログラムを提供することで、この課題を解決します。

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

Microsoft 365は強力な受信側保護機能を備えていますが、DMARCを大規模に管理・監視する機能は限定的です。こうした機能は、専用のメール認証プラットフォームが提供しています。

人間が読みやすいレポートの欠如

現在、マイクロソフトは企業ユーザー向けにDMARCレポートを送信していますが、DMARCレポートを効果的に集約・解析するための組み込みシステムは存在しません。これらのレポートはXML形式で送信されるため、専用のツールがなければ分析が困難な場合があります。その結果、組織は、誰が自社の名義でメールを送信しているのか、またそれらの送信元が適切に認証されているのかについて、把握できていないことがよくあります。

施行に関する指針なし

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

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

専用のDMARCソリューションは、生のレポートを実用的な知見へと変換します。これにより、継続的な監視が可能になり、ポリシー管理が簡素化され、Microsoft 365では標準では提供されない規模で、組織が安全に完全な適用へと移行できるよう支援します。

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

1. DMARCレコードが公開されていない

これは最もよくある問題です。「DMARCレコードが公開されていません」というメッセージは、基本的に、ドメインのDNSにDMARC TXTレコードが設定されていないことを意味しており、そのため受信側は対応すべきポリシーを持っていません。

この問題を解決するには、まず

• DMARCチェッカーを使ってこれを確認してください。
• ツールが「DMARCレコードが見つかりません」というエラーを返した場合、解決策は、v=DMARC1; p=none; rua=mailto:[email protected] から始まるレコードを公開することです。これにより、ポリシーを厳格化する前にレポートの収集を開始できるようになります。
• 設定に慣れたら、レポートを監視しながら、徐々に運用に移行していくことができます。

2. 転送を行うと、SPFおよびDKIMが無効になります

メールの転送は、正当なメールでありながら配信に失敗する最大の原因です。仲介者（メーリングリスト、転送サービス、セキュリティアプライアンスなど）がDKIM署名に含まれるヘッダーを変更すると、署名の検証が失敗し、DKIMが失敗します。通常、転送サーバーのIPアドレスがSPFレコードに含まれていないため、SPFも同時に失敗します。

この問題を解決するための、3つの推奨される対処法をご紹介します：

• ヘッダーが書き換えられない場合、DKIMはSPFよりも転送時の整合性を維持しやすいため、送信元でのDKIM準拠の署名を優先してください
• Sender Rewriting Scheme（SRS）を修正策として使用するのは避けてください。SRSはSPFを修正しますが、Fromドメインの一致は回復しないため、DMARCは依然として失敗します
• メールを正当な理由で変更する転送サービスについては、Microsoft Defender で信頼できるARC（Authenticated Received Chain）シーラーを設定してください。Microsoft は、メッセージを即座に拒否するのではなく、ARC チェーンを介して上流の認証結果を有効とします。

3. DNS 照会が多すぎるために発生した SPF パーマネントエラー

正当な送信元すべてに対してSPFが突然失敗し、Permerrorが返される場合、その根本的な原因は通常、設定レベルではなく構造的な問題にあります。

これには、主に2つの原因が考えられます：

• まず第一に、SPFがinclude、a、mx、redirect、exists、ptrメカニズムに対して課している10件のルックアップ制限を超過してしまったということです。ベンダーのinclude内でのネストされたルックアップもカウントされるため、一見問題ないように見えるレコードでも、実際には12件や13件に達している可能性があります。この制限を超過すると、すべての受信サーバーがpermerrorを返し、ドメイン全体でSPFに基づくDMARCのアラインメントが一度に崩壊してしまいます。

対処法：まず、SPF検索ツールを使用してレコードを点検し、使用しなくなったベンダーを削除することから始めましょう。ただし、これは一時的な対処法に過ぎません。長期的な解決策としては、動的なSPF検索管理のためのSPFマクロ最適化機能を備えた「PowerSPF」のようなホスティング型SPFソリューションを利用することが挙げられます。

• 2つ目の原因として、特にMicrosoftのサーバーに対して「temperror」エラーが発生している場合は、DNSのタイムアウトが考えられます。タイムアウトが特定のドメインで発生している場合、そのベンダーのサーバーを削除するか、リストから外す必要があります。

4. p=拒否ポリシーが遵守されていない

2023年7月以降、Microsoftはデフォルトで「p=reject」を適用しています。つまり、失敗したメッセージは即座に拒否されるべきです。もし拒否されない場合は、以下の4つの要因のいずれかが原因となっています：

• フィッシング対策ポリシーでDMARCの適用が無効になっている可能性があります。「メッセージがなりすましと検出された場合にDMARCレコードポリシーを適用する」が有効になっていること、および p=reject に対するアクションが「拒否」（「隔離」ではない）に設定されていることを確認してください。
• Microsoft 365 の前にサードパーティ製のゲートウェイが配置されている場合：MXレコードがサードパーティ製のセキュリティゲートウェイを指している場合、コネクタで「拡張フィルタリング」を有効にしない限り、Microsoft は DMARC を適用しません。
• 複合認証が結果を上書きしました：MicrosoftはDMARCの上にレピュテーション信号を重ねています。メッセージがDMARCに失敗しても、compauth=passの場合、配信されることがあります。
  （詳細については、Microsoftのラーニングコミュニティをご覧ください）。
• テナントの許可ルールによりフィルタリングがバイパスされます。許可リストに登録された送信者、信頼された受信コネクタ、またはスパム信頼度（SCL）レベルSCL-1を付与するルールは、DMARC の適用を完全にスキップします。

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

Microsoft 365におけるDMARCは、二面性のある課題です。Exchange Online Protectionが受信メールの検証を自動的に行いますが、送信メールの保護については、すべてお客様の責任となります。2025年5月の適用要件の変更により、大量のメールを送信するすべてのユーザーにとって、この責任への対応が急務となっています。

最も安全な方法は、時間をかけて進めることです。まず p=none を設定して公開し、2～4週間レポートを確認しながら、問題のある送信者を修正し、その後 p=quarantine へ移行し、最終的に p=reject へと移行します。手順を飛ばすことが、導入時に正当なメールが受信できなくなる最も一般的な原因です。

ポリシー適用段階に入ると、業務の焦点は設定から監視へと移ります。新しい送信者が追加されたり、サードパーティベンダーがインフラを変更したりしますが、レポートを監視していなければ、こうした変化が知らぬ間に整合性を崩す可能性があります。そこで、専用のDMARCプラットフォームの真価が発揮されます。PowerDMARCのレポートおよび分析ツールは、生のXMLデータを分かりやすいインサイトに変換し、配信率の問題に発展する前にドリフトを検知します。

まずは現在のDMARCレコードを確認し、現状を把握しましょう。

よくあるご質問

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

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

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

はい、マイクロソフトは大量送信者に対してDMARCの導入を義務付けています。また、配信の確実性と保護を確保するため、すべての組織に対してDMARCの導入を強く推奨しています。

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

このエラーは、Microsoftの適用ルールに基づき、DMARCポリシーが欠落しているか、または準拠していないために、メールが拒否されていることを示しています。

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

マイクロソフトは従来、「oreject」（オリジン・リジェクト）と呼ばれる内部的なオーバーライドを適用しており、これによりDMARC検証に失敗したメッセージは、ゲートウェイで即座に拒否されるのではなく、迷惑メールフォルダに振り分けられます。これは正当な送信者が誤ってメッセージを失うのを防ぐために設計されたものですが、その結果、なりすましメッセージが受信者に表示されたままになってしまうという問題があります。

知っておくべき2つのこと：

1) 2025年5月の施行変更以降、マイクロソフトは大量送信者に対して、より厳格な「完全な拒否」措置へと移行しています。

2) 自身の Microsoft 365 テナント内で確実にメッセージを拒否したい場合は、メッセージを強制的に拒否する Exchange 転送ルールを作成してください。

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

まずは「監視（p=なし）」から始めて、送信元やメールチャネルを監視し、次に「隔離」に移行してください。そして、正当な送信元がすべて適切に管理されていると確信できた段階で初めて「拒否」を使用してください。

"`