DMARC

ドメインベースのメッセージ認証、報告、適合（DMARC）は、電子メール認証プロトコルです。これは、電子メールドメイン所有者が、一般的にメールスプーフィングと呼ばれる不正使用からドメインを保護できるように設計されています。DMARC を実装する目的と主な成果は、ビジネスメール詐欺、フィッシングメール、メール詐欺にドメインが利用されるのを防ぐことです

DMARC DNSエントリが公開されると、受信側のメールサーバーは、ドメイン所有者がDNSエントリ内に公開した指示に基づいて、受信メールを認証できるようになります。メールが認証に合格した場合、配信され、信頼できるようになります。メールが認証に不合格になった場合、DMARCレコード内の指示に応じて、メールは配信、隔離、または拒否されます。

DMARCは、既存の2つのメール認証メカニズム、Sender Policy Framework（SPF）とDomainKeys Identified Mail（DKIM）を拡張します。ドメインの管理者は、DNSレコードにポリシーを公開することで、エンドユーザーに表示されるフィールドのチェック方法From:や、受信側がエラーに対処すべき方法を指定できるようになります。また、これらのポリシーに基づいて実行されたアクションに関するレポートメカニズムも提供します。

DMARCは、インターネット技術タスクフォースが2015年3月に発行した文書RFC 7489 [ 1 ]で「情報」として定義されています。[ 2 ]

概要

DMARCポリシーを使用すると、送信者のドメインは、メールメッセージがSPFまたはDKIMによって保護されていることを示すことができ、受信者はこれらの認証方法のどちらも通過しない場合に、メッセージを拒否するか隔離するかなど、どのような対応を取るべきかを指示できます。また、このポリシーでは、メール受信者が送信者のドメインに、通過または不合格のメッセージを報告する方法も指定できます。[ 3 ]

これらのポリシーは、テキストTXT レコードとしてパブリックドメイン ネーム システム(DNS)に公開されます。

DMARCは、メールがスパムメールであるか、あるいは詐欺メールであるかを直接的に判定するものではありません。DMARCは、メッセージがDKIMまたはSPF検証を通過するだけでなく、§ Alignment（アライメント）も通過することを要求します。DMARCでは、SPFまたはDKIM検証を通過してもアライメントに失敗したメッセージは、不合格となる場合があります。[ 4 ]

DMARCを設定すると、正当な送信者からのメッセージの配信性が向上する可能性があります。[ 5 ]

アライメント

DMARCは、メッセージのFrom:フィールド（「RFC5322.From」[ 2 ]とも呼ばれる）内のドメインが、他の認証済みドメイン名と「整合」しているかどうかを確認することで機能します。SPF（フィールドを使用して指定aspf）またはDKIM（adkimフィールドを使用して指定）のいずれかの整合チェックに合格した場合、DMARCの整合テストも合格となります。

アライメントは、厳密または緩和のいずれかで指定できます。厳密なアライメントの場合、ドメイン名は同一である必要があります。緩和されたアライメントの場合、トップレベルの「組織ドメイン」が一致している必要があります。組織ドメインは、以前はパブリックDNSサフィックスのリストをチェックすることで特定されていました。今後の仕様では、代わりに親ドメインをツリーウォークする方法が規定されています。そのため、例えば「abcdexample.com.au」と「example.com.au」は同じ組織ドメインを持ちます。これは、_dmarc.example.com.auが、_dmarc.auを含むすべてのサブドメインの中で唯一定義されているDMARCレコードであるためです。これによりドメイン所有者がドメインの役割を定義できるため、パブリックサフィックスリストよりも正確であると考えられています。[ 6 ]

SPF や DKIM と同様に、DMARC は、特定の DNS ドメインに変更を加えることが承認されているエンティティ (1 つまたは複数) であるドメイン所有者の概念を使用します。

