SPF構文：メール設定のためのSPFレコードを理解する

メールについて考えるとき、メッセージがスムーズに流れ続けるのを支える舞台裏の働きは見落とされがちです。しかし、精密に調整された機械と同じように、メールシステムは混乱を防ぐために特定のルールに依存しており、とりわけスパムやフィッシング攻撃といった厄介な脅威に対してはなおさらです。こうした不可欠なルールの一つが Sender Policy Framework（SPF）であり、送信者が本当に名乗っているとおりの相手なのかを検証するのに役立ちます。

「SPF構文は一見すると単純に見えます」と、DuoCircle の CTO であるアダム・ランドリガン（Adam Lundrigan）は述べています。「v=spf1 に続いてメカニズムと修飾子が並ぶ形は分かりやすそうに見えますが、その評価のセマンティクスは驚くほど複雑です。メカニズムの順序が重要で、最初に一致したものが優先され、~all と -all の違いは配信に実際の影響を及ぼします。私たちは毎週のように、配置を誤ったメカニズムが意図したポリシーを静かに上書きしてしまっているレコードを目にします。」

RFC 7208 に従い、SPF の評価は1回のチェックあたり DNS メカニズムのルックアップ10回、およびボイドルックアップ2回に制限されています。いずれかの上限を超えると PermError が発生し、そのドメインから送信されるすべてのメッセージで認証が失敗します。

SPFレコードを理解することは、メールのセキュリティを高めるだけでなく、メッセージが迷惑メールとして分類されるのではなく受信トレイに届く可能性も高めます。この記事では SPF構文 を分かりやすく解説しますので、その仕組みを把握し、より安全なメール送信のために自信を持ってご自身のレコードを設定できるようになります。

SPFレコードを作成する構文は「v=spf1」で始まり、続いて「a」「mx」「ip4」「include」など、許可された送信サーバーを指定するメカニズムが並び、最後に「~all」や「-all」といった修飾子でポリシーの厳格さの度合いを決定します。たとえば、基本的なSPFレコードは「v=spf1 mx include:example.com -all」のようになり、これはそのドメインのMXサーバーと、example.com のSPFレコードに記載されたサーバーのみが、そのドメインに代わってメールを送信することを許可します。

SPF構文とは何か

その中核において、SPF構文はただ一つの目的を果たします。それは、特定のドメインに代わってメールを送信することを正当に許可されているメールサーバーを特定することです。これは極めて重要です。というのも、フィッシング攻撃の増加により、メール認証はデジタルセキュリティの不可欠な側面となっているからです。SPF構文の各構成要素を理解することは、この検証プロセスがどのように機能するかを把握するのに役立ち、効果的な設定を可能にします。ミスを避けるために、SPFレコードの形式に慣れておきましょう。

SPF構文の構成要素

SPF構文を構成する3つの主要な要素、すなわちメカニズム、修飾子、モディファイアを見ていきましょう。これらはいずれも、メールが検証される仕組みにおいて重要な役割を果たします。当社の SPF用語集 では、これらの各構成要素を定義しています。

まず、メカニズムがあります。これらは、送信サーバーのIPアドレスがドメインのレコードとどのように一致するかを決定する、中核的な構成要素です。たとえば、a のようなメカニズムはAレコード（IPアドレスを指し示すもの）に対応し、一方 mx はドメインのメール処理のために設定されたメール交換（mail exchange）サーバーを指します。これらのメカニズムを正確に使うことは、誰があなたのドメインからメールを送信できるかを定義するのに役立ち、許可されていない送信者からの保護につながります。

次に、修飾子について触れます。修飾子は、メカニズムの結果を示す指標だと考えてください。たとえば、あるメカニズムが合格すると、通常は + が表示され、正当性を示します。これに対し、- はきっぱりとした失敗を示し、送信者が許可されていないことを意味します。また、ソフトフェイルを表す ~ 修飾子もあります。これは、送信サーバーを疑わしいものとして扱うべきだが、必ずしも完全にはブロックしなくてよいことを示唆します。最後に、? は中立を示し、許可について確定的な判断ができなかったことを意味します。

