SPF（Sender Policy Framework）

SPF（Sender Policy Framework）は、ドメイン所有者がそのドメインの代理としてメッセージを送信することを許可されたメールサーバーを宣言できるメール認証プロトコルです。承認されたIPアドレス、サーバーホスト名、includeディレクティブのリストを含むDNS TXTレコードを公開することで機能します。受信側のメールサーバーが受信メッセージを受け取ると、送信者のドメインに対してSPFルックアップを実行し、送信サーバーのIPアドレスをSPFレコードと照合し、その結果に基づいてメッセージを受け入れるか、フラグを付けるか、拒否するかを決定します。SPFは、DKIM（メッセージの暗号署名）とDMARC（ポリシーの適用）と並ぶ、3つの主要なメール認証標準の1つです。

SPFレコードがない場合、インターネット上のあらゆるサーバーがあなたのドメインからメールを送信していると主張できます。攻撃者はドメインスプーフィングを通じてこれを悪用します。これはフィッシングキャンペーン、ビジネスメール詐欺、スパム配信の中心的な手法です。SPFレコードが欠落または誤設定されている場合、正当なメールの配信にも悪影響を及ぼします。Gmail、Outlook、Yahooなどの主要プロバイダーは、適切な認証のないドメインからのメッセージをますます拒否またはスパム判定するようになっています。フリップブックリンクの共有、リードキャプチャ通知の送信、OTPコードの配信など、メールでコンテンツを配信するパブリッシャーにとって、SPFはメッセージが受信箱に届くかスパムフォルダに消えるかに直接影響します。

FlipLinkはパブリッシャーに代わって複数の種類のメールを送信します：リードキャプチャ通知アラート、パブリケーション共有リンク、OTP検証コード、ドキュメント承認リクエストなどです。これらのメールはFlipLinkの検証済みインフラストラクチャを通じて送信され、配信可能性を確保するために独自のSPFレコードを維持しています。FlipLinkのパブリケーションに[カスタムドメイン](/features/custom-domains)を使用し、メール通信がそのドメインから送信される、またはそのドメインを参照するようにしたい場合は、ドメインのSPFレコードにFlipLinkの送信サーバーを追加する必要があります。これにより受信側のメールサーバーにFlipLinkがあなたに代わって送信する権限があることを伝え、メッセージが疑わしいものとしてフラグ付けされるのを防ぎます。設定はDNS管理パネルで数分で完了し、そのドメイン下のすべてのパブリケーションにグローバルに適用されます。

SPFレコードは、ドメインに関連付けられた単一のDNS TXTレコードです。認証ルールを定義するための特定の構文を使用します： - **`v=spf1`** — SPFバージョンを宣言（常にバージョン1） - **`ip4:` / `ip6:`** — 特定のIPアドレスまたはCIDR範囲を認証 - **`include:`** — 別のドメインのSPFレコードを参照（サードパーティ送信者に一般的に使用） - **`a` / `mx`** — ドメインのAレコードまたはMXレコードに関連付けられたIPを認証 - **`~all`**（ソフトフェイル）— 未認証の送信者を疑わしいとマークするが配信は継続 - **`-all`**（ハードフェイル）— 未認証の送信者からのメールを完全に拒否 SPFには、単一レコード内のDNSクエリに対して10回のルックアップ制限があります。この制限を超えると、SPFチェック全体が失敗します。これは多くのサードパーティメールサービスを使用するドメインでよくある問題です。各`include:`ディレクティブは1回のルックアップとしてカウントされ、ネストされたincludeも合計にカウントされます。

FlipLink使用時にドメインのSPFを設定するには、以下の手順に従ってください： 1. **現在のSPFレコードを確認する** — DNSルックアップツールまたはレジストラのDNSパネルを使用して、`v=spf1`で始まるTXTレコードが既に存在するか確認します 2. **すべての認証済み送信者をリストアップする** — ドメインからメールを送信するすべてのサービス（メールプロバイダー、マーケティングツール、FlipLink）のSPF includeの値を収集します 3. **FlipLinkのサーバーを追加する** — 既存のSPFレコードにFlipLinkの認証済み送信サーバーディレクティブを追加します 4. **適用レベルを設定する** — 最初は`~all`（ソフトフェイル）を使用してブロックせずに監視し、すべての正当な送信者が含まれていることを確認してから`-all`（ハードフェイル）に切り替えます 5. **ルックアップ数を確認する** — SPF検証ツールを使用して、レコードが10回のルックアップ制限内に収まっていることを確認します 6. **配信をテストする** — FlipLinkを通じてテストメールを送信し（リードキャプチャをトリガーするか、パブリケーションを共有）、メールヘッダーで`spf=pass`を確認します 7. **定期的に監視する** — ドメインにメール送信サービスを追加または削除するたびにSPFレコードを見直します

**「SPFだけでドメインを保護できる」** SPFは送信サーバーのIPアドレスのみを検証します。受信者が目にする「差出人」アドレスは検証しません。完全な保護にはSPFとDKIM（メッセージコンテンツに署名）およびDMARC（SPFとDKIMの結果を目に見える差出人アドレスに紐付け、失敗時のポリシーを定義）の組み合わせが必要です。 **「SPFは受信箱に表示されるアドレスに適用される」** SPFは実際には「エンベロープfrom」アドレス（リターンパスとも呼ばれる）を確認します。これは受信者からは見えません。ユーザーがメールクライアントで見る「差出人」ヘッダーはDMARCのアラインメントによって管理され、SPF単独ではありません。 **「includeディレクティブが多いほどSPFレコードが強くなる」** 各`include:`は10回のルックアップ制限にカウントされます。サービスを含めすぎると、SPFレコードが完全に壊れ、すべてのチェックで永久的なエラーが返される可能性があります。ドメインから実際にメールを送信しているサービスのみを含めてください。 **「SPFは一度設定すれば二度と触る必要がない」** SPFレコードにはメンテナンスが必要です。新しいメールマーケティングツールの追加、CRMプロバイダーの変更、FlipLinkなどのサービスの導入には、すべてレコードの更新が必要です。廃止されたサービスの古いエントリはルックアップスロットを浪費し、セキュリティ上の隙間を生む可能性があります。