SPFは、送信元サーバーのIPアドレスがSMTPコマンドに指定されたドメインの所有者によって承認されていることを確認しますMAIL FROM。（MAIL FROMのメールアドレスは、バウンスアドレス、エンベロープ送信元、またはRFC5321.MailFromとも呼ばれます。）DMARCは、SPFチェックの合格に加えて、RFC5321.MailFromがRFC5322.Fromと一致しているかどうかも確認します。[ 2 ]

DKIMでは、メールメッセージの一部を暗号的に署名することができ、署名はFromフィールドをカバーする必要があります。DKIM-Signatureメールヘッダー内のd=(domain)タグとs=(selector)タグは、署名の公開鍵をDNSのどこから取得するかを指定します。有効な署名は、署名者がドメイン所有者であること、そして署名の適用後Fromフィールドが変更されていないことを証明します。1つのメールメッセージに複数のDKIM署名が含まれる場合がありますが、DMARCでは、d=タグ内のドメインがヘッダーフィールドに記載された送信者のドメインと一致する有効な署名が1つ必要ですFrom:。

DNSレコード

_dmarcDMARCレコードは、例えばサブドメインラベルを使用してDNSに公開されます_dmarc.example.com。これをSPF（ ）example.com、DKIM（selector._domainkey.example.com） と比較してください

TXT リソース レコードの内容はname=value、SPF や DKIM と同様に、セミコロンで区切られたタグで構成されます。

利用可能なタグは次のとおりです: [ 7 ]

  • adkim、DKIM アライメント モード (デフォルトrは relaxed、代替sとして strict)
  • aspf、SPFアライメントモード（デフォルトrはrelaxed、代替sはstrict）
  • fo、失敗報告オプション（デフォルト0、または1、d、またはs）
  • p、ポリシー（下記参照）、
  • pct、ポリシーを適用する「不良」メールの割合（デフォルト100）
  • rf、メッセージ固有の障害レポートの形式
  • ri、集計レポート間の要求間隔
  • rua、集計レポートを送信するURI
  • ruf、障害/フォレンジックレポートの送信先URI
  • sp、サブドメインポリシー（デフォルトは と同じp）、
  • v、バージョン、

例： 

「v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:[email protected];」

この例では、example.com DNSドメインを管理する組織は、SPFおよび／またはDKIMの失敗率を監視することを意図しており、example.comのサブドメインからのメール送信は想定していません。サブドメインは独自のDMARCレコードを公開できることに注意してください。受信者は、組織のドメインレコードにフォールバックする前に、そのレコードを確認する必要があります。

段階的な導入

このプロトコルは、メール管理者がDMARCを全く実装していない状態から、完全な実装に至るまで段階的に移行できるよう、様々なラチェット（移行段階）を提供しています。[ 8 ] [ 9 ] [ 10 ] 段階的導入という概念は、DMARCの目標は最も強力な設定であると想定していますが、すべてのドメインでそれが当てはまるわけではありません。目的に関わらず、これらのメカニズムはより柔軟な運用を可能にします。

ポリシー

まず第一に、3つのポリシーがあります。

  • noneはエントリーレベルのポリシーです。受信者による特別な処理は必要ありませんが、ドメインがフィードバックレポートを受信できるようにします
  • 検疫機能は、受信者に対し、DMARCチェックに失敗したメッセージを疑わしいものとして扱うよう指示します。受信者によって、例えばメッセージにフラグを付けたり、スパムフォルダに振り分けたりするなど、その方法は異なります。
  • 拒否は、受信者に DMARC チェックに失敗したメッセージを完全に拒否するように要求します。

公開されたポリシーは、DMARCチェックに失敗したメッセージの一部にのみ適用することで、影響を軽減できます。受信者は、単純なベルヌーイサンプリングアルゴリズムを用いて、指定された割合のメッセージを選択するよう求められます。残りのメッセージは、より低いポリシー、つまり、 の場合はなしp=quarantine、 の場合は隔離されますp=reject。指定されていない場合、 pct はデフォルトでメッセージの100%に適用されます。このケースは、p=quarantine; pct=0;の場合にFrom:フィールドを書き換えないメーリングリスト管理者がいるため、From:フィールドの書き換えを強制するために使用されていますp=none。[ 11 ]

