DMARCレポートの読み方：RUAとRUFの完全ガイド
最終更新日:
12 読了時間：12分
主なポイント
- DMARCレポートでは、あなたのドメインを名乗ってメールを送信している送信者がわかります。
- 集計レポート（RUA）は、あなたを差出人とするメールを送信したすべてのIPアドレスと、それぞれについてSPFおよびDKIMの検証に合格したか不合格だったかを記載した、日次XML形式の要約レポートです。
- レポートを読むのはあくまで第一歩に過ぎません。重要なのは、それに基づいて行動を起こすことです。基準を満たしていない正当な送信者を是正し、未知の送信者を監視し、経時的な合格率を追跡してください。
- レポートを参考にして、いつ措置を講じるかを判断してください。既知の送信者すべてが審査を通過し、合格率が95%以上を維持できるようになれば、「p=none」から「隔離」へ、そして「拒否」へと段階を進めていきます。
- PowerDMARCの「DMARC Report Analyzer」が、面倒な作業を代行します。このツールは、生のXMLデータを解析して見やすいダッシュボードに変換し、IPアドレスではなく送信者名で送信者を特定します。また、履歴データを一か所にまとめて管理するため、XMLを手作業で読み解くことなく、傾向を把握して迅速に対応することができます。
DMARCレコードを公開し、rua=を自分のメールアドレスに設定したところ、レポートが圧縮されたXMLファイルとして受信トレイに届くようになりました。これらのファイルは読みにくく、聞いたこともない企業から送られてくる上、これらに対してどのような対応をすべきか、そもそも対応が必要なのかさえ、一目で分かりません。
このガイドでは、その問題を解決します。DMARCレポートの内容、XMLをフィールドごとに読み解く方法、RUAやRUFが実際に何を意味するのか、そして最も重要な点として、送信者が「合格」「不合格」、あるいは予期せぬ結果となった場合にどのような対応を取るべきかを解説しています。もし今、初めてのレポートを手にしているなら、上から順に読み進めてください。
このブログでは、すでにレコードが設定されていることを前提としています。設定されていない場合は、まずDMARCレコードを公開してから、このブログに戻って、そのレコードによって生成されるレポートの解釈について確認してください。
DMARCレポートとは何ですか？
DMARCレポートは、受信メールサーバーから、rua=タグに指定されたアドレス宛てに送信される日次サマリーです。各レポートには、報告期間中に貴ドメインからのものだと主張するメールを送信したすべてのIPアドレスと、そのIPアドレスが SPF および DKIM の検証が各送信元で合格したか不合格だったかも記載されています。これらは、ドメインのメール認証状況を監視するための主要なツールです。また、正当な送信者か否かを問わず、誰があなたの名義でメールを送信しているかを把握できる、実質的に唯一の手段でもあります。
DMARCレポートを送信するのは誰ですか？
rua=が設定されている場合、お客様のドメインからメールを受信するすべてのメールサーバーがレポートを送信します。これには当然、Google、Microsoft、Yahooも含まれます。また、小規模なESP、企業のメールゲートウェイ、大学のシステム、そして受信者がたまたま利用している海外のプロバイダーなども含まれます。
見覚えのない組織からの報告を受け取る ことは正常であり、想定されることです。これは単に、どこかのサーバーが、あなたのドメインから送信されたように見えるメッセージを処理しただけであることを意味する場合もあります。ただし、あなたが管理していないIPアドレスからのメールが、それらのレポートに大量に含まれている場合は、調査が必要であることに注意してください。これは スプーフィングの兆候となるため、調査が必要です。
1日に受け取るレポートの数は、メールを受信した異なるメールサーバーの数によって異なります。受信者がごく少数の場合、1日に2～3件のレポートが届く程度でしょう。大量にメールを送信する送信者の場合は、数百件にも及ぶことがあります。これ自体は、問題があることを示すものではありません。レポートの数は、受信者の分布状況を示すものであり、ドメインの状態を示すものではありません。
レポートはいつ届きますか？
ほとんどのプロバイダーは24時間ごとに1回の集計レポートを送信しており、レポートは通常、その対象となるメールの送信から24～48時間以内に届きます。各レポート提供組織から個別のレポートが届くため（GoogleとMicrosoftはそれぞれ独自に送信します）、1日の間にさまざまな受信者宛てに送信されたメールについては、同じ期間を対象とした複数のレポートが生成されます。
レポートは、自動送信者から.zipまたは.gz形式の圧縮ファイルとして添付されて届きます。一部のメールクライアントでは、これらを不審なメールとしてマークする場合があります。そのため、レポートの受信を待っているにもかかわらず届かない場合は、システムに不具合があると思い込む前に、まずスパムや迷惑メールフォルダを確認してください。
DMARCレポートの種類：RUAとRUF
DMARCレポートには2種類あります。ほぼすべてのドメインにおいて、考慮すべきは最初のタイプのみです。
集計レポート（RUA）：標準仕様
DMARC集計レポート は、特定のメールサーバーが処理した、お客様のドメインからのすべてのメールトラフィックに関する24時間分の要約です。これらは圧縮されたXML形式で配信され、送信元IPアドレス、メッセージ数、SPFの合格/不合格、DKIMの合格/不合格、およびDMARCのディスポジション（受信者が行った処理）が表示されます。 重要な点として、これらのレポートにはメール本文や個人を特定できる情報は一切含まれておらず、認証に関するメタデータのみが含まれているため、どの地域でも安全に受信・保存できます。本ガイドでは、このレポートに焦点を当てています。
障害レポート（RUF）：メッセージごとの障害
DMARC 失敗レポート （従来は「フォレンジックレポート」と呼ばれていた）は、特定のメッセージが認証に失敗したことをほぼリアルタイムで通知するものです。 RFC 9991 （2026年5月）により、このレポート形式が正式に標準化されました。失敗レポートにはメッセージヘッダーや、場合によっては本文の内容（個人を特定できる情報（PII）を含む可能性のあるデータ）が含まれることがあるため、Google、Microsoft、Yahoo などの主要プロバイダーは、これらを一切送信していません。ruf= を有効にするのは、データ処理専用のプロセッサがある場合に限ってください。また、いずれにせよ、大手メールプロバイダーからのレポートは期待しないでください。
RUA 対 RUF
| 特徴 | RUA（集計値） | RUF（失敗） |
|---|---|---|
| 内容物 | 送信元別の全メールの日次まとめ | 単一の障害に関するメッセージごとの通知 |
| 配送頻度 | 約24時間に1回 | メッセージ単位のほぼリアルタイム |
| 主要プロバイダーから送信 | はい（Google、Microsoft、Yahoo、その他） | いいえ、プライバシー保護のため非公開です |
| 形式 | 圧縮されたXML（.zip / .gz） | ヘッダー／メタデータを含むARF形式のメッセージ |
| プライバシーリスク | なし | あり得る |
| ほとんどのドメインにおすすめです | はい、これは標準的なものです | 専用のプロセッサがある場合のみ |
DMARCレポートの内容：各フィールドごとの解説
DMARC集計レポートは、主に3つのセクションに分かれたXMLファイルです。 レポートのメタデータ （送信元と送信日時）、 公開ポリシー （受信側が認識したあなたのDMARCレコード）、および レコード（送信元ごとに1行）。これら3つのブロックを理解すれば、あとは細部です。
Section 1: Report Metadata (<report_metadata>)
このブロックには、レポートの送信者と対象期間が記載されています。
- org_name: 報告を行う組織（例：google.com）。
- メールアドレス：レポートの送信者の連絡先アドレス。
- report_id：この特定のレポートを一意に識別する識別子。
- date_range (begin + end): レポート対象期間。エポックタイムスタンプで指定されているため、人間が読みやすい形式の日付に変換する必要があります。
ここで確認すべき点：レポートの対象期間が想定した期間と一致しているかを確認してください。
Section 2: Policy Published (<policy_published>)
これは、受信側が処理時に評価した通りのDMARCレコードを正確に示しています。
- domain: ポリシーが適用されるドメイン。
- adkim / aspf: DKIM および SPF の整合モード（緩和モードまたは厳格モード）。
- p: 設定（なし、隔離、または拒否）。
- sp: 設定されている場合、サブドメインに関するポリシー。
- pct：旧式のパーセンテージフィールドです。pctはRFC 9989（2026年5月）に基づき削除されたことにご注意ください。古いレポートではまだ表示される場合がありますが、新しいレコードでは省略する必要があります。
ここで確認すべき点：公開されたポリシーが意図した内容と一致しているかを確認してください。一致していない場合は、DNSが完全に反映されていない可能性があります。
Section 3: Records (<record>): The Important Part
Each <record> represents all the emails from one source IP during the reporting period. This is where you spend most of your time.
- source_ip：送信元のIPアドレス。これを調べることで、メールの送信者を特定できます。
- count：そのIPアドレスから送信されたメッセージの数。
- policy_evaluated/disposition：実行されたアクション（なし、隔離、または拒否）。
- policy_evaluated/dkim および policy_evaluated/spf：それぞれについて、DMARCに準拠した合格／不合格の結果。
- identifiers/header_from: 表示される「From:」ドメイン。DMARCが保護する対象となるものです。
- auth_results/spf: SPFドメインと結果。
- auth_results/dkim: DKIMのドメイン、セレクタ、および結果。
ここで確認すべき点：認識できるすべてのIPアドレスがDMARCを通過しているか、また、認識できないIPアドレスはないか？
DMARC XML レポートの例
ここでは、3つの送信元（正規の送信者で検証に合格した1件、正規の送信者で検証に不合格となった1件、および不明なIPアドレス1件）を示す、現実的な匿名化済み集計レポートをご紹介します。各フィールドには、平易な言葉で書かれたコメントが付いています。
<?xml version="1.0" encoding="UTF-8"?>
<feedback>
<!-- ===== SECTION 1: WHO SENT THIS REPORT AND WHEN ===== -->
<report_metadata>
<org_name>google.com</org_name> <!-- The provider that generated this report -->
<email>[email protected]</email> <!-- Where the report came from -->
<report_id>1234567890123456789</report_id> <!-- Unique ID for this report -->
<date_range>
<begin>1718928000</begin> <!-- Start of window (epoch) = 2024-06-21 00:00 UTC -->
<end>1719014400</end> <!-- End of window (epoch) = 2024-06-22 00:00 UTC -->
</date_range>
</report_metadata>
<!-- ===== SECTION 2: YOUR POLICY AS THE RECEIVER SAW IT ===== -->
<policy_published>
<domain>example.com</domain> <!-- The domain this report is about -->
<adkim>r</adkim> <!-- DKIM alignment: r = relaxed -->
<aspf>r</aspf> <!-- SPF alignment: r = relaxed -->
<p>none</p> <!-- Your policy: monitoring only -->
<sp>none</sp> <!-- Subdomain policy -->
</policy_published>
<!-- ===== SECTION 3: ONE RECORD PER SENDING SOURCE ===== -->
<!-- RECORD 1: Legitimate sender (Google). All passing, no action needed. -->
<record>
<row>
<source_ip>209.85.220.41</source_ip> <!-- A Google sending IP -->
<count>150</count> <!-- 150 messages from this IP -->
<policy_evaluated>
<disposition>none</disposition> <!-- No action taken -->
<dkim>pass</dkim> <!-- DKIM aligned & passed -->
<spf>pass</spf> <!-- SPF aligned & passed -->
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from> <!-- Visible From: domain -->
</identifiers>
<auth_results>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
<dkim>
<domain>example.com</domain>
<selector>google</selector>
<result>pass</result>
</dkim>
</auth_results>
</record>
<!-- RECORD 2: Known ESP. SPF passes but DKIM is not configured.
Action: ask the provider to enable DKIM signing for your domain. -->
<record>
<row>
<source_ip>198.51.100.42</source_ip> <!-- Your email service provider -->
<count>45</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim> <!-- DKIM not aligned / not signed -->
<spf>pass</spf> <!-- SPF passes -->
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
<dkim>
<domain>esp-vendor.example.org</domain> <!-- Signed by vendor domain, not yours -->
<selector>s1</selector>
<result>fail</result>
</dkim>
</auth_results>
</record>
<!-- RECORD 3: Unknown sender. Both DKIM and SPF fail.
Low volume here = monitor. High volume would signal active spoofing. -->
<record>
<row>
<source_ip>203.0.113.17</source_ip> <!-- Unrecognized IP -->
<count>8</count>
<policy_evaluated>
<disposition>none</disposition> <!-- Not blocked yet (p=none) -->
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from> <!-- Claiming to be your domain -->
</identifiers>
<auth_results>
<spf>
<domain>example.com</domain>
<result>fail</result>
</spf>
<dkim>
<domain>example.com</domain>
<selector>unknown</selector>
<result>fail</result>
</dkim>
</auth_results>
</record>
</feedback> DMARCレポートの読み方：ステップバイステップ
手順 1：レポートを開いて解凍する
レポートは、件名が「Report Domain: yourdomain.com Submitter: google.com Report-ID: …」のようなメールの添付ファイルとして届きます。添付ファイルを保存し、解凍してください（お使いのオペレーティングシステムに標準搭載されている解凍ツールなら、.zip や .gz 形式のファイルも問題なく処理できます）。その後、生成された .xml ファイルを任意のテキストエディタで開いてください。
ざっと目を通す以上のことをしたい場合は、当社の DMARCレポートアナライザー ツールにアップロードして、生のXMLを読み込むのではなく、人間が読みやすい形式でデータを詳細に分析してください。
ステップ2：報告組織を特定する
Check <org_name> in the metadata so you know whose view you are looking at. Google’s report covers your Gmail recipients; Microsoft’s covers Outlook and Hotmail. You will get separate reports from each, so never assume one report is the whole picture.
ステップ3：公開されたポリシーを確認する
Confirm <p>, <sp>, <adkim>, and <aspf> match what you intended to publish. If they do not, your record may have been propagated incorrectly or edited. Verify the live record with our DMARC Checker.
ステップ4：各レコードの確認（送信元）
For each <record>: look up the <source_ip> with a reverse DNS or IP lookup to identify the service (for example, 209.85.220.41 resolves to Google). Check the <count>. High volume from an IP you do not recognize is a red flag. Then check the disposition and the DKIM/SPF results. A legitimate sender should show both dkim=pass and spf=pass; a failure on either for a sender you recognize means something needs fixing.
ステップ5：各情報源を分類する
すべてのソースを、次の3つのカテゴリのいずれかに分類してください：
- 正当かつ合格： 対応不要。
- 正当ではあるが機能していない： 修正が必要（以下のアクションフレームワークを参照）。
- 不明および送信中： なりすましの可能性があります。送信量を監視し、送信量が多い場合はポリシーの強化を検討してください。
DMARCレポートの大規模な分析：ツールと自動化
複数のプロバイダーから毎日レポートが届くようになると、XMLを手作業で読み取ることは現実的ではなくなります。Gmail、Outlook、Yahooのユーザーにメールを送信しているドメインでは、毎日少なくとも3件のレポートが届きますが、それらを1件ずつ手作業で読み取るのは、1週間も経たないうちに処理が追いつかなくなります。自動解析が業界標準となっているのには、それなりの理由があるのです。
手っ取り早く一度だけ確認したい場合は、PowerDMARCの「DMARC Report Analyzer」のような無料ツールを使えば、生のXMLファイルをアップロードして、テキストエディタを開かなくても、人間が読みやすい形式でその内容を確認することができます。
大規模な継続的な監視については、専用のプラットフォームがすべてを自動的に処理します。各プロバイダーからのレポートを単一のビューに統合し、未知の送信者が現れた際にアラートを送信し、履歴を保持し、監査対応可能なエクスポートデータを作成します。
PowerDMARCをご利用のお客様には、当社のレポートダッシュボードがシングルドメイン環境およびマルチドメイン環境を問わずこれらすべての機能を提供するため、分析は、お客様が確認を思い出した時だけではなく、継続的に行われます。
- すべてのレポートを一か所に集約： 受信トレイのあちこちに散らばっている数十もの個別のXMLファイルの代わりに、すべてのプロバイダーからのレポートが統一された単一のビューにまとめられます。
- すべてのドメインを網羅: 複数のドメインを管理するチームの場合、その統合はポートフォリオ全体に及ぶため、1つのダッシュボードで担当するすべてのドメインを網羅できます。
- 単なるスナップショットではなく、履歴データ：履歴が保存されているため、週ごとの合格率を追跡したり、不具合のあった送信者への修正が実際に定着したことを確認したり、不審な活動がインシデントに発展する前にその緩やかな増加を察知したりすることができます。
- フィルタリングと検索： すべてのレコードを手作業でスキャンする代わりに、特定の発信元や障害の種類を絞り込みます。
- 新しい送信者に関するアラート: 承認されていない新しい送信者が現れた際に通知を受け取れるため、次の手動レビューを待って発見するのを待つ必要がありません。
- 監査対応のエクスポート: コンプライアンス審査やステークホルダーへの報告用に、エクスポート可能なレポートを作成します。
DMARCレポートの活用方法
レポートを読むことは第一歩です。実際にドメインを守るためには、行動を起こす必要があります。新しいレポートを確認する際は、以下の手順に従って順を追って進めてください。
配信に失敗している正当な送信者の問題を修正する
見覚えのある送信元（ESP、CRM、ヘルプデスク、ニュースレター配信プラットフォームなど）から「dkim=fail」または「spf=fail」と表示された場合：
- SPFエラーが発生した場合は、送信元のIP範囲を追加するか、SPFレコードに「mechanism」を含めてから、当社の SPFチェッカーで再確認してください。
- DKIMの検証に失敗した場合：プロバイダーに、お客様のドメインに対してカスタムDKIM署名を有効にするよう依頼し、提供された鍵を公開してから、当社の DKIMチェッカーで検証してください。
不明な送信者の特定と監視
自分のドメインからメールを送信している見覚えのないIPアドレスは、チームが誰にも知らせずに導入したツール、正当な転送サービス、あるいは現在進行中のなりすまし攻撃のいずれかの可能性があります。未知のIPアドレスからの送信量が少なければ、よくあることでリスクも低いです。一方、未知のIPアドレスからの送信量が多い場合は、なりすましの強い兆候であり、このような場合には、ポリシーを強化して隔離または拒否を行うことで、不正利用を効果的に阻止できます。
経時的な合格率の推移を追跡する
DMARCの合格率は、DMARC認証に合格したメールの割合を指します。p=noneに設定している場合、配信には影響しませんが、ポリシーを適用する準備がどの程度整っているかを示す指標となります。ポリシーを厳格化する前に、すべての正当な送信元において、95%以上の合格率を継続的に維持できるよう目指してください。1日だけの結果に反応するのではなく、少なくとも2～4週間は毎週この数値を監視するようにしてください。
保険契約を繰り上げるタイミングを決める
以下の3つの準備状況チェックがすべて満たされた時点で、p=quarantine に移行する：
- 既知の正当な送信元はすべて、DMARCのパス判定を示しています。
- レポートには、予期せぬ大量送信者は見当たりません。
- 合格率は一貫して95％を上回っています。
検疫期間中、1～2週間にわたり同様の条件が維持され、予期せぬ事態が発生しなければ、p=reject に移行します。ポリシーの進行プロセス全体については、当社の DMARC設定ガイドで詳しく解説しています。
PowerDMARCは、この分析プロセス全体を自動化します。当社のプラットフォームは通過率を追跡し、IPアドレスではなく送信者名で送信者を特定し、新たな不正な送信者が現れた瞬間にアラートを送信します。そのため、生のXMLデータから手作業で分析を行う必要がなく、送信許可の可否が自動的に判断されます。
なぜDMARCレポートが届かないのですか？
rua= を設定してレコードを公開したにもかかわらず、レポートが届かない場合は、ほぼ必ず以下の6つの原因のいずれかが原因となっています。
問題 1: DMARCレコードに「rua=」タグがありません。これが最も一般的な原因です。「rua=」がない場合、レポートの受信を明示的にオプトアウトしたことになります。修正方法：レコードに「rua=mailto:[email protected]」を追加し、当社のDMARCチェッカーで確認してください。
問題 2: メールアドレスが間違っているか、無効です。入力ミス、存在しない受信箱、または容量いっぱいのメールボックスが原因で、レポートが自動的に破棄されることがあります。対処法：テストメッセージを送信して、rua=アドレスが実際にメールを受信できることを確認してください。
問題 3: 外部レポート送信先が認証されていません。rua=がDMARCレコードとは異なるドメイン上のアドレスを指している場合（ドメインがcompany.comであるにもかかわらず、rua=が[email protected]を指している場合など）、その外部ドメインは_report._dmarc.reportingservice.comにv=DMARC1を含む認証レコードを公開する必要があります。これがない場合、レポートは破棄されます。ほとんどのDMARCプラットフォームでは、これが自動的に処理されます。
問題 4：新しいレコードを公開しましたが、DNSの反映がまだ完了していません。レコードが世界中で有効になってから24～48時間後にレポートが届き始めます。この問題を解決するには、当社の DNS伝播チェッカーで伝播状況を確認してください。
第5号: レポートがスパムフォルダに振り分けられています。レポートは自動送信者から圧縮された添付ファイルとして送信されるため、フィルタにかかってしまうことがよくあります。この問題を解決するには、スパムフォルダを確認し、レポートの送信元（[email protected]、[email protected]）をホワイトリストに登録してください。
第6号: まだメールは送信されていません。レポートは、お客様のドメインから実際にメールが送信され、プロバイダーに到達した場合にのみ生成されます。レコードを公開してからメールが送信されていない場合は、まだレポートされる内容はありません。
RFC 9990: 2026年集計レポート規格
2026年5月現在、 RFC 9990 が、DMARC集計レポートの形式および配信を規定しており、従来RFC 7489で定められていた報告の役割を引き継いでいます。XMLスキーマは下位互換性があり（既存のパーサーや、すでに受信しているレポートは引き続き機能します）、主な変更点は、報告形式と日次サイクルが正式に標準化されたことです。
最新の更新内容の詳細については、当社の DMARC RFC 9989/9990/9991 ガイドをご参照ください。
よくあるご質問
DMARCレポートとは何ですか？
DMARCレポートとは、受信メールサーバーからrua=タグに記載されたアドレス宛てに毎日送信されるXMLファイルのことで、ドメインからメールを送信したすべてのIPアドレスと、それぞれについてSPFおよびDKIMの検証が合格したか不合格だったかをまとめたものです。Google、Microsoft、Yahooなどのプロバイダーは、あなたのドメインから送信されたと主張するメールを受信するたびに、このレポートを生成します。これは、ドメインのメール認証状況を監視するための主要なツールです。
DMARCにおけるRUAとRUFの違いは何ですか？
RUA（集計）レポートは、お客様のドメインからのすべてのメールアクティビティを網羅した日次XMLサマリーです。RUF（配信失敗）レポートは、個々のメールヘッダーデータを含む場合のある、メッセージごとの配信失敗通知です。Google、Microsoft、Yahoo! を含む主要なプロバイダーの多くは、プライバシー上の制約により配信失敗レポートの送信を中止しているため、集計レポートの方が一般的であり、世界的に広くサポートされています。
DMARCレポートはどのくらいの頻度で送信されますか？
ほとんどのプロバイダは、24時間に1回、集計レポートを送信します。受信側の各メールサーバーが独自のレポートを送信するため、自分のメールを受信したユーザーがいるプロバイダごとに1通ずつレポートが届きます。したがって、Gmail、Outlook、Yahooのユーザーにメールを送信しているドメインの場合、1日あたり少なくとも3通のレポートが届くことが予想されます。
DMARC XMLレポートはどのように読み解けばよいですか？
DMARC XMLレポートは、主に3つのセクションで構成されています。report_metadata（送信元と期間）、policy_published（評価対象となったDMARCレコード）、およびrecords（送信元IPごとに1つのエントリがあり、SPFおよびDKIMの結果が記載されています）です。具体的な手順については、このガイドの前半にあるXMLの例を参照してください。ただし、ほとんどのITチームは、生のXMLを読み取るのではなく、送信者を名前で特定する自動解析ツールを使用しています。
なぜ、見覚えのない組織からDMARCレポートが届くのでしょうか？
rua=が設定されている場合、あなたのドメインから送信されたと主張するメールを受信したメールサーバーは、すべてレポートを送信します。これには、GoogleやMicrosoftだけでなく、小規模なISP、企業のメールゲートウェイ、受信者が利用している海外のプロバイダーなども含まれます。見慣れない組織からレポートが届くことはごく普通のことであり、単にそれらのサーバーが、あなたのドメインから送信されたように見えるメールを処理したということを意味するだけです。
サイバーセキュリティの専門家、CEO（ PowerDMARCのCEO
マイサムは技術起業家であり、サイバーセキュリティの専門家であり、15年以上の業界経験を持つPowerDMARCのCEO兼創設者である。Maithamはマンチェスター大学でグローバルMBAを取得し、CISSP、CISM、CRISC、ISC2 CCSPなど様々な専門資格を持つ。
最新記事 by Maitham Al Lawati(全て見る)
- DMARCの設定方法：完全なステップバイステップ設定ガイド（2026年） - 2026年6月20日
- DMARCレポートの読み方：RUAとRUFの完全ガイド - 2026年6月10日
- DMARCとは？ 定義、仕組み、その重要性 - 2026年4月28日
