SPFレコード：その概要、仕組み、および設定方法

SPFとは？

SPF（Sender Policy Framework）は、DKIMやDMARCと並ぶ3つの主要な電子メール認証プロトコルの1つであり、不正なサーバーがあなたのドメインを使用して電子メールを送信することを防ぎます。SPFレコードとは、あなたに代わってメールを送信することが許可されているすべてのIPアドレスおよびメールサーバーを列挙したDNSのTXTレコードのことです。これが設定されていない場合、インターネット上のどのサーバーでもあなたのドメインを偽装することが可能となり、受信サーバー側ではその違いを見分ける手段がなくなります。

このガイドの内容

任意のセクションへジャンプするか、全体像を把握するために最初から最後まで通読してください：

SPFの働き

受信メールサーバーがメールを受信すると、Return-Path（エンベロープの送信者）からドメインを抽出し、DNSに対して 「v=spf1」で始まるTXTレコードを照会し、送信サーバーのIPアドレスが承認リストと一致するかどうかを確認します。一致すればSPFは合格となります。一致しない場合は、結果として「fail」、「softfail」、または「error」となり、その後の処理はDMARCポリシーによって異なります。

SPFは、表示される「From:」アドレスではなく、Return-Pathドメイン（技術的なエンベロープアドレス）を検証します。つまり、SPFだけでは表示名のなりすましを防ぐことはできません。そのため、このギャップを埋めるためにDMARCアラインメントが存在するのです。

SPFレコードの構文：仕組みと修飾子

SPFレコードは、次のように始まります。 v=spf1, 以下の仕組みなどを用いて、承認された送信者を一覧表示します。 ip4:, ip6:、そして を含む：、そして最後に、リストにない送信者に対して受信者がどう対応すべきかを示す条件が付加されています。例を挙げると：

v=spf1 ip4:192.168.1.1 include:_spf.google.com include:sendgrid.net -all

-all と ~all は、SPF における適用レベルの異なる設定を示します。-all（ハードフェイル）は、リストに記載された送信者のみが許可されており、それ以外はすべて拒否すべきであることを受信サーバーに伝えます。~all（ソフトフェイル）はより寛容な設定であり、許可されていない送信者をすべて「不審」としてフラグを立てますが、それでも受信を許可します。送信者の監査が完全に終了したら、-all を使用してください。

それぞれ include:, a, mx, リダイレクト=、そして exists: この仕組みは、以下の計算に算入されます。 10 DNS検索の制限. この値を超えると、PermErrorが発生し、認証が完全に機能しなくなります。その ptr: この仕組みは非推奨です、使用は避けてください。

SPFレコードの作成方法

まず、ご自身のドメインからメールを送信するすべてのサービスを以下のようにリストアップしてください。例えば：

• メインのメールサーバー
• Google Workspace または Microsoft 365
• マーケティングツール（Mailchimp、HubSpot、Klaviyo）
• トランザクションサービス（SendGrid、Mailgun、Amazon SES）、およびユーザーに代わってメールを送信するCRMやヘルプデスク。

各プロバイダーは、 include: ドキュメント内の値。すべての送信者を組み合わせた単一のレコードを作成します（ ドメインごとに1つのSPFレコード), それをTXTレコードとして、あなたの DNSプロバイダー, そしてそれを SPFチェッカー. DNSの伝播 通常は数時間かかりますが、最大で48時間かかる場合もあります。

プロバイダー別のセットアップガイド

SPFレコードの確認と検証方法

SPFチェッカーツールを使用して、レコードの構文が正しいこと、10回のルックアップ制限内であること、そして正しいIPアドレスに解決されていることを確認してください。PowerDMARCのSPFルックアップツールなら、これらのチェックをすべて瞬時に行えます。

適切なSPFチェックで確認すべき事項：

• レコードは次のように始まります v=spf1
• このドメインにはSPFレコードが1つしか存在しません
• DNS 検索の総数は 10 回以下です
• 構文エラーや解決不能なエラーはありません include: ドメイン
• について all 修飾子が存在し、適切である
• 非推奨の仕組みは含まれていません（例： ptr:)

コマンドラインでの確認（Linux/Mac）：

dig TXT yourdomain.com +short | grep "v=spf1"

PowerDMARCのSPFルックアップの利用方法： PowerDMARC SPFチェッカーにドメインを入力すると、ルックアップ回数、メカニズムの内訳、およびエラーの有無を示す診断レポートが即座に表示されます。

SPFでよくあるエラーとその対処法

SPFの失敗のほとんどは、プロトコルそのものではなく、設定のずれに起因しています。以下に、最も頻繁に見られるエラーと、それぞれの修正箇所を挙げます。

SPFとDMARC：整合性の理解

SPFは通過しても、DMARCは依然として失敗することがあります。これは、SPFがReturn-Pathドメインの有効性を検証するのに対し、DMARCではそのドメインが表示されている「From:」アドレスと一致していることを要求するためです。独自のReturn-Pathを使用するサードパーティのサービスを経由して送信する場合、SPFはそのサービスのドメインに対して認証を行うため、送信元のドメインとは異なるドメインが対象となり、DMARCの一致チェックに失敗します。

この問題を解決するには、各プロバイダーに対してドメインのカスタム Return-Path を設定するか、代わりにDKIM アラインメントを利用します（DKIM 署名は転送後も有効であり、送信元 IP に依存しません）。DMARC レコード内のaspf= タグを使用してアラインメントモードを設定してください：aspf=r（緩和モード、サブドメインも可）または aspf=s（厳格モード、完全一致）。

SPF、DKIM、DMARC：これらがどのように連携するか

これら3つのプロトコルは相互に補完し合うものであり、互いに置き換え可能なものではありません。SPFは送信サーバーを検証し、DKIMは暗号署名を用いてメッセージの完全性を検証します。DMARCはこれら2つを統合し、ポリシー（なし／隔離／拒否）を適用するとともに、集計レポートやフォレンジックレポートを生成します。 メールは、SPFアラインメントまたはDKIMアラインメントのいずれかを満たせばDMARCを通過します。一方の機能が動作しなくなった場合に他方が補完できるよう、両方を設定しておく必要があります（例：転送メールでSPFが失敗しても、DKIMは正常に機能する場合など）。

ホスト型SPF：スケーラビリティの問題の解決

SPFレコードに追加するSaaSツールは、それぞれDNSルックアップを消費します。ルックアップ数が10件の上限に達すると、レコード全体が機能しなくなり、すべてのSPFチェックで「PermError」が返されます。手動によるSPFのフラット化（「includes」を生のIPアドレスに置き換えること）は短期的には有効ですが、ベンダーがIP範囲をローテーションすると（実際、事前の警告なしにローテーションが行われます）情報が古くなってしまいます。

PowerDMARCの SPFの自動平坦化 これを、動的に解決することで解決します include: チェーンを最適化されたレコードに変換し、ベンダーのIPアドレスの変更を監視し、手動でのDNS編集を行うことなく、レコードをルックアップ制限内に収めます。以下のサービスを利用している組織では、 SPFマクロ または管理 複数のドメインおよびサブドメインにわたるSPF, ホスト型SPFを利用すれば、メンテナンスの負担を完全に解消できます。

SPFのベストプラクティス・チェックリスト