最後に、サブドメインポリシーsp=と新しく追加されたドメインなしポリシーnp=[ 12 ]により、特定のサブドメインのポリシーを微調整することができます。

レポート

DMARCは2種類のレポートを作成できます。集計レポートは に続くアドレスに送信されますrua。フォレンジックレポートは に続くアドレスにメールで送信されます。これらのメールアドレスはURI mailtoruf形式（例：mailto:[email protected]）で指定する必要があります。複数のレポートアドレスを指定することもできますが、それぞれをカンマで区切った完全なURI形式で指定する必要があります。[ 13 ]

対象のメールアドレスは外部ドメインに属している場合があります。その場合、対象ドメインはDMARCレコードを設定して受信に同意していることを示す必要があります。そうしないと、報告機能を悪用してスパムを増幅させる可能性があります。例えば、receiver.exampleメールを受信しFrom: [email protected]、報告したいとします。DMARCレコードが見つかった場合ruf=mailto:[email protected]、対象ドメインが管理する名前空間内で確認用のDNSレコードを検索します。例： 

sender.example._report._dmarc.thirdparty.example IN TXT "v=DMARC1;"

集計レポート

集計レポートはXMLファイルで、通常1日に1回送信されます。件名には、レポートが生成されたDNSドメイン名を示す「レポートドメイン」と、レポートを発行するエンティティである「送信者」が記載されます。ペイロードは、レポート発行受信者、Unix形式のタイムスタンプで表されたレポート期間の開始エポックと終了エポック、オプションの一意の識別子、および可能な圧縮方法に応じた拡張子（以前は.txt .zip）など、ビッチェルで区切られた要素で構成される長いファイル名の添付ファイルです。[ 14 ]

例えば： example.com!example.org!1475712000!1475798400.xml.gz。

XMLコンテンツは、レポートの基となるポリシーとレポートのメタデータを含むヘッダーと、それに続く複数のレコードで構成されます。レコードはリレーションとしてデータベースに格納され、表形式で表示できます。XMLスキーマは仕様書[ 15 ]の付録Cで定義されており、生のレコードの例はdmarc.org [ 16 ]に掲載されています。ここでは、データの性質をよりよく伝えるリレーショナルな例を使用します。DMARCレコードは、 XSLスタイルシートを適用することでHTMLに直接変換することもできます。

集計レコードの DMARC 行を表形式で表示
送信元IPカウント 処理SPFDKIM ヘッダー元 SPFドメイン（結果） DKIMドメイン（結果）  
192.0.2.112 なし 合格 合格example.org example.org ( 合格) example.org ( 合格)  
192.0.2.11 なし 合格✗ 不合格example.org example.org ( 合格) example.org ( ✗ 不合格)  
192.0.2.2842 なし✗ 不合格 合格example.org example.org ( ✗ 不合格) example.org ( 合格) forwarder.example ( パス)
192.0.2.8221 なし✗ 不合格✗ 不合格example.org ディスカッションリストの例 ( 合格) example.org ( ✗ 不合格) ディスカッションリストの例 ( 合格)
...

行はソース IP および認証結果ごとにグループ化され、各グループのカウントのみが渡されます。SPFおよびDKIMというラベルの付いた左端の結果列には、アライメントを考慮した DMARC ごとの合格または不合格の結果が表示されます。同様のラベルの右端の列には、メッセージの送信に参加していると主張するドメイン名と (括弧内に) 識別子アライメントに関係なく元のプロトコル (SPF または DKIM) に従ったその主張の認証ステータスが表示されます。右側では、SPF はテスト用に 1 回とテスト用に 1 回の合計 2 回まで表示できます。DKIM はメッセージにある署名ごとに 1 回表示できます。例では、最初の行は example.org からの主要なメール フローを表し、2 行目は DKIM の不具合 (送信中の小さな変更による署名の破損など) を表しています。3 行目と 4 行目はそれぞれ転送側とメーリング リストの一般的な障害モードを示しています。DMARC 認証は最後の行でのみ失敗しました。 example.org が厳格なポリシーを指定していた場合、メッセージの処理に影響した可能性があります。 Return-Path:HELO

