はじめに

独自ドメインでWebサイトや事業用メールを運用していると、いずれ迷惑メールや営業メールが届くようになります。

私も独自ドメインを取得し、事業用の代表アドレスとして、次のようなメールアドレスを使い始めました。

info@example.jp

すると、運用開始からしばらくして、登録した覚えのない事業者から営業メールが届くようになりました。

最初はよくある営業メールだと思っていましたが、過去にも似たメールが届いていたこと、一定期間後に内容を変えたメールが再び届いたことから、少し気になりました。

そこで、Gmailの「メッセージの原文」を確認し、メールヘッダーを比較してみることにしました。

調査の結果、次のことが分かりました。

2通は同一のIPアドレスから送信されていた
同じメール配信システムが使われていた
受信者ごとに割り当てられたとみられる識別値が固定されていた
SPF・DKIM・DMARCは、すべてpassだった
それでも、私が配信に同意したメールではなかった
メールは個別送信ではなく、機械的な一斉配信だった

この記事では、特定の人物や企業を評価するのではなく、独自ドメインのメールアドレスに届いた営業メールを、メールヘッダーからどこまで調べられるのかを整理します。

また、調査後に行った証拠保存と通報についても紹介します。

独自ドメインのinfoアドレスに営業メールが届いた

今回メールが届いたのは、独自ドメインで作成したinfo@アドレスです。

info@example.jp

届いたメールには、ITエンジニアや開発案件に関する営業情報が記載されていました。

しかし、私は送信元のサービスに登録した覚えがなく、メール配信に同意したこともありません。

さらに、メール内には複数のドメインが登場していました。

From:        送信に使われたドメイン
Reply-To:    返信先として指定された別ドメイン
本文中:      営業窓口として記載された別ドメイン
解除URL:     送信元ドメイン上のURL

画面に表示される送信者名だけを見ても、実際にどのサーバーから送られたのかは分かりません。

そこで、メールの原文を確認しました。

最初に行わなかったこと

不審な営業メールを受け取ったとき、私は次の操作を行いませんでした。

メールへ返信する
記載された電話番号へ電話する
配信解除URLを開く
メール内のリンクをクリックする
相手方へ直接問い合わせる

配信解除リンクが記載されていても、送信元を信頼できない場合は慎重に扱う必要があります。

解除URLには、受信者を識別するための値が含まれていることがあります。

例えば、今回のURLには次のような値がありました。

u=xxxxxxxxxxxxxxxx

複数回届いたメールを比較したところ、この値は2通とも同一でした。

このため、送信者側のデータベースで、私のメールアドレスに固定の受信者IDが割り当てられている可能性が考えられました。

解除リンクを開けば配信が停止される可能性はありますが、同時に次の情報が送信側へ伝わる可能性もあります。

メールアドレスが現在も有効である
人がメールを確認している
解除URLを操作した日時
アクセス元のIPアドレス
受信者IDとアクセス履歴の対応

そのため、今回は解除リンクを使わず、証拠を保存して外部の相談・通報窓口へ提出する方法を選びました。

Gmailで「メッセージの原文」を確認する

ブラウザ版Gmailでは、次の手順でメールの原文を確認できます。

対象のメールを開く
メール右上の三点メニューを開く
「メッセージの原文を表示」を選択する

原文には、通常のメール画面では表示されない情報が含まれています。

主に確認した項目は次のとおりです。

Return-Path:
Received:
Authentication-Results:
Received-SPF:
DKIM-Signature:
From:
Reply-To:
List-Unsubscribe:
Precedence:
Message-ID:

それぞれ、メールの送信経路や認証状態を判断する材料になります。

Fromだけでは実際の送信元は分からない

メール画面で表示されるFromは、差出人として見せるための項目です。

From: Example Company <info@example-a.com>

しかし、Fromだけでは、実際にどのサーバーから送られたかは判断できません。

メールでは、次の項目がそれぞれ異なる場合があります。

項目	主な役割
`From`	受信画面に表示される送信者
`Reply-To`	返信ボタンを押したときの宛先
`Return-Path`	配信不能通知が返される宛先
`Received`	メールが通過したサーバーの記録
`Message-ID`	メールを識別するためのID

例えば、メール画面上の送信元と、返信ボタンを押したときの宛先が異なることがあります。

From: info@example-a.com
Reply-To: info@example-b.net

この設定自体は、メールマガジンや問い合わせ管理でも使われるため、必ずしも不正ではありません。

ただし、複数のドメインの関係が説明されていない場合は、送信経路を確認する材料になります。

Receivedヘッダーから実際の送信サーバーを確認する

Receivedヘッダーには、メールがどのサーバーを通過したかが記録されます。

今回のメールでは、次のような構造が確認できました。

