SPF（Sender Policy Framework）のようなセキュリティ技術は、サイバー攻撃や迷惑メールが蔓延する現代において貴重な存在です。
サイバーセキュリティは、個人、企業、そして政府機関に至るまで、すべての人にとっての課題。なりすましメール、フィッシング、迷惑メールなど、データやアプリケーション、ネットワーク、個人を狙った悪質なセキュリティリスクが横行しているのが現実です。
サイト所有者は、このような危険に晒されれば、データや資金、評判、顧客の信頼などを失いかねません。電子メールは、最も使用される攻撃経路の一つです。
SPFは、広く普及しているメール認証技術で、メールの改ざんを検出し、迷惑メールをブロックしてくれます。また、SPFレコードを使用することで、顧客にメールを送信する際、受信者側のサーバーで迷惑メールと判定されるのを防ぐことができます。
この記事では、SPFレコードについて、そして、メールのセキュリティを強化するため、SPFレコードの導入が不可欠である理由をご紹介します。
SPFとは
SPFレコードについてご説明する前に、まずはSPFのことから。
SPF（Sender Policy Framework）とは、メール送信者アドレスの偽造を検証するために開発されたメール認証技術です。
攻撃者は送信者アドレスを偽造し、あたかも一般ユーザーのアドレスのように見せかけます。SPFは、このようなメッセージを検出して排除してくれるため、メールを利用したサイバー攻撃を回避することができます。
SPFは、受信側のサーバーからは一見すると正当なドメインから送信されたメールが、本当にそのドメインの正規IPアドレスから送信されているかを検証してくれます。そのドメインの正規IPアドレスとサーバーの情報は、DNSレコードで参照できます。
SPFレコードとは
SPFレコードは、DNSのゾーンファイルに追加されるTXTレコードの一種。ゾーンファイルには、差出人のドメインに代わってメールを送信できるすべての正規メールサーバー情報が含まれます。SPFレコードは、DNSに追加することで実装でき、スパム業者によってアドレスが偽造されたメールを検出し、送信を阻止します。
迷惑メールを配信する攻撃者は、ほとんどのメールサーバーで認証されません。そのため、メールヘッダーを改ざんして差出人情報を変更し、あたかも安全なドメインから届いているように見えるメールを配信します。
この行為はスプーフィングと呼ばれ、スパム業者や攻撃者は、ユーザーを騙して個人情報を入手することで、ターゲットとする個人や組織に損害を与えます。
今日、ほぼすべての迷惑メールには、偽のアドレスが使われています。攻撃者にメールアドレスを盗用された個人や組織は、顧客からの信用を失ったり、バウンスメール（配信できなかったメール）の再送に余計な時間を費やしたり、自社のIPアドレスがブラックリストに登録されてしまったりなどの被害を受けることになります。
したがって、メールの配信性と安全性を高めるには、SPFレコードの設定が不可欠です。
SPFレコードの書き方
一般的に、SPFレコードはTXTレコードを使用して定義されます（従来のファイルタイプとの混同を避けるため）。
SPFレコードは、使用するSPFのバージョンを示す「v」から始まります。現在は、最も多くのメールサーバーで認識される「spf1」でなければなりません。
この後は、そのドメインからメールを送信するサーバーに関する情報を定義する用語が続きます。この用語は、SPFレコードの処理についての詳細情報を含む場合もあります。
SPFレコードの記述例
以下は、SPFレコードの記述例です。
<v="spf1 a include:_spf.google.com -all">
v=spf1：SPFのバージョン1、TXTレコードをSPFレコードとして識別する要素a：ドメインのAレコードで特定されたサーバーがメールの送信を許可するものinclude:：送信者がドメイン（上の例ではgoogle.com）に代わって送信するメールの認証に使用-all：SPFレコードで定義されていないアドレスからのメール送信を許可しない旨を受信側のサーバーに伝えるもの（またそのようなアドレスを拒否するように指示）
SPFレコードの仕組み
SMTPで許可されたアドレスが差出人のメールは、どのコンピュータからでも送信可能です。攻撃者や詐欺師は、追跡困難な偽造アドレスを使って、この仕組みを悪用しています。
フィッシングにも同様の手法が使われており、攻撃者は、ユーザーがよく利用するサイトやサービスを模倣して、個人情報や企業情報の入手を試みます。
SPFを導入すると、ドメインの所有者がDNSレコードを使用し、ドメインからメールを送信する権限を持つコンピュータを定義することができるため、これに対抗することができます。また、受信者は、不正な送信元からのメールを受信する前に、SPFレコードを使ってそのアドレスを検証し、必要に応じてメールの受信を拒否することができます。
先ほどの例で見たように、SPFレコードは、正規メールサーバーのすべてのIPアドレスをリストアップしたTXTレコード形式です。SPFレコードには、1つまたは複数のメール送信を行う正規IPアドレスを定義します。
正規ユーザーがSPFレコードを使ってメールを送信すると、受信者のメールサーバーでDNSルックアップが実行されます。それから、TXTレコードを検出し、送信者のIPアドレスに偽造がないかを判定します。
SPFレコードで定義されたアドレスと一致しない場合は、送信者に「hard fail」または「soft fail」のメッセージが返されます。
受信側のサーバーがそのドメインを拒否すると、認証に失敗したユーザーまたはクライアントに、認証失敗のメッセージが送信されます（hard fail）。また、クライアントがメール転送エージェント（MTA）だった場合には、実際の差出人アドレスにバウンスメールが送信されます（soft fail）。
SPFレコードの構成要素
SPFレコードは、バージョン番号を筆頭に複数の要素で構成されます。
バージョン番号
SPFレコードは、バージョン番号で始まります。この番号は、正当な送信者を定義する機構よって認証されなければなりません。バージョン番号（spf1など）の後には、機構、限定子、修飾子の文字列が続きます。
機構（mechanism）
機構には、あるドメインに対して認証された送信元サーバーの情報が含まれ、ゼロまたは複数の機構を定義することができます。一般的なものには、以下が挙げられます。
a：DNSのAレコードに含まれるすべてのIPアドレスを指定（例:v=spf1 a:google.com -all）。最後に使用され、事前の機構に一致しない送信者IPを処理するルールを定義。mx：各サーバーに属するMXレコードに紐付くすべてのAレコードを定義（例:v=spf1 mx mx:google.com -all）。include:：他の認証されたドメインを定義（例:v=spf1 include:outlook.microsoft.com -all）。定義されたドメインと一致すれば、SPFが通過する。他のドメインにメール送信の権限を委任したい場合には、redirectを使って拡張が必要。ptr：各サーバーのPTRレコードに指定したAレコードを定義（例:v=spf1 ptr:domain.com -all）。基本的には非推奨。all：リモートとローカルのすべてのIPアドレスと一致し、SPFレコードの末尾で使用（例:v=spf1 +all）。exists：SPFの定義に基づき、例外としてサインアウトされたドメインを定義。定義されたドメインでクエリを実行すると、結果取得時に一致。使用する機会は稀で、DNSBLクエリのようなより複雑な照合が可能。ip4：IPv4アドレスの定義に使用（例: v=spf1 ip4:192.0.0.1 -all）。ip6：IPv6アドレスの定義に使用（例: v=spf1 ip6:2001:db8::8a2e:370:7334 -all）。
上記のような機構で、ドメインからのメール送信を許可されたすべてのIPアドレスを定義します。
限定子
機構には、照合処理の方法を定義する限定子があります。
メールサーバーは、送信者のIPアドレスを機構で定義された正規IPアドレスと照らし合わせます。SPFの機構内に一致するIPアドレスを検出したら、結果処理のルール（デフォルトではpassまたは+）を実装します。
限定子には、以下4種類あります。
+：認証されたことを意味する「PASS」を表す。アドレスが認証されると、メールが受け入れられる（例:v=spf1 +all）。+mxとmxと同じものであるため省略可能。-（ハイフン）：「HARDFAIL」を表す。アドレスの認証失敗を意味し、メールは拒否される（例:v=spf1 -all）。~（チルダ）：「SOFTFAIL」を表す。アドレスの認証失敗を意味するが、結果は明確ではない。非準拠のメールを受け入れて、タグ付けすることができる（例:v=spf1 ~all）。?：「NEUTRAL」を表す。認証に成功でも失敗でもなく、メールの扱いは自由（例:v=spf1 ?all）。
SPFレコードに限定子がない場合は、+allが設定されます。
修飾子
修飾子を使うと、フレームワークを拡張することができます。修飾子は=記号で区切られた値または名前のペアで、より詳細な情報を示すことができます。0〜2個まで記述可能で、レコードの最後に一度だけ示すことができます。
主な修飾子は以下の2つです。
redirect：他のドメインにクエリを送信するために使用。他の機構や修飾子と比較して扱いやすく、複数のドメインで同じSPFレコードを利用する場合に役立つ。exp：一致した機構にFAIL限定子が含まれる際、説明の記述に使用。この説明は、SPFログに記載される。
SPFレコードの必要性
ドメインにSPFレコードを設定しておけば、迷惑メールを受信する可能性が減少し、メールセキュリティが強化され、サイバー攻撃者や迷惑メールから自社を守ることができます。
また、ドメインの信頼性を高め、配信したメールが迷惑メール判定される可能性が下がることで、顧客の元にスムーズにメールを届けることができます。
ドメインへのSPFレコードの追加は、どの送信者がドメインに代わってメールを送信できるかを検証するために、近年ますます重要視されています。ここからは、SPFレコードを設定するさまざまなメリットをご紹介していきます。
メールセキュリティの向上
SPFレコードは、個人・法人を問わず、メールのセキュリティを高めるのに役立ちます。世界中のユーザーがサイバー犯罪の被害に遭いかねないサイバーセキュリティ時代には、受信トレイを自分で守るための対策が必要です。
ここで一役買うのが、まさにSPFレコードです。攻撃者が侵入しにくい環境を作ることで、迷惑メールの受信を防ぎ、メールセキュリティを高めることができます。
メール到達率の向上
SPFレコードのないドメインは、バウンスメールが発生したり、サーバーで迷惑メール判定されたりすることがあります。このようなことが繰り返されると、顧客にメールを適切に正常に送信する能力（配信能力とも）が低下します。
メール配信能力のないドメインは、個人や企業がターゲットとする顧客、従業員、販売業者、その他の関係者にメールを送信する際の障害となります。
ドメインの評価を高める
自社の顧客が、頻繁に自社を装った攻撃者からのメールを受け取っている場合、ドメインの信頼性が危険に晒されています。また、悪質な業者によって、顧客や従業員の個人情報が流出してしまう恐れもあり、さらにドメインの評価を下げてしまうことになります。
したがって、SPFレコードを利用して、このような事態からドメインを保護することが重要です。SPFレコードで定義した正規IPアドレスのみにメールの送信権限を与えることで、迷惑メールを防ぎ、攻撃の標的となる可能性を低減することができます。
DMARC準拠
送信ドメイン認証システムDMARCによって、許可されたユーザーのみがドメインからメールを送信できるように制限することができます。
また、サーバーにDKIMやSPFの認証に失敗したメールの処理方法についても指示を出し、拒否、隔離、何もしないの選択肢から選ぶことができます。
また、ドメイン管理者は、メールの送信状況に関するレポートを確認し、設定を調整することが可能です。
SPFレコードが必要になる事例
顧客、従業員、販売業者などに商用・取引用のメールを送信する場合は、ドメインにSPFレコードを設定するのが賢明です。さまざまなメールセキュリティソリューションを利用して、メールの配信性と安全性を高めましょう。
- 個人・企業─SPFレコードのようなメール認証技術を導入することで、ドメインからのメール送信を許可されているユーザーか、アドレスを偽造する第三者であるかを特定できます。また、SPFレコードをDMARCやDKIMと併用すると、すべてのメールに認証ポリシーを指定することができ、さらなるセキュリティ強化につながります。
- ISP─SPFレコードは、ISPにとっても有益です。SPFレコードを適切に設定していなければ、メールのフィルタリングが再度必要になる可能性があります。また、認証に失敗した場合は、メールが多くのサーバーでブロックされたり、迷惑メールと判定される可能性があることを意味します。
SPFレコードを使用することで、ドメインとメールのセキュリティが向上します。また、フィッシングなどの悪意ある業者による偽装メールをフィルタリングして、自社の評判を守ることができます。
SPFレコードの設定と編集方法
次に、SPFレコードの設定と編集方法をご紹介します。
SPFレコードの設定方法
SPFレコードの設定に取り掛かる前に、まずはそもそも設定が必要かどうかを確認してください。
ここで注目するのが、Return-Pathです。SPFは、Fromドメインではなく、主にReturn-Pathで使用されるドメインに機能するため、メールの送信に使用されているReturn-Pathを確かめます。
Googleなどの特定のメールサービスプロバイダ（ESP）では、自分のドメインをReturn-Pathに使用することができるため、ドメインに独自のSPFレコードを設定しなければなりません。
一方で、PostmarkなどのESPの場合は、Return-pathにESPのドメインが使用されるため、独自にSPEレコードの設定は不要です。
SPFレコードの設定が必要かどうかを判断したところで、早速設定方法を見ていきましょう。
ステップ1. メール送信元のIPアドレスを特定する
企業では、メール送信元が複数あることも考えられます。そのため、最初のステップは、自社ドメインからどのIPアドレスを使用してメールを送信しているかを特定すること。テキスト文書やスプレッドシートに、すべてのIPアドレスと対応するメールサーバーを一覧にしてみましょう。
また、メール送信に使用されるすべての手段も特定します。これには、ウェブサーバー、Microsoft Exchangeなどの社内用メールサーバー、ESPのメールサーバー、顧客が利用しているメールサービスのサーバー、サードパーティのメールサーバーなどが挙げられます。
IPアドレスが不明な場合は、ESPに問い合わせて、アカウントに関連するすべてのIPアドレス情報を入手してください。または、システム管理者の手を借りて、事業で使用しているすべてのIPアドレスを確認することもできるはずです。
ステップ2. 送信ドメインをリストアップする
企業であれば、複数のドメインを所有している場合があります。このうち、一部のドメインをメール送信用に、その他のドメインを別の目的に割り当てることができます。
次に、ドメインの目的に関わらず、所有する各ドメインにSPFレコードを設定します。
メール送信用のドメイン以外にも設定が必要な理由としては、サイバー犯罪者がSPFで保護されていないその他のドメインを利用して、なりすましを試みる可能性があるためです。
ステップ3. SPFレコードを設定する
SPFは、送信者のメールサーバーのIPアドレスと、送信者がDNSレコードで公開した正規の送信者IPアドレスとを照らし合わせ、送信者の身元を検証してメールセキュリティを強化する仕組みです。
SPFレコードを設定するには、v=spf1を記述した後、メール送信を許可するIPアドレスを定義していきます（例: v=spf1 ip4:192.0.0.1 -all）。
サードパーティのサービス、ドメインからメールを送信する場合は、以下の手順に従ってください。
- SPFレコードに
includeを追加して、そのサードパーティサービスが正当な送信者であることを定義する（例:include:google.com） - ドメインに関連するすべての正規IPアドレスを定義した後、SPFレコードの最後に
-all（HARDFAIL）または~all（SOFTFAIL）をつける（主要メールサービスでは、-allと~allのどちらも認証失敗を意味するが、一般的には、-allの方が安全） - SPFレコードは255文字、include機構（ルックアップとも）は10を超えないように注意する
以下は、SPFレコード例です。
v=spf1 ip4:192.0.0.1 include:google.com -all
なお、これはメール送信を行うドメイン用で、その他のドメインについては、修飾子（-all以外）を除外した、以下のようなSPFレコードを設定します。
v=spf1 –all
SPFレコードの設定を終えたら、次はこのレコードを公開していきます。
ステップ4. SPFレコードを公開する
SPFレコードの定義を終えたら、DNSにこのレコードを追加します。方法は以下の2通り。
- 社内のDNS管理者と連携し、DNSにSPFレコードを追加する（DNSサービスの管理画面で簡単に追加可能）
- DNSサービスに問い合わせて、SPFレコードの追加を依頼する
これによって、Gmail、Hotmail、Mailbirdなどのサービスを利用する受信者がSPFレコードを参照することができるようになります。
DNSレコードを更新する場合は、以下の手順で行なってください。
- ドメインを紐付けしているサーバーのアカウントにログイン
- 該当のドメインを選択
- DNSレコードが保存されている画面に移動（DNSマネージャでも可）
- TXTレコードを作成し、Hostフィールドにドメイン名を定義
- TXT値にSPFレコードを入力して、TTL（Time To Live）を指定
- 設定を保存してDNSにSPFレコードを追加
ステップ5. SPFレコードをテストする
SPFレコードを設定して公開したら、SPFレコードのチェックツールを使ってテストします。チェックツールには、Dmarcian、Agari、Mimecastなど、さまざまなものがあります。
テストを実行すると、SPFレコードの有効性、およびドメインからメールを送信できるすべての正規IPアドレスを確認することができます。正規IPアドレスが表示されない場合は、送信IPアドレスを残してレコードを更新してください。
SPFレコードの追加方法
SPFレコードをドメインに追加するには、ドメインのDNSコントロールパネルにアクセスします。Kinstaなどのホスティングサービスを利用している場合は、DNSへのSPFレコードの追加は比較的容易です。ドキュメントを参照して、実行してください。
メールサービスプロバイダでは、通常、ドメインからメール送信が行えるようにSPFレコードを公開しています。専門知識がない、またはISPがDNSレコードを管理している場合には、IT担当者に一任するのがベストです。
SPFレコードの制限事項
SPFレコードは、メールのセキュリティや配信性の面でメリットがありますが、ある一定の制限があります。
DNSのSPFレコード
初期のSPFバージョンは、導入やテストを効率よく行える様、送信者ドメインのDNS TXTレコードの設定を検証するために使用されていました。DNSのTXTレコードは、意味付けのない自由形式のテキストとして設計されていました。
しかし、2005年にIANAによってSPFにコード99のリソースレコードが割り当てられて以降、その複雑さからSPF利用が減少し、2014年に廃止されることに。
ヘッダーに関する問題
当初、SPFは、攻撃者がメールのエンベロープFrom（Return-Path）を偽造するのを防ぐために開発されました。ところが、現在ではメールヘッダーのFromフィールドのみが改ざんされることが多く、MTA（メール転送エージェント）で処理されるのではなく、受信者の目に触れるようになっています。これが、なりすましのリスクを助長しています。
メールヘッダーのFromフィールドを確認するために、DMARCでSPFを使用することはできますが、表示名偽装に対策を講じるには、SPFよりも高度なソリューションが必要になるかもしれません。
さらに、メールストリーム（ドメインに代わって一連のメールが送信元から受信元へ送られる経路）の追加や、ISPの変更を行なった場合には、SPFレコードの更新は困難になります。また、SPFレコードは、テキストメールの転送を中断する恐れがあり、メール認証は保証されません。
SPFレコードの注意事項
SPFレコードを設定・管理に関する注意事項をご紹介する前に、まずは一般的なものを見ていきます。
- 送信側IPアドレスには、PTRレコードが必要─PTRレコードは、ホスト名と一緒にIPアドレスを調べることができ、逆引きの電話帳のように使用することができます。ただし、公共のインターネットのアクセスポイントや、インターネット接続のための住宅用IPアドレスには、PTRレコードがない傾向にあります。これは、着信接続を確認する必要がある場合に使用されます。
- 送信ドメイン認証を使用する─SPF、DMARC、DKIM、いずれかまたはすべての送信ドメイン認証使用しましょう。これを利用する送信者は、利用しない送信者と比べて、識別が簡単であり、迷惑メールによってセキュリティリスクに晒される可能性を軽減することができます。このシステムを利用すれば、必ず配信したメールが顧客に届くというわけではありませんが、保護効果は高まります。ドメインの評価を監視・保護するためのメールセキュリティの仕組みは、あるに越したことはありません。
+allの使用、またはレコードへの追加は必ず避ける─allは、~allまたは-allとしてのみ使用してください。
この一般的な注意事項に加えて、以下、SPFレコードの注意事項もご紹介します。
限定的なSPFレコードを使用する
SPFには、強力で複雑な仕組みが多数ありますが、そのすべてをSPFレコードで使用する必要はありません。SPFレコードはシンプルに、必要な数だけを定義してください。
include:にも同じことが言えます。DNSルックアップ数が上限である10回を超えてしまわない様、数は可能な限り抑えて、入れ子構造は避けましょう。また、広範なIPアドレスを個別に追加するのではなく、一度に追加すると処理が簡素化され、手間の削減につながります。
IPアドレスの範囲をCIDR表記で指定する
1つのミスで値が大きく変わってしまうことを考慮し、IPアドレスの範囲はCIDR（サイダー）表記で指定しましょう。攻撃者によってシステムの一部が危険に晒され、その一部がこの範囲に含まれるIPアドレスを保持していたとしたら、致命的なことになりかねません。攻撃者が認証された正規IPアドレスを悪用して、迷惑メールを送信すれば、信用と大事なデータを失い、メールサービスに迷惑メール判定されてしまう恐れがあります。
このようなリスクは非常に大きく、メールサービスプロバイダは体制を強化し、疑わしいドメインをブロックしたり、SPFレコードで有効とみなすCIDRの範囲を制限したりしています。
all機構の使用を避ける
SPFレコードでは、+allを使用しないようにしてください。構文的には有効であるものの、許可範囲が広くなりすぎてしまい、この種のセキュリティ問題の検出が困難になります。レコードのテストツールやソリューションですら、識別されないことがあります。
+allは、文字通り、悪意のあるものを含めてウェブ全体でドメインの代わりにメール送信を許可する機構です。迷惑メールの配信に関与しているドメインには、+allで終わるSPFレコードが設定されていることがあります。この結果、どのIPアドレスからでも、マルウェアに感染メールを送信することができてしまいます。
レコードの重複に注意
原則、ドメインに設定するSPFレコードは1つ。つまり、v=spf1で始まるTXTレコードは1つだけ保存することができます。ドメインに複数のレコードを設定しようとすると、恒久的エラーを引き起こす可能性があります。
このSPFの制限に違反するケースは一般的で、ドメイン内でさまざまなサービスを導入していて、各サービスの提供元でそれぞれドメインへのSPFレコードの設定が必要になる場合によく見られます。
レコードの重複は、メールの配信性に影響を与え、セキュリティリスクを招き、顧客の信用を失う可能性があります。GoogleやMicrosoftのような大手メールサービスには、このような事態を防ぐため、重複したレコードを自動修正する機能が備わっていますが、小規模なメールシステムにはこのような機能がないことも。
SPFレコードの重複を見つけたら、すぐに対処してください。幸い、対処方法は非常に簡単です。複数のSPFレコードを持つ企業であれば、1つに統合することができます。2つのSPFレコードを統合すると、v=spf1がレコードの先頭に残り、一度だけ表示され、allは末尾に残ります。
文字数の制限
RFCによると、SPFレコードの文字制限は255文字です。この制限は、DNSのすべてのTXTレコードに適用されます。
先にも触れましたが、文字制限を超えるSPFレコードは、受信者のメールシステムで一時的、あるいは恒久的エラーを引き起こす恐れがあります。DNS管理者がこれに対処するかもしれませんが、文字数を超過するレコードを保存している間に問題が発生する可能性があります。
1つの文字列が255文字に制限される場合でも、1つのDNSレコードに複数の文字列を記述することもできます。そのため、受信側のメールサーバーがSPFレコードの解析を開始し、レコード内で複数の文字列が検出されると、スペースなしで特定の順序で結合されます。
解析が終わると、メールの内容が確認されます。繰り返しになりますが、複数の文字列を追加しても、レコードの総文字数には制限があることをお忘れなく。この制限はやや複雑ですが、DNSパケットが推奨UDPパケットサイズである512バイトを超えないようにするために設けられています。
SPFレコードがこの制限を超える場合は、サブレコードを作成し、1つのレコードを複数のレコードに分割して、問題を回避してください。なお、SPFレコードを分割する際は、メインとなる部分に各サブレコードを含めます。ただし、DNSリクエストの数が増えすぎて、セキュリティ上の問題が発生する可能性があるため、注意が必要です。
DNSルックアップ数を制限する
SPFレコードの最大文字数が255文字であることとは別に、DNSルックアップの回数も制限してください。RFCの仕様では、レコード内で実行されるDNSルックアップ数は、10回を超えないように指示されています。これは、DNSの無限ループやDDoS（Distributed Denial of Service）攻撃などの対策になります。
では、レコード内で10回以上のルックアップが実行されると、一体何が起こるのでしょうか。
SPF認証時に恒久的なエラーが発生します。SPF機構のinclude:、a、PTR、mx、exists、redirectは、DNSクエリにつながります。
all、ip4、ip6機構は、DNSクエリに対して数えられません。
さらに、長すぎるレコードの分割に使用するサブレコードなど、入れ子構造になったincludeステートメントには注意が必要です。SPFレコードが生成するDNSクエリを増加させてしまう可能性があります。サードパーティのサービスを利用する場合は、SPFレコードで過剰なDNSクエリを使用しないように気をつけてください。
サブネットとIPアドレスの重複を避ける
すべてのSPFエントリは、サブネットまたはIPアドレスに解決されます。
メール送信を許可されたIPアドレスやシステムの一覧を作成する際、重複するサブネットやIPアドレス生成されてしまうことがあります。これは、メールサービスプロバイダのドメインのMXレコードと同様で、SPFレコードにinclude:を追加した際に発生するのが一般的です。このIPは、含まれるサブネットに属している同じものである可能性があります。
サーバーのIPアドレスがほとんど変更されない場合は、ip4またはipv6表記を使用するのが得策です。これによって、受信者がDNSルックアップを回避することができます。また、SPFレコードのDNSルックアップは10回に限られるため、送信メールサーバーが多い場合は、IPアドレスの範囲を指定しましょう。
加えて、以下のような点も考慮してみてください。
include:の数を抑え、可能なら入れ子構造を避ける+allではなく、~allまたは-allを使用するexistsの使用を避ける─適切に使用しなければ、処理中のエラーからセキュリティリスクを助長する恐れがあるptrの使用を避ける─SPFの最新RFCで非推奨- DNSレコードの種類は指定しない─現在はTXTレコードで無効
- CIDR表記でアドレスブロックを指定する場合、/30から/16までのブロックを使用する─スラッシュの後の数字が大きいほど、アドレスブロックが小さいことを意味し、小さいほど良い。また、/1～/15のブロックは、受信者によっては無視されたり、割り引かれたりすることがあるため非推奨。
- SPFレコードでドメインを使用するすべてのメカニズムを解決する─Office365のクラウドサービスが置き換えた、オンプレミスにあるExchangeサーバーのような古いシステムをシステム管理者が削除していないことがよくある。更新されたSPFレコードにOffice365が必要であるにもかかわらず、古いシステムを削除しても、まだ更新されていない可能性が。この場合、SPFレコードのドメインは残っていても、実際にはもう存在しないことになり、一時的にSPFの認証に失敗することがある。
- DKIMやDMARCなどの送信ドメイン認証システムとSPFを併用することで、ドメインの保護をさらに強化する─DKIMやDMARCを利用する場合は、それぞれのベストプラクティスも要確認。
DKIMとSPFの併用
DomainKeys Identified Mail（DKIM）は、公開鍵暗号方式を使った電子署名を利用して、メールの改ざんが行われていないことを検証するための認証技術です。DKIMを使用する際は、以下のような点に注意してください。
- 攻撃者に悪用されないよう、暗号鍵は定期的に更新する─多くのメール送信者は、何年も前に生成された古い鍵を使用しており、これが悪用されるリスクを高めています。これに該当する場合は、新たにDKIM鍵を作成してください。また、月に数千または数百万通のメールを送信する場合は、鍵を1年に何度も更新することで、機密性の高いメールを保護することができます。
- 鍵長は少なくとも1,024ビットに─1,024ビット以下の鍵で生成された署名は無視されることがよくあります。多くのユーザーが、2,048ビットまたはそれ以上の長さを保っています。
- ESPを利用している場合は、すべての顧客に1つのDKIM鍵を使用するだけでなく、それぞれのメールに独自のDKIM鍵を割り当てる
- バウンスメールに気づいたらDKIMを使用して署名する
SPFとDMARCの併用
Domain-based Message Authentication, Reporting, and Conformance （DMARC）は、SPFとDKIM認証の仕組みを共通のフレームワークに統合し、ドメイン所有者が、メールの認証が失敗した際の処理方法を定義できるようにする技術です。
DMARCにはさまざまなメリットがあります。例えば、レポート機能で、メールサービスプロバイダへ認証に失敗したメールやドメインに代わって送信されたメールをブロックするように指示することができます。これによって、ドメインから送信された不正なメッセージを特定・ブロックし、顧客を保護するとともに、ドメインの評価を高めることができます。
DMARCを利用していない場合には、今すぐ導入することをお勧めします。また、使用する際には、メールに識別子アライメントが含まれていることを確認してください。アライメントは、メールがDMARCの検証を通過するのに不可欠で、これがなければ、正当なメールまで認証されなくなる可能性があります。
SPFレコードの確認方法
SPFレコードの確認には、さまざまなツールが利用できます。SPFレコードチェックツール、またはSPFレコードチェッカーなどと呼ばれます。
SPFレコードチェックツール
SPFレコードチェックツールは、さまざまな指標を通してSPFレコードの有効性を確認することができます。
- レコードの存在─指定したSPFレコードが実際にDNSに存在するかどうかを確認
- 複数のレコード─レコードが1つ、もしくは複数存在しているかどうかを確認（1つのDNSに対し許可されるSPFレコードは1つまで）
- 最大ルックアップ数─ルックアップの合計回数、また10回を超えていないかを確認（SPFレコードのルックアップ数は最大10回まで）
- PTRの有無─PTRの有無を確認（PTRの使用は非推奨）
代表的なチェックツールとしては、Dmarcian、Agari、Mimecastなどが挙げられます。
まとめ
サイバーセキュリティのリスクは年々高まり、個人にも企業にも影響を及ぼしています。対策として、可能な限り多くのセキュリティ層を実装し、保護を強化することが重要です。データ、ネットワーク、アプリケーション、システムを保護するため、さまざまなセキュリティ技術、ツール、サービスを賢く活用しましょう。
ドメインにSPFレコードを追加すると、スパム業者のなりすましメールを阻止することができ、アセットとドメインの評価を保護することができます。
SPFレコードだけでは十分にセキュリティを強化することができない場合があるため、DKIMとDMARCの併用をお勧めします。この2つの併用によって、メールスプーフィング、サーバーのブラックリスト入り、迷惑メール判定などのセキュリティリスクを効率的に検出することができます。
そして、SPFレコード、DKIM、DMARCのベストプラクティスに従い、SPFレコードチェックツールでレコードの有効性を確認することをお忘れなく。