処理結果は、メッセージに実際に適用された公開ポリシー（none、quarantine、またはreject ）を反映します。表には示されていませんが、DMARCはポリシーのオーバーライドも規定しています。受信者が要求されたポリシーとは異なるポリシーを適用できる理由は、仕様で既に規定されています。

転送
同じバウンスアドレスを維持しながら、通常はDKIMを破ることはありません。
サンプル抽出
送信者はポリシーをメッセージの割合のみに適用することを選択できるため、
信頼できる転送業者
メッセージはローカルで既知のソースから届きました
メーリングリスト
受信者は、メッセージがメーリングリストから届いたことをヒューリスティックに判断し、
ローカルポリシー
受信者は好きなポリシーを自由に適用できますが、送信者に知らせるのは良いことです
その他
上記のいずれにも該当しない場合は、コメント欄に詳細を記入してください。

故障報告

失敗レポート（フォレンジックレポートとも呼ばれる）はリアルタイムで生成され、タグに指定された値に基づいて、SPF、DKIM、またはその両方で失敗した個々のメッセージのコピー（編集されている可能性があります）で構成されます。その形式はAbuse Reporting Formatfoの拡張であり、「message/rfc822」または「text/rfc822-headers」のいずれかを含む点で、通常のバウンスメールの形式に似ています。

法医学レポートには以下の内容も含まれます。

  • 送信元IPアドレス（メッセージ送信者）
  • 送信元ポート（RFC 6692に準拠）
  • 送信元メールアドレス
  • 受信者メールアドレス
  • メール件名
  • SPFおよびDKIM認証結果
  • 受信時刻
  • 送信ホスト、メールメッセージID、DKIM署名、その他のカスタムヘッダー情報を含むメールメッセージヘッダー。[ 17 ]

互換性

フォワーダー

メール転送にはいくつかの種類があり、その中にはSPFを破ってしまうものもあります。[ 18 ]これがメール転送がDMARC認証の結果に影響を与える理由の一つです。[ 19 ]

メーリングリスト

メーリングリストは、例えば件名ヘッダーにプレフィックスを追加するなど、元の作成者のドメインDKIM署名の正当な破壊の頻繁な原因となります。いくつかの回避策が可能であり、[ 20 ] [ 21 ]、メーリングリストソフトウェアパッケージは解決策の開発に取り組んでいます。[ 22 ]

すべてのメッセージの変更をオフにする

この回避策は標準的なメーリングリストのワークフローを維持し、多くの大規模メーリングリスト運営者によって採用されていますが、リストにフッターや件名プレフィックスを追加することはできません。[ 23 ]署名付きヘッダーが並べ替えられたり変更されたりしないように、メーリングソフトウェアを慎重に設定する必要があります。設定ミスのあるメールサーバーは、メーリングリストに送信されたメッセージのDKIMにList-idを挿入してしまう可能性があり、その場合、メーリングリスト運営者はメッセージを拒否するか、From:を書き換える必要に迫られます。

From:書き換え

最も一般的で、最も邪魔にならない回避策の1つは、From:ヘッダーフィールドを書き換えることです。これにより、元の作成者のアドレスをフィールドに追加できますReply-To:。[ 24 ]書き換えは、ドメイン名に.INVALID[注1 ]を追加するだけのものから、ユーザーのアドレスを変更したバージョンを使用して一時的なユーザーIDを割り当てるもの、またはユーザーの「実際の」メールアドレスをリストから非公開にする不透明IDを使用するものまで多岐にわたります。さらに、表示名を変更して、作成者とリスト（またはリスト運営者）の両方を表示することもできます。[ 25 ]これらの例は、それぞれ次のいずれかの結果になります 

送信者: John Doe <[email protected]>送信者: John Doe <[email protected]>送信者: John Doe <[email protected]>送信者: John Doe (メーリングリスト経由) <[email protected]>返信先: John Doe <[email protected]>