Received: from example-host.133-18-xxx-xxx.plesk.page
(example-a.com. [133.18.xxx.xxx])
by mx.google.com

この情報から、Googleのメールサーバーへメールを渡した直前のサーバーを確認できます。

2通のメールを比較したところ、次の項目が一致していました。

送信IPアドレス
送信ホスト名
送信ドメイン
サーバー内部のユーザーID
DKIMの署名ドメイン
配信解除システムのパス
受信者識別値

つまり、内容は異なっていても、同じ配信基盤から送られたメールだと判断できました。

SPF・DKIM・DMARCがすべてpassだった

今回、特に興味深かったのは、メール認証の結果です。

メールヘッダーには、次のように記録されていました。

spf=pass
dkim=pass
dmarc=pass

最初に見ると、「すべて認証に成功しているなら、安全なメールではないか」と思うかもしれません。

しかし、SPF・DKIM・DMARCがpassであることと、受信者にとって迷惑なメールではないことは、別の問題です。

SPFとは

SPFは、Sender Policy Frameworkの略です。

簡単にいうと、メールを送ったサーバーが、そのドメインからメールを送ることをDNS上で許可されているかを確認する仕組みです。

例えば、次のメールが届いたとします。

Return-Path: error@example-a.com
送信IP: 192.0.2.10

受信サーバーは、example-a.comのDNSに登録されたSPF情報を確認します。

example-a.comは、192.0.2.10からのメール送信を許可しているか

許可されていれば、SPFはpassになります。

spf=pass

つまり、SPFのpassが示すのは、主に次のことです。

このメールを送ったIPアドレスは、エンベロープ送信元ドメインのDNS設定上、送信を許可されている。

一方、SPFは次のことを保証しません。

受信者がメール配信に同意した
メール内容が正しい
表示された会社が信頼できる
営業方法が適切である
メールが迷惑メールではない

DKIMとは

DKIMは、DomainKeys Identified Mailの略です。

送信側がメールに電子署名を付け、受信側がDNSに公開された鍵を使って検証する仕組みです。

メールヘッダーには、次のようなDKIM署名が含まれます。

DKIM-Signature:
  d=example-a.com;
  s=default;

主な項目は次のとおりです。

項目	意味
`d=`	署名したドメイン
`s=`	公開鍵を特定するセレクター
`b=`	メールに付けられた署名値
`bh=`	本文のハッシュ値

受信側は、DNS上の公開鍵を使って署名を検証します。

検証に成功すると、次のように表示されます。

dkim=pass

DKIMのpassが示すのは、主に次のことです。

メールは、署名ドメインが管理する秘密鍵で署名され、署名対象部分が配送途中で改変されていない。

ただし、これも送信者の善意や営業メールへの同意を保証するものではありません。

迷惑メールの送信者であっても、自分が管理するドメインとサーバーを正しく設定すれば、DKIMをpassさせることはできます。

DMARCとは

DMARCは、Domain-based Message Authentication, Reporting and Conformanceの略です。

SPFやDKIMの結果に加えて、受信画面に表示されるFromドメインとの整合性を確認します。

ここで重要なのが、アライメントという考え方です。

例えば、画面上の送信元が次のようになっているとします。

From: info@example-a.com

DMARCでは、SPFやDKIMで認証されたドメインが、Fromのexample-a.comと整合しているかを確認します。

整合していれば、DMARCはpassになります。

dmarc=pass
header.from=example-a.com

DMARCのpassが示すのは、主に次のことです。

画面上のFromドメインと、SPFまたはDKIMで認証されたドメインに整合性がある。

これにより、無関係な第三者が有名企業のドメインを単純にFrom欄へ書いただけのメールを検出しやすくなります。

一方、DMARCも次のことは保証しません。

その会社名とドメインの関係
メール内容の正確性
配信先の取得方法
広告メールへの同意
法令や利用規約への適合
送信者が信頼できる人物・企業であること

3つの認証結果をまとめる

SPF、DKIM、DMARCがすべてpassだった場合、一般的には次のように解釈できます。

認証	`pass`で確認できること
SPF	送信IPが送信元ドメインから許可されている
DKIM	ドメインの秘密鍵で署名され、署名対象部分が改変されていない
DMARC	FromドメインとSPFまたはDKIMの認証ドメインが整合している

まとめると、次の状態です。

このメールは、
表示されたドメインの認証済み環境から送られており、
配送途中で大きく改変された形跡もない

しかし、次の状態を意味するわけではありません。

このメールは、
受信者が希望した安全なメールであり、
内容も送信方法も適切である

ここが今回の調査で最も重要だった点です。

認証済みメールでも迷惑メールになり得る

SPF・DKIM・DMARCは、主にドメインのなりすましやメール改ざんを検知するための技術です。

これらは「メールの出所が技術的に整合しているか」を確認します。

