問い合わせ用や通知用のメールアドレスに、見覚えのない広告や本物そうに見えるが怪しいメールが増えた、という話はよく聞きます。
この記事では、専門用語は必要なところだけにとどめて、次の順で整理します。
- スパムメールって何？
- なぜ届く？
- どんな対策ができる？
- 調査方法
- 今回の対応例（概要）
スパムメールって何？
ふだん言う「スパムメール」は、だいたい 「受け取りたくないのに届いたメール」 のことです。中身は一種類ではありません。
たとえば次のようなものがあります。
- 広告・勧誘（登録した覚えのないメルマガ、オプトアウトがわかりにくいものなど）
- 迷惑扱いされやすい一斉送信（送った側は正当でも、受信側のルールではジャンクに入りやすいことがある）
- フィッシング（銀行や有名サービスを装って、リンクや添付でだまそうとするもの）
- 差出人が本当かどうか怪しいもの（画面に表示されている送信者名と、裏側の送り方が合っていない疑いがある場合）
「法律上どうか」「契約上どうか」と「メールの設定でどう防ぐか」は別の話です。技術の話と、ルールや法律の話を混ぜないほうが、あとあと整理しやすくなります。
なぜ届く？
理由は一つではなく、次のようなことが重なって起きます。
- メールアドレスがどこかに出ている（Web サイトの問い合わせリンク、名刺、PDF、過去のメーリングリストなど）
- 漏えいやリスト売買（別のサービスの事件などでアドレスが知られてしまうケース）
- 推測で送られる（よくある名前のローカル部を、同じドメインに大量に試すなど）
- 転送やエイリアスで、別の箱に届いたメールが、いま見ているアドレスに集まっている
- インターネット上のメールの仕組みの性質上、届けやすい部分がある（そのうえで、送信元のなりすましが起きやすい環境もある）
「フォームから来たから安全」と決めつけないほうがよいです。画面の件名や本文だけでは、なりすましかどうかは判断しにくいことがあります。確かめたいときは、後述の調査のように 認証結果やログ を見る、という考え方になります。
どんな対策ができる？
大きく 3 つの方向 に分けると、頭の中が整理しやすいです。
受信側（プロバイダ・メールソフト）
迷惑メールフィルタを使う、強さを変える、などが代表例です。ここでひとつ大事なのは、「受信箱が静かになった」とき、迷惑メールフォルダに逃がしているだけかもしれないという点です。効果を測るなら、受信箱だけでなく 迷惑フォルダも含めて 見る必要が出てきます。
送信側（自分のドメインから送る正当なメールの信頼性）
ざっくり言うと、自分が送ったメールが本物だと受信側に示しやすくするための設定です。結果として 迷惑メール扱いされにくくなる ことも期待できますが、それだけではありません。他人があなたのドメインを装って送るなりすましを抑える、DMARC で 認証の成否を把握する、といった意味も含みます。
自分が運用するドメインについて、SPF・DKIM・DMARC といった設定を整える、という話です。DMARC には集約レポート（rua）のような仕組みもありますが、これは 「認証がどう通ったか」の統計に近いもので、「スパムが何通来たか」の一覧ではない と理解しておくと、期待とズレにくくなります。
受信箱に来る迷惑メールの量と、**「自分のドメインのなりすましを相手にどう扱ってもらうか」**は関係しうる一方で、常に同じではない と考えておくとよいです。受信側のコンテンツ判定や評判（レピュテーション）などが主戦場になることもあります。
公開と運用
公開するメールアドレスを用途ごとに分ける、問い合わせ専用を用意する、などです。対策の前後で比べられるように、期間をそろえた件数や 受信箱＋迷惑フォルダの合計 など、何を「増えた／減った」の数字にするか を先に決めておくと説明しやすくなります。
調査方法
「サーバや DNS を変える前に、いまどれくらい・どんな傾向かをそろえる」というのが、安全で説明しやすい出発点になります。
事前にメモしておくとよいこと
あとから自分や他人に説明しやすいよう、短いメモやスクリーンショットで残しておくとよいです。
- 対象アドレスの用途（問い合わせ用か、通知用かなど）
- 受信の経路（Web メール、POP、IMAP、転送の有無）
- コントロールパネルで変えられること（迷惑フィルタの強さ、検知したあと受信箱に残すか迷惑フォルダに送るか など）
- DNS に SPF・DKIM・DMARC があるか、DMARC のポリシー
- DMARC の集約レポートが届いているか
データの取り方（比較をしたいとき）
対策の前後で数字を比べたい場合の例です。手順は環境によって変わります。
- 受信箱を、mbox などクライアントが出せる形式で書き出す。
- ファイル名やフォルダ名に 調査日（YYYYMMDD） を入れておく。
- 書き出したデータに含まれる 期間（先頭と末尾の日付）をメモする。
効果を語るなら、迷惑メール（ジャンク）フォルダも同様に書き出すのが有効なことが多いです。フィルタを「迷惑へ移動」にすると、受信箱の件数だけが減るのは当然で、スパムが消えたとは限りません。比較するときは 受信箱＋迷惑の合算や、同じ日数にそろえた 1 日あたりの件数 など、定義をそろえます。
オフラインでの集計（一例）
本文を一通ずつ人の目で読み切らない前提で、ヘッダを抜き出して表や集計にする方法があります。
- 手元の Python 3 だけで実行し、追加の pip パッケージは使わない。ネットワークにメールを送らない。
- mbox を読み、通ごとに
From・Return-Path・Authentication-Results（spf/dkim/dmarc）・Receivedから推測した送信元 IP（IPv4 に限る簡易的な取り方）などを 1 行にまとめる。 - 出力は 表計算や検索に渡しやすい CSV と、件数・分布用の JSON やテキストの要約 にする。
「この通はスパム」とスクリプトだけで最終判定するのは避け、人間がルールに沿って判断する、という前提を決めておくとよいです。
今回の対応例（概要）
ある環境で、問い合わせ用の受信箱に迷惑や偽装疑いのメールが目立つ、という相談を受けたときの 流れの一例 を短くまとめます。数字や期間は案件ごとに異なります。
- 用途・経路・パネル・DNS をメモし、現状を言葉とスクショでそろえた。
- 受信箱と迷惑フォルダの両方を、期間がわかるように書き出した。
- 手元で Python によるオフライン集計（上記の調査方法）で、傾向と認証まわりの様子を CSV と要約にした。
- 変更候補を一覧にした。迷惑フィルタのオンオフと強さ、検知後の動き（受信箱に残す／迷惑へ／削除など）、受信側の DMARC 関連オプションの有無、必要なら振り分けルール——といった順で、公式の説明に沿って確認できるようにした。
説明のときは、**「受信箱に来る迷惑メールの話」と「SPF／DKIM／DMARC の設定の話」**を一文に混ぜないようにすると、誤解が減ります。
まとめ
- スパムは一語で一種類ではなく、広告・迷惑・フィッシング・偽装疑いなど幅があります。
- 届く理由は、アドレスの公開・漏えい・推測・転送・仕組み上の要因などが重なります。
- 対策は、受信フィルタ・送信認証・公開と運用のどこを厚くするかの組み合わせです。
- 調査は、メモ → 受信箱と迷惑の書き出し → オフライン集計、という順が再現しやすいです。
レコードの具体的な編集手順は、利用中のドメイン・メールのドキュメントと併せて読むと、全体像とつながりやすくなります。