最後の構成要素はモディファイアとして知られています。モディファイアは、SPFレコード自体に含まれる追加のルールや情報を提供します。よく使われるモディファイアには、失敗時の説明テキストを指定できる exp= と、チェックを別のドメインのSPFレコードへ送り込むことができる redirect= の2つがあります。この繊細な柔軟性は、SPFレコードを過度に複雑にすることなく特定のニーズを満たすうえで、計り知れない価値を持ち得ます。

SPF構文のこれらの基礎的な要素を見てきましたので、次は各構成要素の適用とその重要性を実際のシナリオで示す例を見て、実践的な使い方をより深く理解しましょう。

SPFレコードの例

たとえば、v=spf1 a -all のような単純なSPFレコードを考えてみましょう。ここでは、AレコードのIPアドレスから直接送信されたメールのみが有効であり、その他はすべて即座に拒否されることを示しています。これは、送信されたメッセージを評価する際に、メールサーバーに明確なメッセージを送ります。

もう少し複雑な、v=spf1 a mx include:_spf.google.com ~all のように複数のメカニズムを持つ例に進みましょう。このシナリオでは、AレコードとMXサーバーの両方からのメールを許可しつつ、Google のSPFレコードに記載された任意のサーバーも許可しています。末尾のチルダは、その他の身元不明の送信元に対するソフトフェイルとして機能します。

これらの例を理解することは、適切なSPF構文の設定を通じて、どれほど柔軟かつ明確にメールの許可を確立できるかについての理解を深めてくれます。

この基礎を築いたところで、いよいよ効率的な自前の SPFレコード を作成するための実践的な手順へと移りましょう。

SPFレコードの作成方法

SPFレコードの作成は最初は気後れするように感じられるかもしれませんが、手順ごとに分解していけば扱いやすくなります。あるいは、SPFレコードを自動生成することもできます。ゲームのルールを定めることに例えて考えてみてください。正しいプレイヤー、つまり許可されたメールサーバーだけが、あなたに代わってメッセージを送信することに関わるようにするには、明確なガイドラインが必要です。

ステップI：許可するメールサーバーを特定する

最初のタスクは単純です。あなたのドメインに代わってメールを送信するすべてのメールサーバーを特定することです。これには、ウェブホスティングプロバイダーだけでなく、Google Workspace や Mailgun のように利用しているかもしれないサードパーティのサービスも含まれます。これらの主体を洗い出すことで、どのサーバーに許可が必要かを判断できます。それはパーティーの招待客リストを作成するようなもので、リストに載っている人だけが入場できるのです。

このプロセスを思い描いてみてください。あなたのビジネスのメールを処理するすべてのプロバイダーとサービスを書き出します。顧客関係管理からのトランザクションメールであれ、一括送信ツールを通じて発送されるマーケティングメッセージであれ、円滑な配信を確保しバウンスを避けるためには、あらゆるサービスを漏れなく把握しておく必要があります。

ステップII：SPFレコードを構築する

リストが手元にそろったら、SPFレコードを構築する番です。当社の SPFレコードの作り方 に関するガイドでは、各メカニズムを網羅しています。これは、複数の「メカニズム」と「修飾子」を組み合わせて構成されます。簡単に言えば、メカニズムは受信者のメールサーバーに対して、許可された送信元をどこで探せばよいかを伝えます。修飾子は、違反に対してどれほど厳格に、あるいは寛容に対応したいかを指定します。

たとえば、サンプルのレコードは v=spf1 mx include:_spf.google.com include:mailgun.org ~all のようになります。ここでは、mx があなたのメール交換（mail exchange）サーバーを許可し、include:_spf.google.com が Google のSPFレコードに指定された任意のIPアドレスを許可します。

この行を構築する際には、次の点を思い出してください。

• バージョンを示すために v=spf1 で始めます。

• a、mx、ip4 のように、サービスごとに1つのメカニズムを追加します。

• 「all」メカニズムで締めくくり、許可されていない送信に対してどれほど厳格にしたいか、つまり通過させるのか、ソフトフェイルにするのか、失敗させるのか、中立のままにするのかを示します。

この構造化されたアプローチにより、許可されたサーバーのみがあなたのドメインを代表してメールを送信できるようになり、同時になりすましを効果的に防ぎます。

ステップIII：SPFレコードをDNSに公開する

