SPFは、ドメインのメールを送信できるサーバーを列挙するDNSレコードです。SPFがない、重複している、または誰にでも開放されていると、そのドメインのメールは偽装されやすくなり、拒否されたり迷惑メールに振り分けられたりする可能性が高くなります。
意味
受信側のメールサーバーは、SPFレコードを照会して、あなたのドメインから送信されたと主張するメッセージが許可されたサーバーから送信されたかを判断します。ドメインに設定できるSPFレコードは1つだけで、末尾ではそれ以外のすべてのサーバーをフラグ付け（~all）または拒否（-all）する必要があります。
発生条件
DNSとメールのセキュリティのチェックでは、1日1回、パブリックDNSを通じて登録ドメインのTXTレコードを読み取り、v=spf1で始まるものを確認します。この問題には次の3つのパターンがあります：
- SPFレコードが複数ある（高）：受信側のサーバーは、ドメインのSPFが壊れているものとして扱います。オーナーと管理者には、メールとチャットで一度通知されます。
- SPFレコードが誰にでもメール送信を許可している（高）：レコードが+allで終わっており、インターネット上のすべてのサーバーに送信を許可しています。オーナーと管理者には、メールとチャットで一度通知されます。
- SPFレコードがない（中）：ドメインにMXレコードがあり、メールを受信する場合にのみ検出されます。アプリ内に表示され、メールでは通知されません。
主な原因
- ニュースレター、CRM、ヘルプデスクのサービスが、既存のレコードに追加されるのではなく、独自のv=spf1レコードで設定された。
- +allで終わるレコードがテンプレートからコピーされた、または配信エラーを止めるために追加された。
- メールを新しいプロバイダーに移行した際に、そのプロバイダーが求めるSPFレコードを公開しなかった。
修正方法
- そのドメインとしてメールを送信するすべてのサービスを一覧にしてください：メールボックスのプロバイダー、ニュースレターツール、ウェブサイト、ヘルプデスク、請求書発行ソフトウェア。各サービスの設定ガイドに、使用するincludeが記載されています。
- DNSプロバイダーで、v=spf1で始まるTXTレコードを1つだけ残し、そこにすべてのサービスを含めてください（例：v=spf1 include:_spf.google.com include:sendgrid.net ~all）。それ以外のレコードは削除してください。
- 末尾は~allまたは-allにし、+allにはしないでください。また、DNSルックアップは10回以内に抑えてください（includeごとに1回とカウント）。超えると、受信側のサーバーはいずれにせよ失敗として扱います。
- SPFが正しく設定できたら、DMARCレコードも追加してください。DMARCレコードがありませんをご覧ください。
解消されるタイミング
問題が見つからなくなった次の日次チェックの後に問題は消え、そのアクションは7日後にアクションプランから外れます。
アクションを完了にしても14日後にまだ問題が見つかる場合は、「修正が効いていません」として再表示されます。アクションプランの使い方をご覧ください。