SPFでPermErrorが出たら、評価対象ドメインのレコード、構文、DNS参照を必要とする仕組みの連鎖を確認します。includeの数を表面だけ数える方法では十分ではありません。参照先でさらに参照が行われる場合もあるため、規格の制限と実際の評価経路に沿って調べます。

対象と原因の整理

日本の中小企業では、長年追加したフォーム、販売管理、ニュースレターの設定が一つのドメインへ残っている場合があります。利用していないサービスを調べることは有用ですが、見覚えがないという理由だけで削除すると請求や予約のメールを止めかねません。送信元ごとの担当者と現在の利用状況を先に確認しましょう。

SPFの規格には、DNS参照を引き起こす項目の評価に関する制限があります。文字列内に見える項目数と実行時の参照は同一ではありません。また、複数レコードや構文不備など別の原因もあります。ツールの警告をそのまま結論にせず、対象レコードと指摘の根拠を運用担当者が確認します。

確認手順

外部サービスの設定例を統合するときは、一つの正しいSPF方針として整理する必要があります。各社の例をTXTレコードとして別々に追加するだけでは済みません。IPへ固定化する変更も、サービス側の変更に追従する管理が必要になるため、短くなったという理由だけで採用しないでください。

想定例として、年度末に販促ツールを追加した後、請求通知でPermErrorが報告されたとします。新しいincludeがきっかけでも、昔の未使用経路が積み重なっているかもしれません。担当者一覧を作り、不要と確認できた経路だけを整理し、販促と請求の両方から新しいメールを送って結果を確認します。

修正の記録には、変更前のレコード、削除や追加の理由、影響するサービス、検証結果を残します。問い合わせ先が複数の管理会社に分かれる場合は、誰がDNSを更新するのかを一人に定めます。同時に違う内容を上書きすると原因を追えなくなるため、作業の順序と戻す方法も共有します。

参照回数の問題を解消しても、他の認証や受信分類が正常になる保証はありません。Inbox Checkでは変更後の各送信経路から標本を確認し、構文の検査結果と実メールのSPF結果を区別して保存します。配信量の増加や顧客全体の到達を、この変更だけで改善したと断言しないでください。

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