作成できたら、次のステップは、あなたのドメインのDNS設定内にSPFレコードを公開することです。これには通常、ドメインレジストラのウェブサイトにログインし、DNS管理に移動して、新しいTXTレコードを追加する作業が含まれます。すべてのレジストラがセクションを一貫した名称で表示しているわけではない点に留意し、DNSレコードに関連するオプションを探してください。

DNS設定への追加に成功したら、変更が世界中に伝播するまで、多くの場合最大48時間ほどの時間を与えてください。それはイベントを告知するのに似ています。いったんみんなに共有したら、その情報を受け取って行動に移すまで、しばらく待つ必要があるのです。

SPFレコードを作成して公開した後は、各構成要素を理解しておくことが、それらが正しく連携して機能することを確実にするうえで不可欠です。それぞれの要素がどのように寄与しているかを把握しておくと、後々起こり得る設定の問題を防ぐのに役立ちます。

主要なSPFメカニズムとモディファイア

SPFメカニズムを理解することは、ゲームのルールを知るようなものです。いったんその仕組みが分かれば、より自信を持って効果的に実装できるようになります。各メカニズムは、あなたのドメインのためにメールを送信することを許可された特定のホストやIPアドレスを指定します。

メカニズム

a メカニズム

a メカニズムは、あなたのドメインのAレコードに記載されたIPアドレスが、そのドメインに代わってメールを送信することを許可します。信頼できる友人に許可を与えることに例えて考えてみてください。相手のアドレスが一致すれば、その人は入場できるのです。たとえば、v=spf1 a -all と書かれたSPFレコードは、そのAレコードに関連付けられたサーバーのみがメールを送信でき、その他はすべて即座に拒否されることを示します。

mx メカニズム

同様に、mx メカニズムは、あなたのドメインのMXレコードに記載されたメールサーバーが送信メールを処理することを許可することで機能します。これは、複数のサーバーがメールの役割を分担している多くの企業構成のように、メインのサーバー以外の複数のサーバーからメールが送信される場合に特に役立ちます。ここでの例としては v=spf1 mx -all があり、これはそのドメイン内で設定されたすべてのMXサーバーを有効な送信者として指定します。

include メカニズム

include メカニズムを使うと、別のドメインのSPFレコードを取り込むことができます。これは、Mailgun や Google Workspace のように、それらのサービスがあなたに代わって送信機能を管理するサービスを利用する際に特に便利です。ただし、この点についてはよく考えてください。他のドメインを取り込むことは管理を簡素化する一方で、取り込んだドメインに何らかの問題が生じた場合、SPFの構成を複雑にしかねません。v=spf1 include:_spf.example.com -all のようなものを検討しつつ、予期しない配信失敗を防ぐために、それら取り込んだレコードの健全性に目を配ってください。

モディファイア

redirect

redirect モディファイアは、追加のポリシーを定めた別のSPFレコードへのポインタとして機能します。これにより、複数のドメインにまたがるSPFポリシーを統合でき、多数のサブドメインを管理する組織に理想的です。例としては v=spf1 redirect=_spf.anotherdomain.com があり、これはこのドメインから送信されるあらゆるメールが、指定されたレコードで定義された規則に従うことを保証します。

exp

最後に、exp モディファイアがあります。これは、SPFの失敗について人間が読める形の説明を提供することで、明確さを高めることができます。つまり、あるメールがSPFチェックに合格しなかった場合、技術的な詳細に深入りすることなく、なぜ基準を満たさなかったのかについての手がかりを提供できるのです。たとえば、v=spf1 -all exp=_spf_error.example.com のような実装は、失敗したメッセージに関する説明について、受信者が別の情報源を参照すべきことを示します。

これらのメカニズムとモディファイアを理解することは、メール認証のフレームワークを効果的に確立するための基盤を築きます。次に、SPF設定をDNS環境に統合するための具体的な手順を見ていきます。

SPFをDNSに実装する手順

Sender Policy Framework（SPF）レコードを実装するための最初の手順は、DNS管理コンソールにアクセスすることです。これは通常、ドメインレジストラやウェブホスティング会社のインターフェースを通じて行えます。それは、メール通信を保護するためのツールが詰まった部屋の扉を開けるようなものです。ご利用のプロバイダーに応じてログインし、さまざまなメニューをたどって、DNS設定の適切なセクションを見つけてください。

