DMARC RFCの基礎知識とメール認証における役割
著者: Ayan Bhuiya
翻訳: 東條 百々朱
この記事はPowerDMARCのブログ記事 DMARC RFC Explained: A Core Standard for Modern Email Authentication の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
主なポイント
- DMARCはRFC 7489（Informational RFC）として規定されており、その後継となるIETF DMARCbisドラフトは、正式なStandards Track RFCとしてRFC 7489に代わる標準仕様となることを目指しています。
- DMARCは、SPFおよびDKIMの認証結果を利用して、メールが正当な送信元から送信されたものであることを確認します。
- ドメイン所有者はDNS上にDMARCポリシを公開し、認証に失敗したメールの取り扱い方法を制御できます。
- DMARCはレポート機能を提供し、ドメイン所有者が自社ドメインのメール送信状況を把握できるようにします。
- DMARCは直接的なドメインなりすましや、それに依存する多くのフィッシング攻撃を軽減しますが、類似ドメインの悪用や表示名のなりすましは防止できません。
- DMARCの導入は、ブランドの信頼性向上とメール到達率の改善につながります。
DMARC（Domain-based Message Authentication, Reporting and Conformance）は、RFC 7489（Informational RFC）で規定されたメール認証プロトコルです。
その後継であるIETF DMARCbisドラフトは、プロトコルの更新や仕様の明確化を行い、RFC 7489に代わる正式な標準仕様となることを目指しています。
DMARCは、SPF（Sender Policy Framework）およびDKIM（DomainKeys Identified Mail）を基盤として構築されており、ドメインのなりすましやフィッシング、不正利用を防止するための仕組みです。
ドメイン所有者はDNS上にDMARCポリシを公開することで、認証チェックに失敗したメールを受信側メールサーバがどのように処理すべきかを指示できます。
この仕組みにより、DMARCは現代のメールセキュリティと信頼性を支える重要な基盤となっています。
DMARC RFCとは何ですか？
IETF（Internet Engineering Task Force）は、2015年3月にRFC 7489（Informational RFC）としてDMARCを公開しました。
このRFCでは、メールがDMARC評価に失敗した場合に、受信側がどのように処理すべきかをドメイン所有者がDNSポリシとして公開する方法を定義しています。
DMARCプロトコルはもともと、Google、Microsoft、Yahoo、PayPalなどを含む業界コンソーシアムによって開発されました。
これらの企業はDMARC.orgのもとで協力し、ドメイン単位で認証結果を共有し、認証ポリシを適用できる共通の仕組みを構築することで、メール詐欺を減らすことを目指していました。
その後、この仕様はIETFへ提出され、RFC 7489として公開されました。
RFC 7489はStandards Track文書ではなくInformational RFCに分類されますが、現在でもDMARC実装における事実上の標準文書として広く利用されています。
RFC 7489には何が含まれていますか？
RFC 7489は、DMARCの基本的な仕組みを定義した文書です。
内容は技術的ですが、その目的は比較的わかりやすく整理できます。
- ポリシーメカニズムの提供
- DMARCを利用することで、ドメイン所有者は認証チェックに失敗したメールを受信側がどのように処理すべきかを、DNS上でポリシとして公開できます。
- レポート機能の提供
- DMARCは認証ポリシーだけでなく、レポート機能も備えています。
これにより、ドメイン所有者はどのメールが認証に成功し、どのメールが失敗したのかを把握できます。
その結果、正当なメールと不正なメールを区別しやすくなります。 - メールのなりすましや詐欺メールの抑止
- DMARCは、RFC5322.FromドメインがSPFまたはDKIMによって認証された識別子と整合しているかを確認します。
これにより、直接的なドメインなりすましを防止できます。
ただし、類似ドメインを利用した攻撃や表示名のなりすましは防止できず、またメール転送などの間接的なメールフローの影響を受ける場合があります。 - SPFおよびDKIMとの連携
- DMARCはSPFおよびDKIMの認証結果を利用し、さらに識別子アラインメント、ポリシ（p=）、レポート機能（rua／ruf）を追加します。
DMARC独自の要件
DMARCでは、アラインメント（整合性）の確認結果に基づいてポリシが適用されます。
特に重要なのは、DMARCが「識別子アラインメント（Identifier Alignment）」という独自の要件を導入している点です。
DMARCがSPFとDKIMをどのように評価するか
DMARCは、単にSPFやDKIMの認証が成功したかどうかを確認するだけではありません。
認証に使用されたドメインが、利用者に表示されるRFC5322.Fromドメインと整合していること（識別子アラインメント）も確認します。
SPFアラインメント
DMARCは、SPF認証済みのRFC5321.MailFrom（またはHELO）ドメインを利用し、それがRFC5322.Fromドメインと整合していることを要求します。
緩和モード（aspf=r、デフォルト）では組織ドメインレベルで一致している必要があります。
厳格モード（aspf=s）では完全一致が必要です。
DKIMアラインメント
DMARCは、DKIM署名のd=ドメインを利用し、それがRFC5322.Fromドメインと整合していることを要求します。
緩和モード（adkim=r、デフォルト）では組織ドメインレベルで一致している必要があります。
厳格モード（adkim=s）では完全一致が必要です。
このアラインメント要件こそがDMARC最大の特徴です。
認証結果を、利用者がメール上で目にする送信元ドメインと結び付けることで、攻撃者によるなりすましを可能にしていた抜け穴を防いでいます。
ポリシーモード（p=）
DMARCレコードでは、メールがDMARC認証に失敗した場合に受信側が従うべき3種類のポリシを指定できます。
- p=none
- 監視専用のモードです。
レポートの送信を要求しますが、メール配信には影響を与えません。 - p=quarantine
- 認証に失敗したメールを疑わしいメールとして扱うよう指示します。
通常は迷惑メールフォルダへ振り分けられます。 - p=reject
- 認証に失敗したメールを受信拒否するよう求めるポリシーです。
RFCではローカルポリシによる例外処理（既知の正当な送信者など）が認められていますが、主要なメールプロバイダは一般的に未認証のなりすましメールに対してこのポリシを厳格に適用しています。
レポート機能（RUAおよびRUF）
DMARCは2種類のレポートを通じて有益なフィードバックを提供します。
集計レポート（RUA）
RUAレポートは、DMARC評価結果をまとめた機械可読なXML形式のサマリーレポートです。
通常は1日単位で送信されます。
レポートには以下の情報が含まれます。
- 送信元IPアドレス
- SPF認証結果
- DKIM認証結果
- アラインメント情報
- メッセージ数
ただし、生のXMLファイルは人が直接読み取るには分かりづらく、専用ツールなしで分析することは容易ではありません。
PowerDMARCのDMARC Report Analyzerツールは、このプロセスを自動化し、複雑なデータを分かりやすいグラフやチャートへ変換します。
個別失敗レポート（RUF、一般にフォレンジックレポートと呼ばれる）
RUFレポートはオプション機能であり、プライバシー上の理由から送信されることは多くありません。
多くの受信側メールシステムでは、情報をマスキングするか、RUFレポート自体を無効化しています。
DMARCbis文書では、こうしたプライバシー上の懸念について説明するとともに、失敗レポートに関する別ドラフトを参照しています。
そのため、RUFレポートは実運用において徐々に利用される機会が減っています。
DMARCbisと今後の変更点
技術標準は常に進化しており、DMARCも例外ではありません。
DMARCbisは、IETFで策定が進められているDMARCプロトコルの次世代仕様です。
過去数年間の運用で得られた知見を反映し、DMARCを「Informational RFC」から正式な「Proposed Standard」へ引き上げることを目指しています。
これはDMARCを根本から変更したり廃止したりするものではなく、既存仕様を整理・改善する進化版と考えると分かりやすいでしょう。
DMARCbisにおける主な変更点や明確化された内容は以下の通りです。
p=quarantineの動作
DMARCbisでは、quarantineポリシの意味や、受信側がどのように扱うべきかがより明確に定義されています。
ただし、最終的な処理については、引き続き受信側の判断に委ねられています。
新しい用語と文書構成
DMARCbisはRFC 7489をベースにしていますが、文書構成が見直され、より理解しやすい形に整理されています。
仕様は現在、以下の3つの独立した文書に分割されています。
また、理解しやすさを高めるため、一部の用語も変更されています。
例えば、以下のような変更があります。
- 「Report Consumer」→「Report Receiver」
- 「DMARC Policy」→「Domain Owner Assessment Policy」
- p=quarantineおよびp=reject →「Enforcement（強制適用）」
- p=none→「Monitoring Mode（監視モード）」
レポートに関する課題
メール転送はSPF認証を失敗させる可能性があります。
また、メーリングリストではDKIM署名が壊れることも少なくありません。
そのためDMARCbisでは、メーリングリスト宛ての送信が多い場合、p=rejectポリシの使用には注意が必要であることが示されています。
さらに、集計レポートに関するルールも厳格化されており、新しいタグに対応するためXMLレポート形式も更新されています。
RUFレポートの非推奨化
DMARCbisでは、プライバシー上の懸念から、RUFレポート（フォレンジックレポート）の利用は推奨されない方向になっています。
また、失敗レポートに関する仕様は、別のドラフト文書として管理されています。
DNS Tree Walk
従来の組織ドメイン（Organizational Domain）の判定方法は、Public Suffix List（PSL）に大きく依存していました。
しかし、PSLは常に完全とは限りません。
DMARCbisでは、適用すべきDMARCポリシを見つけるための、より柔軟で信頼性の高い「DNS Tree Walk」アルゴリズムが正式に定義されています。
追加・削除されるDMARCタグ
一部のDMARCタグは廃止される予定です。
削除予定のタグには以下があります。
- pct
- rf
- ri
一方で、新しいDMARCタグも追加されます。
例えば、以下のタグです。
- np
- psd
- t
組織にとっての重要性
DMARC RFCを理解することは、組織にとって多くのメリットがあります。
コンプライアンス強化
Google、Yahoo、Microsoft、Apple Mailは現在、大量送信者に対してDMARCレコードの公開を求めています。
さらに、以下の要件も求められています。
- SPFおよびDKIMの設定
- アラインメントの実施
- 低いスパム率の維持
- その他のメール送信要件への対応
これらの要件を満たしていない場合、メール到達率に大きな影響が出る可能性があります。
設定ミスの防止
RFCの基本概念、特にアラインメントを正しく理解していないと、正当なメールまでブロックしてしまう可能性があります。
RFC 7489の内容を理解しておくことで、問題発生時の原因特定がしやすくなり、最初から適切なポリシを設定しやすくなります。
設定ミスを防ぐには、DMARCレコードジェネレータツールを利用して正しいDMARCポリシを生成する方法もあります。
すでにDMARCレコードを公開している場合は、PowerDMARCのDMARCレコードチェッカーを使用し、強制適用ポリシへ移行する前にレコードが正しく公開されているか確認できます。
セキュリティ面でのメリット
適切に設定され、p=rejectが適用されたDMARCポリシは、直接的なドメインなりすましに対する最も効果的な防御策の一つです。
ドメインなりすましは、ビジネスメール詐欺（BEC）や多くのフィッシング攻撃の主要な原因となっています。
DMARCを導入することで、従業員、顧客、そしてブランドの信頼を、さまざまなメール詐欺から保護できます。
まとめ
DMARC RFCは、メール詐欺やドメインなりすましからドメインを保護するための強固な基盤を提供します。
また、DMARCの設定・運用に関する標準と指針を定義しています。
DMARC RFCに基づいて適切に実装することで、メールセキュリティの向上、ブランド価値の保護、そしてメール到達率の改善を実現できます。
また、DMARCの導入や運用管理を必ずしも手作業で行う必要はありません。
PowerDMARCプラットフォームを利用すれば、初期設定から監視、ポリシ適用まで、DMARC運用全体を効率化できます。
DMARCの導入や運用でお困りの場合は、ぜひPowerDMARCチームへご相談ください。
よくある質問
- RFC 7489はいつ公開されましたか？
- RFC 7489は2015年3月に公開されました。
- DMARCは誰が利用できますか？
- 独自ドメインを使用してメールを送信するすべての組織および個人がDMARCを利用できます。
また、なりすまし対策の観点から、利用することが推奨されます。
DMARCはオープンな標準であり、ライセンス費用や利用制限はありません。 - なぜ主要なメールプロバイダーは大量送信者にDMARCを要求するのですか？
- 一般の利用者が、受信したメールが本物かどうかを判断するのは容易ではありません。
そのため、メールサービスプロバイダーは受信トレイへ配信するメールの信頼性を慎重に評価する必要があります。
DMARCは、そのための仕組みを提供します。
DMARCを導入することで、送信者、受信者、そしてメールサービスプロバイダーが連携してメール詐欺やなりすましに対抗できるようになります。
2024年2月以降、GoogleおよびYahooは大量送信者に対して以下を求めています。- SPFまたはDKIMによる認証
- p=none以上のDMARCポリシの設定
- 低いスパム苦情率の維持
- RFC5322.Fromドメインとのアラインメント
- DMARCの設定や適用を支援するツールはありますか？
- はい。
PowerDMARCは、以下のようなツールやサービスを提供しています。
- DMARC Generator
- DMARC Checker
- Hosted DMARCサービス
- その他のDMARC管理ソリューション