TIPS456

呼称	内容	備考
エンベロープ	配送制御用・SMTPプロトコル	受信したメールには現れない。本当のエンベロープはSMTPセッション中だけに存在し、通常ユーザは直接見られない
ヘッダ	メッセージの属性・配送履歴・認証情報	ヘッダ部には、ヘッダ部固有の情報のほか、エンベロープ由来の情報が書き込まれる。
ボディ	本文と添付ファイル、MIMEで多層化可能

電子メールの経路

MUA (送信) → SMTP → 送信MTA → DNS (MXレコード) → SMTP → 受信MTA (MDA) → POP3/IMAP → MUA (受信)

略称	名称	役割
MUA	Mail User Agent	メールの作成・閲覧ソフト
MTA	Mail Transfer Agent	送信、受信サーバーであり、中継サーバーともなる
MDA	Mail Delivery Agent)	メールの配送システム（ドメイン内部）

Return-Path:
→ 最終の受信サーバ*1が、その時に有効な MAIL FROM をコピーして付与する。
→ バウンス先（エラーメールの返送先）を記録する目的。

Envelope-From:
→ その時の受信サーバーは、その時に有効なMAIL FROMをコピーして付与する挙動が一般的な設定。

Delivered-To:
→ 実際に配送されたローカルの受信者アドレス。

X-Envelope-From / X-Envelope-To
→ 一部のMTAやフィルタが内部情報として追加する独自ヘッダ。標準化されていない（X-ヘッダ扱い）。

受信サーバによる取扱い

MAIL FROM（envelope-from）は複数の中継サーバーを通っても通常リレーである限り改変されない。
ただし、メーリングリスト、SRS、迷惑メール対策等で改変されることはある。

総合理解

パターン	認証プロセス		ヘッダFROMとのアライメント(DMARC)
A	SPF認証成功	→	DMARCアライメント認証（return-pathとヘッダーFromの一致）
B	DKIM認証成功	→	DMARCアライメント認証（DKIM署名ヘッダーとヘッダーFromの一致）

A,Bのいずれかの成功で、DMARCは成功。

失敗した場合でも、ARC情報によてって、ある程度、救われる余地はある(ARCは完全な信頼性を有するにいたっていないので苦しいところ。将来性はあると見られている)。

