SPFレコードとは？仕組みと設定方法

SPF（Sender Policy Framework）は、フィッシング攻撃や迷惑メールでよく使われる手法であるメールスプーフィングを防ぐために設計されたメール認証プロトコルです。メールのサイバーセキュリティにおいて不可欠な要素として、SPFは受信メールサーバーが、受信したメールがそのドメインの管理者によって許可されたドメインから送信されたものかどうかを確認できるようにします。

典型的なフィッシング攻撃において、脅威アクターが送信者のアドレスを公式のビジネスアカウントや被害者が知っている人物のように偽装するため、SPFは有効な対策となります。SPFを実装することで、組織はフィッシングメールや迷惑メールを送信する脅威アクターによって自身のドメインが悪用されるのを防ぐことができ、それによってメールの配信到達性と全体的な評判を向上させることができます。

SPFの核心はシンプルな技術的プロセスにあります。受信メールサーバーが、ドメインの管理者によって認可されたホストとメールの送信元を照合する方法を指します。ドメインネームシステム（DNS）レコードには、ドメインの認可された送信ホストとIPアドレスのリストが記載されています。

メールを受信すると、SPFプロトコルにより、受信サーバーは特定のドメインからのメールであると主張するメールをそのドメインの所有者が認可したものかどうかを検証できます。検証されると、メールは受け入れられます。検証に失敗した場合、そのメールはスプーフィングと見なされ、通常はスパムとしてマークされるか拒否されます。

SPFは組織のメールセキュリティ態勢を効果的に改善できますが、SPF単体では十分ではありません。SPFは、DKIMやDMARCなどの他の技術と組み合わせた多層的なメールセキュリティアプローチの一部であるべきです。

SPFはメールセキュリティツールとして非常に重要な役割を果たします。万能な解決策ではありませんが、SPFは以下のような効果があります。

• メールスプーフィングの防止: SPFはドメインをスプーフィングから保護し、スパムフィルターがあなたのドメインをブラックリストに載せるリスクを軽減します。
• メール配信到達性の向上: SPFによってメールを検証することで、スパムとして扱われる可能性が減少し、配信到達性が向上します。
• ドメインの評判向上: 有効なSPFレコードは、インターネットサービスプロバイダー（ISP）やメールクライアントにおけるドメインの評判を高め、メールの正常な配信を促進します。
• フィッシング攻撃対策: SPFは、脅威アクターがあなたのドメインから送信されたように見せかけてメールを送ることを防ぐため、フィッシングメールとの戦いにおいて重要です。
• コンプライアンスのサポート: メールコミュニケーションが規制されている業界では、SPFレコードはメールコミュニケーションの正当性を確立して、コンプライアンスの確保を支援します。

SPFレコードとは、あなたのドメインに代わってメールの送信を許可されているメールサーバーを識別するDNSレコードの一種です。SPFレコードの目的は、スパマーがドメインに関連づけられたメールアカウントを偽造して、「From」アドレスを使用してメッセージを送信するのを防ぐことです。

技術的には、SPFレコードはドメインのDNSにおけるエントリで、そのドメインのメール送信を許可されたIPアドレスとホスト名を指定します。メールを受信した際、メールサーバーは送信ドメインのSPFレコードを確認し、そのメールが正当なものであることを確認できます。メールの送信元が許可されたサーバーのリストに含まれていれば、そのメッセージはSPFチェックに合格します。そうでない場合、メールの配信は失敗し、スパムとしてマークされるか拒否されます。

SPFレコードを持つことはメール認証の重要な部分です。これにより、管理者はフィッシングメールが意図された被害者に届くのをブロックすることができます。

SPFレコードは、組織の公式メールサーバーとビジネスに代わってメールを送信できるドメインのIPアドレスを含むDNSエントリです。SPFレコードは、どのメールサーバーがドメインのメール送信を許可されているかを指定して、メールがスパムとしてマークされる可能性を減少させます。これはメールの配信到達性を向上させ、メールが受信者の受信トレイに届き、スパムフォルダに振り分けられないようにします。

SPFレコードを維持することは、ドメインの評判を守るために不可欠です。SPFレコードがないことが理由でドメインがスパム送信に使用された場合、正当なメールがブロックされたり、スパムフォルダに入ってしまったりする可能性があり、ドメインの評判を損なう可能性があります。

