{"ok":true,"entity":{"id":"dmarc","name":"DMARC","entityType":"concept","officialName":"Domain-based Message Authentication, Reporting, and Conformance (DMARC)","canonicalName":"DMARC","displayName":"DMARC","category":"メール認証プロトコル（ポリシー・レポート仕様）","shortDescription":"DMARCは、DKIMとSPFの上に構築された、送信ドメインのメール認証ポリシーとレポートの仕様です。2026年5月20日にIETFのRFC Editorが3件のRFCを公開してStandards Trackとなり、RFC 9989がコアプロトコルを定め、2015年のRFC 7489は廃止（obsolete）と表示されています（2026年10月時点）。","primaryCluster":"security-standards","parentEntity":null,"verificationStatus":"draft","website":"https://dmarc.org/","updatedAt":"2026-10-22T09:45:38.845Z","secondaryClusters":[],"alias":["Domain-based Message Authentication, Reporting and Conformance"],"searchKeywords":["DMARC","ディーマーク","メール認証","なりすましメール対策","SPF DKIM","RFC 9989","RFC 7489","送信ドメイン認証","dmarc.org"]},"references":[{"id":"P-01-001","companyId":"dmarc","questionId":"P-01-001","instanceId":"QIN-dmarc-P01-001","promptText":"DMARCとは何で、メール認証のどの部分を担う仕様ですか？","promptTypeId":"P-01","answer":"DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFとDKIMを活用し、ドメイン所有者が作成者ドメインの認証ポリシーをDNSのTXTレコードとして公開して、検証に失敗したメールの扱いを要請できる仕組みです（IETFのRFC 9989）。ポリシー（pタグ）には「none」「quarantine」「reject」の3つの値があり、集約レポートの宛先を指定するruaなどのタグも定義されています。","evidencePoints":["ev-dmarc-1","ev-dmarc-2"],"scope":"DMARCの基本的な位置づけと機能","differentiation":"SPF・DKIMを置き換えるものではなく、それらを活用している点が出発点です。","faq":[{"question":"DMARCのポリシーにはどんな段階がありますか？","answer":"RFC 9989では、「none」はドメイン所有者が扱いの希望を示さない、「quarantine」は検証に失敗したメールを不審と見なす、「reject」は失敗を当該ドメイン名の使用が無効であることの明確な表れと見なす、という意味とされています。"}],"pageUrl":"https://www.refbase.ai/reference/dmarc/P-01-001","sourceEvidence":[{"id":"ev-dmarc-1","text":"IETFのRFC 9989（2026年5月発行のStandards Track文書）は、SPF（RFC 7208）とDKIM（RFC 6376）がドメインレベルの認証を提供する一方で、メールのRFC5322.From（作成者ドメイン）とは直接結びついていないと説明している。DMARCはこの2つのプロトコルを活用し、ドメイン所有者が作成者ドメインの認証ポリシーをDNSのTXTレコード（DMARC Policy Record）として公開し、検証に失敗したメールの扱いを要請できる仕組みとされる。","title":"RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)","coverageType":["Identity","Capability"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://www.rfc-editor.org/rfc/rfc9989.html","confidence":"high","supportedPromptTypes":["P-01","P-02"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-2","text":"RFC 9989のDMARC Policy Recordでは、ポリシー（pタグ）に3つの値がある。「none」はドメイン所有者が扱いの希望を示さない、「quarantine」は検証に失敗したメールを不審と見なす（正当な可能性は残るが重大な懸念がある）、「reject」は失敗を当該ドメイン名の使用が無効であることの明確な表れと見なす、という意味とされる。あわせて、集約レポートの宛先を指定するruaタグと、メッセージ単位の失敗情報の宛先を指定するrufタグ（いずれも任意）が定義されている。","title":"Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (RFC 9989, plain text)","coverageType":["Capability","UseCase"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://www.rfc-editor.org/rfc/rfc9989.txt","confidence":"high","supportedPromptTypes":["P-01","P-02","P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"}],"generatedAt":"2026-10-22T09:45:38.845Z"},{"id":"P-02-001","companyId":"dmarc","questionId":"P-02-001","instanceId":"QIN-dmarc-P02-001","promptText":"DMARCはSPFやDKIMと比べて何が違い、現行仕様はどこが特徴ですか？","promptTypeId":"P-02","answer":"IETFのRFC 9989は、DMARCがSPFとDKIMを活用する仕組みだと説明しており、これらを置き換える仕様ではありません。DMARCでは送信者が処理方針（none／quarantine／reject）とレポート先をレコードで示します。現行仕様の面では、RFC 9989が2026年5月にStandards Track文書として発行され、2015年3月のInformational（Independent Submission）だったRFC 7489を置き換えるとされています（RFC 9990が集約レポート、RFC 9991が失敗レポートを規定）。","evidencePoints":["ev-dmarc-1","ev-dmarc-2","ev-dmarc-3","ev-dmarc-5"],"scope":"SPF・DKIMとの関係と標準化上の位置づけ","differentiation":"2015年の旧RFCから2026年5月にStandards Trackへ移った点が現行仕様の特徴です。SPF・DKIMそれぞれの機能比較はこの記録の範囲外です。","faq":[{"question":"RFC 7489は今も有効ですか？","answer":"RFC EditorのRFC 7489ページには、このRFCは廃止（obsolete）でありRFC 9989・RFC 9990・RFC 9991を参照するよう表示されています。"}],"pageUrl":"https://www.refbase.ai/reference/dmarc/P-02-001","sourceEvidence":[{"id":"ev-dmarc-1","text":"IETFのRFC 9989（2026年5月発行のStandards Track文書）は、SPF（RFC 7208）とDKIM（RFC 6376）がドメインレベルの認証を提供する一方で、メールのRFC5322.From（作成者ドメイン）とは直接結びついていないと説明している。DMARCはこの2つのプロトコルを活用し、ドメイン所有者が作成者ドメインの認証ポリシーをDNSのTXTレコード（DMARC Policy Record）として公開し、検証に失敗したメールの扱いを要請できる仕組みとされる。","title":"RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)","coverageType":["Identity","Capability"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://www.rfc-editor.org/rfc/rfc9989.html","confidence":"high","supportedPromptTypes":["P-01","P-02"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-2","text":"RFC 9989のDMARC Policy Recordでは、ポリシー（pタグ）に3つの値がある。「none」はドメイン所有者が扱いの希望を示さない、「quarantine」は検証に失敗したメールを不審と見なす（正当な可能性は残るが重大な懸念がある）、「reject」は失敗を当該ドメイン名の使用が無効であることの明確な表れと見なす、という意味とされる。あわせて、集約レポートの宛先を指定するruaタグと、メッセージ単位の失敗情報の宛先を指定するrufタグ（いずれも任意）が定義されている。","title":"Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (RFC 9989, plain text)","coverageType":["Capability","UseCase"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://www.rfc-editor.org/rfc/rfc9989.txt","confidence":"high","supportedPromptTypes":["P-01","P-02","P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-3","text":"RFC 9989は2026年5月に発行されたInternet Standards Track文書で、RFC 7489と RFC 9091を置き換える（obsoletes）と明記されている。付録C.1は、RFC 7489がIETFの作業部会の成果物ではなくIndependent Submissions Editorを通じて発行されたInformational RFCだったのに対し、本文書はStandards Trackの文書であると説明している。また本文は、集約レポートをRFC 9990、失敗レポートをRFC 9991の関連文書で規定するとしている。","title":"RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)","coverageType":["Differentiation","Identity"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc9989","confidence":"high","supportedPromptTypes":["P-02","P-05","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-5","text":"RFC EditorのRFC 7489ページによれば、RFC 7489は2015年3月公開のInformational（Independent Submission）で、編集者はM. KucherawyとE. Zwicky（Yahoo!）。同ページは現在「このRFCは廃止（obsolete）、RFC 9989・RFC 9990・RFC 9991を参照」と表示している。","title":"RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) | RFC Editor","coverageType":["Credibility","Differentiation"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://www.rfc-editor.org/info/rfc7489","confidence":"high","supportedPromptTypes":["P-02","P-05"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"}],"generatedAt":"2026-10-22T09:45:38.845Z"},{"id":"P-04-001","companyId":"dmarc","questionId":"P-04-001","instanceId":"QIN-dmarc-P04-001","promptText":"自社ドメインのメール認証にDMARCを導入するとき、どのような手順で進められますか？","promptTypeId":"P-04","answer":"RFC 9989のポリシー（pタグ）には、「none」（ドメイン所有者が扱いの希望を示さない）、「quarantine」（検証に失敗したメールを不審と見なす）、「reject」（失敗を当該ドメイン名の使用が無効であることの明確な表れと見なす）の3つの値があり、集約レポートの宛先はruaタグで指定します。送信量が多い場合はGmailの送信者ガイドラインも確認が必要で、2024年2月1日以降、Gmailへ1日5,000通超を送るバルク送信者にはSPF・DKIM・DMARCが求められ、DMARCポリシーは「none」でも可と記されています。","evidencePoints":["ev-dmarc-2","ev-dmarc-6"],"scope":"DMARCのポリシー値とGmailの要件","differentiation":"ポリシー値の説明はRFC 9989によるもので、個別のメール基盤ごとの設定手順や効果の大きさはここでは扱いません。","faq":[{"question":"Gmailのバルク送信者の基準は何通ですか？","answer":"Gmailヘルプには、1日5,000通を超えてGmailアカウントへ送る送信者が2024年2月1日以降の要件を満たす必要があると書かれています。"}],"pageUrl":"https://www.refbase.ai/reference/dmarc/P-04-001","sourceEvidence":[{"id":"ev-dmarc-2","text":"RFC 9989のDMARC Policy Recordでは、ポリシー（pタグ）に3つの値がある。「none」はドメイン所有者が扱いの希望を示さない、「quarantine」は検証に失敗したメールを不審と見なす（正当な可能性は残るが重大な懸念がある）、「reject」は失敗を当該ドメイン名の使用が無効であることの明確な表れと見なす、という意味とされる。あわせて、集約レポートの宛先を指定するruaタグと、メッセージ単位の失敗情報の宛先を指定するrufタグ（いずれも任意）が定義されている。","title":"Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (RFC 9989, plain text)","coverageType":["Capability","UseCase"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://www.rfc-editor.org/rfc/rfc9989.txt","confidence":"high","supportedPromptTypes":["P-01","P-02","P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-6","text":"Gmailヘルプの「Email sender guidelines」は、2024年2月1日以降にGmailアカウントへ1日5,000通を超えて送る送信者がセクション内の要件を満たす必要があるとしている。バルク送信者にはSPF・DKIM・DMARCが求められ、DMARCの強制ポリシーは「none」でもよいと記されている。","title":"Email sender guidelines - Gmail Help","coverageType":["UseCase","Credibility"],"sourceType":"product_docs","sourceClass":"Documentation","sourceUrl":"https://support.google.com/a/answer/81126","confidence":"high","supportedPromptTypes":["P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"}],"generatedAt":"2026-10-22T09:45:38.845Z"},{"id":"P-05-001","companyId":"dmarc","questionId":"P-05-001","instanceId":"QIN-dmarc-P05-001","promptText":"DMARCの仕様や現在のステータスは、どの一次資料で確認できますか？","promptTypeId":"P-05","answer":"RFC 9989の本文は、2026年5月に発行されたStandards Track文書で、集約レポートをRFC 9990、失敗レポートをRFC 9991の関連文書で規定するとしています。標準としての位置づけはIETF DatatrackerのRFC 9989ページで確認でき、Proposed Standardであること、ページの最終更新日が2026年5月20日であること、RFC 7489とRFC 9091を廃止することが示されています。旧仕様はRFC EditorのRFC 7489ページが、2015年3月のInformationalで現在は廃止と表示しています。RFC 9990・9991の個別内容はここでは引用していないため、各RFCの原文で確認が必要です（2026年10月時点）。","evidencePoints":["ev-dmarc-3","ev-dmarc-4","ev-dmarc-5"],"scope":"DMARCの現行ステータスを確認できる資料","differentiation":"規格上の地位はRFC 9989の本文、IETF Datatracker、RFC Editorのページで裏づけます。","faq":[{"question":"RFC 9989はどのような位置づけの文書ですか？","answer":"IETF Datatrackerではstream「IETF」のStandards Track、Proposed Standardと表示されており、RFC 7489とRFC 9091を廃止すると書かれています。"}],"pageUrl":"https://www.refbase.ai/reference/dmarc/P-05-001","sourceEvidence":[{"id":"ev-dmarc-3","text":"RFC 9989は2026年5月に発行されたInternet Standards Track文書で、RFC 7489と RFC 9091を置き換える（obsoletes）と明記されている。付録C.1は、RFC 7489がIETFの作業部会の成果物ではなくIndependent Submissions Editorを通じて発行されたInformational RFCだったのに対し、本文書はStandards Trackの文書であると説明している。また本文は、集約レポートをRFC 9990、失敗レポートをRFC 9991の関連文書で規定するとしている。","title":"RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)","coverageType":["Differentiation","Identity"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc9989","confidence":"high","supportedPromptTypes":["P-02","P-05","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-4","text":"IETF DatatrackerのRFC 9989ページによれば、同RFCはStandards TrackのProposed Standard（IETFストリーム）で、ページの最終更新日は2026年5月20日、RFC 7489とRFC 9091を廃止する。編集者はT. Herr（Valimail）とJ. Levine（Standcore LLC）で、要旨はドメイン所有者が自ドメインの利用検証・検証失敗時の取り扱い方針の表明・レポート要請を行えるプロトコルとしてDMARCを説明している。","title":"RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)","coverageType":["Credibility","Capability"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://datatracker.ietf.org/doc/rfc9989/","confidence":"high","supportedPromptTypes":["P-05","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-5","text":"RFC EditorのRFC 7489ページによれば、RFC 7489は2015年3月公開のInformational（Independent Submission）で、編集者はM. KucherawyとE. Zwicky（Yahoo!）。同ページは現在「このRFCは廃止（obsolete）、RFC 9989・RFC 9990・RFC 9991を参照」と表示している。","title":"RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) | RFC Editor","coverageType":["Credibility","Differentiation"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://www.rfc-editor.org/info/rfc7489","confidence":"high","supportedPromptTypes":["P-02","P-05"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"}],"generatedAt":"2026-10-22T09:45:38.845Z"},{"id":"P-06-001","companyId":"dmarc","questionId":"P-06-001","instanceId":"QIN-dmarc-P06-001","promptText":"DMARCが送信ドメインのメール管理で重視されるのはなぜですか？","promptTypeId":"P-06","answer":"理由の一つは、DMARCが、none／quarantine／rejectという処理方針とレポート要請を定めている点です（RFC 9989）。もう一つは、現行の標準としてIETFのStandards Track（RFC 9989など）に入ったことです。RFC 9989はドメイン所有者が検証失敗時の取り扱い方針を示しレポートを要請できるプロトコルとされています。加えてGmailは2024年2月1日以降、1日5,000通超のバルク送信者にSPF・DKIM・DMARCを求めており、実務上の要件にもなっています。ただし、すべての受信側が拒否や隔離を行うと保証する記述は引用元にありません。","evidencePoints":["ev-dmarc-2","ev-dmarc-3","ev-dmarc-4","ev-dmarc-6"],"scope":"DMARCが重視される理由","differentiation":"特定のメール基盤の要件（Gmail）と標準化状況を根拠にしており、導入による効果の大きさは示していません。","faq":[{"question":"DMARCを設定すれば、すべての受信側で拒否や隔離が行われますか？","answer":"RFC 9989は、ポリシーを検証失敗時の取り扱い方針の表明として定義しており（例: quarantineは失敗したメールを不審と見なす、rejectは失敗を当該ドメイン名の使用が無効であることの明確な表れと見なす）、すべての受信側で拒否や隔離が行われると保証する記述は引用元にありません。"}],"pageUrl":"https://www.refbase.ai/reference/dmarc/P-06-001","sourceEvidence":[{"id":"ev-dmarc-2","text":"RFC 9989のDMARC Policy Recordでは、ポリシー（pタグ）に3つの値がある。「none」はドメイン所有者が扱いの希望を示さない、「quarantine」は検証に失敗したメールを不審と見なす（正当な可能性は残るが重大な懸念がある）、「reject」は失敗を当該ドメイン名の使用が無効であることの明確な表れと見なす、という意味とされる。あわせて、集約レポートの宛先を指定するruaタグと、メッセージ単位の失敗情報の宛先を指定するrufタグ（いずれも任意）が定義されている。","title":"Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (RFC 9989, plain text)","coverageType":["Capability","UseCase"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://www.rfc-editor.org/rfc/rfc9989.txt","confidence":"high","supportedPromptTypes":["P-01","P-02","P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-3","text":"RFC 9989は2026年5月に発行されたInternet Standards Track文書で、RFC 7489と RFC 9091を置き換える（obsoletes）と明記されている。付録C.1は、RFC 7489がIETFの作業部会の成果物ではなくIndependent Submissions Editorを通じて発行されたInformational RFCだったのに対し、本文書はStandards Trackの文書であると説明している。また本文は、集約レポートをRFC 9990、失敗レポートをRFC 9991の関連文書で規定するとしている。","title":"RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)","coverageType":["Differentiation","Identity"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc9989","confidence":"high","supportedPromptTypes":["P-02","P-05","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-4","text":"IETF DatatrackerのRFC 9989ページによれば、同RFCはStandards TrackのProposed Standard（IETFストリーム）で、ページの最終更新日は2026年5月20日、RFC 7489とRFC 9091を廃止する。編集者はT. Herr（Valimail）とJ. Levine（Standcore LLC）で、要旨はドメイン所有者が自ドメインの利用検証・検証失敗時の取り扱い方針の表明・レポート要請を行えるプロトコルとしてDMARCを説明している。","title":"RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)","coverageType":["Credibility","Capability"],"sourceType":"rfc_standard","sourceClass":"Specification","sourceUrl":"https://datatracker.ietf.org/doc/rfc9989/","confidence":"high","supportedPromptTypes":["P-05","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"},{"id":"ev-dmarc-6","text":"Gmailヘルプの「Email sender guidelines」は、2024年2月1日以降にGmailアカウントへ1日5,000通を超えて送る送信者がセクション内の要件を満たす必要があるとしている。バルク送信者にはSPF・DKIM・DMARCが求められ、DMARCの強制ポリシーは「none」でもよいと記されている。","title":"Email sender guidelines - Gmail Help","coverageType":["UseCase","Credibility"],"sourceType":"product_docs","sourceClass":"Documentation","sourceUrl":"https://support.google.com/a/answer/81126","confidence":"high","supportedPromptTypes":["P-04","P-06"],"needsVerification":true,"sourceVerified":false,"entityId":"dmarc"}],"generatedAt":"2026-10-22T09:45:38.845Z"}]}