DNS管理コンソールの場所を見つけたら、次の重要な段階、すなわち新しいTXTレコードの追加へと進む準備が整います。

2つ目の手順は、SPFポリシーを格納する新しいTXTレコードを作成することです。ここでは、「Add New Record」またはそれに類するラベルのオプションが見つかります。「Name」については、空欄のままにするか、ルートドメインを表す「@」を入力します。これは、そのレコードがサブドメインではなくメインのドメインに適用されることを意味し、あなたのドメインからメールが送信されたときに、メールサーバーがどこで許可を確認すればよいかを特定するのに役立ちます。

TXTレコードの設定ができたら、最も重要な側面の一つ、すなわちSPF構文を正しく入力することへと進みます。

この手順では、どのメールサーバーがあなたのドメインに代わってメールを送信することを許可されているかを定義する、丁寧に構築したSPFレコードを使用します。「Value」または「Data」フィールドに、この構文を正確に入力してください。たとえば、v=spf1 a mx include:_spf.google.com ~all です。この入力は、ほんの小さなタイプミスでも設定ミスにつながり、許可されていないサーバーがあなたに代わってメールを送信できてしまったり、正当なサーバーがブロックされてしまったりする可能性があるため、二重に確認してください。構文は特定の構造に従うことを覚えておいてください。すなわち、バージョン宣言（v=spf1）で始まり、続いて許可された送信サーバーを詳述するメカニズムと修飾子が並びます。

SPF構文を入力したら、レコードを保存し、変更がDNSサーバー全体で反映されるのを待つ番です。

最後の手順は伝播に焦点を当てています。新しく作成したTXTレコードを保存すると、世界中のDNSシステムがそのレコードを更新するまでに最大48時間かかることがあります。それは招待状を送ることに例えられます。いったん送り出したら、人々が返信するには時間が必要なのです。この期間中は、SPFレコードが正しく伝播したかどうかを確認するオンラインツールを利用できます。これらのツールは非常に便利で、すべてが所定の位置にあり、あるべき形で機能していることを確認することで、後々起こり得る頭痛の種からあなたを救ってくれます。

これらの手順を踏むことで、なりすまし攻撃から身を守るだけでなく、あなたのドメインから送信されるメールの全体的な到達性も向上します。

それでは、あなたの設定が円滑かつ安全に機能しているかを効果的に検証する方法を見ていきましょう。

SPF設定を検証する

SPF設定の検証は単なる形式的な手続きではありません。ドメインのセキュリティを維持しつつ、メールが適切に配信されることを確実にするための不可欠な手順です。SPFレコードを設定する際には、意図したメールサーバーだけが、あなたのドメインに代わってメールを送信することを許可されていることが極めて重要です。これは、悪意ある攻撃者がメールアドレスを偽造して受信者を欺くようなメールスプーフィングといった問題を防ぐのに役立ちます。

検証のためのツール

このプロセスを支援するために、SPFレコードを分析し潜在的な問題を特定することに特化したオンラインツールがいくつも開発されています。たとえば、MXToolbox、SPF Analyzer、Google の CheckMX といったツールは、使いやすいインターフェースを備え、あなたのSPF設定をベストプラクティスに照らして素早く評価します。

これらのツールがどのように分析を行うのか、疑問に思われるかもしれません。通常、これらは、SPFレコードが構文ルールやDNSルックアップの上限といった重要な基準に準拠しているかどうかを確認します。これらの検証ツールのいずれかにあなたのドメインを通した後は、たいてい相違点や対応が必要な箇所を詳述したレポートを受け取ります。すべてが整っているかどうかを再確認する、単純ながら効果的な方法です。

ツール	機能	URL
MXToolbox	総合的なSPFルックアップ	mxtoolbox.com
SPF Analyzer	SPFレコードの詳細な分析	spfanalyzer.com
Google’s CheckMX	SPFレコードとMXレコードの両方を確認	toolbox.googleapps.com

これらの検証ツールがあなたの設定を確認してくれることで、適切に構造化されたSPFレコードとは何かを理解する態勢がより整います。この知識は、効果的なSPF設定を示す具体的な例とともに、実際の応用を探る次のステップへの備えとなります。

