送信ドメインを認証するためのSPFレコードに詳しくなろう

この記事は Sender Policy Framework (SPF): A Layer of Protection in Email Infrastructure の抄訳です。

誰かがあなたのスマホを取り上げて、勝手にSMSを送信してしまったら？困りますよね。1度そんなことが起きると、受信者は本当にあなたから送られたSMSなのかずっと疑うようになるでしょう。あっという間に信頼関係は崩れ去ってしまいます。

これはEメールの世界でも同じです。恐ろしいことに、フィッシング詐欺師はユーザ名とパスワードが無くてもあなたになりすましてビジネスメールを送信できてしまいます。

でも安心してください。あなたのブランドとメールのレピュテーションを守ってくれる、Sender Policy Framework（SPF）という仕組みがあります。

Twilio SendGridなど多くのメール配信サービスでは、サーバからサーバへメールを送る際にSimple Mail Transfer Protocol (SMTP)というプロトコルを使用しています。

SMTPのセキュリティ上の弱点として、誰でも任意のドメインの差出人になりすますことができる、というものがあります（ドナルド・トランプ氏のXアカウントが大量に作成されるようなものです）。 そのため受信者には、本当にその差出人からメールが送信されたかどうか分かりません。

受信者はメールを信頼できなくなり、送信者は自分のブランドになりすまされているのではないかと不安にかられる…これは誰にとっても良いことではありません！ こんな時、DNSのTXTレコードに登録されているSPFレコードが解決策の一端を担います。この記事では、SPFの概要からチェック方法まで、すべてを網羅して説明します。

SPFレコードとは？

SPFとは、メールの送信ドメイン認証のひとつで、メールが正規のサーバ（＝そのドメインからの送信が許可されているサーバ）から送信されているのかどうかを判断するのに有効です。SPFがあれば、ISPはあなたのドメインを利用した悪意のあるメールを判断できます。

SPFを使用すれば、受信者は期待通りの相手からメールが送られたと確信が持てますし、送信者はなりすましやブランド名を騙ったフィッシングメールが送信されないことで安心できます。

技術的にいうと、SPFレコードとはドメインの管理者が作成する短いテキストデータです。このTXTレコードは、他のレコード（A、PTR、MXなど）と一緒に、DNS (domain name system) へ登録します。たとえば次のようなものです。

"v=spf1 ip4:12.34.56.78 include:example.com -all"

SPFレコードの例

SPFレコードの一般的な例を見ながら、その意味について説明していきます。

例1：基本的なSPFレコード

基本的なSPFレコードの例は以下のとおりです。

v=spf1 ip4:192.168.0.1 -all

このレコードでは、メールがIPアドレス192.168.0.1から送信されることを許可し、それ以外のIPアドレスからの送信を禁止しています（-all）。1つのメールサーバから送信しているケースで見られるシンプルなSPF設定です。

例2：複数の送信元IPアドレスがある場合

複数のメールサーバから送信している場合は、SPFレコードを以下のように記述する必要があります。

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 -all

このレコードでは、メールが2つのIPアドレス（192.168.0.1と192.168.0.2）から送信されることを許可し、それ以外のIPアドレスからの送信を禁止しています。

例3: メール送信サービスを利用している場合

SendGridのようなメール送信サービスを利用している場合は、以下のようなSPFレコードが必要です。

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 include:sendgrid.net -all

このレコードは、自社で管理するサーバから送信したメール、SendGrid経由で送信したメールの両方を正当とみなすことを意味します。

このようにSPFレコードは、送信環境に応じて柔軟に記述することができます。SPFレコードを適切に設定し、自身のドメインを保護してメールを確実に受信者に届けましょう。

SPFの仕組み

SPFレコードを見れば、そのドメインからメール送信を許可されているのはどういったサーバなのか分かります。

通常、SPFレコードは、SMTPの一連の通信手順のうち、メール本文が送信される前の段階で問い合わせられます。

メッセージを送信するために、まずは送信サーバと受信サーバの間でTCPコネクションが開かれます。コネクションが確立したのち、HELOコマンドによってメールの送信元ドメインを受信サーバに伝えます。 次に、MAIL FROMコマンドによって送信元メールアドレスを伝えます。 MAIL FROMコマンドで入力されたドメインがSPFレコードのチェックに使用されるドメインで、メールのエンベロープFromとReturn-Pathヘッダに設定されます。

たとえばMAIL FROMコマンドにおいて、luke@example.comが入力されたとします。 受信サーバは、example.comのパブリックDNSレコード群のうち”v=spf1″で始まるTXTレコード、すなわちSPFレコードを確認します。SPFレコードがなければ認証は通り、複数あればエラーになるでしょう。SPFレコードが一つだけならば、受信サーバはそれに従って、送信サーバのIPアドレスを認証するかどうか判断します。