サードパーティのメールシステム（例：Google Suite）を使用してメールを管理している場合、送信者があなたのビジネスに代わってメッセージを送信する権限があることを受信メールサーバーに伝えるSPFレコードが必要です。SPFレコードがない場合、受信者のメールサーバーはそのメッセージがフィッシング攻撃の可能性があると受信者に警告する場合があります。一部のビジネスメールサーバーでは、システムがメッセージを破棄したり、直接受信者のスパム受信トレイに送信したりするため、受信者がそのメッセージを受け取らない可能性があります。

多くの受信者はスパムフォルダのメッセージを読まないため、企業は顧客や潜在的なリードとのコミュニケーションに困難を抱えることになります。大手のメールシステムの多くはすでにSPF検出を組み込んでいるため、すべてのドメイン所有者はDNSサーバーにレコードを追加して、メールメッセージが受信者の受信トレイに届くようにする時間を取るべきです。Google、Hotmail、Yahooなどの個人向けサードパーティメールシステムはすでにSPFレコードを組み込んでいるため、個人のメールアカウントにレコードを追加する必要はありません。

すべてのドメインはDNSサーバーを使用しており、ウェブサーバーのIPアドレスをユーザーがブラウザウィンドウに入力する使いやすいドメイン名にリンクさせています。SPFレコードは、メール認証に使用されるDNSレコードの一種で、メール送信者が特定のドメインに代わってメールを送信する権限があることを検証します。以下は、SPFレコードの仕組みの概要です。

• 認可されたサーバーの定義: SPFレコードには通常、IPアドレスやドメイン名などの識別子が含まれており、これらがドメインに代わってメールを送信することを許可されたメールサーバーやドメインを明確に示します。
• SPFレコードの検証: メールが到着すると、受信サーバーは送信者のドメインに関連するSPFレコードを確認します。送信サーバーのIPアドレスをSPFレコードの許可されたアドレスと比較します。
• 認証結果: SPFレコードのルールに基づいて、受信サーバーはメールの正当性を判断します。結果は、受け入れから不審としてマークされる、あるいは完全に拒否されるまで様々です。
• 不正防止: SPFを使用することで、ドメイン所有者はメールスプーフィングやフィッシングから身を守ります。これにより、自分のドメインからのメールだと主張するメールが確かに認可されたサーバーから送信されていることを確認し、不正行為を軽減します。

SPFレコードが適切に機能するには、特定のフォーマットと値が必要であり、多くの場合ドメイン管理者による設定に依存します。SPFはメール認証の一要素に過ぎず、DKIMやDMARCなどの他の標準と連携して機能します。

SPFレコードには、IPアドレス以外の情報も含まれています。送信者のIPが許可されたIPアドレスのリストと一致しない場合に、受信サーバーがどのように対応すべきについての指示も含まれています。IPアドレスにはIPv4とIPv6があるため、SPFレコードでは両方のバージョンを定義できます。各メールメッセージには2つの「ヘッダー」があります。メールメッセージの上部に表示される可視ヘッダーと、非表示の技術的ヘッダーです。各ヘッダーには「from」メールアドレスが含まれています。可視ヘッダーに表示されるもの（「ヘッダーfrom」または「フレンドリーfrom」とも呼ばれる）と、メールの非表示の技術的ヘッダーに含まれる「エンベロープfrom」アドレス（Return-Pathやmfromとしても知られる）です。以下は各ヘッダーの例です。

ユーザーに表示されるヘッダー：

技術的な非表示ヘッダー：

SPFレコードの別の例は以下です。

v=spf1 ip4:48.213.51.127 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e include:authorized-domain.com -all

SPFレコードの他の具体的な例には以下があります。

SoftFail： この例では、指定されたIPアドレスからのメールを許可しますが、潜在的に不審なものとしてマークします。

v=spf1 ip4:192.0.2.0/24 ~all

HardFail： このSPFレコード例では、指定されたIPアドレスからのメールのみを許可し、他のすべてのメールを拒否します。

v=spf1 ip4:192.0.2.0/24 -all

リダイレクトメカニズム： この例では、別のドメインのSPFレコードにリダイレクトします。

v=spf1 redirect=_spf.example.com

上記のSPFレコードの各コンポーネントを分解すると、最初のコンポーネントである「v=spf1」は、SPFエントリのバージョンを示しています。バージョンは、今のところ常にSPF1となり、受信者のメールサーバーがSPF情報を提供するTXTレコードを識別するための方法を提供します。