最後の行はReply-To:、投稿者への返信機能に対応するように設計する必要があります。この場合、リストへの返信機能は、前述のFrom:ヘッダーフィールドの変更によってカバーされます。これにより、これらのフィールドの本来の意味が逆転します。

著者名を変更することは一般的に公平ではなく、そのデータの意味と外観との間の期待される関係を壊す可能性があります。また、データの自動的な利用も妨げます。メーリングリストを使用して作業を調整し、From:添付ファイルの著者を付与するためにフィールドを使用するツールを導入しているコミュニティもあります。[ 26 ]

その他の回避策

メッセージをラッピングすることは、ラッピングされたメッセージを理解するメールクライアントを使用している場合はうまく機能します。何も変更しないことがおそらく最も明白な解決策ですが、一部の国では法的に義務付けられているようで、SPF認証が定期的に失われると、認証全体がより脆弱になる可能性があります。[ 27 ]

送信者フィールド

From:DKIMアライメントを通過するためにヘッダーフィールドを変更すると、 RFC 5322セクション3.6.2「『From:』フィールドは、メッセージの作成者、つまりメッセージの作成を担当した人物またはシステムのメールボックスを指定します。」に準拠しなくなる可能性があります。メールボックスとは、作成者のメールアドレスを指します。このSender:ヘッダーは、メールが別の当事者に代わって送信されたことを示すために使用できますが、DMARCは送信元ドメインのポリシーのみをチェックし、送信者ドメインは無視します。[注2 ]

ADSPとDMARC [ 4 ]はどちらも、多くのユーザーエージェントが受信者にこれを表示しないという非技術的な理由で、送信者フィールドの使用を拒否しています。

歴史

DMARC仕様のドラフトは2012年1月30日から維持されています。[ 28 ]

2013年10月、DMARCポリシーを持つドメインからの投稿者を処理するオプションを備えたGNU Mailmanp=reject 2.1.16がリリースされました。[ 22 ]この変更は、制限的なポリシーが人間のユーザーを持つドメイン（純粋にトランザクションメールのドメインとは対照的）に適用された場合に予想される相互運用性の問題を予測しようとするものでした。

2014年4月、YahooはDMARCポリシーをに変更しp=reject、それによっていくつかのメーリングリストで不正行為を引き起こしました。[ 29 ] [ 30 ]数日後、AOLもDMARCポリシーをに変更しましたp=reject。[ 31 ]これらの動きは大きな混乱をもたらし、これらのメールボックスプロバイダーは、セキュリティ上の失敗のコストを第三者に押し付けていると非難されています。[ 32 ] 2020年現在、公式DMARC wikiのFAQには、厳格なDMARCポリシーを持つドメインからのメッセージをメーリングリストが処理するための提案がいくつか含まれています。[ 33 ]その中で最も広く実装されているのは、メーリングリストが「From」ヘッダーを自分のドメインのアドレスに変更することです。

2014年8月、相互運用性に関する懸念から始まり、標準仕様とドキュメントの改訂まで継続する可能性のあるDMARCの問題に対処するため、IETFワーキンググループが結成されました。[ 34 ]一方、既存のDMARC仕様は、多くの人々の合意と実装を得て編集段階に達していました。2015年3月、Independent Submissionストリームの「Informational」（非標準）カテゴリでRFC 7489として公開されました。[ 35 ]

2017年3月、連邦取引委員会は企業によるDMARCの使用に関する調査を発表しました。[ 36 ]調査では、569社のうち約3分の1が何らかのDMARC構成を実装し、10%未満がDMARCを使用して認証されていないメッセージを拒否するようにサーバーに指示し、大多数がSPFを実装していることがわかりました。

貢献者

DMARC仕様の貢献者は次のとおりです。[ 37 ] [ 38 ]

商用サービス

DMARC分析やレコード検証を実行する一般的なサービスには、Red Sift、Valimail、dmarcian、DMARC Advisor、EasyDmarc、Cloudflareなどがあります。[ 43 ]

