送信ドメイン認証のベストプラクティス文書 (M3AAWG)

2023年4月16日2024年3月2日

当サイトには広告を含みます。

当サイトでは、広告掲載ポリシーに沿って広告を掲載しています。

"オススメ" として紹介している商品やサービスは、個人的にそう思えたものだけです。

共感、興味をもっていただけるものがあればご利用ください。

タブレットが気になる

高解像 (FHD+) な8インチタブレットを比較

クレカ積立10月買付分まで10万円×5%還元

【10万Pチャレンジャー求む】プラチナプリファード初年度フル活用

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証 (Sender Domain Authentication)。

その送信ドメイン認証に関し、M3AAWGから発行されたベストプラクティス文書があります。本記事ではその概要をまとめておきます。

※本記事は、あくまで私の認識に基づくまとめです。詳細については原文をご確認願います。

SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証のまとめ記事はこちらです。

M3AAWG

M3AAWG(※)は、様々なネットワーク上の脅威への対策について、ベストプラクティス発行やミーティング開催を行っているグローバルな組織です。
(※)The Messaging, Malware, and Mobile Anti-Abuse Working Group

電子メールの送信ドメイン認証についても扱っています。

日本における関連組織はJPAAWGです。

送信ドメイン認証に関するベストプラクティス

M3AAWG の Webサイトでは、ベストプラクティス文書も公開されています。

その中から、本記事では、2020年に発行された “M3AAWG Email Authentication Recommended Best Practices” という文書について記載していきます。

M3AAWG Email Authentication Recommended Best Practices (PDF)

9ページで要点をまとめた文書

ページ数は少なく、概要レベルで要点をまとめてあります。
詳細については別の文書等を参照するよう構成されています。

“No auth, no entry”

“2. Introduction”では、“No auth, no entry” という表現が登場します。

適切な認証 (送信ドメイン認証) に成功した電子メールのみが、その宛先 (recipient) に配送されるという考え方です。

この“No auth, no entry”が広く普及した際にも対応できるよう、M3AAWGから各ベストプラクティスが発行されています。

観点として、DMARC (RFC7489) に沿った、組織ドメイン (organizational domain) の保護が挙げらています。

(2024年1月追記) この “No Auth, No Entry” の適用と言われる動向については、以下の記事にまとめてあります。

4つの認証プロトコル

この文書は、以下の4つのプロトコルについて言及しています (“3. Scope”)。

SPF (Sender Policy Framework) RFC 7208
DKIM (Domain Keys Identified Mail) RFC 6376
DMARC (Domain-based Message Authentication, Reporting, and Conformance) RFC 7489
ARC (Authenticated Received Chain) RFC 8617

本記事の作成時点 (2023年4月) で、上記RFCが最新のままなので、基本的な考え方について大きな読み替えは不要かと思います。

最新の補足事項として、RFC 7489 を Obsoletes する予定の次期DMARC (DMARCbis、2023年4月時点でInternet-Draft)の策定が進むと、さらに相互運用性に関する考慮事項等がまとめられていくと思います。機会があれば別記事にまとめます。

Sender、Intermediary、Receiverそれぞれに対する推奨事項

“4. Executive Summary: A Checklist”では、Sender、Intermediary、Receiverという3つの分類に沿って推奨事項がチェックリスト形式でまとめられています。

出典："M3AAWG Email Authentication Recommended Best Practices" — 出典：”M3AAWG Email Authentication Recommended Best Practices”

続いて、”5. Authentication Recommendation Discussion” で、より詳細が解説されています。

Sender、Intermediary、Receiverの定義

3つの分類は以下です。RFCの表現が考慮されています。

Senders (labeled in RFC 5598 as Authors or Originators)
- ブランドオーナー (文脈から組織ドメインとして)、メールボックスやメールサービスのプロバイダーを含みます。
- ただし、人から人に送信されるメールの送信者は含まない (その送信者自身がドメインやブランドのオーナーでない限り)。
- 本記事では、”送信するドメイン側” と呼びます。

Intermediaries (as a catch-all for the RFC 5598 terms Mediators, Relays, or Gateways)
- 電子メールの転送サービスやメーリングリストサービス等を含みます。
- 一般的なメールボックスプロバイダーが転送機能を提供している場合にも該当します。
- 本記事では、”中継者”と呼びます。

Receivers
- 電子メールの宛先 (recipient) のために、電子メールを受信、格納(ストア)するドメインのことです。
- 電子メールの宛先 (recipient) 自体は、Receivers には該当しません。
- 本記事では、”受信する側” と呼びます。

Sender (送信するドメイン側) のベストプラクティス

SPF、DKIM、DMARCを使用するよう記載されており、それぞれのベストプラクティスの参照先も挙げられています。

ARCの使用については言及されていません。Intermediariesの方で登場します。

補足として、DMARCに関する以下の記載については、留意が必要です。

Policy statements should be “p=reject” where possible, “p=quarantine” otherwise.
– “p=none”, “sp=none”, and pct<100 should only be viewed as transitional states, with the goal of removing them as quickly as possible.

Policy should be set for balance between protection benefits of a “reject” or “quarantine” policy setting and the potential loss of legitimate mail due to missing
or broken signing.

“p=reject” や “p=quarantine(pct=100)” とするよう言及されていますが (DMARC Enforcement)、不用意にそのようなポリシーを一律適用することは “送信したメールが届かない” といったトラブルの発生も懸念されます。一般的にメーリングリストシステムとの相互運用性の問題等があります。

なお、前述の次期DMARC (DMARCbis、2023年4月時点でInternet-Draft) では、どのような場合にSenderが “p=reject” や “p=quarantine(pct=100)” を適用すべきかについて、より詳しく記述されると予想しています。

DMARCbisについては、以下の記事で経過を少しまとめています。

Intermediaries (中継者) のベストプラクティス

ARCの使用と、DMARC report の生成をするよう記載されています。

これは、中継者が SPF、DKIM、DMARC の検証も行うことを意味します (AAR ヘッダの生成やDMARC report の生成のため)。

また、メーリングリスト等のサービスにおいて、中継時に行われるメッセージ内容の変更を最小限とするよう記載されています。

While M3AAWG recognizes that alteration may be unavoidable for intermediaries such as mailing list servers, it nevertheless recommends that such alteration be kept to a minimum.

リスクの軽減策として、From ヘッダの変更も例として挙げられています。 ※その手法が常に正しいという意味ではありません。

例：Fromヘッダがjohn.jones@dmarc.domain.tldのメールをメーリングリストサーバが中継する際に、john.jones=40dmarc.domain.tld@list.domainに書き換えることで、DMARC 認証の失敗を回避する