SPFメールレコードとは何か？機能・構文・エラー

SPFで偽装を封じる

2024年6月25日
著者: Maitham Al Lawati
翻訳: 岩瀨　彩江

この記事はPowerDMARCのブログ記事 What Is SPF Email Record? Function, Syntax, and Errors の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

重要なポイント

1. SPFは、送信サーバをDNSレコードで検証することでスプーフィングを防ぐ、重要なメール認証プロトコルです。
2. すべての認可された送信者を含め、照会数や文字数の制限を遵守して適切にSPFを構成することで、メールの到達率と送信者の評価が大幅に向上します。
3. SPFは、包括的なメールセキュリティ、レポート機能、およびポリシー適用を実現するために、DKIMおよびDMARCと組み合わせて使用するのが最も効果的です。
4. SPF単体では、メール転送時の問題や、多数の第三者送信者を管理する際、またはDNS照会制限を超える場合などに制約があります。
5. 一般的な誤りを回避し、フィッシングやスパムからの保護を維持するためには、ツールを使用してSPFレコードを定期的に確認・更新・検証することが重要です。

世界のどこかで、39秒ごとにサイバー攻撃が発生していることをご存じですか？
その多くは、単純な偽造メールから始まります。
その結果は壊滅的なものになり得ます。

企業は顧客の信頼を失い、ブランドの評判が回復不能なほど損なわれるリスクを抱えています。
これらの攻撃の背後にある最も一般的な手口の一つが「ドメインスプーフィング」です。
これは、犯罪者が信頼されたドメインになりすまし、受信者を欺くというものです。

朗報として、SPFメールレコード（Sender Policy Frameworkとしても知られます）が、最も強力な防御線として機能します。
このガイドでは、SPFメールレコードとは何か、なぜ重要なのか、そしてスプーフィングからドメインをどのように保護できるのかを学びます。

SPFメールレコードとは何か？

DNSレコードで定義されるSPFポリシーは、あなたのドメインの代わりにメッセージを送信することを許可されたメールサーバの一覧を示します。
より具体的に言うと、Sender Policy Framework（SPF）は、ドメインにおける「ゲストリスト」のように機能するメール認証プロトコルです。
たとえば、招待されたゲストだけが入場できる特別なイベントを主催していると想像してみてください。

同じように、SPFを使うことで、あなたのドメインの名で正式にメールを送信できるサーバのリストを作成することができます。
SPFの主な目的は、権限のない送信者があなたになりすますことを防ぎ、メールスプーフィング攻撃を阻止することです。
さらに、SPFを導入することで、メールの到達率を向上させ、送信者としての評価を高めることができるため、正当なメールが迷惑メールフォルダではなく受信トレイに届きやすくなります。

技術的な観点から見ると、SPFはドメインのDNS（Domain Name System）に公開されるTXTレコードの一種です。
このレコードは、受信側のメールサーバに信頼できる送信元を知らせ、あなたのドメインの身元が容易に偽装されないようにします。

SPFメールチェックは実際どのように機能するのか？

SPFは、ドメイン所有者が、そのドメインの代わりに送信することができるメールサーバをIPまたはホスト名で列挙したDNSのTXTレコードを公開できるようにします。
これは、承認済み送信者リストと考えると分かりやすいです。
以下では、SPFがどのように段階的に機能するかを示します。

1.DNSにSPFレコードを公開する

SPFの基盤は、ドメインネームシステム（DNS）から始まります。
DNSは、example.com のような人間が読めるドメイン名を、コンピュータやサーバが通信に使用するIPアドレスに対応付ける仕組みです。
これにより、メールが送信される際、受信サーバはそのメールが主張するドメインを特定し、検証することができます。

SPFを機能させるためには、ドメイン所有者が自分のドメインのDNS内にSPFレコードを公開する必要があります。
このレコードはTXTレコードの形式で、ドメインの代わりにメールを送信する権限を持つメールサーバを、IPアドレスまたはホスト名で指定します。

SPFレコードを公開することは必須の最初のステップです。
これがなければ、受信メールサーバが参照する情報が存在しないため、SPFチェックを実行することはできません。

2.あなたのドメインからメールを送信する

SPFの検証プロセスは、メールが送信された瞬間に始まります。
各送信メールには送信者のドメインに関する情報が含まれており、特に重要なのが「Return-Path」アドレス（エンベロープ送信者またはMAIL FROMアドレスとも呼ばれます）です。
このアドレスは、配信不能メールやバウンスメールの返送先を指定するだけでなく、SPFレコードと照合されるドメインを特定する役割も果たします。

このステップは、SPF検証ワークフロー全体のトリガーイベントです。
Return-Pathでドメインを宣言してメールを送信する行為がなければ、受信サーバが検証する対象が存在しません。
この段階から、受信側のメールサーバは、公開されているSPFレコードに基づき、送信サーバが認可されているかどうかを確認するプロセスを開始します。

