Loading article…
ドメインベースメッセージ認証、レポート、および適合性（DMARC）は、電子メール認証プロトコルです。これは、電子メールドメインの所有者が、一般的に電子メールスプーフィングとして知られる不正使用からドメインを保護できるように設計されています。DMARCを実装する目的と主な成果は、ビジネスメール詐欺攻撃、フィッシングメール、および電子メール詐欺でドメインが悪用されるのを防ぐことです。
DMARC DNSエントリが公開されると、受信側のメールサーバーは、ドメイン所有者がDNSエントリ内に公開した指示に基づいて、受信メールを認証できます。メールが認証に合格すれば、配信され、信頼できるメールとして扱われます。認証に失敗した場合、DMARCレコードに記述された指示に応じて、メールは配信されるか、隔離されるか、拒否されるかのいずれかになります。
DMARCは、既存の2つのメール認証メカニズムであるSender Policy Framework（SPF）とDomainKeys Identified Mail（DKIM）を拡張したものです。ドメインの管理者は、DNSレコードにポリシーを公開することで、エンドユーザーに表示されるフィールドのチェック方法From:や、受信側がエラーが発生した場合の処理方法を指定できます。また、これらのポリシーに基づいて実行されたアクションを報告するメカニズムも提供します。
DMARCは、インターネット技術タスクフォースが2026年5月に公開した文書RFC 9989 [ 1 ]で「標準化トラック」として定義されています。[ 2 ]
DMARCポリシーでは、送信者のドメインが電子メールメッセージがSPFおよび/またはDKIMによって保護されていることを示すことができ、これらの認証方法のいずれも通過しなかった場合に受信者が何をすべきか（メッセージを拒否したり隔離したりするなど）を指示します。このポリシーでは、電子メールの受信者が通過したメッセージと失敗したメッセージについて送信者のドメインに報告する方法も指定できます。[ 3 ]
これらのポリシーは、パブリックドメインネームシステム（DNS）にテキスト形式のTXTレコードとして公開されます。
DMARCは、メールがスパムか不正メールかを直接判断するものではありません。その代わりに、DMARCはメッセージがDKIMまたはSPFの検証に合格するだけでなく、§ アライメントにも合格することを要求できます。DMARCでは、メッセージがSPFまたはDKIMに合格しても、アライメントに不合格であれば失敗する可能性があります。[ 4 ]
DMARCを設定することで、正当な送信者からのメッセージの配信率が向上する可能性があります。[ 5 ]
From:DMARCは、メッセージのフィールド（「RFC5322.From」[ 2 ]とも呼ばれる）のドメインが、他の認証済みドメイン名と「一致」しているかどうかを確認することで動作します。SPF（フィールドを使用して指定aspf）またはDKIM（adkimフィールドを使用して指定）のいずれかの一致チェックに合格すれば、DMARCの一致テストに合格します。
アライメントは厳密または緩和として指定できます。厳密なアライメントの場合、ドメイン名は同一である必要があります。緩和されたアライメントの場合、トップレベルの「組織ドメイン」が一致する必要があります。組織ドメインは、以前は公開DNSサフィックスのリストをチェックすることで見つけられていました。今後の仕様では、代わりに親ドメインをツリーウォークするように指定されています。たとえば、「abcdexample.com.au」と「example.com.au」は同じ組織ドメインを持ちます。これは、_dmarc.auを含むすべてのサブドメインの中で、_dmarc.example.com.auだけが定義されているDMARCレコードであるためです。これにより、ドメイン所有者がドメインの役割を定義できるため、公開サフィックスリストよりも正確であると考えられています。[ 6 ]
SPFやDKIMと同様に、DMARCはドメイン所有者という概念を使用します。ドメイン所有者とは、特定のDNSドメインに変更を加える権限を与えられた主体または複数の主体を指します。
SPF は、送信サーバーのIP アドレスが SMTP コマンドに表示されるドメインの所有者によって承認されているかどうかを確認しますMAIL FROM。(MAIL FROM の電子メール アドレスは、バウンス アドレス、エンベロープ フロム、または RFC5321.MailFrom とも呼ばれます。) DMARC は、SPF チェックに合格することに加えて、RFC5321.MailFrom が 5322.From と一致しているかどうかも確認します。[ 2 ]
DKIMでは、電子メールメッセージの一部を暗号署名することができ、署名はFromフィールドをカバーしている必要があります。DKIM-Signatureメールヘッダー内のd=(domain)タグとs=(selector)タグは、署名用の公開鍵をDNSのどこから取得するかを指定します。有効な署名は、署名者がドメイン所有者であり、署名が適用されてからFromフィールドが変更されていないことを証明します。電子メールメッセージには複数のDKIM署名が存在する可能性がありますが、DMARCでは、タグ内のドメインがヘッダーフィールドに記載されている送信者のドメインと一致する有効な署名が1つ必要です。d=From:
_dmarcDMARCレコードは、例えばサブドメインラベルとともにDNSに公開されます_dmarc.example.com。これをSPF（example.com）やDKIM（）と比較してみてくださいselector._domainkey.example.com。
TXTリソースレコードの内容はname=value、SPFやDKIMと同様に、セミコロンで区切られたタグで構成されています。
利用可能なタグは次のとおりです: [ 7 ]
rはrelaxed、代替sとしてstrict）rはリラックス、代替sとして厳格）0、または1、dまたはs）100）p）、例えば：
"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"この例では、example.com DNSドメインを管理する組織は、SPFおよび/またはDKIMの失敗率を監視することを目的としており、example.comのサブドメインからメールが送信されることは想定していません。なお、サブドメインは独自のDMARCレコードを公開できます。受信者は、組織のドメインレコードにフォールバックする前に、そのサブドメインのレコードを確認する必要があります。
このプロトコルでは、さまざまな段階、つまり移行状態が用意されており、メール管理者がDMARCを全く実装しない状態から、完全に適用する設定まで段階的に移行できるようになっています。[ 8 ] [ 9 ] [ 10 ] 段階的な導入という概念は、DMARCの目標が最も強力な設定であることを前提としていますが、これはすべてのドメインに当てはまるわけではありません。意図に関係なく、これらのメカニズムによって柔軟性が高まります。
まず第一に、３つの方針があります。
公開されたポリシーは、DMARC チェックに失敗したメッセージの一定割合にのみ適用することで緩和できます。受信者は、単純なベルヌーイサンプリングアルゴリズムによって指定された割合のメッセージを選択するように求められます。残りのメッセージは、より低いポリシーに従う必要があります。つまり、 の場合は何も適用されずp=quarantine、 の場合は隔離されますp=reject。指定されていない場合、pct はデフォルトでメッセージの 100% になります。 の場合、一部のメーリングリスト管理者は From: フィールドを書き換えないため、このケースはp=quarantine; pct=0;メーリングリスト管理者に From: フィールドを書き換えるように強制するために使用されていますp=none。[ 11 ]
最後に、サブドメインポリシーsp=と新たに追加されたドメインなしポリシーnp=[ 12 ]により、特定のサブドメインのポリシーを調整できます。
DMARC は 2 種類のレポートを生成できます。集計レポートは、タグの後に指定されたアドレスに送信されますrua。フォレンジックレポートは、タグの後に指定されたアドレスに電子メールで送信されます。これらのメールアドレスは、 URI mailto形式 (例: mailto:worker@example.netruf )で指定する必要があります。複数のレポートアドレスも有効で、それぞれ完全な URI 形式で、カンマで区切って指定する必要があります。[ 13 ]
ターゲットのメールアドレスは外部ドメインに属する場合があります。その場合、ターゲットドメインは受信に同意する旨のDMARCレコードを設定する必要があります。そうしないと、スパム増幅のために報告が悪用される可能性があります。たとえば、 がreceiver.exampleメールメッセージを受信しFrom: someone@sender.example、それを報告したいとします。 が を見つけた場合ruf=mailto:some-id@thirdparty.example、ターゲットが管理するネームスペースで、次のような確認DNSレコードを探します。
sender.example._report._dmarc.thirdparty.example IN TXT "v=DMARC1;"集計レポートは、通常 1 日 1 回、XMLファイルとして送信されます。件名には、レポートが生成された DNS ドメイン名を示す「レポート ドメイン」と、レポートを発行するエンティティである「送信者」が記載されています。ペイロードは、レポート発行の受信者、Unix スタイルのタイム スタンプとして報告期間の開始および終了エポック、オプションの一意の識別子、および可能な圧縮に依存する拡張子(以前は.zip) などの要素を bang で区切った長いファイル名を持つ添付ファイルです。[ 14 ]
例えば： example.com!example.org!1475712000!1475798400.xml.gz。
XML コンテンツは、レポートの基となるポリシーとレポートのメタデータを含むヘッダーと、それに続く複数のレコードで構成されます。レコードは、データベースにリレーションとして格納し、表形式で表示できます。XML スキーマは仕様書の付録 C [ 15 ]で定義されており、生のレコードの例は dmarc.org [ 16 ]で示されています。ここでは、データの性質をよりよく伝えるために、リレーションの例を使用します。DMARC レコードは、 XSL スタイルシートを適用することで、HTMLに直接変換することもできます。
行は送信元IPと認証結果でグループ化され、各グループのカウントのみが渡されます。SPFとDKIMというラベルが付いた一番左の結果列には、アライメントを考慮したDMARCごとの結果（合格または不合格）が表示されます。同様のラベルが付いた一番右の列には、メッセージの送信に参加していると主張するドメインの名前と、（括弧内に）識別子アライメントに関係なく、元のプロトコル（SPFまたはDKIM）によるその主張の認証ステータスが表示されます。右側では、SPFはテストとテストでそれぞれ1回ずつ、最大2回表示できます。DKIMは、メッセージに含まれる署名ごとに1回表示できます。この例では、最初の行はexample.orgからのメインのメールフローを表し、2番目の行は、転送中の軽微な変更による署名の破損など、DKIMの不具合を表しています。3番目と4番目の行は、それぞれ転送業者とメーリングリストの典型的な障害モードを示しています。最後の行のみDMARC認証が失敗しました。example.orgが厳格なポリシーを指定していた場合、メッセージの処理に影響があった可能性があります。Return-Path:HELO
この処理結果は、公開されたポリシーのうち実際にメッセージに適用されたもの（なし、隔離、拒否）を示しています。また、表には示されていませんが、DMARCではポリシーの上書きも可能です。受信側が要求されたポリシーとは異なるポリシーを適用できる理由については、仕様書に既に規定されています。
フォレンジックレポートとも呼ばれる障害レポートは、リアルタイムで生成され、タグで指定された値に基づいて、SPF、DKIM、またはその両方に失敗した個々のメッセージの、編集済みのコピーで構成されます。その形式は、不正利用報告フォーマットfoの拡張であり、通常のバウンスと同様に「message/rfc822」または「text/rfc822-headers」のいずれかを含みます。
鑑識報告書には、以下の内容も含まれます。
メール転送にはいくつかの種類があり、その中にはSPFを破るものもあります。[ 18 ]これは、メール転送がDMARC認証結果に影響を与える可能性がある理由の1つです。[ 19 ]
メーリングリストは、例えば件名ヘッダーにプレフィックスを追加するなどして、元の著者のドメインDKIM署名を正当に破壊する原因となることがよくあります。いくつかの回避策が可能であり、[ 20 ] [ 21 ]メーリングリストソフトウェアパッケージは解決策に取り組んでいます。[ 22 ]
この回避策は標準的なメーリングリストのワークフローを維持し、いくつかの大規模なメーリングリスト運営者に採用されていますが、リストがフッターや件名接頭辞を追加することを妨げます。[ 23 ]署名付きヘッダーが並べ替えられたり変更されたりしないように、メーリングソフトウェアを慎重に構成する必要があります。設定が誤っているメールサーバーは、メーリングリストに送信されたメッセージの DKIM に List-id を入れる可能性があり、その場合、リスト運営者はそれを拒否するか From: を書き換える必要があります。
From:書き換え最も一般的で影響の少ない回避策の 1 つは、From:ヘッダー フィールドを書き換えることです。元の著者のアドレスをそのReply-To:フィールドに追加できます。[ 24 ]書き換えは、ドメイン名に.INVALID[注 1 ]を追加するだけの場合から、ユーザーのアドレスの変更版を使用する一時的なユーザー ID を割り当てる場合、またはユーザーの「実際の」メールアドレスをリストから非公開にする不透明な ID を使用する場合まで、さまざまな方法があります。さらに、表示名を変更して、著者とリスト (またはリスト オペレーター) の両方を表示することもできます。[ 25 ]これらの例は、それぞれ次のいずれかの結果になります。
差出人: John Doe <user@example.com.INVALID>差出人: John Doe <user@example.com.dmarc.fail>差出人: John Doe <243576@mailinglist.example.org>差出人: John Doe ( MailingList経由) <list@mailinglist.example.org>返信先: John Doe <user@example.com>最後の行はReply-To:、投稿者への返信機能に対応するように設計する必要があります。この場合、リストへの返信機能は、From:ヘッダーフィールドの前の修正によってカバーされます。このようにして、これらのフィールドの本来の意味が逆転します。
一般的に、著者を変更することは公平ではなく、そのデータの意味と外観の間の期待される関係を壊してしまう可能性があります。また、そのデータの自動使用も妨げてしまいます。メーリングリストを使用して作業を調整し、From:添付ファイルに著者を割り当てるためにそのフィールドを使用するツールを展開しているコミュニティがあります。[ 26 ]
メッセージをラップする方法は、ラップされたメッセージを理解するメールクライアントを使用しているユーザーにとってはうまく機能します。何も変更しないことがおそらく最も明白な解決策ですが、一部の国では法的に義務付けられているようで、SPF認証が定期的に失われると、認証全体がより脆弱になる可能性があります。[ 27 ]
DKIM アライメントを通過するためにヘッダー フィールドを変更すると、From:メッセージがRFC 5322セクション 3.6.2 に準拠しなくなる可能性があります。「'From:' フィールドはメッセージの作成者、つまりメッセージの作成を担当する人物またはシステムのメールボックスを指定します。」メールボックスは作成者の電子メール アドレスを指します。ヘッダーは、電子メールがSender:他の当事者に代わって送信されたことを示すために使用できますが、DMARC は From ドメインのポリシーのみをチェックし、Sender ドメインは無視します。[注 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」ヘッダーを自社ドメインのアドレスに変更することです。
DMARC の問題に対処するため、相互運用性に関する懸念から始まり、改訂された標準仕様とドキュメントの作成へと続く可能性のある作業グループが 2014 年 8 月にIETFに設立されました。 [ 34 ]一方、既存の DMARC 仕様は、多くの人が合意し実装した編集段階に達していました。これは、 RFC 7489として、2015 年 3 月に Independent Submission ストリームの「Informational」（非標準）カテゴリで公開されました。[ 35 ]
2017年3月、連邦取引委員会は企業によるDMARCの使用に関する調査を発表しました。[ 36 ] 569の企業のうち、約3分の1が何らかのDMARC構成を実装しており、10%未満がDMARCを使用して認証されていないメッセージを拒否するようにサーバーに指示しており、大多数がSPFを実装していることがわかりました。
更新されたRFC 9989は2026年5月に公開されました。
DMARC仕様の貢献者には以下が含まれます: [ 37 ] [ 38 ]
DMARC分析やレコード検証を行う人気のサービスには、Red Sift、Valimail、dmarcian、DMARC Advisor、EasyDmarc、Cloudflareなどがあります。[ 43 ]
んが、それは
がIANAにMIMEアプリケーションタイプとして登録されると、DMARCグループはそれをドラフトに含めることを検討します。
フィールドが書き換えられないという事実は重要です。なぜなら、fromフィールドを書き換えると、git amコマンドが壊れてしまうからです。git amコマンドはFrom:フィールドを使用して
git
コミットのfromフィールドを埋めるからです。