「ip4」と「ip6」の項目は、許可されたメールサーバーのIPv4アドレスとIPv6アドレスです。複数のIPアドレスを記載する場合は、各IPアドレスをスペースで区切り、ip4 または ip6 というプレフィックスとコロンを使用します。例えば、以下のSPFレコードは、2つのIPv4アドレスを認可されたサーバーとして定義しています。

v=spf1 ip4:48.213.51.127 ip4:31.217.43.153 ip6:2a05:d018:e3:8c00:bb71:dea8:8b83:851e include:authorized-domain.com -all

「include」ディレクティブは、定義されたサードパーティードメインがあなたの組織に代わってメールを送信できることを示します。例えば、サードパーティプロバイダーを使用してバルクマーケティングメールを送信するとします。このサードパーティメールプロバイダーをSPFレコードに含めることで、受信者のメールサーバーがメッセージを拒否したり、迷惑メールフォルダに入れたりすることがなくなります。

最後に、「-all」ディレクティブは重要で、送信者が認可されたIPアドレスを使用していない場合に使用するポリシーを、受信者サーバーに指示します。「-all」ディレクティブは、受信者サーバーにフラグを「fail」に設定するよう指示します。他に2つのオプションがあります。「-all」ディレクティブは「soft fail」となり、受信者の受信箱に届きますが、悪意のあるメッセージである可能性があるという警告が残されます。「+all」ディレクティブは、あらゆるセキュリティ制限を無視して、受信者サーバーにメッセージを「pass」に設定するよう指示します。後者の設定は、安全でないポリシーとみなされるため、避ける必要があります。

SPFレコードの作成方法は、DNSホストによって異なります。ドメイン登録業者のDNSサーバーを使用している場合、通常、登録業者はDNSエントリを追加および削除できるダッシュボードを提供しています。このダッシュボードでSPFレコードを追加します。

SPFレコードを作成する手順は、以下の通りです。

1. メールの送信に使用されるIPアドレスを収集する: ドメインからメールを送信するために使用するすべてのメールサーバーとそのIPアドレスのリストを作成します。
2. SPFレコードを作成する: 収集したIPアドレスを使用して、どのサーバーがあなたのドメインに代わってメールを送信する権限があるかを指定します。SPFレコードは、この情報を含むDNS TXTレコードです。
3. SPFレコードをDNSに公開する: SPFレコードを作成したら、それをDNSに公開する必要があります。これには、DNS TXTレコードをドメインプロバイダーに追加することが含まれます。
4. SPFレコードをテストする: SPFレコードを公開した後、正しく設定されていることを確認するためにテストします。これは、オンラインで利用可能なSPFレコードテストツールを使用して行うことができます。

SPFレコードの作成を簡素化するには、SPFレコードジェネレーターが利用できます。

メールプロバイダーから受信者にメッセージを送信することで、新しい変更点をテストすることができます。例えば、Google Suiteを使用していて、ドメインのSPFレコードを追加した場合、ビジネスアカウントから個人アカウントにメッセージを送信してテストすることができます。SPFルックアップの結果を判断するには、メールヘッダーを確認する必要があります。

例えば、Gmailのヘッダーは、返信アイコンの横にあるその他のアイコンをクリックし、「メッセージのソースを表示」メニューオプションをクリックすることで表示できます。ヘッダーウィンドウが開き、ヘッダーの上部にSPFルックアップの結果が表示されます。次の画像は、Gmailの例です。

SPFレコードがパスしているため、このメッセージはGmailで正当なメールとみなされ、受信者の受信トレイに届いたことに注目してください。SPFに失敗したレコードは、迷惑メールフォルダから探すことができ、Gmailが警告メッセージでラベル付けしていることに気づくでしょう。

フィッシング攻撃が脅威アクターにとって主要な手段であり続けるため、SPFレコードやその他のメールセキュリティは、悪意のあるメッセージを受信した際にユーザーに警告を発するのに役立ちます。SPFレコードを使用すると、攻撃者はあなたのドメインを利用して、狙った被害者に対してフィッシングキャンペーンを仕掛けることができなくなります。これにより、あなたのビジネスの評判と、ユーザーが被害者になることを防ぐことができます。