これらのレコードの微妙な違いに慣れておくと、将来の変更を自信を持って実装できるようになり、ひいてはより円滑なメール運用と、ドメインのセキュリティ強化につながります。

SPFレコードの例

効果的なSPFレコードを構築する際の微妙なニュアンスを把握するうえで、例は計り知れない価値を持ちます。重要な構文とベストプラクティスを浮き彫りにしてくれるからです。

例1：単純なSPFレコード

基本的なSPFレコードは、次のようになります。

v=spf1 mx -all

この構造では、mx メカニズムは、あなたのドメインに関連付けられたメール交換（MX）サーバーのみがメールを送信することを許可されていることを示します。末尾の -all 修飾子は、あなたのドメインに代わってメールを送信しようとするその他のあらゆる送信元が即座に拒否されることを定めます。これは保守的なアプローチであり、メールスプーフィングに対する厳格な保護を求める企業に最適です。

例2：include を含む複雑なSPFレコード

より詳細な設定については、次の例を考えてみましょう。

v=spf1 a mx include:_spf.google.com include:mailgun.org ~all

ここでは、許可リストを大幅に拡張しました。a と mx のメカニズムに加えて、Google Workspace と Mailgun という2つの外部サービスを取り込んでいます。include メカニズムを使うことで、これらのサービスにあなたに代わってメールを送信する許可を与えています。末尾の ~all は、明示的に記載されていないあらゆるサーバーに対するソフトフェイルを意味します。それらのサーバーからのメールは依然として通過しますが、疑わしい可能性があるものとしてマークされることがあります。この構成は、許可されていない送信元の取り扱いにおいて一定の慎重さを保ちながら、サードパーティのサービスに依存する組織に理想的です。

さらに、このように包括的な設定を採用することは、セキュリティを損なうことなく複数のプラットフォームを活用するうえで企業の助けとなります。ただし、取り込んだドメインのいずれもが自ら問題を抱えていないことを確実にするための監視は必要です。もし問題が生じれば、意図せず自らを脆弱性にさらしてしまうかもしれません。

SPFレコードの作成は、単に一行のテキストを書くことだけにとどまりません。誰にメール送信を託すのか、そして各構成要素が互いにどのように作用し合うのかを、慎重に検討する必要があります。よくある落とし穴を理解することは、全体的なメール設定にシームレスに溶け込む効果的な戦略を練り上げるうえで不可欠です。

よくあるSPFの問題を解決する

SPFに関しては、ささいな細部を見落とすことさえ、重大な問題につながりかねません。よくある問題の一つは、DNSルックアップの上限を超えることで、この上限は10回に定められています。つまり、SPFレコードに include のようなメカニズムが多すぎると、そのそれぞれが1回のDNSルックアップとしてカウントされるのです。このしきい値を超えると検証の失敗に遭遇し、メール配信の混乱を招く可能性があります。

その解決策はさほど複雑ではなく、要はアプローチを簡素化することにあります。まず、複数のIPを単一のメカニズムの下に統合し、可能な限り include ステートメントの数を減らすことから始めましょう。複数のサブドメインに対して個別のエントリーを設けるのではなく、それらをまとめてSPFレコードを簡潔に保つことを検討してください。この削減は、上限内に収めるのに役立つだけでなく、レコードの管理も容易にします。

DNSルックアップは重要ですが、構文にエラーがないことを確認するのも忘れないでください。

問題II：構文エラー

構文エラーは、SPFレコードの管理におけるもう一つの大きな障害となります。単純なタイプミスや文字の置き間違いだけでも、あなたのメールドメインを脆弱にする設定エラーを引き起こしかねません。細心の注意を払うことが不可欠です。スペースの置き間違いや誤ったメカニズムが、意図しない結果につながる可能性があります。

こうした懸念を軽減する効果的な方法の一つは、レコードを公開する前にSPF構文チェッカーを使用することです。これらのオンラインツールは、素早く誤りを特定するのに役立ち、実装中の不手際を防ぐことで、後々の時間と手間を省いてくれます。

以下は、SPF設定の正しさを確保するためのいくつかの戦略です。

• dmarcian やその他の信頼できるサイトで提供されているようなオンラインのSPFバリデーターを活用しましょう。

