SPF
SPF（Sender Policy Frameworkの略）は、ドメインの所有者がそのドメインからメールを送信できるメールサーバーの一覧を公開できるメール認証規格です。受信サーバーはその一覧を確認して、受信したメッセージが許可された送信元から来たものかを確かめるため、ドメインを装ったメールの偽造が大幅に難しくなります。
定義
Sender Policy Frameworkは、DKIMやDMARCと並ぶ3つの主要なメール認証規格の一つです。SPFは、メールの根本的な弱点に対処します。元々のメールプロトコルには本当の送信者を証明する仕組みが組み込まれていなかったため、初期状態では誰でも任意のドメインから送られたと称するメッセージを送信できてしまいます。SPFは、そのドメインに代わってメールを送信できるサーバーを、公開かつ機械可読な形式で正確に宣言する手段をドメイン所有者に提供し、この欠陥の一部を解消します。
この宣言は、ドメイン名をネットワークアドレスに変換するグローバルなディレクトリであるDomain Name Systemに置かれます。ドメイン所有者は、許可された送信元を記載した特別なDNSレコードを公開します。メッセージが届くと、受信メールサーバーはそのレコードを参照し、実際にメッセージを配信したサーバーと照合します。送信サーバーが一覧にあればメッセージはSPFに合格し、なければSPFに失敗します。失敗は、そのメールが偽造されている可能性を強く示します。SPFは何も暗号化せず、メッセージの内容もチェックしません。答えるのは、このメッセージはドメイン所有者が承認したサーバーから送信されたか、という一点だけです。
仕組み
SPFポリシーは、ドメイン上の1つのDNS TXTレコードとして公開されます。レコードは必ずバージョンタグv=spf1で始まり、許可された送信元を記述する一連のメカニズムが続き、通常はデフォルトの結果を定めるallメカニズムで終わります。シンプルなレコードはv=spf1 include:_spf.google.com -allのようになり、これはGoogle Workspaceのメールサーバーを許可し、それ以外をすべて拒否します。
メカニズムは構成要素です。ip4とip6メカニズムは、特定のアドレスやアドレス範囲を直接許可します。aメカニズムはドメインのアドレスレコードにあるサーバーを許可し、mxはドメインのメールエクスチェンジャーとして登録されたサーバーを許可します。実際に最もよく使われるのはincludeメカニズムで、別のプロバイダーのSPFポリシーを取り込みます。ドメインはこれによって、Google、Microsoft、メール配信プラットフォームなどのサービスに送信を委任します。各メカニズムには、一致したときの結果を決める修飾子を付けられます。デフォルトのプラス記号は合格（pass）、マイナス記号は失敗（fail）、チルダはソフトな警告であるsoftfail、疑問符は中立（neutral）を意味します。末尾のallメカニズムは一致しなかったすべてのサーバーを対象とするため、-allは一覧にないものを厳格に拒否し、~allはより緩やかなシグナルになります。
受信サーバーがSPFを評価する際は、SMTPのやり取りで宣言されるリターンパスであるenvelope-fromアドレスを確認し、リターンパスが空のバウンスメッセージの場合は代わりにHELOのIDを確認します。規格には重要な制約があります。1つのレコードの評価に使えるDNSルックアップは10回までで、include、a、mx、existsなどのメカニズムはそれぞれ1回を消費します。10回を超えるとPermErrorとなり、受信側は失敗として扱うことがあるため、SPFレコードは簡潔に保つ必要があります。SPFには構造上の限界もあります。転送サーバーは元のドメインの一覧に含まれないため、メールが転送されるとSPFは機能しません。そして決定的なのは、SPFが検証するのはenvelope-fromアドレスだけで、受信者が実際に目にする表示上のFromアドレスではないという点です。
メール
SPFは今や任意の追加機能ではなく、必須の基本要件です。メールボックスプロバイダーはSPFチェックの合格を信頼のポジティブなシグナルとみなし、レコードがない、または失敗する場合は疑いの理由とみなします。これはメールが受信トレイと迷惑メールフォルダのどちらに届くかに直接影響します。GoogleとYahooが2024年に導入した送信者要件以降、大量送信者にはSPFによる認証が求められており、有効なSPFレコードがないドメインはメールの送信を制限されたり、完全に拒否されたりすることがあります。
SPFが重要なもう一つの理由は、認証を表示上のFromアドレスに結びつけるポリシー層であるDMARCの前提条件だからです。DMARCは、SPFまたはDKIMが合格したか、そしてその結果がFromドメインと一致（アライメント）しているかを確認します。SPFレコードが正しく設定されていなければ、ドメインはSPFによるDMARCアライメントを達成できず、全体的な保護が弱まります。同時に、SPFにできないことも現実的に理解しておくことが大切です。表示上のFromヘッダーを無視し、転送で機能しなくなるため、SPFだけでは執拗ななりすましを防げません。SPFは3層防御に欠かせない1層であり、DKIMとDMARCを併せて導入したときに初めてその価値を最大限に発揮します。
VeriMailsでの
SPFとメール検証は、同じ到達率の課題をそれぞれ別の側面から解決します。SPFは送信するメールを認証し、それが本当にあなたから送られたものだと受信サーバーに信頼させます。メール検証は送信先のリストをクリーンにし、実在し到達可能なアドレスだけに送信できるようにします。受信トレイへの確実な到達には両方の連携が必要で、どちらも他方の代わりにはなりません。
VeriMailsは受信者側に注力しています。送信されたすべてのアドレスは、構文チェック、MXおよびDNSの照会、リアルタイムのSMTPハンドシェイク、キャッチオール検出、使い捨てアドレス検出、ロールベース検出で確認されます。これにより、無効なアドレスはバウンスする前に除外され、適切なSPF、DKIM、DMARCレコードが守るべき評価を損なうことがありません。認証面のサポートとして、VeriMailsは無料のSPFジェネレーターも提供しています。ドメインと送信サービスに合わせて構文的に正しいレコードを作成し、10回のルックアップ制限内に収めます。リストはREST APIまたはCSVの一括アップロードで検証でき、キャンペーンの判断に役立つ明確な到達率カテゴリーで結果を確認できます。検証は1件あたり$0.0019から、10,000クレジットで$19、年払いの年間プランなら月額$12.50からです。すべてのアカウントは100クレジット無料で始められ、クレジットカード不要、クレジットに有効期限はありません。