メーリングリストは一般的に、エンベロープMAIL FROM変換(envelope-fromをMLのドメインに書換）するので、SPF認証はPASSしても、DMARCのSPFアライメントで失敗。
メーリングリストがDKIM証明内容のコンテンツを書き換えた場合には、DKIMは失敗する。subjectなどの書換は失敗要因。

一般の転送は、エンベロープMAIL FROM変換(envelope-fromを書換）をしない。return-pathのドメインのDNSのSPF設定に転送サーバのIPアドレスの記載がないので、SPF認証で失敗する。
転送時にSRSを適用すれば、エンベロープMAIL FROM変換(envelope-fromを書換）をするので、SPF認証は pass するが、DMARCのSPFアライメントで失敗。

一般の転送は、本文並びにDKIMのh=タグ対象のヘッダを書き換えない。DKIMも壊れないので、DKIMは壊れずに最終MTAに届き、DKIM認証をpass。DMARCアライメントもpassする。

一般の転送は、風呂敷で包んだまま運ぶからDKIMによって内容（署名対象ヘッダも含む）は崩れない。DKIMは配送経路はどうでもいいけど、DKIMさえ崩れなければ、最初の発信者がこの内容を発信したことを保証する。SPFは、内容は保証しないけど、最終経路のみの最終発信者の身元が MAIL FROMドメインであることを保証するものなので、一般の転送ではSPF失敗する。

上記から、メーリングリストの場合は、DMARC失敗となる可能性が高い。ARCでどこまで受信サーバーが斟酌して救われるか、というレベルとなる。

よって、件名等を書き換えるメーリングリストを使って、DMARCアライメントまで突破しようと思えば、ヘッダFROMをMLのドメインに書き換える、すなわちFROM書換、しかない。
さくらインターネットメーリングリストでFROM書換をする方法

※だからGoogle GroupsやMicrosoft365のメールグループは、From書換をしているのでしょう。
※ARCも有力な仕組みであるとは言われているようですので、将来はどうなるかはわかりません。

SPF

return-path(=最終MTAに到着した時にHELOした送信サーバーから送付されるMAIL FROM*2(=envelope-from)) 記載のドメインから発信されているかを確認する技術である。当該検証ドメインのTXTレコードにあるspfレコードに、最終MTAに送信したサーバーのIPアドレスの記載があれば、passする。すなわち、SPFは適切に設定されており、かつ、送信サーバーと検証サーバーがSMTPプロコトルとして直結（1:1）通信していれば pass する。

SPFレコードの役目は「そのIPアドレスから発信されたメールなら正当なものですよ」ということを宣言するものである。
ドメインのDNS textレコードに　メールサーバーのFQDNまたはIPアドレスを記載する。それを受信側で検証し、return-path の正当性を検証する。
SMTPプロコトルとして直結していなければ fail する。

よってSPFは、最終MTA直前の最後の経路*3しか、保証しない。経路全体は保証しない。「自分に接続してきた相手の正当性のみを確認」するものである。

【送信MTA →→→　転送MTA(ML) →→　最終MTA】の場合、

→→→がSPF的にfailであっても、転送MTAがSPFを適切に設定し、かつ、MAIL FROMを転送MTAに書き換えていれば、→→は、pass ということとなる。
一般的かつ正常なメーリングリストに、怪しげなメールがポストされた場合、最終MTAのSPFチェックにおいては、SPFはpassすることになる*4。

【送信MTA →→→　転送MTA(MLではないただの転送) →→　最終MTA】の場合、

→→→がSPF的にどうであっても、転送MTAは、MAIL FROMを書き換えないので、仮に転送MTAにおいて適切にSPFが設定されていたとしても、→→において、SPFはfailすることとなる（理論上、送信MTAと転送MTAが同じドメインであれば、passする可能性はあるが、実務としてはありえないだろう）。

SPFはヘッダFromは一切検証対象としないので、ヘッダfromなりすましは、防げない。

設定例
https://www.naritai.jp/guidance_spf_example.html

DKIM

メールヘッダー部のDKIMヘッダーに、認証用ドメインを記載、これを認証する。

DKIMヘッダーには、メール本文及び複数のヘッダ（h=タグで定義される)*5をハッシュ化したものに、認証用ドメインの秘密鍵で暗号化した文字列を記載（署名することと同義）。受信側は、認証用ドメインのtextレコードから公開鍵を入手し、DKIMに記載された文字列を複合化したハッシュと、受信側で[本文＋指定のヘッダ]をハッシュ化したものとの一致を確認することで、認証用ドメインを確認する。

※ハッシュ化は、元の文章が1文字でも異なれば生成されるハッシュが一致しないから、本文＋ヘッダーを統合するときに正規化が行われ、空白や改行は無視される方式が多く使われる（relaxedモード）。厳密なモードも定義されているが、経路途中のMTAが勝手に空白や改行を加えることもあるから、pass率が著しく落ちてしまうので、relaxedを使うのが実務である。

認証用ドメインは、ヘッダFromを記載する方法と、ヘッダFromではなくMAIL FROM(envelope-from)を記載する方法（＝第三者認証）がある*6。

第三者認証が使える以上、ヘッダfromなりすましを防止できない（ただしDMARCを併用すれば、アライメントで失敗するので、ヘッダFromなりすましを防止できることとなる）。
　

https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/dkim/

DKIMでは、署名するヘッダーを選択できるが、通常、subjectヘッダも含まれており、subjectを変更するタイプのメーリングリストの場合、認証に失敗する。
（署名対象は、当該ヘッダー＋本文）

ARCは、受信したサーバーが元のDKIMを認証し、成功していればそれを記録し(AAR)、その記録(AAR)と新しい本文等署名(AMS)のふたつをまとめて署名（封印：AS）するが、新たにDKIMとして署名するものではない。メーリングリストはDKIM署名を検証して、ヘッダに記録することとなるが、元のDKIM署名が壊れたままの場合は、それ以降のDKIM署名は壊れたままとなる。ARCは、認証経路の信頼の連鎖（チェーン）を保証しようとするプロコトルであり、送信元の改ざんを防ぐ仕組みそのものではない。あくまでも、チェーンの保証である（ただし、当該中継サーバーが信頼できることが前提なので、そこがARCの弁慶の泣き所となっている。）。

さくらインターネットは、2025/1に、ARCにも対応した。

転送サーバーが、前経路のDKIMを壊した場合、転送サーバーが自分のドメインでDKIM署名することは可能（再署名）。ただし、ヘッダーFromを書き換えない限り、DMARCアライメントで失敗するので、DMRACはpassしない。再署名は万能ではない。
さくらインターネットでは、メーリングリストにおいてはARCのみの対応であり、DKIM再署名までは対応していない（執筆時点）。

DMARC

Domain-based Message Authentication, Reporting and Conformance

SPF、DKIMは、envelope from と　ヘッダーFromが異なることを許容するが、DMARCアライメントは、少なくとも一方において、[SPFにおいては認証が成功し、かつ、envelope from と　ヘッダーFromが一致していること]　[DKIMにおいては、d=ドメイン(=通常署名時のヘッダーFromが採用される)と到着時ヘッダーFromの一致]を要求する。
これにより、ヘッダーFromなりすましを防止する。

https://maildata.jp/specification/dmarc.html

転送メール、メール配信サービス、メーリングリストサービスを使う場合、SPFは、Alignmentチェックをパスしないので、DKIMにおいて、ヘッダFromを認証する方式を確保しておく必要がある。
しかし、DKIMも万能ではなく、転送、MLサービスによって、本文（可視ヘッダー含む）が改変された場合、ハッシュ一致しなくなるので、DKIMも失敗する可能性がある。特に件名を変更するタイプが要注意であろう。

その欠点を補完するために、ARCがあるが、限界がある。
これは転送にかかわる経路途中のサーバーにおいて、DMARC認証を行い、その結果をヘッダーに記録し、受信サーバーにつなげる仕組みである。
確実な認証の引継ではなく、頼むよ～、レベルなので、斟酌するかは受信サーバー次第。
https://maildata.jp/specification/arc.html

まとめ

技術	強み	弱み	運用Tips
SPF	導入簡単	IP検証,転送時失敗しやすい	SRSと組み合わせる
DKIM	改ざん検知	MLで署名破壊	再署名を検討
DMARC	包括的ポリシー	アライメント厳格	ARCで補完
ARC	中継時の緩和	普及が遅れている	中継者信頼性を確認

Gmail のセキュリティーポリシーの変更　2024/2

https://zenn.dev/ken_yoshi/articles/gmail-new-requirements-2024

5000通未満と以上で対応が分かれるようだが、要確認

MLサービス参考

http://www.kt.rim.or.jp/~atsato/ml/mlprov.html

DKIMヘッダーの例(Gemini)

以下は、メールヘッダーに実際に含まれるDKIM-Signatureフィールドの典型的な例です。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com;
s=20231120; t=1756479600; bh=g+Lq+J9uK8/b+R0j+v7oF+P+5F+n8P/J1+q/g==;
h=From:To:Subject:Date:Message-ID; b=...signature_string...

各タグの解説

v=1
意味: DKIM署名のバージョンを示します。現在はバージョン1が一般的です。

a=rsa-sha256
意味: 署名アルゴリズムを示します。

rsa: 公開鍵暗号方式のアルゴリズム。
sha256: ハッシュ関数。

c=relaxed/simple
意味: 正規化アルゴリズムを示します。

relaxed: 緩和モード。メールヘッダーの空白や大文字・小文字の違いを無視して検証します。
simple: 厳格モード。メールヘッダーの空白や変更を一切許容しません。

この例では、ヘッダーにはrelaxedモード、本文にはsimpleモードが適用されています。

d=example.com
意味: 署名ドメイン。このメールに署名した組織のドメインです。
DMARCアライメントの鍵となる部分です。このドメインが、メールヘッダーのFromフィールドに記載されたドメインと一致するかどうかがDMARCアライメントの評価基準となります。

s=20231120

意味: セレクター。この署名を検証するために使用する公開鍵の名前を示します。

受信側のメールサーバーは、d=example.comとs=20231120の組み合わせでDNSサーバーを検索し、公開鍵を取得します。

t=1756479600
意味: 署名が作成された日時をUnixタイムスタンプで示します。

bh=...
意味: メールの本文のハッシュ値。本文が改ざんされていないかを確認するために使われます。

h=From:To:Subject:Date:Message-ID
意味: 署名に含まれるヘッダーフィールドのリスト。ここに記載されたヘッダーが改ざんされていないかを確認します。

b=...signature_string...

意味: 署名データ。hタグで指定されたヘッダーとbhタグで指定された本文のハッシュ値を、秘密鍵で署名した文字列です。受信側は公開鍵を使ってこの署名を検証します。
このDKIMヘッダー全体がメールに添付されることで、受信側はメールの送信元と内容が正当であることを確認できます。

歴史

2023年10月
グーグルがにGoogleは、Gmailの新しいガイドライン発表。2024.2から適用。
https://support.google.com/a/answer/81126?hl=ja

2024年１月31日
さくらインターネットがDKIM対応発表（ＳＰＦは以前から対応）
https://www.sakura.ad.jp/corporate/information/announcements/2023/12/19/1968214527/

2024年2月
新ガイドライン施行

2025年1月～2月
さくらインターネットがARC対応。
https://www.sakura.ad.jp/corporate/information/announcements/2025/01/14/1968218162/

SPF は **最終受信 MTAが直接接続してきたサーバの IP** と、SMTP セッションで名乗られたドメイン（MAIL FROM または HELO）を突き合わせる仕組み。
SPF が保証できるのは **直前ホップの正当性のみ**。経路全体やオリジナル送信者を保証するものではない。
通常のリレーでは `MAIL FROM` は改変されないが、転送サーバが **SRS (Sender Rewriting Scheme)** を導入している場合は書き換えられる。

2. SPF と転送の関係

転送サーバが `MAIL FROM` をそのまま流すと、最終受信 MTAから見ると「転送サーバの IP とオリジナルドメイン」の組合せになる。
その IP が SPF レコードに載っていなければ Fail。
これを解決するのが **SRS**。転送サーバのドメインに書き換えることで SPF Pass が成立する。

3. DKIM の役割

**`d=` タグは署名ドメイン**。MAIL FROM とは関係なく、署名者が主張するドメインを示す。
メッセージヘッダや本文に署名をかけることで「改ざん検知」を可能にする。
メーリングリストが Subject 追加やフッタ挿入をすると DKIM 署名は壊れる。

4. DMARC の位置づけ

DMARC は **RFC5322.From ヘッダのドメイン**を基準に、SPF/DKIM の結果との alignment を確認する。
SPF/DKIM いずれかが Pass かつ alignment していれば DMARC Pass。
メーリングリストが From を書き換えない場合、SPF/DKIM が壊れて DMARC Fail になる。
実務上は **From 書換（From munging）** を行い、ML ドメインで DKIM 再署名することで DMARC Pass を成立させるケースが多い。

5. ARC の役割

ARC は **前段での SPF/DKIM/DMARC の結果を署名付きで引き継ぐ仕組み**。
これにより「ML で署名が壊れても、オリジナルでは Pass だった」ことを最終受信者が確認できる。
ただし ARC の信頼性は「中継者を信用できるか」に依存するため、単独では不十分。
現状では Gmail や Microsoft 365 が導入しており、将来的には From 書換を減らせる可能性がある。

コメント（0件）

TIPS456

検索条件

2025/08/24(日)メールセキュリティ覚書(SPF,DKIM,DMARC)

基礎

電子メールの内部構造