SPF failを調べるときは、表示上のFromではなく、そのメールでSPFが検証したドメインと送信元IPを確認します。差出人のブランド名が正しく見えていても、SPFの対象は別の場合があります。実際のAuthentication-Resultsと配送経路を読んでからDNSの修正を検討してください。

対象と原因の整理

国内の事業者が、Google Workspace、予約システム、販促ツールを同時に使うと、経路ごとにエンベロープ送信元が異なることがあります。会社の主ドメインへ設定を足しても、別ドメインが検証対象なら問題は直りません。どのサービスが何を送った一通かを、送信ログの識別子と原文で結び付けます。

SPFの結果にはfail以外の状態もあります。レコードの構文問題や評価上の制限を、単純な許可漏れと同じものとして扱わないでください。認証結果の理由やDNS応答を保存し、対象ドメインの既存設定を確認します。すでにあるレコードを見ずに二本目のSPFを作成するのは適切な修正ではありません。

確認手順

正規のサービスのIPやincludeを追加する場合も、そのサービスが現在案内する設定を使用します。古いブログの例や、失敗したメールに書かれたIPを無条件で追加しません。権限のある担当者が既存の全送信元を確認し、他の業務メールの設定を失わないよう、変更前の内容と目的を残してください。

想定例として、店舗の予約通知だけがSPF failで、スタッフメールは成功しているケースを考えます。通知の検証対象が配信サービス側のドメインなら、まずそのサービスのカスタム送信元設定を確認します。会社の主ドメインへ無関係なIPを追加するより、通知が使う経路と設定の対応を直す方が筋が通ります。

変更後は新しい通知を発生させ、受信した原文で評価を取り直します。DNS管理画面に保存できたことだけで終わらせず、実際に参照されたドメインが同じかを確認します。段階的な移行中なら旧経路も確認し、切替後に問題が出た場合に戻せる設定情報を担当者が保持しておきます。

SPFが成功しても、Fromとの整合性がなければDMARCの成功に直結しません。また、SPFの成功自体は受信箱配置を保証しません。Inbox Checkの標本では認証と配置を分けて読み、国内のすべての受信サービスに対する結果へ一般化しないでください。転送がある場合は、その後の経路も別途確認します。

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