参照

注記

  1. ^ INVALIDは、この種の使用のためにRFC 2606で予約されているトップレベルドメインです
  2. ^リメーラーによる送信者フィールドの使用については、RFC 4871 のセクション B.1.4 および B.2.3 で説明されています (DMARC ではなく DKIM のコンテキストで)。

参考文献

  1. ^ RFC  7489
  2. ^ a b c Murray Kucherawy、Elizabeth Zwicky (2015年3月18日).ドメインベースメッセージ認証、報告、適合性 (DMARC) . IETF . doi : 10.17487 /RFC7489 . RFC 7489
  3. ^ Terry Zink (2016年9月27日). 「microsoft.com を ap=quarantine DMARC レコードに移行した方法」 . MSDNブログ.大変な作業のように思えるかもしれませんが、それは
  4. ^ a b Kucherawy, M. ; Zwicky, E. (2013年7月15日). 「ドメインベースメッセージ認証、レポート、適合性 (DMARC) [ドラフト01]」 IETF. 付録A.3、送信者ヘッダーフィールド. 2016年5月24日閲覧。
  5. ^ 「一括送信ガイドライン - Gmailヘルプ」 support.google.com 2015年4月24日閲覧。
  6. ^ Dave Crocker (2020年11月24日). 「PSL検索ではなくツリーウォークを実行する」 . dmarc-ietf (メーリングリスト).
  7. ^ RFC 7489 . 6.3節. doi : 10.17487/RFC7489 .
  8. ^ 「チュートリアル: 推奨される DMARC ロールアウト」 . google.com .
  9. ^ 「実装ガイダンス：電子メールドメイン保護」cyber.gc.ca . 2021年8月12日。
  10. ^ 「Cisco Domain Protection のユーザー ガイド」(PDF) . cisco.com . 2021 年 5 月 25 日。
  11. ^ジョナサン・カーメンズ (2018年10月9日)。」「p=なし」と「p=隔離; pct=0」（メーリングリスト）。
  12. ^ Scott Kitterman (2021年7月26日). Tim Wicinski (編).パブリックサフィックスドメイン向けの実験的なドメインベースメッセージ認証、レポート、および適合性（DMARC）拡張. IETF . doi : 10.17487/RFC9091 . RFC 9091 .
  13. ^ 「RUA vs RUF - DMARCレポートの各種タイプについて解説」 Progist.net 、 2023年12月14日。 2023年12月14日閲覧。
  14. ^ 「集計レポートにZIP形式を選択する根拠は何ですか？」 DMARC.org 2012年2019年4月3日閲覧。GZIPがIANAにMIMEアプリケーションタイプとして登録されると、DMARCグループはそれをドラフトに含めることを検討します。
  15. ^ Murray S. Kucherawy、Elizabeth Zwicky編（2015年3月）。「DMARC XMLスキーマ」。ドメインベースメッセージ認証、レポート、および適合性（DMARC）。IETF。sec . C。doi : 10.17487 /RFC7489。RFC 7489。 2019年3月3日閲覧。
  16. ^ 「集計レポートを実装する必要がありますが、どのようなものになるのでしょうか？」 DMARC.org . 2016年5月26日閲覧。
  17. ^ 「2022年版DMARCレポート完全ガイド」 2019年8月23日。
  18. ^ Franck Martin、Eliot Lear 、 Tim Draegen、Elizabeth Zwicky、Kurt Andersen編（2016年9月）。「Alias」。ドメインベースのメッセージ認証、レポート、適合性（DMARC）と間接メールフローの相互運用性に関する問題。IETF。sec . 3.2.1。doi : 10.17487 /RFC7960。RFC 7960。2017年3月14日閲覧。
  19. ^ 「メール転送はDMARC認証結果にどのような影響を与えるか？」 progist.net 2023年1月6日。
  20. ^ Anti-Spam Research Group . 「第三者メールへのDMARC被害の軽減」
  21. ^ dmarc.org ウィキ
  22. ^ a bマーク・サピロ (2013 年 10 月 16 日)。「郵便配達員とDMARC」。list.org 。2015 年8 月 13 日に取得。
  23. ^ 「lists.debian.org の今後の変更」 . lists.debian.org .
  24. ^ Al Iverson (2014年4月9日). 「スパムリソース：メールディスカッションリストを運営していますか？DMARCへの対応方法」spamresource.com . 2014年4月18日閲覧。
  25. ^ 「ThreadableがDMARCの問題を解決した方法」Threadableブログ。2016年5月21日閲覧。
  26. ^ Theodore Ts'o (2016年12月18日). 「DMARCへの現実的な対応」 . IETF-Discussion (メーリングリスト) . 2017年3月14日閲覧. fromフィールドが書き換えられないという事実は重要です。fromフィールドを書き換えると、「git am」コマンドが機能しなくなるからです。これは、From:フィールドを使ってgitコミットのfromフィールドを埋めるからです。
  27. ^ John Levine (2014年5月31日). 「DMARCによる第三者メールへの被害の軽減」 . wiki . ASRG . 2014年6月1日閲覧。
  28. ^「歴史」、dmarc.org
  29. ^ Lucian Constantin (2014年4月8日). 「Yahooメールのなりすまし対策ポリシーがメーリングリストに悪影響」 . PC World . 2014年4月15日閲覧。
  30. ^ Laura Atkins (2014年4月12日). 「Yahoo!のDMARCポリシーに関する声明」 . wordtothewise.com.
  31. ^ Vishwanath Subramanian (2014年4月22日). 「AOLメールがDMARCポリシーを「拒否」に更新」" . AOL . 2015年8月13日時点のオリジナルよりアーカイブ。2015年8月13日閲覧。
  32. ^ John Levine (2016年8月13日). 「DMARCとietf.org」 . IETF (メーリングリスト) . 2016年10月10日閲覧。
  33. ^ "DMARC wiki の FAQ" . 2020 年7 月 15 日に取得。
  34. ^ 「WGアクション：形成されたドメインベースのメッセージ認証、レポート、適合性（dmarc）」 IETF -Announce（メーリングリスト）2014年8月11日。 2016年10月10日閲覧。
  35. ^ 「DMARC FAQ」 . dmarc.org .
  36. ^ 「企業は電子メール認証を利用してフィッシングを阻止し、ブランドを保護することができる」（PDF）。連邦取引委員会。2017年3月3日。
  37. ^ Kucherawy, Murray; Zwicky, Elizabeth. 「謝辞」 .ドメインベースメッセージ認証、レポート、および適合性（DMARC） . sec. E. ID draft-kucherawy-dmarc-base-01.
  38. ^ DMARC貢献者（PDF）
  39. ^ Vitaldevara, Krish (2012年12月10日). 「Outlook.com、DMARCおよびEV証明書のサポートによりセキュリティを強化」 . Outlook Blog . Microsoft . 2012年12月12日閲覧。
  40. ^ Martin, Franck (2012年9月20日). 「DMARC: 本物のメールを検出するための新しいツール」 . LinkedInエンジニアリングブログ. Linkedin . 2013年8月17日閲覧。
  41. ^ Josh Aberant (2013年2月21日). 「Twitter.comメール向けDMARCの導入」 . twitter.com . 2014年4月10日閲覧。
  42. ^ a b c d e f g「History – dmarc.org」 . dmarc.org . 2020年9月23日閲覧。
  43. ^ Hureau, Olivier; Bayer, Jan; Duda, Andrzej; Korczyński, Maciej (2024). Richter, Philipp; Bajpai, Vaibhav; Carisimo, Esteban (編). 「なりすましメール：DMARCの大規模導入を阻む問題の分析」 . Passive and Active Measurement . Cham: Springer Nature Switzerland: 232– 261. doi : 10.1007/978-3-031-56249-5_10 . ISBN 978-3-031-56249-5。

「 https://en.wikipedia.org/w/index.php?title=DMARC&oldid=1325148516」より取得