Email ツール
メール認証の実像をまとめた実務リファレンス。エンベロープとヘッダーの2つのFrom、SPF/DKIM/DMARC/ARCが証明できることとできないこと、Receivedチェーンと認証結果の読み方、ヘッダーや.emlの調査ツールの選び分けまでを扱います。
3 ツール
2つの From を分けて考える
なりすましの疑問はほぼすべて2つの送信者IDの混同に行き着きます。エンベロープ送信者は
SMTPの MAIL FROM のアドレスで、バウンスの戻り先。受信側は Return-Path: や
Received-SPF: の smtp.mailfrom= に記録します。ヘッダー送信者は本文中の From: で、
人間が見るのはこちら。SMTPは両者の一致を要求しません。
SPFが認証するのはエンベロープ(接続元IPは MAIL FROM のドメインで送れるか)、DKIMは内容
(h= のヘッダーと本文ハッシュ bh= への署名、公開鍵はDNS)です。どちらも受信者が読む
アドレスには触れません。その隙を埋めるのがDMARCの alignment で、From: のドメインが
SPFかDKIMの d= と一致することを要求します。銀行を騙るメールで spf=pass は普通ですが、
dmarc=pass は違います。
検証しているのは自分ではありません。判定は受信MTAが配送時に行い Authentication-Results:
に書きます。以後それはテキスト上の主張で、書いたホップが自組織の設備のときだけ信頼でき
ます。
各方式が証明できること
| 方式 | 公開場所 | 認証対象 | 転送で残るか | From: 偽装を防げるか |
|---|---|---|---|---|
| SPF | エンベロープドメインの TXT | MAIL FROM の接続元IP | 残らない | 防げない |
| DKIM | <selector>._domainkey.<d=> の TXT | h= のヘッダー + 本文ハッシュ bh= | 本文/Subject 無改変なら残る | alignment時のみ |
| DMARC | _dmarc.<domain> の TXT | From: のalignmentとポリシー | 残ったDKIM経由で有効 | 防げる(本来の目的) |
| ARC | ARC-Seal / ARC-Message-Signature | 上流の判定を中継越しに保全 | 設計目的そのもの | 防げない |
| MTA-STS / DANE | _mta-sts.<domain> の TXT / TLSA | 経路(TLSの必須化) | 対象外 | 防げない |
結果の語は3方式で共通で、値ごとに直す対象が違います。
| 値 | 意味 | 主な原因 |
|---|---|---|
pass | 検証成功 | — |
fail | 権限なし・強い拒否(-all) | なりすまし、登録漏れの中継 |
softfail | 権限なしだが受理(~all) | 移行途中で緩いまま放置 |
neutral | 判断しない(?all) | ポリシーが何も述べていない |
none | レコード未公開 | 未設定 |
temperror | DNS一時障害(再試行可) | リゾルバや権威側の不調 |
permerror | レコードを評価できない | DNS参照10回超、v=spf1 重複、構文エラー |
どのツールをいつ使うか
生ヘッダーがあるならメールヘッダー解析。継続行をunfoldし、
Received: を反転してホップ1=発信サーバー、最終=自分のプロバイダの順に並べ、ホップ間の
秒数を出します。Delay: 1800s はメールを30分抱えた中継の名指しです。下段に
Authentication-Results / Received-SPF / DKIM-Signature /
ARC-Authentication-Results が原文のまま並びます(DMARCの判定は1つ目の中の
dmarc=pass (p=REJECT …))。生ヘッダーは送信元IPや内部ホスト名を含みます。解析はブラウザ内
完結です。
.eml ごと(バウンスや保存した添付)なら
EMLメールビューア。RFC 2047のencoded-word(=?UTF-8?B?…?=)をデコード
して日本語Subjectを読める形にし、From/To/Cc/Subject/Date/Reply-To/Message-ID
を並べます。From: と別ドメインの Reply-To はBECの典型です。本文は生表示でMIME
boundaryも見え、base64パートはBase64に通せます。
ドメインしか無いならDNSへ。DNSルックアップは TXT(v=spf1)、MX
(優先度付き)、修正が効くまでを決める TTL も出ます(キャッシュはdnsハブ)。
サーバーツールで、ドメイン名だけが api.sitekits.dev に送られ保存されません。受理は
ホスト名ラベルのみで _dmarc.example.com 等は弾かれるため、そこは
dig TXT _dmarc.example.com を使います。
リンク調査はURLパーサー(送信せず分解のみ)と
IDN/Punycode変換(xn-- 形でホモグラフを暴く)。どちらもブラウザ内
完結で、メールヘッダー解析やEMLビューアと同じ
/ja/for/security/に収録しています。オフセット違いの時刻は
タイムゾーン変換が速く、これもブラウザ内完結ですが、収録先は
security ではなく/ja/for/sre/です。証跡添付前のマスキングは手作業で、
HARサニタイザーの対象はHARでメールヘッダーではありません。
つまずきやすい点
p=none は何も守らない
レポートを求めるだけです。p=quarantine / p=reject に進めない限り受信側は失敗に何も
しません。pct= は強制する割合の指定です。
DNS参照10回の上限を超える
include: / a / mx / ptr / redirect= が参照を消費し、SaaS送信元の入れ子 include:
も再帰加算されます。10回超で全体が permerror = SPFなし扱いです。
失敗をすべて攻撃と読む
転送やメーリングリストは正当に認証を壊します(中継IPはSPFに落ち、[list] 接頭辞や
フッターはDKIMの本文ハッシュを壊す)。単発の fail では断定できません。
Delayや前段ホップを証拠として使う
境界MTAより前のホップは攻撃者が書ける文字列です。Delayの負値や — も時計ずれか
タイムスタンプ欠落で、証拠にはなりません。
送信しないドメインを放置する
駐車ドメインやサブドメインにも v=spf1 -all、_dmarc.<domain> に p=reject のDMARC
レコード、できれば null MX(MX 0 .)が必要です。ポリシータグは p= が必須で、
sp=reject だけのレコードは不正なため受信側は何も適用せず、駐車ドメイン自身が無防備な
まま残ります。sp=reject はサブドメインのポリシーを明示したいときに p= と併記します
(sp= を省けばサブドメインは p= を継承します)。放置は自社ブランド入りのなりすまし
素材です。