SPFの構文。完全ガイド
by
読書時間 5 分
SPFの概念を学び、実践することは、技術主導型の企業にとって重要です。フィッシングやスパムの潜在的なリスクから保護することができます。 BEC攻撃などから保護することができます。SPF（センダー・ポリシー・フレームワーク）の仕組みは SPFレコードを使用します。
このブログでは、SPFシンタックス・テーブル、SPFメカニズム、SPF修飾子、SPF修飾子など、技術的なプロトコルを使った電子メール認証のコンセプトをしっかり理解するために必要なことを幅広く説明する。
主なポイント
- テクノロジーを駆使する企業にとって、SPFを理解することはフィッシングやなりすましメールから身を守るために不可欠です。
- SPFレコードは、どのIPアドレスがあなたのドメインに代わってメールを送信することを許可されているかを指定する重要なDNSエントリです。
- SPFレコードを作成し、定期的にチェックすることは、メール攻撃におけるドメインの不正使用を防御するために不可欠です。
- SPFメカニズム、修飾子、およびモディファイアは、受信サーバーがSPFレコードをどのように解釈するかを決定する重要な要素である。
- 最適なEメールのセキュリティと配信性を確保するためには、単一の正しい形式のSPFレコードを維持することが必要です。
BenginnersのSPFシンタックス
SPFレコードは、お客様の公式ドメイン名を使ってメールを送信することを許可されたすべてのIPアドレスのリストを含むDNSレコードです。リスト外のサーバーがそのドメインを使用してメールを送信すると、不正なものとして扱われます。そのため、受信者のメールボックスでその入力が拒否されます。これにより、ハッカーが仕掛ける悪質な行為に企業名が巻き込まれるのを防ぐことができます。
企業はSPレコードを作成し、確認する必要があります。 SPFレコードの確認を作成し、独自ドメイン名によるフィッシング攻撃を未然に防いでください。過去 2億5500万件以上のフィッシング攻撃は、2022年の上半期だけで2億5,500万件以上記録されています。SPFを実装し、SPFの構文について学ぶことがいかに重要であるかを想像してみてください。
SPFレコードは、受信者のサーバーに、あなたのドメインから受信したメールをチェックし、認証するように指示するものです。また、認証に失敗したメールをどのように処理するかも記述されています。特定のコンポーネントが、すべての指示を表します。
SPFレコードを例にして、各要素を分解してみましょう。.SPFの構文はこのようになっています。
v=spf1 ip4:123.1.5.0 ip4:100.5.2.1 include:exampledomain.com ~all
各要素の機能は以下のとおりです。
- v=spf1は受信サーバーにSPFレコードを指定します。すべてのSPFレコードはこのように始まる必要があります。
- このSPF構文の次のセクションでは、あなたのドメインを使用してメールを送信することを許可されたIPアドレスを指示します。上記の例では、ip4:123.1.5.0 と ip4:100.5.2.1 を指定しています。
- 上記の例の「include:exampledomain.com」。セクションは、そのドメインを使用してメールを送信することを許可された第三者を指定します。include'タグは、受信者サーバーが、含まれるドメイン（exampledomain.com）のSPFレコードを検証し、同じく許可されているIPアドレスを確認することを示します。SPFレコード内に複数のドメインを追加することができますが、それらは有効である必要があります。
- all 要素は、SPF レコードで指定されたリスト以外のドメインや IP アドレスから送られたメールを SPF の NOT PASS とするよう受信サーバに指示します。
PowerDMARCで構文をシンプルに！
高度なSPF構文
SPF構文テーブルは、DNSのTXTレコードを使用して、単一の文字列で定義される。それは常に、使用されるSPFバージョンを指定する'v='要素で始まり、現在のところ1つのバージョンしかありません。
すべてのSPFレコードには、公式ドメインを使用してメッセージを共有することを許可するホストのルールとして動作する特定の用語が列挙されており、いくつかの追加情報を表示することもできます。
SPFの高度な構文 を分解していきます。 SPFメカニズム、SPF修飾子、SPFモディファイアの3つの構成要素に分解します。
SPFの仕組み
- ALL:常にマッチし、SPFレコードの最後に追加されるメカニズムです。マッチしないIPに対しては、'-all'のようなデフォルトの結果を表示します。
- A:ドメイン名にAAAAまたは Aレコードを一致させると、送信者アドレスを選別するためです。このDNS SPFレコードの構文が未指定の場合、現在のドメインが使用されます。
- ip4:送信者がSPFレコードの指定されたipv4アドレス範囲に接続されている場合、正に一致します。範囲の長さを指定するプレフィックスを付けて追加します。 プレフィックスがない場合は/32を使用します。
- ip6:送信者が指定されたipv6アドレス範囲に所属している場合に正とします。ip4ディレクティブと範囲の長さを示すプレフィックスを付加します。プレフィックスがない場合は /128 を使用します。
- MX:指定されたMXレコードに含まれるIPアドレスと同じIPアドレスを持つ送信者を許可します。 MXレコードは、各サーバーがメッセージを受け入れるためのIPアドレスと優先度の値で構成されています。
- PTR:IPアドレスをサブドメインやドメインに解決するのに役立つ、認可されたドメインを指定します。正確に一致するすべてのドメインまたはサブドメインについて、IPアドレスを取得するために前方探索が行われます。
このメカニズムは、複数のルックアップを必要とするため、時間がかかり、信頼性が低いと考えられています。RFC7208のガイドラインでは推奨されていません。 RFC7208のガイドラインでは推奨されていません。.
- EXISTS:入力されたドメインのDNS Aレコード検索を行います。実際の検索結果に関係なく、有効なAレコードが見つかれば一致となります。
- インクルード:第三者のメール送信者のドメインを記載して認可するものです。送信者のIPアドレスが、記載されたドメインのSPFレコードに記載されたIPアドレスまたはドメインと一致する場合のみ、送信者は認可されます。
SPF修飾子
あるメカニズムが修飾子を持たず、かつ、マッチングが成功した場合、SPF認証は通過する。8つのメカニズムはそれぞれ、後述する4つの修飾子のうちの1つと組み合わされています。
| 予選 | 結果 | 受信サーバーの対応 |
| + | パス | メールがSPF認証を正常に通過し、サーバーでメールのやり取りができるようになる。メールは本物としてマークされます。これは、Qualifierがない場合に適用されるデフォルトの動作です。 |
| - | 失敗 | 送信サーバーがリストに属していないため、メールの認証に失敗する。 受信者のメールボックスで拒否される可能性があります。 |
| ~ | ソフトフェイル | 受信者のメールボックスはメッセージを受け入れるが、不審なメッセージと判定され、スパムフォルダに振り分けられる。 |
| ? | ニュートラル | 電子メールメッセージは、認証に合格も不合格もしない。実行されるアクションは特定されず、電子メールは受信者によって受け入れられます。 |
SPF改質剤
SPD修飾子は、SPF構文の作業パラメータを決定する役割を担っている。これは、'='記号で区切られた名前と値のペアを含み、余分な詳細や規則に対する例外があればそれを共有します。
修飾子は一度だけ、SPFレコードの最後のセクションにのみ表示されます。正体不明の修飾子はすべて処理中に無視されます。redirect' 修飾子は、他のSPFレコードに認証を指示するために使用します。複数のドメインに同じSPFレコードの内容を持たせたい場合に使用します。
include」メカニズムは、お客様の代わりに、またはお客様のビジネス名を使用してメールを送信することを許可されたサードパーティドメインに使用されます。exp' 修飾子は、メカニズムが一致したときに受信サーバーが Fail SPF Qualifier を返した理由を指定します。
SPFレコードのガイドライン
SPF構文表を使ってSPFレコードを作成する際には、以下の点に注意してください。
- 1つのドメインに対して複数のSPFレコードを揃えることはできません。
- SPFレコードには大文字を含めてはいけません。そうしないとエラーが発生します。
- 255文字を超えてはいけません。これを超える文字列は、認証に失敗します。
- 同じドメインに解決するSPFメカニズムがある場合は削除する。
- 使用していないip4とip6のSPF機構を削除してください。また、任意のアドレス範囲をマージできるかどうかを確認します。
- SPF情報を保存するためのサブドメインを作成することができます。これは、'_spf.domain.com'を使って行うことができます。1つのSPFレコードに追加するIPアドレスが複数あるため、大手IT企業にはおすすめです。
ドメインとメールセキュリティのエキスパートPowerDMARC
ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。
最新記事 by Yunes Tarada(全て見る)
- DKIMドメインのアライメントの失敗 - RFC 5322による修正- 2025年6月5日
- DMARCbisの説明 - 何が変わり、どう備えるべきか- 2025年5月19日
- BIMIとは？BIMIロゴの要件とセットアップの完全ガイド- 2025年4月21日
