BtoB向けのマーケットプレイスやSaaSで、出品者や取引先からの「パスワード再設定メールが届かない」という問い合わせに悩んだことはないでしょうか。
受注通知は時間との勝負ですが、パスワード再設定メールも業務継続の観点では同じくらい重要です。
ログインできない出品者は、新規注文にも対応できません。
この記事では、認証系メールがなぜ迷惑メール（スパム）フォルダに振り分けられるのか、その原因を段階的に分解し、自分のシステムが該当するかどうかを確認する方法と、具体的な対策手順を整理します。
何が起きるか：送信成功と到達は別物
まず押さえておきたいのは、アプリケーションのログに残る「送信成功」というステータスと、実際に受信者の受信トレイに届いたかどうかは、全くの別物だという点です。
SMTP（メール転送に使われるプロトコル）サーバーが受信応答を返したことと、受信者のメールボックスにメッセージが表示されることは、1つのアトミックな操作ではありません。
RFC 5321はSMTPの応答仕様を定義していますが、受信トレイへの配置結果をアプリケーション側から観測可能にする仕組みは含んでいません。
つまり、送信ログに「成功」と記録されていても、そのメールが迷惑メールフォルダに入っている可能性は常に残ります。
注文アラートのような通知メールで「届いた実績」があっても、同じ送信基盤だからパスワード再設定メールも同様に届くはず、という思い込みは危険です。
送信者が認識しているログの戻り値と、受信者側のメールクライアントが下すフィルタリング判断は、まったく異なるレイヤーの話だからです。
なぜ起きるか：認証の仕組みを段階的に分解する
パスワード再設定メールが迷惑メール扱いされる原因は、大きく3つに分けられます。
送信者認証の不整合、送信ドメインやインフラの評判（レピュテーション）の低さ、そして受信側フィルタによる「望ましくないメール」という判定です。
ここで重要なのは、認証が通っていても迷惑メール行きを防げるとは限らないという事実です。
認証は「誰が送ったか」を証明する仕組みであり、「受信トレイに届けてよいか」を保証する仕組みではありません。
3つの認証技術がそれぞれ何を検証しているか、順番に見ていきます。
SPF（Sender Policy Framework）は、SMTPのエンベロープドメイン（配送制御用のドメイン情報）に対して、送信元ホストが許可されているかどうかをチェックします（RFC 7208）。
DKIM（DomainKeys Identified Mail）は、署名ドメインと、署名対象となった本文・ヘッダー部分に対する署名を検証します（RFC 6376）。
署名後にコンテンツが変更されると、署名が無効になる場合があります。何が署名対象で、何が変更されたかによって影響は変わります。
DMARC（Domain-based Message Authentication, Reporting and Conformance）は、SPFやDKIMの認証結果と、受信者が実際に目にする「差出人（Fromヘッダー）」のドメインとの整合性（アライメント）を確認します（RFC 7489）。
ここが落とし穴です。パスワード再設定メールはSPFチェックを通過していても、それが受信者の見るFromアドレスとのアライメントを保証するわけではありません。
SPF・DKIM・DMARCのすべてが通過していても、受信側のメールプロバイダは独自の評判スコアや迷惑メール率、過去の送信パターンを元に最終判断を下します。
これらの基準は公開されている受信者側ガイドラインでも触れられていますが、受信トレイへの到達を保証する「魔法の件名」や万能な設定は存在しません。
自分のプロジェクトが該当するか確認する方法
実際の調査では、テストメールを受信してヘッダー情報を確認することから始めます。
以下の項目を記録してください。
- エンベロープドメイン（SMTP MAIL FROMで指定されるドメイン）
- 受信者が見るFromヘッダーのドメイン
- DKIM署名に使われているドメイン（d=タグ）
- 受信側で評価されたSPF・DKIM・DMARCの結果（Authentication-Resultsヘッダー）
これらはメールクライアントの「元のメッセージを表示」機能や、Gmailなら「メッセージのソースを表示」から確認できます。
# 送信ドメインのSPFレコードを確認する
dig txt example.com +short
# DKIMセレクタを指定して公開鍵レコードを確認する
dig txt selector._domainkey.example.com +short
# DMARCポリシーを確認する
dig txt _dmarc.example.com +short設定ファイルを見る場合は、送信インフラ（SendGrid、Amazon SES、Postmarkなど）の管理画面でドメイン認証ステータスを確認してください。
DKIM署名が「Verified」になっていても、転送やメーリングリスト経由で本文が書き換えられるケースでは署名が無効化されることがあるため、実際の配送経路も合わせて確認する必要があります。
また、パスワード再設定メールのテンプレートが、プロモーションメールと同じ送信ドメインやIPアドレスを共有していないかも確認してください。
共有していると、プロモーションメールの評判低下が再設定メールの到達率に波及するリスクがあります。
対策の手順
調査結果をもとに、以下の順番で対策を進めます。
1. 再設定メール専用のサブドメインを用意する（例: notify.example.com）。プロモーションメールと送信インフラを分離し、評判スコアの影響を切り離します。
2. SPF・DKIM・DMARCをサブドメイン単位で設定する。DMARCポリシーは最初はp=noneで導入し、認証失敗のレポートを収集してからp=quarantineやp=rejectに段階的に引き上げます。
3. 再設定リクエストと注文通知を別のビジネスイベントとして扱う。識別子（IDなど）を分け、同じ出品者IDだけで重複排除しないようにします。異なる業務イベントを混同すると、正当な再設定メールが抑制されるリスクがあるためです。
4. 再設定エンドポイントにレート制限（送信回数の上限設定）を設ける。再送信をスパム対策として悪用されないよう、一定時間内のリクエスト回数を制限します。ただし再設定用の認証情報（トークンなど）はログに残さないよう注意してください。
5. 受信側の観測証拠を記録する仕組みを作る。可能であれば、受信確認のためのテストアカウントを主要なメールプロバイダ（Gmail、Outlook、Yahooメールなど）ごとに用意し、定期的に到達状況を確認します。
これらの手順は、リクエスト（再設定の申請）、ハンドオフ（メールサーバーへの引き渡し）、受信側の観測、という3つの境界ごとに証拠を分けて残すという考え方に基づいています。
境界を分けておくことで、問題が起きたときに「送信設定のミスなのか」「受信側のフィルタリング判断なのか」を切り分けやすくなります。
まとめ
パスワード再設定メールの不達は、送信ログが「成功」でも起きる現象です。
SPF・DKIM・DMARCはそれぞれ異なる対象を検証する仕組みであり、すべて通過しても受信トレイへの到達を保証しません。
まずdigコマンドでSPF・DKIM・DMARCの設定を確認し、再設定メール専用のサブドメインを分離し、DMARCレポートで実際の認証結果を継続的に観測することから始めてみてください。
再設定リクエストと他の通知メールを別のビジネスイベントとして扱う設計も、障害発生時の切り分けを大きく楽にします。