重要なメールが届かない！ ── 迷惑メールフォルダの落とし穴と、簡単なのに確実な対策

はじめに

みなさんは「重要なメールが届かない」という経験はありますか？

私は先日、外部サービスの二要素認証でこの問題に直撃されました。今日はその体験と、そこから学んだことを共有します。

1. 何が起きたか

その外部サービスでは、ログイン後にメールで届く認証コードを入力する手順があります。

さっきまで普通に届いていた認証コードのメールが、ある瞬間からパタッと届かなくなりました。

「何かやってしまったか？」と焦り、直前の作業を見直したり、設定を確認したり。直接関係する修正をしたわけではないのに、自分を疑ってしまう。

結局、ワタワタと3時間近くを費やしたあと、ふと迷惑メールフォルダを開いてみたら、、、そこにありました。

2. 「そんなはずはない」という思い込み

振り返ると、いちばんの敵は思い込みでした。

• 「重要なシステムからのメールが迷惑メールに入るはずがない」
• 「さっきまで届いていたのだから、メール以外の問題だろう」

この2つの思い込みが、迷惑メールフォルダを確認するという単純な行動をすっかり遅らせてしまいました。 でも、なぜそんなことが？と気になりました。

3. 送信側の設定を調べてみた

原因を調べる中で、メールの信頼性を担保する3つの仕組みを知りました。

メールのヘッダーを確認したところ、送信側はSPFもDKIMもきちんと設定されていました。つまり、送信側に問題はなかったのです。

4. では、なぜ迷惑メールに？

ここが盲点でした。SPF/DKIM/DMARCは「なりすましでないことの証明」であって、迷惑メールかどうかの判定はまた別の話です。¹

Gmailは認証に加えて、以下のような要素も総合的に判断しています。

• メール本文の内容（定型文・テンプレート的な文面は要注意）
• 送信ドメインの評判（レピュテーション）
• 受信者の過去の行動（開封率、削除パターン）
• 他のGmailユーザーからの迷惑メール報告
• 受信側でのエイリアス使用（同じ送信元から複数のアドレスに同じ内容が届くと、大量配信に近いパターンとして判定される場合がある）

私のケースでは、認証コードのメールがほぼ毎回同じ定型文だったことに加え、Gmailのエイリアスで複数アドレスを受信していたことも影響した可能性があります。エイリアスは開発テストやシステム運用でよく使う便利な機能ですが、Gmailのアルゴリズムには「同じ内容が複数アドレスに届いている」パターンとして映ることがあります。正確な原因の特定は難しいのですが、「認証が正しい＝迷惑メールにならない」ではないということは確かです。

5. 確実な対策はこれでした

いろいろ調べましたが、受信側でできる最も確実な対策はGmailのフィルタ設定です。²

手順（PC版Gmail / Google Workspace共通）

1. Gmailの設定 → 「すべての設定を表示」
2. 「フィルタとブロック中のアドレス」タブを開く
3. 「新しいフィルタを作成」をクリック
4. 「From」に、届かなくなったメールの送信元アドレスやドメインを入力
5. 「フィルタを作成」→「迷惑メールにしない」にチェック → 「フィルタを作成」

これだけです。

定型文の繰り返しや、エイリアスを使った複数アドレス受信のように、アルゴリズムが反応しやすい使い方をしている場合は特に有効です。フィルター設定はスパム判定アルゴリズムより優先されるため、「このメールは受け取りたい」という受信者自身の意思表示として機能します。

重要なシステムからのメールは、問題が起きる前に設定しておくことをおすすめします。

6. もうひとつの気づき ── 自分たちのユーザーは大丈夫か？

今回の経験で、私にはもうひとつ大事な学びがありました。もし自分たちが提供しているシステムのエンドユーザーが同じ状況に陥ったらどうでしょう。

「認証コードのメールが届きません」という問い合わせの裏側に、迷惑メールフォルダの問題が隠れているかもしれません。メールが届かないと先に進めないシステムであれば、なおさらです。

「メールが届かない場合は、迷惑メールフォルダもご確認ください」

たったひとことの案内がそこにあるだけで、誰かの「3時間」を3分に縮められるかもしれない、ということです。

この言葉、最近よく見かけていて「大事なことだな」と思っていたはずなのに、思い込みが邪魔をして、ずいぶんと時間を無駄にしてしまいました。使う人の気持ちに立って考える、その大切さを身をもって感じることができました。

まとめ

• 重要なメールでも迷惑メールフォルダに入ることがある
• SPF/DKIM/DMARCが正しくても、Gmailのスパム判定は別の要素も見ている
• 困ったら、まず迷惑メールフォルダを確認する
• 確実な対策は、Gmailフィルタで「迷惑メールにしない」を設定すること
• そして、自分たちのシステムのユーザーにも同じことが起きうるという意識を持つこと

おまけ：実際のメールヘッダーで認証を読んでみる

Gmailでメールを開き、右上の「⋮」→「メッセージのソースを表示」を選ぶと生データが確認できます。その中の Authentication-Results: が認証結果のサマリーです。

今回の認証コードメールのヘッダーを見ると、面白いことが分かりました。このメールは社内のメーリングリスト経由で届いていたのです。

外部サービスのサーバーを出た時点（ヘッダー内の ARC i=1 に記録）

1
2
3

spf=pass    送信元IPがSPFレコードに登録されている
dkim=pass   電子署名あり・改ざんなし
dmarc=pass  SPFとDKIMが揃って合格

社内MLを経由した後、私のアドレスに届いた時点の最終結果

1
2
3
4

spf=none    MLを通じて送信元IPが変わった
dmarc=fail  SPFが外れ、ヘッダーの差出人ドメインとも合わなくなった
dkim=pass   電子署名はメールに残り続けた（ここだけ変わらない）
arc=pass    転送前の認証結果を保全・引き継ぎ

SPFは「どのIPから送ったか」を見るため、MLを経由すると送信元が変わって判定が外れます。一方DKIMの電子署名は転送しても消えません。前回の勉強会でお話しした秘密鍵・公開鍵の署名の仕組みと同じで、対になった鍵でのみ暗号化/復号可能であり、その結果で署名の検証ができます。

ARCは転送の前後で「この時点では認証が通っていた」という記録をリレーで引き継ぐ仕組みです。Gmailはそのチェーンをたどって、元の正当性を確認できます。dmarc=fail でも届いたのはそのためです。

それでも迷惑メール判定を完全に逃れられなかったのは、本文の「認証が通っても判定は別の話」に戻ります。

参考文献