• タイプミスがないか常に二重に確認しましょう。手入力の際にしばしば発生します。

• 各メカニズムが正しく整形されていることを確認しましょう。正しい接頭辞（+、~、-、?）は、意図した結果と一致していなければなりません。

これらのよくある問題、すなわちDNSルックアップの上限超過と構文エラーに対して注意を怠らないことで、SPFレコードを堅牢かつ機能的に保つことができます。正確なSPFレコードを維持することは、メールの到達性を高めるだけでなく、なりすまし攻撃に対するドメインのセキュリティも強化します。定期的な確認と更新により、あなたはSPF設定を見過ごしている多くの組織の一つにならずに済み、コミュニケーションを信頼性が高く安全なものに保てます。

SPFレコードに関するこの議論を締めくくると、これらの設定の管理において先手を打ち続けることは、あなたのメールセキュリティとパフォーマンスを大きく高め得るのです。

SPFレコードを書く際に避けるべきよくあるミスは何ですか？

SPFレコードを書く際に避けるべきよくあるミスには、有効な送信元IPアドレスをすべて含めることを怠ること、うっかり10回のDNSルックアップ上限を超えてしまうこと、そして適切な指定なしに「all」メカニズムを使うことが挙げられ、後者はドメインをなりすましのリスクにさらしかねません。データによれば、設定エラーの15%は追加の送信元を見落とすことに起因しており、これは適切なメール配信とセキュリティコンプライアンスを確保するための包括的なアプローチの重要性を強調しています。

SPF構文はメールの到達性とスパム対策にどのように影響しますか？

SPF構文は、どのメールサーバーが自らに代わってメールを送信することを許可されているかをドメインが指定できるようにすることで、メールの到達性とスパム対策に大きな影響を及ぼします。この認証メカニズムは、受信サーバーが受信メッセージの正当性を検証するのを助け、それらがスパムとしてマークされる可能性を減らします。2023年の調査によれば、SPFを実装した組織はスパム関連のインシデントが20〜30%減少しており、これはメールの信頼性を高め、送信者としての総合的な評価を向上させるうえでの有効性を示しています。

ドメインのSPFレコードはどのように作成しますか？

ドメインのSPFレコードを作成するには、どのメールサーバーがあなたのドメインに代わってメールを送信することを許可されているかを指定するTXTレコードを、ドメインのDNS設定に追加する必要があります。基本的な構文には、バージョンタグ「v=spf1」に続いて、許可された送信元を列挙する「ip4」「ip6」「include」といったメカニズムが含まれます。たとえば、SPFレコードは「v=spf1 ip4:192.0.2.0/24 include:_spf.example.com -all」のようになります。SPFレコードを適切に設定することはメールスプーフィングを大幅に減らし得ます。研究によれば、SPFレコードを導入しているドメインは、フィッシング攻撃を最大77%少なく経験することが示されています。

SPFレコードは、DKIMやDMARCといった他のメール認証方式と共存できますか？

はい、SPFレコードはDKIMやDMARCといった他のメール認証方式と共存でき、実際、メールセキュリティを強化するために推奨されています。SPFが送信者のIPアドレスを検証するのに対し、DKIMは暗号署名によってメッセージの完全性を保証し、DMARCはこれらの上に構築され、レポートとポリシー適用の仕組みを提供します。これらのプロトコルを組み合わせることは、なりすましやフィッシング攻撃に対するより堅牢な防御につながります。研究によれば、SPFおよび DKIM と併せてDMARCを実装しているドメインは、メール到達率が10〜20%向上することが示されています。

SPF構文の構成要素は何ですか？

SPF 構文の構成要素には、バージョン識別子（常に「v=spf1」）、どのホストがメールを送信できるかを定義するメカニズム（「ip4」「ip6」「include」など）、そしてSPFレコードの取り扱いに関する追加の指示を提供するモディファイアが含まれます。各メカニズムには固有の機能があり、たとえば「-all」は記載されていないその他すべての送信元に対する失敗を示し、一方「~all」はソフトフェイルを示唆します。これらの構成要素を理解することは極めて重要です。というのも、SPFを導入している組織では、メールスプーフィングの試みが平均で70%減少し、メールセキュリティが大幅に強化されているからです。