一方、迷惑メールかどうかを判断するには、別の観点が必要です。

受信者が配信に同意したか
過去に取引や問い合わせをしたか
配信停止を求めた後も送られていないか
送信者情報が適切に表示されているか
配信先がどのように取得されたか
同じ内容が大量・反復送信されていないか
メールサービスの利用規約に違反していないか

つまり、メールの評価には少なくとも2つの軸があります。

技術的な真正性
    SPF・DKIM・DMARC

配信の適切性
    同意、取得方法、表示、頻度、内容、法令・規約

今回のメールは、技術的には送信ドメインの認証に成功していました。

しかし、私は配信に同意しておらず、同じ配信基盤から繰り返し営業メールが届いていました。

そのため、認証結果がpassであることと、迷惑メールとして対応することは矛盾しません。

Precedence: bulkとは

今回のメールには、次のヘッダーも含まれていました。

Precedence: bulk

bulkは、メールが一斉配信や大量配信として扱われていることを示すために使われる値です。

これは、送信者が個別に手作業で送信したメールというより、配信システムを使ってまとめて送信したメールであることを示す材料になります。

ただし、Precedence: bulkがあるだけで違法な迷惑メールになるわけではありません。

正規のメールマガジンや通知メールでも使用されることがあります。

今回の場合は、次の事情と組み合わせて判断しました。

同じ送信サーバー
同じ配信システム
同じ受信者識別値
一定期間後の反復配信
本文だけを差し替えた構造
配信への同意をした覚えがない

2通を比較して分かったこと

2通のメールヘッダーを比較すると、次の項目が一致していました。

比較項目	結果
送信ドメイン	同一
送信IPアドレス	同一
送信ホスト名	同一
DKIM署名ドメイン	同一
DKIMセレクター	同一
Reply-To	同一
配信解除システム	同一
受信者識別値	同一
`Precedence`	2通とも`bulk`

一方、次の部分は変わっていました。

紹介される人材情報
案件情報
技術キーワード
配信回を識別するとみられる値
エラー処理用メールアドレス

このことから、次のような配信構造が推定できました。

固定されたメールテンプレート
        ＋
今回の人材情報
        ＋
今回の案件情報
        ＋
受信者固有の識別値

つまり、個別に私の事業内容を確認して送ったメールではなく、配信リスト上の宛先に対して、内容の一部を差し替えながら反復配信している可能性が高いと判断しました。

なぜinfo@独自ドメインが狙われるのか

今回、メールアドレスがどこから取得されたかは確認できませんでした。

メールヘッダーには、配信先の取得経路は記録されないためです。

ただし、一般的には次の経路が考えられます。

Webサイトから収集される

Webサイト上に次のような記載があると、自動収集プログラムでも取得できます。

<a href="mailto:info@example.jp">
  info@example.jp
</a>

メールアドレスが平文で表示されている場合も同様です。

info@を機械的に生成される

独自ドメインが発見されると、一般的な名前を付けてメールアドレスを生成できます。

info@example.jp
contact@example.jp
sales@example.jp
admin@example.jp
support@example.jp

info@は企業や個人事業の代表アドレスとして広く使われるため、存在する可能性が高いアドレスです。

到達したアドレスだけが保存される

最初は推測で送信し、エラーメールが返らなかったアドレスだけを有効な送信先として保存する方法も考えられます。

今回のメールでは、同じ受信者識別値が複数回使われていました。

そのため、少なくとも現在は、私のメールアドレスが送信者側の配信データベースに登録されている可能性が高いと考えました。

独自ドメインのinfoアドレスを使う際の注意点

info@は分かりやすく、名刺やWebサイトにも掲載しやすいアドレスです。

一方で、推測されやすいという特徴があります。

そのため、迷惑メールが届くことを前提に運用した方が安全です。

迷惑メールフィルターを利用する

Google Workspaceなどのメールサービスでは、迷惑メール判定や管理機能を利用できます。

ただし、自動判定ですべてのメールを防げるわけではありません。

特定の送信元や本文が繰り返される場合は、フィルターやラベルを追加する方法もあります。

問い合わせフォームを併用する

Webサイトにメールアドレスを直接掲載せず、問い合わせフォームを利用する方法があります。

ただし、フォームにも自動送信やスパム対策が必要です。

メールアドレスの用途を分ける

代表窓口とサービス登録用を分ける方法もあります。

info@example.jp
service-name@example.jp
inquiry@example.jp

どこからアドレスが漏れたか、または収集されたかを判断しやすくなります。

catch-all設定には注意する

存在しない宛先もすべて受信するcatch-all設定を有効にすると、辞書型で生成された大量の宛先メールまで受信する可能性があります。

必要性がなければ、存在するアドレスだけを受信する設定の方が管理しやすくなります。

