メールヘッダ診断

メールヘッダ診断は、メールのヘッダを読み込んで、次の2つを診断するツールです。

受信者向け：なりすまし・リプレイの兆候

届いたメールのヘッダから、正規のメールを別の宛先に再送する「DKIMリプレイ」や、無関係なドメインからブランドを名乗るなりすましなどの兆候を探します。
SPF・DKIM・DMARCがすべてpassし、ブランドのロゴまで表示されるなりすましメールもあるため、認証の結果だけでは見抜けない兆候を確認します。
攻撃者が自分で取得したドメインから送れば、SPF・DKIM・DMARCは正しくpassするため、passしていることは、表示名や件名のブランドから送られたことを意味しません。

送信者向け：送信側の設定の診断

自社が送ったメールのヘッダから、DKIMの署名範囲、SPFとDKIMのアライメント、DMARCのポリシーなどを確認します。
なりすましに強い設定になっているか（安全性）と、受信側に届きやすい設定になっているか（到達性）を、それぞれA〜Fのランクで示します。

兆候が見つからなくても、本物のメールとは限りません

このツールが確認できるのは、ヘッダに残る記録だけです。
兆候が見つからなかった場合も、そのメールが本物であることを保証するものではありません。
少しでも不審な点があれば、メール内のリンクやボタンは開かず、送信元の公式サイトやアプリから確認してください。
実際に起きた事例は、入力エコー攻撃とは？フォーム入力でDMARC・BIMIを通過するフィッシングの手口と対策で解説しています。

読み込んだヘッダの扱い

読み込んだヘッダは、お使いのブラウザの中だけで解析します。
ヘッダの内容を、MailDataや第三者のサーバーに送ることはありません。
DKIMの公開鍵、SPF、DMARCを確認するため、署名ドメイン、セレクタ、ヘッダFromとMAIL FROMのドメイン名、SPFのinclude先のドメイン名だけを、Google Public DNS（DNS over HTTPS）に問い合わせます。
本文が含まれていた場合も、本文は解析に使いません。

受信者向け：確認するなりすまし・リプレイの兆候

次の兆候が見つかった場合に、その内容を表示します。
どれも、正規のメールでも起こり得るものなので、兆候があることは、なりすましであることの確定ではありません。
複数の兆候が重なっている場合は、特に注意してください。

診断結果の一番上には、判定の結果を次の4段階で表示します。

なりすましメール

SPFもDKIMも、ヘッダFromのドメインとアラインしていない場合です。
ヘッダFromのドメインの持ち主が送ったことを示す認証が1つもなく、DMARCの判定はfailになります。
（メールセキュリティ仕様に基づく判定です。）

高い

DKIMがヘッダFromのドメインとアラインしておらず、SPFのアライメントを確認できない、元の宛先の変更、MAIL FROMが空、不自然な境界文字列、「+all」のSPF、受信側でのDMARCのfail、差出人の表示名でのブランドの詐称、表示名や件名への見えない文字の多用など、なりすましやリプレイに特徴的な兆候が1件以上ある場合か、兆候が3件以上ある場合です。
件名だけにブランド名がある場合は、正規のメールでも多いため、特徴的な兆候としては扱いません。

注意が必要

正規のメールでも起こる兆候が、1〜2件ある場合です。

兆候は見つかりませんでした

兆候が1件もない場合です。
本物のメールであることを保証するものではありません。

送信者向け：ランクの決め方

安全性と到達性は、それぞれA〜Fの6段階で示します。
ランクは点数の合計ではなく、見つかった条件のうち、いちばん悪いものに合わせて決まります。
例えば、ほかの設定がすべて良くても、Fromが署名されていなければ、安全性はFになります。
ランクはMailDataの基準による評価で、RFCに定められたものではありません。
DNSの問い合わせに失敗した場合は、DNSの項目を除いた暫定のランクになります。

