Eメールはビジネスにとって必要不可欠なツールであり、私たちの多くはコミュニケーションのために日々Eメールに依存している。しかし、メールユーザーの増加に伴い、スパム、なりすましメール、フィッシング、ホエーリング、メール詐欺などの問題も発生しています。この種の攻撃は、評判の失墜、経済的損失、データ漏洩など、重大な被害をもたらす可能性があります。このような攻撃を防ぐために、企業は電子メールシステムの安全性を確保するための積極的な対策を講じる必要があります。その方法のひとつが、SPFの設定です。
Yahoo MailやGoogle Workspaceのような主要な電子メールプロバイダーは、潜在的な詐欺から電子メール受信者を保護するために、Sender Policy Framework(SPF)、DomainKeys Identified Mail(DKIM)、Domain-based Message Authentication, Reporting, and Conformance(DMARC)のような電子メール認証プロトコルを推奨しています。
主なポイント
- SPFのような電子メール認証プロトコルは、電子メールのなりすまし、フィッシング、詐欺を防止するために不可欠なツールです。
- 有効なSPFレコードを設定するには、ドメインごとに1つのDNS TXTレコードを使用して、許可されたすべてのメールサーバー(サードパーティを含む)を指定します。
- SPFレコードを定期的に更新し、10回のDNSルックアップ制限を守ること(「ptr」のような推奨されないメカニズムを避けること)は、メンテナンスと配信のために非常に重要です。
- SPFレコードをテストすることで、正しい設定と機能を確認することができます。
- SPFは基本的な保護を提供しますが、包括的なメールセキュリティとコンプライアンスのためにDKIMおよびDMARCと最もよく機能します。
メールセキュリティにおけるSPF - 説明
SPFとは?? SPFSender Policy Frameworkの略。メール認証プロトコルの1つで、ドメインへのメール送信を許可するサーバーを指定できます。SPFは、ドメインのDNSゾーンファイルにDNS TXTレコードを追加することで機能します。このDNS TXTレコードには、特定のドメイン名からのメール送信が許可されているIPアドレスまたはホスト名が記載されています。このレコードは、メールの真正性を確認するために受信メールサーバーによって検索されます。このレコードは、許可されたIPアドレスから送信されていないドメインからのメールは、指定されたポリシーに従って処理されるべきであることを他のメールサーバーに伝えます(例えば、拒否または疑わしいとマーク)。
有効なSPFレコードを設定することは、無許可のユーザーがお客様のドメイン名を使用してメールを送信することを防ぐために不可欠です。例えば、スパマーや攻撃者は、あなたのドメイン名を使用してスパムやフィッシングメールを送信する可能性があります。 フィッシングメールその結果、ブランドの評判が落ちたり、正規のメールがブロックされたり、他のサーバーで拒否されたり、顧客や従業員のセキュリティが脅かされたりする可能性があります。
PowerDMARCでSPFセットアップを簡素化!
SPFコンポーネント
SPFレコードの主な構成要素 DNSのSPFレコードの主な構成要素は以下のとおりである:
- バージョン(v=spf1):
SPFのバージョンを指定します。 v=spf1. - IP4とIP6(IP4/ ip6:):
ドメインに対してメール送信が許可されているIPv4アドレスとIPv6アドレスを一覧表示します。 - AとMXのメカニズム (a: / mx:):
- a:は、IPがドメインのAレコードに一致するサーバーからのメールを許可します(特定のホスト名を指定した場合は、`a:mail.example.com`など)。
- mx:は、ドメインのMX(Mail Exchange)レコードにリストされているサーバーからのメールを許可します。これは特定のメールサーバーのホスト名ではなく、ドメイン(`mx:example.com`)を指定する必要があります。
- インクルード・メカニズム(include:):
他のドメインのSPFレコードが送信者を承認することを許可します。サードパーティ・サービスがあなたのドメインに代わってメールを送信する場合に便利です。includeステートメントの正しいドメイン値を確認するには、サードパーティの組織に問い合わせてください。 - PTRメカニズム(ptr:):
DNSの逆引きを実行する。しかし、RFC7208では、信頼性の問題や性能負荷の問題から、'ptr'メカニズムの使用を推奨していない。一般的には、代わりに 'a'、'mx'、'ip4'/'ip6' メカニズムを使用することが推奨されている。 - すべてのメカニズム (何れも):
以前のメカニズムでマッチしなかった送信者のためのデフォルトルールを設定する。このルールは常にSPFレコードの末尾に置く。オプションは以下の通り:- -すべて:ハードフェール(非認証IPを拒否)。エンフォースメントに推奨。
- ~(すべて):ソフトフェール(許可されていないIPを疑わしいものとしてマークする)。初期設定やテスト時によく使われる。
- ?:中立(非認証IPに対して特定のアクションを取らない)。ほとんど保護されない。
- +すべて:パス (すべてのIPを許可する。SPFの目的を否定するため、強く推奨されない)。
- リダイレクト(リダイレクト):
現在のレコードでメカニズムを定義する代わりに、別のドメインのSPFレコードのポリシーを使いたい場合に、そのレコードを指す。all' メカニズムの必要性に取って代わる。 - 修飾子:
あまり一般的ではないが、`exp=`のような失敗時の説明のための、微調整のためのオプションルール。
SPFの例
v=spf1 ip4:192.168.1.1 include:_spf.thirdparty.com -all
この例では 192.168.1.1からのメールを許可し、サードパーティのSPFレコードを含んでいます。 -すべて.
SPF設定をマスターする
SPFセットアップとは、ドメイン所有者のDNSにおけるSPFメール認証プロトコルの設定を指します。SPF設定により、正当な送信元を認証し、受信サーバーが本物のメール送信者と正当なドメイン名になりすましているだけの送信者を簡単に区別できるようにします。これは、電子メールベースのサイバー攻撃から保護するために、電子メールの検証において必要なステップです。
SPFレコードの設定と追加方法
SPFの設定は、アクティブなソースに対してだけでなく、悪意のある使用に対して安全であることを保証するために、非送信ドメインや「パーク」ドメインを含む、所有するすべてのドメインに対しても不可欠です。SPFレコードの設定は簡単で、以下の手順で行います:
ステップ1:メールサーバーと送信元の決定
最初のステップは、ドメインのメール送信を許可されているすべてのサーバーとサービスの包括的なリストを作成することです。これらの送信元には、自社のメールサーバー(Microsoft ExchangeやGmailのようなウェブベースなど)、マーケティングやトランザクションメールに使用しているサードパーティのメールサービスプロバイダ(ESP)、決済代行業者、Eコマースプラットフォーム、CRM、ヘルプデスク、サポート/チケットシステムなど、お客様に代わってメールを送信するその他のサービスを含めることができます。
ステップ2:SPFレコードの作成
許可された送信元をすべて特定したら、以下のSPFレコード作成ツールを使ってSPFレコードを作成できます。 SPFレコード生成ツールを使用するか、手動で構文を作成します。SPFレコードは、ドメインのDNS設定にあるTXT(テキスト)レコードです。ドメインごとにSPFレコードを1つだけ作成するようにしてください。簡単な構文は次のようになります:
v=spf1 ip4:<IP address> include:<third-party domain> -all
In this example, “v=spf1” indicates the SPF version, “ip4:<IP address>” lists an authorized IP, “include:<third-party domain>” incorporates a third-party sender’s policy, and “-all” at the end indicates that emails from sources not listed should be rejected. Double-check for typos, as even small errors like ‘inlcude’ instead of ‘include’ can invalidate the record.
ステップ3:SPFレコードを公開する
SPFレコードを作成したら、ドメインのDNSに公開する必要があります。ドメイン管理者は、必要なDNSの更新を簡単に行うことができます。DNSプロバイダーのウェブサイトにログインし、SPFレコードの内容を含む新しいTXTレコードを追加することでこれを行うことができます。実際のコンテンツは`v=spf1`で始まり、DNSエントリ自体は二重引用符で囲むべきではありません(DNSインターフェースによっては引用符付きで表示される場合もあります)。また、ITチームやホスティングプロバイダーに依頼することもできます。DNSの変更は、インターネット全体に伝播するのに時間がかかることがある(最大72時間ですが、もっと早いこともよくあります)ことを覚えておいてください。
ステップ4:SPFレコードのテスト
SPFレコードを公開し、伝播のための時間を確保したら、それが正しく動作し、DNSルックアップの制限である10回を超えないことを確認するためにテストすることが重要です(`include`、`a`、`mx`、`ptr`、`exists`、`redirect`などのメカニズムは、ネストされた`include`ステートメント内のルックアップを含め、この制限にカウントされます)。オンラインSPFレコードチェッカーPowerDMARC や MXToolbox が提供しているようなオンライン SPF レコードチェッカーを使用して、SPF レコードをテストすることができます。これらのツールは、あなたのSPFレコードが有効かどうか、正しくフォーマットされているかどうか、ルックアップ制限内かどうか、意図したとおりに機能しているかどうかを教えてくれます。
SPFレコードに関する5つの誤解
SPFレコードに関する俗説がインターネット上で流布している。ひとつひとつ潰していこう:
1.SPFだけでもなりすましは防げる
これは真実ではない。SPFを設定するだけでは、すべてのタイプのなりすましやなりすましを防ぐことはできない。より強力な保護を提供し、失敗した場合の対処方法を受信者に指示するためには、SPFをDKIMやDMARC(Domain-based Message Authentication, Reporting, and Conformance)と組み合わせる必要がある。DMARCでは、ドメイン所有者がSPFやDKIMのチェックに失敗したメールに対するポリシー(拒否や隔離など)を指定できる。
2.SPFレコードに+allを使用できます。
allを使用すると、インターネット上のどのサーバーでも、あなたのドメインに代わってメールを送信できるようになります。これは、SPFプロトコルが提供するセキュリティの目的を完全に否定するものです。代わりに、~all(ソフト・フェール)か、できれば-all(ハード・フェール)が、SPFを効果的に導入するためにレコードの最後に使用する推奨メカニズムです。
3.SPFは転送された電子メールに対して機能する
私たちは皆、そうであってほしいと願っている。残念ながら、多くのメール転送のシナリオでは、SPFが壊れてしまいます。これは、転送サーバーのIPアドレスが元の送信者のSPFレコードに記載されている認証済みIPと一致しないことが多く、ヘッダー情報が変更される可能性があるために起こります。このような場合、DKIM(通常は転送に耐える)や、できればARC(Authenticated Received Chain)のようなプロトコルが、転送ホップをまたいで認証結果を維持するのに役立つ。
4.SPFレコードのDNS検索回数は無制限
SPFの仕様(RFC)では、1回のSPFチェックにつき、DNSルックアップの上限を 10回としている。include`、`a`、`mx`、`ptr`、`exists`、`redirect` などのメカニズムが DNS 検索を行う。この制限を超えるとSPF PermError(Permanent Error) となり、正当なメールが認証に失敗する原因となります。レコードを簡潔に保ち、特にサードパーティの送信者を多く使用している場合は、フラット化や動的SPFマクロのようなSPF最適化メソッドを使用して制限内に収まるようにすることが重要です。
5.SPFは "セットアップして忘れる "ことができる。
このようなSPFのミスを犯さないようにしましょう!新しいサードパーティサービスを追加したり、ESPを変更したり、古いサーバーを廃止したりと、メール送信インフラは時間とともに変化します。これらの変更を反映させるために、SPFレコードを定期的に更新する必要があります。更新を怠ると、新しい正当な送信元が承認されない可能性があり、受信サーバーでメールがブロックされたり、スパムとしてマークされたりする可能性があります。
SPFレコードの仕組み
- ドメイン所有者はSPFレコード(DNSのTXTレコード)を手動またはオンラインツールを使って作成し、ドメインに代わってメールを送信することが許可されている送信元(IPアドレス、インクルード経由のドメインなど)を指定します。
- 電子メールを受信すると、受信側のメールサーバーは、電子メールのReturn-Path(envelope senderまたはMail Fromとも呼ばれる)アドレスからドメインを抽出する。
- 受信サーバーはDNSクエリを実行し、その送信者ドメインのSPF TXTレコードを検索する。
- 受信サーバーは、メールを送信した接続サーバーのIPアドレスが、SPFレコードに記載されている認可されたソースのいずれかと一致するかどうかをチェックする。
- 一致した場合(Pass)、メールはSPFチェックを通過します。一致しない場合、結果はレコードで定義された「all」メカニズムに依存します(例:-allはFail、~allはSoftFail、?allはNeutral)。この結果は、特にDMARCと組み合わせた場合、メールが受信トレイに入るか、スパムフォルダに入るか、拒否されるかに影響します。
正確なSPF設定のためのヒント
以下は、強力で効果的なSPFレコードを作成するためのヒントです:
- 許可された送信元をすべて含める:ドメインのメール送信を許可されているすべてのサーバーとサードパーティ・サービスを詳細にリストアップしてください。送信元が欠落していると、正当なメールの配信に問題が生じる可能性があります。
- すべてのドメインにSPFを適用する:v=spf1 -all`のようなSPFレコードを公開することで、非送信ドメイン(パークドメイン)も保護し、そのドメインからメールが送信されないように明示します。
- 正しい'all'メカニズムを使用する:最初のテスト段階や移行段階では `~all` (SoftFail) を使用する。一旦確信が持てたら、`-all` (Fail)を使ってより厳格に実施し、未承認のメールを拒否するように受信サーバーに明確に伝えます。all` (Neutral)は避け、`+all` (Pass)は使用しないこと。
- all' を正しく配置する:all` メカニズムは、SPFレコード文字列の一番最後のコンポーネントであるべきです。
- include」メカニズムを正しく使うこと:include」メカニズムは、サードパーティの送信者を認証するために不可欠です。サードパーティが提供するSPFポリシーの正しいドメインを使用していることを確認してください。
- mx' と 'a' メカニズムを注意深く使用すること:mx` を使用して、ドメインの MX レコード (`mx:yourdomain.com`) にリストされているサーバを認証する。ドメインのAレコード(`a`)または特定のホスト名(`a:mail.yourdomain.com`)に関連付けられたIPアドレスを認証するには `a` を使用する。特定のメールサーバーホスト名で `mx` を使用しないでください。
- 推奨されないメカニズムは避けること:ptr`メカニズムは非推奨で信頼性が低いので使わないこと。
- DNSルックアップの上限を10回に抑える:DNSルックアップを必要とするメカニズム(`include`、`a`、`mx`、`exists`、`redirect`)に注意すること。ネストされたルックアップもカウントされる。制限を超えると PermError になる。
- タイプミスのチェックSPFレコードを公開する前に、構文エラーやタイプミスがないか注意深く確認してください。
- DNSで正しくパブリッシュする:レコードがTXTタイプとして公開され、実際のDNSデータフィールドでコンテンツが引用符で囲まれずに`v=spf1`で始まっていることを確認してください。
- SPFレコードを常に最新の状態に保つ:お客様のメールインフラや第三者送信者リストに変更があった場合は、SPFレコードを速やかに更新し、変更を反映させるようにしてください。定期的にレコードを見直し、維持しましょう。
PowerDMARCでSPF設定を最適化するメリット
DNSルックアップの制限は、SPF標準によって課された重要な制限である。これは、受信サーバーがメールのSPFレコードを検証する際に実行できるDNSルックアップの回数を制限するものです。この制限は10 DNSルックアップに設定されています。もしSPFレコードを評価する際に10回以上のルックアップ(`include`メカニズムによるネストされたルックアップを含む)が必要な場合、SPF PermErrorとなり、正当なメールが認証に失敗し、配信上の問題に直面する可能性があります。
SPFフラット化は、メールのSPFレコードを検証するために必要なDNSルックアップの回数を減らすために使用されるテクニックです。これは、`include`のようなメカニズムを、これらのルックアップから解決された実際のIPアドレスに置き換え、メインのSPFレコードに直接統合することで機能します。これにより、メールを認証するために必要な DNS クエリの回数を大幅に減らすことができます。PowerDMARCは、複雑なSPFレコードを管理し、制限値を維持するために、自動SPFフラット化またはダイナミックマクロベースのソリューションを提供します。
SPFフラット化がどのように役立つかの一例である:
あなたの会社では、いくつかのサードパーティサービスを利用してメールを送信しているとします。これには、マーケティングオートメーションソフトウェア(例:`include:spf.marketing.com`)、ヘルプデスクシステム(例:`include:spf.support.com`)、中小企業向けCRMツールが含まれます。中小企業向けCRMツール(include:spf.crm.com`)がある。これらの `include` ステートメントにはそれぞれ DNS ルックアップが必要であり、インクルードされたレコード自体にもルックアップが含まれる可能性があります。合計数が10を超えると、SPFレコードは壊れてしまいます。
SPFフラット化(またはマクロソリューション)を使用することで、これらのサードパーティインクルードによって認可されたIPアドレスをより効率的に解決し、表現することができます。これにより、メールサーバーがSPFレコードを検証するためにDNSルックアップを実行する際、PermErrorのしきい値にヒットすることなく、正常に評価を完了することができます。
要約すると
SPFの設定は、メールシステムを保護し、メール詐欺を防止するための重要なステップです。正確なSPFレコードを作成し、ドメインのDNS設定で正しく公開し、長期間維持することで、ドメインから送信される正当なメールが認証され、不正ユーザーによるドメイン名の悪用を防ぐことができます。上記のベストプラクティスとヒントに従うことで、強力なSPFレコードを作成し、特にDKIMやDMARCと併用することで、全体的なメールセキュリティ体制を強化することができます。
SPFレコードの設定に関するFAQ
1つのドメインに複数のSPFレコードを持つことはできますか?
いいえ。1つのドメインに1つのSPFレコードが必要です。同じドメインに複数のSPFレコードを発行するのはよくある間違いで、SPFの検証に失敗したり、予測できない結果(多くの場合NoneやPermError)を返したりします。複数の送信元を認証する必要がある場合は、1つのSPF TXTレコード文字列内にすべて含める必要があります。
大きなSPFレコードを分割できますか?
論理的に大きなSPFポリシーを同じドメインの複数のTXTレコードに分割することは、1レコードルールのために許されない。さらに、個々のDNS TXTレコードには文字列制限があります(ただし、最近のDNSシステムでは、古い255文字の制限を克服するために、1つのレコード内で複数の文字列をサポートすることがよくあります)。レコードが複雑になりすぎたり、10個のDNSルックアップ制限を超えたりした場合、単純に分割することはできません。代わりに、以下の方法を試してみてください:
- 記録を簡素化する:冗長なエントリや不要なエントリを削除する。可能であれば、CIDR表記を使用してIPレンジを統合する。
- ルックアップ生成メカニズムを最小限にする:include`、`a`、`mx`、`exists`、`redirect` メカニズムの数を減らす。
- SPF管理ソリューションを使用する:複雑なレコードを管理し、制限内に収めるために、SPFフラット化や動的SPF(マクロベース)ソリューションを提供するサードパーティ・サービスを利用する。
SPFレコードはなぜ使われるのか?
SPFレコードは、ドメイン所有者が自分のドメインに代わってメールを送信する権限を持つメールサーバーを公的に宣言することで、メールのなりすましを防ぐために使用されます。受信サーバーはこのレコードをチェックして送信サーバーの正当性を確認し、ドメイン名を使って送信されたフィッシングやスパムなどの詐欺メールが受信者の受信箱に届く可能性を減らします。
SPFはいつ必要?
SPFは、所有するドメイン、特にメール送信に使用するドメインに必要です。SPFは、メール配信品質の向上、ブランド評価の保護、真正性の確認、受信サーバーのポリシーや業界のベストプラクティス(GoogleやYahooなどの大手プロバイダーからの最近の義務付けを含む)への準拠のために必要な、基本的なメール認証プロトコルです。SPF設定の重要性 SPF設定の重要性.メールを送信しないドメインでも、悪用を防ぐために制限付きのSPFレコード(例:`v=spf1 -all`)を設定する必要があります。
SPFレコードを最適化するには?
許可された送信者を慎重に確認して統合し、使用されていない送信元を削除し、効率的なIP範囲表記(CIDR)を使用し、DNSルックアップを引き起こすメカニズムを最小限に抑えることで、SPFレコードを手動で最適化することができます。しかし、複雑なシナリオや10ルックアップの制限を確実に守るためには、自動フラット化や動的SPFマクロソリューションを提供するサードパーティのSPF最適化サービスを利用し、継続的なレコード管理を行う方が手間がかかりません。
SPFレコードが正しく設定されていることを確認するには?
SPFレコードは、オンラインの SPFレコード検索ツール.これらのツールは、構文を検証し、レコードがDNSに存在するかどうかをチェックし、10 DNSルックアップ制限内にあるかどうかを確認し、それが一般的に正しく設定されているかどうかを確認します。
- ベンダーメール詐欺(VEC):信頼できるベンダーからの攻撃を阻止する方法- 2025年7月3日
- 顧客の受信箱に届かないマーケティング・メール- 2025年7月2日
- DMARC MSP ケーススタディ:S-ITがPowerDMARCで電子メール認証管理を自動化した方法- 2025年6月29日