2025/09/23(火)SPF,DKIM,DMARC,ARC,SRS総ざらえ（メールセキュリティ技術）

メールtips

調査ツール

https://mxtoolbox.com/SuperTool.aspxが便利

比較表

技術着目点主な仕組み作用層なりすまし防止の観点技術根拠（RFC等）公開年標準化状況
SPFエンベロープFrom（MAIL FROM / Return-Path）の送信元IPDNSに登録された許可IPリストを参照し、受信側が検証エンベロープ偽装したIPアドレスからの送信を排除（送信経路の正当性）RFC 72082014Proposed Standard
DKIMメッセージ本文と特定ヘッダの改ざん防止、署名ドメイン（d=タグ）公開鍵暗号方式で署名、受信側がDNS公開鍵で検証ヘッダ＋本文本文改ざん防止、署名ドメインが責任を持つことを保証RFC 63762011Proposed Standard
DMARCヘッダFromのドメインとSPF/DKIMのアライメントSPFとDKIMの検証結果を参照し、From: ヘッダのドメインと一致するか判定ヘッダユーザーが目にするFromドメインを守り、ブランドなりすまし防止RFC 74892015Informational（※bisで標準化作業中）
ARC認証結果（SPF/DKIM/DMARC）の履歴を改変ホップごとに署名AAR/AMS/ASで署名付き認証履歴を中継サーバーが保持ヘッダ転送やメーリングリストで失われる認証結果を後続ホップに伝達RFC 86172019Experimental
SRS転送時のエンベロープFromの書換えReturn-Pathを転送サーバーの形式に書換え、SPF整合性を維持エンベロープ転送によるSPF破綻を防ぎ、転送メールの正当性を保証draft-levine-srs-*2003以降Internet-Draft（標準未策定、事実上の運用仕様）

攻撃シナリオSPFDKIMDMARCARCSRS
IPなりすまし（送信元サーバ偽装）◎△○△△
Fromドメイン偽装（表示ドメイン詐称）△○◎△×
本文改ざん（経路上で内容書換え）×◎○△×
転送時のSPF破綻（Return-Pathが元のまま）×○△△◎
メーリングリスト経由（Subject等改変で署名崩壊）×△△◎○
経路改ざん/不正中継○○◎○△
凡例：

◎ … 強力に有効
○ … 一定の有効性あり
△ … 間接的または限定的に有効
× … 効果なし

補足：
  • SPF：送信元IPの正当性が主目的。転送で壊れやすい。
  • DKIM：本文／ヘッダ署名で改ざん検知。From偽装には直接効かない。
  • DMARC：From表示ドメインの整合性を最終的に強制するポリシー。
  • ARC：転送やMLで失われがちな認証結果を「履歴として伝える」仕組み。
  • SRS：転送時にReturn-Pathを書き換え、SPF破綻を防ぐ補助策。
コメント（0件）

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

メールtips

基礎

電子メールの内部構造

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

電子メールの経路

MUA (送信) → SMTP → 送信MTA → DNS (MXレコード) → SMTP → 受信MTA (MDA) → POP3/IMAP → MUA (受信)
略称名称役割
MUAMail User Agentメールの作成・閲覧ソフト
MTAMail Transfer Agent送信、受信サーバーであり、中継サーバーともなる
MDAMail 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

*1 : 正しくはインターネットに接続された最終の受信MTA

*2 : HELO時のドメイン名でSPF検証することも定められているが、実装としてはMAIL FROM検証が必須

*3 : 通常の1:1通信の場合は最後の経路といっても、インターネット上の全経路、ということとなる

*4 : その他の技術で迷惑メールは防御される必要がある

*5 : 通常To,From,Subject等が入る

*6 : というか、認証用ドメインなので、どちらでもないドメインを記載することも可能。意味は無いが。

まとめ

技術強み弱み運用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/

AIによるまとめ

電子メール認証技術の整理（改訂版）

1. SPF の本質

  • 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件）