SPFレコードは、メール配信に使われるドメインについて、送信を許可されたシステムを示します。それだけで、顧客に表示されるFromアドレスを検証したり、受信者がメッセージを希望していると証明したりするものではありません。ストア運営者が行うべきことは、正しいホスト名を特定し、正当な送信元を維持したうえで、利用中の送信アカウント向けに提供されたレコードを使うことです。
ホスト名と既存の送信元を特定する
DNSを管理する担当者に、該当するホスト名を正確に確認してもらいます。社内スタッフのメールとマーケティングサービスで送信の仕組みが異なることがあるため、すべてのレコードを同じ場所に設定すると決めつけないでください。
アカウント向けに提供された値を使います。変更前の設定を保存し、現在それに依存しているサービスを特定しましょう。同じホスト名に競合するSPFポリシーを二つ追加すると、許可できる送信元が増えるのではなく、エラーの原因になることがあります。
SPFで確認できる送信元を理解する
SPFは通常、メール送信の内部処理で使われるドメインを評価します。これはメッセージのReturn-Path情報などに表示され、From欄に表示されるアドレスとは異なる場合があります。そのためSPFの合格結果は、どのドメインについて合格したか、DMARCのアラインメントがどうなっているかと合わせて解釈します。
ポリシーはDNSで公開しますが、許可するのは送信インフラであり、メールを書く従業員の一覧ではありません。新しいメールボックス利用者を追加する作業と、新しい配信サービスを許可する作業は別です。どのDNSポリシーを確認すべきか判断する前に、そのサービスが実際にどのドメインを使うか調べましょう。
評価対象の同じホスト名に、競合するSPFポリシーを複数設定してはいけません。一方、DNS管理画面が長いTXTレコードを引用符付きの文字列に分けて表示する場合があります。これは別々のレコードが複数あることとは異なります。管理者は画面上の表示と独立した複数ポリシーを区別する必要があります。表示上の行数だけを見て、レコードを結合または削除しないでください。
推測で編集しない
SPFレコードから別のレコードを参照すると、参照回数の上限や依存関係が発生します。送信元を一つずつ追加した結果、設定全体が長く複雑になり、個々の追加が妥当に見えても動作しなくなることがあります。構成が複雑になったら、資格のある管理者に全体を評価してもらいましょう。
見慣れない項目が何に使われているか確認せず削除しないでください。同時に、テストに合格するという理由だけで、使わなくなったサービスをいつまでも許可しないようにします。正当な送信元と、各サービスの担当者を短い一覧にまとめてください。
追加の一項目でポリシーが失敗する理由を知る
SPFでは、評価中にDNSを参照する仕組みや修飾子の回数に制限があります。短く見えるレコードでも、入れ子になった参照を通じて多数の問い合わせが発生する場合があります。そのため、新しいincludeの文法が正しくても、追加によって評価エラーが起きる可能性があります。確認すべきなのは文字数ではなく、評価される経路全体です。
管理者に現在の参照先を見てもらい、どれがまだ必要か特定してもらいます。検査ツール上の表示を簡単にするためだけに、サービスがサポートする設定を固定のIPアドレス一覧へ手作業で置き換えないでください。IPアドレスが変わることがあります。サービス提供元がサポートする方法を使い、複雑さは担当する技術チームと解消しましょう。
メールが届いた後の認証結果を確認する
変更が反映された後、意図したSendvio設定から確認用のメールを送信し、認証結果を調べます。SPFだけで完了とせず、DKIMとDMARCのアラインメントも合わせて確認してください。
検証できたホスト名と日付を設定記録に残します。ドメインや送信サービスを変更したときは再確認しましょう。SPFの設定が正しければ、認証失敗の一種類を減らせますが、配信許可、苦情、コンテンツ、送信方法も受信者の体験に影響します。
問題をエスカレーションするときは、影響を受けた送信ドメイン、確認メールを送った時刻、評価対象のIDとSPF結果、認証ヘッダーのうち個人情報を取り除いた関連部分を共有します。社内の通常メールも失敗するのか、マーケティング設定だけで起きるのかも伝えましょう。これによりドメイン全体の変更か、個別サービスの問題かを切り分けやすくなります。
修正後は、変更したポリシーが対象とするすべての正当な送信経路をテストしてください。マーケティング配信を直すために、サポートや運用のメール送信許可を消してはいけません。承認済み送信元の一覧を、設定担当者と最終確認日と一緒に保管します。SPFの保守が成功したと言えるのは、一度のキャンペーンがたまたま合格したときではなく、正当な送信元が許可され、使われなくなったものが意図的に除外されたときです。