3.メールヘッダーから送信者のドメインを特定する

メールが受信者のメールサーバに到達すると、次のステップはどのドメインを検証対象とするかを判断することです。
これを行うために、サーバは「Return-Path」アドレス（エンベロープ送信者またはMAIL FROMアドレスとも呼ばれる）を参照します。
このフィールドは、配信不能またはバウンスしたメッセージの返送先を指定するため、非常に重要です。

ここで重要なのは、SPFチェックはユーザの受信トレイに表示される「From」アドレスではなく、技術的な「Return-Path」アドレスに基づいて行われるという点です。
攻撃者はしばしばこの違いを悪用し、表示上の「From」フィールドを偽造して受信者を欺こうとします。

4.ドメインのSPFメールレコードを照会する

送信者のドメインが特定されると、受信サーバはそのドメインの代わりにメールを送信する権限を持つサーバを確認する必要があります。
これを行うために、サーバはDNSでそのドメインのSPFレコードを照会します。
DNS（ドメインネームシステム）は、インターネット上の公開アドレス帳のようなもので、ドメイン名をサーバが読み取れる情報に変換する役割を果たします。

受信サーバは特に、「v=spf1」で始まるTXTレコードを検索します。
このレコードには、認可された送信サーバの一覧が含まれています。
この情報により、サーバはメールが承認済みの送信元から送信されたものかどうかを判断でき、SPF検証プロセスにおいて非常に重要なステップとなります。

5.送信者のIPアドレスをレコードと照合する

SPFレコードには、そのドメインのメール送信を許可されているサーバを定義するポリシーが含まれています。
受信側のメールサーバは、実際にメールを送信したサーバのIPアドレスを、SPFレコードに記載された認可済みサーバの一覧と照合します。
また、受信側では、Return-Pathメールアドレスを基に照合を行い、送信元のIPアドレスがSPFレコード内に含まれているかどうかを検証します。

6.SPF認証結果を判定する

SPFレコードの確認が完了すると、受信サーバは認証結果を判定します。
考えられる結果は以下のとおりです。

• Pass（合格）：送信元のIPアドレスが、認可された送信者としてSPFレコードに登録されています。
• Fail（失敗）：送信元のIPアドレスが認可されておらず、メールは拒否されるべきです。
• SoftFail（ソフトフェイル）：送信元のIPアドレスはおそらく認可されていませんが、警告付きでメールが受け入れられます。
• Neutral（中立）：送信元のIPアドレスについて、特に明確な主張がされていません。
• None（なし）：ドメインにSPFレコードが存在せず、検証を行うことができません。

7.結果に基づいて処理を実行する

受信側のメールサーバは、SPFチェックの結果および（存在する場合は）ドメインのDMARCポリシーに基づいて対応を行います。
サーバはメールを受け入れる場合もあれば、スパムとしてマークしたり、完全に拒否したりする場合もあります。

検証結果が肯定的であれば、メールは通常受信トレイに配信されます。
一方で、認証が失敗した場合は、SPFエラーとして扱われる可能性があります。

SPFメールレコードを有効化して使用する方法

SPFを活用する前に、その仕組みを理解し、あなたのドメインとメールサービスプロバイダの両方がSPFをサポートしていることを確認することが重要です。
SPFは単独でも送信サーバの認証を行いますが、送信者本人の実際の身元やメッセージ内容の正当性までは検証しません。
そのため、SPFはDKIMやDMARC、さらにはBIMIなどの追加プロトコルと組み合わせることで、より強力で包括的なメール認証フレームワークを構築できます。

SPFを実装する準備が整ったら、プロセスはあなたのドメインのDNSにSPFレコードを作成・公開することから始まります。
このレコードは、あなたのドメイン名を使用してメールを送信する権限を持つサーバを明確に定義し、受信側のメールサーバが不正または偽装されたメッセージをフィルタリングできるようにします。
メールでSPFを有効化するには、次の手順を行う必要があります。

認可されたメールサーバを特定する

あなたのドメインの代わりにメールを送信する権限を持つすべてのメールサーバのIPアドレスまたはホスト名を特定します。
これには、自社のメールサーバだけでなく、Google Workspace、Microsoft 365、SendGrid、Mailchimpなどの第三者メールサービスプロバイダ、そしてあなたのドメイン名を使用してメールを送信するその他のサービスも含まれます。
これらすべてのIPアドレスおよび送信ドメインを網羅した包括的なリストを作成してください。

SPFポリシーを定義する

SPFのポリシーを決定します。
これは、どのサーバがあなたのドメインの代わりにメールを送信できるかを、SPFのメカニズムを用いて指定する作業です。
また、受信サーバがそのポリシーをどの程度厳格に適用するかを、修飾子（たとえば、-allはFail、~allはSoftFail）を使って設定する必要があります。

SPFフォーマットを構築する