不審なメールは原文を保存する

通常のスクリーンショットだけでは、送信IPや認証結果を確認できません。

Gmailの場合は、「メッセージをダウンロード」から.eml形式で保存できます。

.emlには、本文と完全なメールヘッダーが含まれます。

証拠として保存したもの

今回、次の資料を保存しました。

2026-06-22_営業メール.eml
2026-07-12_営業メール.eml
メールヘッダー比較メモ.md
相談窓口への提出記録.eml
サーバー事業者への通報記録.eml

重要なのは、元メールを削除する前に.eml形式で保存することです。

.emlなら、次の情報をまとめて残せます。

メール本文
送信日時
送信元
返信先
Return-Path
Received
SPF・DKIM・DMARC
Message-ID
配信解除URL
MIME情報

迷惑メール相談窓口へ提出した

今回、同意していない広告・営業メールとして、2通の原文を迷惑メールに関する相談・情報提供窓口へ提出しました。

Gmailでは、対象メールを選択し、「添付ファイルとして転送」を使うと、複数のメールを.eml形式で添付できます。

提出時には、人物や企業への評価は書かず、次の事実だけを記載しました。

受信日時
受信先
表示上の送信元
Reply-To
同意や登録をしていないこと
同じ送信基盤から繰り返し届いたこと
2通の原文を添付したこと

VPS事業者へ技術情報を付けて通報した

メールヘッダーから送信IPとホスティング事業者を確認し、VPS事業者の迷惑行為・規約違反に関する窓口へも通報しました。

通報には次の情報を含めました。

送信IPアドレス
送信ホスト名
受信日時
From
Reply-To
SPF・DKIM・DMARCの結果
同一配信システムの使用
同一受信者識別値の使用
Precedence: bulk

また、「違反している」と断定するのではなく、利用規約上の禁止行為に該当する可能性があるメールとして、調査を依頼しました。

メールサーバーやVPS事業者は、契約者情報を通報者へ回答するとは限りません。

それでも、契約者への確認、警告、送信停止、利用制限などを判断する材料にはなります。

調査しても分からなかったこと

メールヘッダーは多くの情報を含みますが、すべてを明らかにできるわけではありません。

今回も、次の点は確認できませんでした。

最初にメールアドレスを取得した場所
実際に配信操作を行った人物
送信ドメインと本文記載企業との契約関係
配信リスト全体の件数
配信システムの契約者
受信者識別値が完全に削除されたか
紹介されている人材や案件の実在性

特に、サーバーのIPアドレスが分かっても、ホスティング事業者がメールを送信したわけではありません。

一般的には、次の関係になります。

ホスティング事業者
        ↓
VPSやIPアドレスを提供
        ↓
契約者がサーバーを管理
        ↓
契約者または利用者がメールを配信

メールヘッダーだけで、契約者の氏名や法人名までは確認できません。

SPF・DKIM・DMARCは安全マークではない

今回の調査で改めて分かったのは、SPF・DKIM・DMARCの認証結果を正しく読む必要があるということです。

すべてpassだったとしても、それはメール内容や営業方法を保証するものではありません。

SPF・DKIM・DMARCがpass
    ＝
送信ドメインとの技術的な整合性が確認できた

であって、

SPF・DKIM・DMARCがpass
    ＝
安全で信頼できるメール

ではありません。

逆に、今回のように認証がすべて成功している場合、単純なFrom詐称ではなく、送信者が管理または利用できる認証済み環境から送られていることが分かります。

これは、送信経路を調べるうえでは重要な情報です。

おわりに

独自ドメインのinfo@アドレスは、事業用の代表窓口として便利です。

一方で、アドレスを推測しやすく、Webサイトからも収集されやすいため、迷惑メールの送信先になりやすいという側面があります。

今回、メールヘッダーを確認したことで、画面上の送信者名だけでは分からなかった次の情報を確認できました。

実際の送信サーバー
送信IPアドレス
SPF・DKIM・DMARCの認証結果
FromとReply-Toの違い
一斉配信を示すヘッダー
複数メールで固定された受信者識別値
同じ配信基盤からの反復送信

不審なメールを受け取った場合、すぐに返信したり、配信解除リンクを押したりする前に、まず原文を保存してメールヘッダーを確認することが重要です。

また、自分で送信者を追及するのではなく、公的な相談窓口やサーバー事業者へ、確認できた技術情報と原文を提出する方法もあります。

メール認証は、メールの安全性を一つの結果だけで判断する仕組みではありません。

SPF・DKIM・DMARCが何を確認し、何を保証しないのかを理解しておくと、不審なメールを受け取ったときにも冷静に判断しやすくなります。

法規制・国際規格の調査や、複雑な文書を扱いやすくするためのツール開発に取り組んでいます。

きのとリサーチ