多くの企業は、従業員や消費者を対象とした電子メール詐欺のトレーニングに投資しています。しかし、このような投資にもかかわらず、BEC（Business Email Compromise）: 信頼できる企業のIDになりすまし、従業員を騙す、高度な標的型かつ少量の攻撃やクレデンシャルフィッシング詐欺に騙される人が後を絶ちません。そして、これらの攻撃は効果的です。ベライゾンによると、フィッシングメールの30%は標的となったユーザーが開封し、そのうちの12%は悪意のある添付ファイルをクリックしています。

なりすましメールに対する防御は、人ではなく、メール認証が常に第一線であるべきです。SPFは、受信箱に届く前に悪質なメッセージを識別してブロックすることで、標的となる受信者の当て推量を排除します。しかし、SPFだけでは、従業員や顧客を狙ったフィッシングメールをブロックするには十分ではありません。それにはいくつかの大きな課題があります。

• 精度: あなたのブランドに代わってメールを送信するベンダーは、頻繁に変更され、数も増えます。 これらの変更をリアルタイムで把握できなければ、 SPFレコードは古くなってしまいます。
• 耐性: SPFは、メールプロバイダーが配信の判断に使用する多数のシグナルのひとつです。 SPFが失敗したとしても、メールがブロックされることを保証するわけではありません。
• 免責: メールが転送されると、SPFレコードは壊れてしまいます。
• 保護: SPFは、ユーザーがメールクライアントに表示される「ヘッダーfrom」アドレスを詐称から保護するものではありません。サイバー犯罪者は「エンベロープfrom」アドレスに所持しているドメインを含めることでSPFを通過することができ、目に見えるFromアドレスに正規のブランドのドメインを偽装することができます。

幸いにも、他のメール認証技術でこういった欠点を補うことができます。

SPFはメール認証において重要なツールですが、その制限を理解することも同様に重要です。

• DNSルックアップの制限: SPF仕様では、SPFレコードを完全に解決するためのDNSルックアップ回数を10回に制限しています。この制限はサービス拒否（DoS）攻撃を防ぐためのものですが、includeモディファイアを無分別に使用するユーザーに問題を引き起こす可能性もあります。
• 文字数の制限: SPFレコードには、単一の文字列に255文字の制限があります。これはDNS TXTレコードの固有の制限です。
• 不完全な解決策: SPFは完全なエンドツーエンドの暗号化を提供せず、類似ドメインを使用するフィッシング攻撃からも保護しません。そのため、SPFはより包括的なメール認証ソリューションの一部に過ぎません。
• SPFレコードの維持が困難: SPFレコードの維持は、特に複雑なメールインフラを持つ組織にとって困難な場合があります。組織がより多くのメールサーバーやサードパーティのメールサービスを追加すると、SPFレコードを最新の状態に保つことが難しくなる可能性があります。
• 不適切なメール転送によるSPF認証の破壊の可能性: 不適切なメール転送はSPF認証を破壊する可能性があります。メールがSPFレコードで許可されていないサーバーを通じて転送された場合、そのメールはSPF認証に失敗する可能性があります。
• 大規模組織では複数のSPFレコードが必要な場合がある: 複数のドメインを持つ大規模組織では、複数のSPFレコードが必要となり、管理が困難になる場合があります。

これらの制限にもかかわらず、SPFは依然としてメールスプーフィングやフィッシング攻撃を防ぐのに役立つ不可欠なセキュリティプロトコルです。

まず始めに、ProofpointのDMARC作成ツールを試してみてください。これは組織がドメインのDMARCレコードを作成するのを支援する無料のオンラインツールです。このツールでは、ドメインのDMARCレコードとSPFレコードも確認できます。

このツールはProofpointのEmail Fraud Defense（メール詐欺防御）の一部で、SPFとDMARCをサポートする包括的なメールセキュリティソリューションです。メールスプーフィングやフィッシングなどのソーシャルエンジニアリング攻撃から保護します。ドメインのDMARCとSPFレコードを確認して、正当な送信者を特定し、適切に認証されていることを確認するプロセスを合理化しています。

Email Fraud Defenseは、誰があなたのドメインに代わってメールを送信しているかを可視化し、正当な送信者を承認し、未承認のメッセージをブロックすることができます。直感的なレポーティングポータルを通じてアクティビティを確認し、Proofpointのコンサルタントとの定期的な会議を活用して、メールセキュリティ態勢を強化できます。