SPFレコードは、ドメインのDNS内にTXTレコードとして公開されます。
このレコードは特定の形式に従う必要があり、v=spf1で始まり、その後にメカニズムや修飾子を記述し、最後に修飾子付きのallメカニズムで締めくくります。

SPFレコードを公開する

まず、SPFレコードを作成します。
無料のSPFジェネレーターを使用するか、認可された送信元およびポリシーに基づいて手動でレコードを構築することもできます。
次に、ドメイン登録業者またはホスティングプロバイダが提供する、あなたのドメインのDNS管理システムにアクセスします。

ドメインのDNS設定を開き、新しいTXTレコードを追加します。
ホスト名（通常は「@」または空欄でルートドメインを指定）を設定し、値／データ欄に完全なSPFレコード文字列を貼り付けて登録します。

SPFレコードの構文

SPFレコードには、受信メールサーバが認可された送信者を検証するための特定の構造があります。
SPFレコードの主な構成要素は以下のとおりです。

v=spf1

使用されているSPFのバージョンを指定します。

メカニズム（Mechanisms）

どのサーバがあなたのドメインの代わりにメールを送信できるかを定義します。
一般的なメカニズムには、a、mx、ip4、ip6、include、exists、allなどがあります。

修飾子（Qualifiers）

メカニズムをどの程度厳密に適用するかを示します。
例として、+（Pass）、-（Fail）、~（SoftFail）、?（Neutral）などがあります。

モディファイア（Modifiers）

ルールに追加の指示や例外を与えるもので、redirectやexpなどが該当します。

これらの各要素については、包括的なSPF構文ガイドで詳細に説明されています。
そこでは、有効なSPFレコードの例や、さまざまなシナリオに応じた構成方法も紹介されています。

SPFメールレコードを確認する方法

SPFレコードを設定した後、DNSの変更がインターネット全体に反映されるまでに時間がかかる場合があります（最大48時間かかることもありますが、通常はそれより短時間です）。
SPFレコードチェックツールを使用して、レコードの検証とテストを行いましょう。
これにより、構文の正しさを確認し、DNSサーバによって正しく認識されていることを確かめることができます。

SPFレコードは、メールインフラの要件によっては複雑になることがあります。
構文に不安がある場合や、より高度な設定が必要な場合は、システム管理者、ITサポート、またはメール認証の専門家に相談し、正確なSPFレコードを作成することをお勧めします。

よくあるSPFメールの誤りを避ける

設定ミスがあると、SPFポリシーが正しく機能しなかったり、正当なメールがブロックされたりする可能性があります。
以下の一般的な落とし穴を避けましょう。

複数のSPFレコードを使用する

すべての送信サービスを1つのレコードに統合し、検証エラーを防ぎましょう。

構文の誤り

構文やメカニズムを正しく使用し、レコードが無効にならないように注意してください。

すべての認可送信者を含めていない

ドメインの代わりにメールを送信するすべてのサーバおよび第三者サービスをリストに含めましょう。

DNSルックアップ制限（10回）を超える

メカニズムを制限内に収め、SPFが正しく機能するようにしてください。

文字数制限を超える

1つの文字列につき255文字以内、かつDNS全体のサイズ制限を超えないようにします。

誤ったレコードタイプを使用する

常にTXTレコードとしてSPFを公開し、廃止されたSPFタイプは使用しないでください。

更新を怠る

メールサービスやサーバを追加・削除した際には、必ずSPFレコードを更新しましょう。

PowerDMARCでSPFメールポリシーをさらに強化する

SPFメールレコードの導入は、あなたのドメインをスプーフィング、フィッシング、スパムメールから保護するための重要なステップです。
SPFレコードを正しく設定・維持することで、認可されたサーバだけがあなたの名でメールを送信できるようになり、ブランドの信頼性を守ることができます。
SPFの構文を理解し、よくある設定ミスを回避し、さらにSPFをDKIMやDMARCと組み合わせることで、メール認証戦略を強化し、不正メールが受信者に届くリスクを大幅に減らすことができます。

メールセキュリティをさらに高めたい方は、SPFをより深く理解し、信頼性の高いツールを活用することが効果的です。
PowerDMARCは、SPFレコードの監視・管理・最適化を簡単に行えるソリューションを提供し、あなたのドメインを安全に保ち、メールの信頼性を維持する手助けをします。

よくある質問

SPFメールレコードの制限にはどのようなものがありますか？

SPFは送信サーバの認証しか行えず、送信者本人の身元やメール内容の正当性までは検証できません。
また、DNSルックアップは最大10回までという制限があり、構文にも厳格なルールが存在します。

SPFとDKIMは同じものですか？

いいえ、異なります。
SPFは送信サーバを検証しますが、DKIMは暗号署名を使用してメッセージ内容が改ざんされていないことを確認します。

メールがSPFで失敗するのはなぜですか？

メールが認可されていないサーバから送信された場合、SPFレコードに構文エラーがある場合、またはDNSルックアップの上限を超えた場合に失敗することがあります。