2048ビット未満のRSA鍵には、量子コンピュータに関する注記も表示します。
Googleは、耐量子計算機暗号（PQC）への移行期限を2029年に設定しています。
（Google「Quantum frontiers may be closer than they appear」、2026年3月25日）
NISTも、112ビット相当のRSA署名を2030年より後に非推奨、2035年より後に使用禁止とする計画を示しています。
（NIST IR 8547 Initial Public Draft Section 4.1.1）
DKIMの鍵は暗号化ではなく署名に使うため、TLSの鍵交換のような「Harvest Now, Decrypt Later（今収集して、後で復号する）」の対象にはなりません。
危険なのは、DNSで公開されている公開鍵から秘密鍵を求められると、そのドメインとして署名したメールを偽造できるようになることです。
1024ビットの鍵は、2048ビットの鍵より少ない計算資源で破られるため、先に危険になると考えられます。
2048ビット以上の鍵に替え、定期的に鍵を交換して古い公開鍵をDNSから削除すれば、偽造に使える期間を限れます。

SPFとDKIMの双方のアライメントは、DMARCに完全に参加する（Full DMARC Participation）ためにドメイン所有者が満たすべき要件です。
（RFC 9989 Section 8）
受信側の判定では、どちらか一方がアラインすればDMARCはpassしますが、MailDataの観測では、片方だけでは個人向けメールサービスで拒否される例があります。
詳しくは、DMARCアライメントとは？SPF・DKIMの一致判定とメールが届かない原因【2026年版】で解説しています。

SPFの隠蔽化の確認（DNS）

ヘッダFromのドメインのSPFレコードが、SPFマクロで隠蔽化されているかも確認します。
隠蔽化されていないSPFは、include先を順にたどるだけで、利用している送信サービスやMTAが誰にでも分かります。
攻撃者は、その中から入力エコー攻撃などに使える脆弱な送信サービスを探すことができます。
隠蔽化されていない場合、安全性のランクはB以下になります。
SPFの隠蔽化には、PowerSPFを利用できます。

ヘッダの準備のしかた

1. 診断したい送信元から、自分のメールアドレス宛てにメールを送ります。
   問い合わせフォームの自動返信、会員登録の確認メール、メールマガジンなど、送信サービスごとに確認することを勧めます。
2. メールソフトやWebメールの「メッセージのソースを表示」「ヘッダを表示」などの機能で、ヘッダを表示します。
3. ヘッダをコピーして貼り付けるか、テキストファイルに保存して選びます。
   .eml形式で保存したファイルをそのまま選ぶこともできます。

注意事項

• 送信者向けの診断で判定できるのは、ヘッダから分かる送信側の設定です。
  入力エコーのように、本文の作り方に原因がある問題は判定できません。
  フォームの入力内容を自動返信に載せていないかは、別に確認してください。
• 本文のハッシュ（bh=）や署名値（b=）は検証しないため、署名が正しいかどうかは判定しません。
• ブランドの詐称は、なりすましに使われることが多いブランドと、その送信ドメインの一覧にもとづいて判定します。
  一覧は網羅的ではないため、一覧にないブランドの詐称は検出できません。
  また、ブランドが子会社や委託先のドメインから正規に送るメールを、詐称と判定する場合があります。
• 本文のリンク先や、本文に隠された文字は解析しません。
  ヘッダに兆候がなくても、本文のリンク先が公式サイトのドメインかどうかは、別に確認してください。
• 到達性のランクは、受信側に届くことを保証するものではありません。
  実際に届くかどうかは、送信元IPアドレスの評判や本文の内容など、受信側の多層フィルタの判定にも左右されます。
• アライメントの判定は、組織ドメインを簡易的に求めて行います。
  RFC 9989のDNSツリーウォークによる判定とは、結果が異なる場合があります。
• 転送や再送を経たメールでは、MAIL FROMやAuthentication-Resultsが、送信元が送った時点の内容と異なる場合があります。
  診断には、送信元から直接届いたメールを使ってください。
• ワンクリック登録解除の要件は、マーケティングメールや購読メールに適用されるものです。
  取引の通知などのメールには、List-Unsubscribeがなくても問題ありません。

ドメインのDNSの設定だけを確認する場合は、ドメインメールセキュリティチェッカーを使ってください。
MailDataでは、DMARCレポートの分析を通じて、送信元ごとのDKIM署名とアライメントの状況を洗い出し、p=rejectへの移行を支援しています。
送信元や署名範囲の見直しでお困りの場合は、お問い合わせフォームからご相談ください。