このとき、1件のSPFレコードが見つかったとします。

"v=spf1 ip4:12.34.56.78 include:example.com -all"

受信サーバは、送信サーバのIPアドレスがSPFレコードに含まれているかどうかをチェックします。 IPアドレスが含まれていればSPF認証は通ります。

SPFレコードを形作るもの

SPFレコードは様々な機構(mechanism)の組み合わせによって出来ています。各機構は、左側に書かれているものから順番に評価されます。

include

include機構は、ドメイン名を引数とします。
include先ドメインのSPFレコードで認証処理が通るならば、認証を通します。include先でさらにinclude機構があった場合は、再帰的に評価します。

A

a機構は、ドメイン名を引数とします。
送信サーバのIPアドレスが、与えられたドメインのAレコードもしくはAAAAレコードで解決されるならば、認証を通します。

MX

mx機構は、ドメイン名を引数とします。
送信サーバのIPアドレスが、与えられたドメインのMXレコードで解決されるならば、認証を通します。

IP4、IP6

IP4機構とIP6機構は、IPアドレスを引数とします。
CIDR記法によるブロック指定(例 192.168.0.0/16)も可能です。送信サーバのIPアドレスが、与えられたIPアドレスに含まれるならば、認証を通します。

PTR

ptr機構は使わないようにしましょう。
いくつかの技術的な理由によりエラーとなってしまう場合があり、名前解決のために受信サーバのメモリと帯域を多く消費します。受信サーバによっては、ptr機構が含まれているだけで、認証を弾いてしまう場合もあります。

ALL

all機構は、引数を取らず常に認証を通します。
SPFレコードの末尾で使うのが一般的です。たとえば認証結果を失敗にする検証子(qualifier)と組みあわせた「-all」は、「これまでの機構によって認証が通らなかったIPアドレスは、全て認証失敗する」ことを意味します。

REDIRECT

redirectは、正確には機構ではなく変更子(modifier)です。
redirect先ドメインのSPFレコードを使って認証処理を行います。redirect変更子を利用するならば、他の機構は使わないようにしましょう。redirect変更子を使ったシンプルな例は次のとおりです。

"v=spf1 redirect:example.com"

機構のうちinclude、a、mx、ptr、exists、redirectは、DNSの問い合わせが必要になるため、一つのSPFレコード内での使用は10回以下にしなければならない、という制限があります。一見、10回までであれば十分な余裕があるように思われるかもしれませんが、include機構は再帰的に評価されるため、たとえばinclude先のSPFレコードがさらに2つのinclude機構を含んでいたならば、3回としてカウントされます。これには注意が必要です。

SendGridユーザがしなければならないこと

送信元ドメインの参照先をSendGridドメイン(sendgrid.net)に向けるため、CNAMEレコードを登録します。こうすることで、SMTPの受信サーバは、送信元ドメインのSPFレコードではなく、CNAMEで指定されているSendGridのSPFレコードをチェックするようになります。

DNSレコードの設定内容について、詳しくは『独自ドメイン利用（Sender Authentication）および設定時のDNSレコードについて、詳しく教えてください』をご覧ください。

SPFレコードのテスト方法

すべてのISPがSPF認証を導入している訳ではありませんが、認証が失敗したメールはブロックされたり迷惑メールフォルダに入れられたりします。

SPFレコードの記述方法は複数あり、少しずつ異なります。正しく設定されていることを確認しておきましょう。 レコードの検証に役立つツールを紹介します。

• Scott Kitterman’s SPF Testing Tools：あなたのドメインのSPFレコードがすでに存在するかどうかを確認できます。また、SPFレコードの有効性やパフォーマンスのテストを行えます。
• SPF Record Check：SPFレコードのルックアップと検証が行えます。入力されたドメインのSPFレコードに対して診断テストを実行し、配信に影響を与える可能性のあるエラーを強調表示してくれます。

SPFの設定は率先して実施しよう

フィッシング詐欺師は、SPFが設定済みであるドメインよりも未設定のドメインを標的にします。 SPFはスパムメールを防ぐことはできませんが、攻撃を受けにくくする抑止力になるのです。それを望まない人はいないですよね？SPFレコードの作成を推奨するのはこのためです。

SPFをSender IDやDKIM、DMARCと組み合わせて使用すれば、スパム送信者からのメールを適切に識別することができます。

メールは、とても大切なコミュニケーションツールです。ユーザからの信頼を保ち、メールを確実に届けるために下記リンクもぜひご覧ください。

• DKIMとは？
• DMARCがもっとよくわかる！概要とレコードの読み方
• SPF、DKIMの特徴と違い
• SendGridからメール送信する場合のSPFとDKIMの認証の仕組み – 前編
• SendGridからメール送信する場合のSPFとDKIMの認証の仕組み – 後編