このSPFレコードジェネレーターは、あなたが選択した送信者から有効なSender Policy Frameworkレコードを組み立て、DNSに公開する1行を渡します。その1行に何が含まれているかを知ることで、メンテナンスがはるかに容易になり、SPFレコードを正しく設定できます。ここでは、ジェネレーターが何を構築しているのか、そして各部分がなぜ重要なのかを解説します。
SPFレコードの構造
すべてのSPFレコードは厳格なSPFレコード構文に従います。バージョンタグ、1つ以上のメカニズム、そして締めくくりの修飾子という3つの部分から成る単一のDNS TXTレコードです。完全なレコードは次のようになります。
v=spf1 include:_spf.google.com ip4:203.0.113.10 -all
v=spf1タグは、そのエントリがSPFであることを示し、最初に来なければなりません。他の何かで始まるレコードは無視されます。中央の各メカニズムは送信者のグループを許可し、末尾の-allは、一致しなかったすべての送信者を受信者がどう扱うべきかを伝えます。ジェネレーターは常にこれらを正しい順序で出力します。先頭のv=spf1や締めくくりのall修飾子がないレコードは無効として扱われるからです。
追加できるメカニズム
ジェネレーターに追加した各行は、次のいずれかのメカニズムになります。
include:- 別のドメインの送信者を許可します（Google Workspace、Microsoft 365、SendGrid、そしてほとんどのSaaSプロバイダーを追加する方法です）。各includeは少なくとも1つのDNSルックアップを消費し、さらにincludeを取り込むことがあるため、多くの場合それ以上になります。ip4:とip6:- 特定のIPアドレスまたはCIDR範囲を直接許可します。これらはDNSルックアップをゼロしか消費しないため、既知のメールサーバーを追加する最も安価な方法です。aとmx- あなたのドメインのAまたはMXレコードにあるホストを許可します。それぞれ1ルックアップを消費します。all- 最後に来なければならないキャッチオールで、あなたのポリシーを設定する修飾子と組み合わされます。
ポリシーの選択：-all、~all、または?all
allの前の修飾子は、他のどのメカニズムでも許可されなかったメールを受信者がどう扱うかを決めます。
-all（ハードフェイル） - 許可されていないメールを完全に拒否します。すべての正規の送信者がレコードに含まれたら目指すべき設定です。~all（ソフトフェイル） - 許可されていないメールを受け入れつつ、疑わしいものとしてマークします。SPFを展開し、正規のものが漏れていないか確認する間に使用します。?all（ニュートラル） - まったく何も主張しません。保護を提供せず、正しい選択であることはめったにありません。
安全な展開方法は、~allで生成し、1〜2週間レポートを観察してから、自信が持てたら-allで再生成することです。+allは完全に避けてください。インターネット全体にあなたのドメインとしての送信を許可してしまいます。
ジェネレーターが防ぐよくある間違い
- 複数のSPFレコード。 ドメインは
v=spf1TXTレコードを1つしか公開できません。2つ目があると両方が無効になります。ジェネレーターが生成する単一のレコードに、すべての送信者をまとめてください。 - 10ルックアップ上限の超過。
include:メカニズムを追加しすぎると上限を超え、PermErrorを引き起こします。ライブのカウンターが公開前にこれを警告します。 ptrの使用。ptrメカニズムは非推奨で遅いため、ジェネレーターは代わりにinclude、ip4、ip6に依拠します。all修飾子の欠落や、255文字のTXT上限を超える文字列の分割。どちらもレコードを静かに壊します。
10 DNSルックアップ上限内に収める
SPF仕様は、1回の評価あたりのDNSルックアップを10に制限しています（RFC 7208、セクション4.6.4）。すべてのinclude、a、mx、existsメカニズムが加算され、ネストしたincludeは再帰的に加算されるので、ほんの数個のSaaSプロバイダーで簡単に10を超えてしまいます。生成したレコードが上限を超えている（または近い）場合、AutoSPFがincludeをコンパクトなレコードにフラット化し、15分ごとに再スキャンして、許可された送信者を1つも失うことなく上限内に収めます。詳しい説明はDNSルックアップが多すぎるをご覧ください。
SPF、DKIM、DMARCは協調して機能する
生成したSPFレコードは、3つのメール認証標準の1つです。SPFは送信サーバーを検証し、DKIMはメッセージに署名して改ざんされていないことを受信者が証明できるようにし、DMARCはそれらを結び付けて、失敗時に受信者がどうすべきかを伝えます。Gmail、Yahoo、Microsoftは現在、大量送信者にこの3つすべてを要求しているので、このジェネレーターを無料のDMARCチェッカーとDKIMルックアップと組み合わせて、完全にカバーしましょう。
公開してから検証する
レコードを生成したら、ドメインの頂点（ホスト@）にTXTレコードとして公開し、DNSが伝播するのを待ち（通常5〜60分）、無料のSPFチェッカーで確認するか、SPFレコードをルックアップして、解決し10ルックアップ以内に収まっていることを確かめます。サブドメインは親のSPFレコードを継承しないことを覚えておいてください。メールを送信するサブドメインには独自のレコードが必要で、同じ方法で構築できます。