転送後だけSPFが失敗する場合は、最初の送信と転送後の配送経路を分けて確認します。SPFは接続元と検証対象ドメインに関わるため、経路が変われば結果も変わり得ます。ただしSPFだけでDMARCの失敗は決まらないため、整合したDKIMの成否と受信側のDMARC結果も読んでください。

対象と原因の整理

日本の店舗では、公開アドレスから担当者個人の受信箱へ転送する運用があります。最終受信箱で見つからないとき、元のアドレスへ届いていないのか、転送処理で止まったのかを先に分けます。複数の転送先へ同時に送られる場合も、各経路の時刻と結果を独立して記録しましょう。

証拠は、元の受信先と最終受信先の原文や配送記録から集めます。転送メールをさらに担当者が転送して提出すると、調べたい経路に別の段階が加わります。可能なら原文ファイルとして保存し、どのサーバーが書いた認証結果なのかを確認します。古い段階の成功を最終段階の結果と誤認しないようにします。

確認手順

本文の変更やフッターの追加がある場合は、DKIMの検証へ関わる可能性も確認します。転送サービスの具体的な処理は、公式の運用手順と管理者の情報に従います。原因が分からないまま、見知らぬ転送サーバーを自社SPFへ追加したり、DMARCの方針を弱めたりして解決したことにしないでください。

想定例として、問い合わせ窓口から二人の担当者へ転送し、一人の受信箱だけで認証が異なる状況を考えます。まず最終受信サービスと転送途中の処理を比べます。元のメールは同じでも、一方だけ本文を付け替える仕組みがあれば別の検証条件になります。差がある段階を見つけてから、該当する管理者へ相談します。

転送を止めて直接送る比較は、許可された検証用アドレスで行います。業務用の公開アドレスを急に変更すると、顧客の問い合わせを取り逃がす可能性があります。元の設定と復旧手段を残し、検証中に発生したメールをどう扱うかも担当者間で決めておくと、調査と通常業務を両立できます。

Inbox Checkへ直接送った標本は、顧客の転送経路を通っていない可能性があります。したがって、その結果だけで転送後の正常性を証明できません。テストした経路を明記し、再現していない転送や企業ゲートウェイは未検証として残してください。認証とフォルダー位置も引き続き別項目で扱います。

検証の方法と限界を確認してから、Inbox Checkで標本を観察してください。未測定の受信サービスは結果に含めず、到達を保証しない形で記録します。