SPFレコードチェッカー

SPF公開後に確認すべきこと

SPFのミスは、新しい送信サービスを追加したのにDNSを更新し忘れたときや、2つのベンダーがそれぞれ独自のSPFレコードを求め、両方が公開されてしまったときによく起こります。メールボックスプロバイダーは、1ドメインにつきSPFレコードが1つであることを前提としています。v=spf1で始まるレコードが2つあると、個々のレコードが妥当に見えてもSPFが失敗することがあります。

ドメインを入力したら、生のレコードとメカニズムを確認しましょう。include:メカニズムは通常、外部の送信プラットフォームを指します。ip4:とip6:は固定の送信インフラを許可します。mxはドメインのメールエクスチェンジャーを許可します。最後のポリシー（多くの場合-allまたは~all）は、リストにないシステムからのメールをどの程度厳しく扱うかを受信側に伝えます。

SPFレコードが見つからない場合は、ドメインの送信準備ができているとは考えないでください。 SPFレコードジェネレーターでレコードを作成してTXTレコードとして公開し、DNSの反映後に再度テストしましょう。レコードはあっても正当なプラットフォームが含まれていない場合は、キャンペーン開始前にその送信サービスを追加してください。

送信サービスを変更するたびにSPFをチェック

新しいメールサービスを導入すると、認証の構成が変わる可能性があります。ニュースレタープラットフォーム、CRM、ヘルプデスク、ECの通知アプリ、営業用シーケンサーがあなたのドメインから送信することもあります。その場合は、SPFとあわせて DKIM と DMARCも確認しましょう。これにより、受信箱プロバイダー間で送信者のアイデンティティを一貫させられます。

SPFが正しくても、アドレスリストに問題がないことの証明にはなりません。配信開始の準備中なら、受信者も検証しましょう。ドメイン単位の確認にはメールヘルスチェックを、大規模なCSVリストには一括検証ワークフローをお使いください。認証はメールを信頼してもらうのに役立ち、リストの整備はバウンスやネガティブなエンゲージメントを抑えるのに役立ちます。

キャンペーン前のSPF運用チェックリスト

大規模なリストに送信する前に、送信ドメインと専用サブドメインを確認しましょう。SPFレコードが1つであること、稼働中のすべての送信サービスが含まれていること、使っていないベンダーが削除されていることを確認します。CRMやマーケティングプラットフォームがブランドのサブドメインから送信する場合は、ルートドメインでカバーされていると思い込まず、そのサブドメインを個別にチェックしてください。

次に、SPFレコードと実際のキャンペーンの送信経路を照らし合わせます。キャンペーンがセールスエンゲージメントプラットフォーム経由なら、そのプラットフォームを許可する必要があります。プロダクトの通知がトランザクションメールのプロバイダー経由なら、そのプロバイダーも許可する必要があります。このリストを最新に保てば、チームがツールを変更したときに直前で到達率のトラブルに見舞われずに済みます。

最後に、受信者リストを確認します。SPFは送信者が許可されていることをメールボックスに伝えるものであり、エクスポートから無効なアドレスを取り除くものではありません。CRM、ニュースレター、見込み客のリストは、送信前にファイルを検証し、キャンペーン後にバウンス結果を再確認しましょう。バウンス率3%未満は健全、3-5%はクリーンアップが必要、5%超は高リスクです。

共有ドメインでは、このチェックリストを送信サービスのオンボーディングに組み込みましょう。営業、マーケティング、サポート、プロダクトの各チームが同じブランドドメインを使っている場合、1つの送信サービスの登録漏れが全員に影響します。キャンペーン送信後に認証失敗を調査するより、開始前に短くSPFを見直すほうがはるかに低コストです。