DNS SPFレコードとは?

SPFレコードは一種のDNS TXTレコードで、一般にメール認証に用いられます。送信元ドメインからのメール送信を許可されたIPアドレスリストとドメインのリストを含んでいます。

学習目的

この記事を読み終えると、以下のことができるようになります。

  • DNS SPFレコードを定義する
  • DNS SPFレコードのメリットを説明する
  • DNS SPFレコードの構成内容を理解する

記事のリンクをコピーする

DNS SPFレコードとは?

センダーポリシーフレームワーク(SPF)レコードは、特定ドメインからのメール送信が許されたすべてのサーバーをリスト化した一種のDNS TXTレコードです。

DNS TXT(テキスト)レコードは、ドメイン管理者がドメインネームシステム(DNS)に任意のテキストを入力できるようにします。TXTレコードは当初ドメインに関する重要な通知を含める目的で作られましたが、後に他の目的も果たすようになっています。

そもそもSPFレコードが作られたのは、標準的メールプロトコルである簡易メール転送プロトコル(SMTP)がメール送信元アドレスの認証機能を本来持たないものだったからです。つまり、SPFやその他の認証レコードがなければ、攻撃者は簡単に送信者になりすまして受信者を騙し、本来ならとらないであろう行動をとらせたり、共有しないであろう情報を共有させたりできます。

SPFはいわば、ドアマンが管理するゲストリストのようなものとお考え下さい。リストに名前がない人が中に入れないのと同様に、SPFレコードのリストに送信者のIPアドレスやドメインが登録されていなければ、受信側サーバー(ドアマン)はメールを届けないか、スパム判定して届けます。

メールの出所の信頼性をメールサーバーが確認できるようにするDNSベースの機構はたくさんあり、SPFレコードはその1つにすぎません。Domain-based Message Authentication Reporting and Conformance(DMARC)とDomainKeys Identified Mail(DKIM)もメール認証に使われます。

注意したいのは、SPFレコードにはかつて専用のDNSレコードタイプがあったこと。しかし今ではそのレコードタイプは推奨されておらず、TXTレコードだけを使うことになっています。

メールサーバーはどのようにしてSPFレコードをチェックするのか?

メールサーバーのSPFレコードチェックは、比較的シンプルなプロセスです。

  • サーバー1がメールを送信します。そのメールのIPアドレスは192.0.2.0で、リターンパスはemail@returnpath.comです。(リターンパスのアドレスは送信元のアドレスと異なり、バウンスメールの収集と処理に使われます。)
  • そのメッセージを受け取るメールサーバー(サーバー2)が、そのリターンパスのSPFレコードを検索します。
  • リターンパスのドメインのSPFレコードが見つかれば、サーバー2はサーバー1のIPアドレスのSPFレコードを許可済み送信者リストの中から探します。そのIPアドレスがSPFレコードのリストにあれば、SPFチェックは合格となり、メールは送られます。そのIPアドレスがSPFレコードのリストになければ、SPFチェックは不合格となります。この場合、メールは拒否されるかスパム表示されます。

SPFレコードはどのようなものか?

SPFレコードは、サーバーが内容をどう解釈するか理解できるように、特定の基準に則っていなければなりません。以下は、SPFレコードの核を成す構成要素の例です。

v=spf1 ip4=192.0.2.0 ip4=192.0.2.1 include:examplesender.email -all

この例は、レコードのタイプをサーバーに知らせ、このドメインの承認済みIPアドレスと第三者を記述し、不適合メールの取り扱い方をサーバーに伝えています。具体的にどうやっているのか、構成要素を個別に見ていきましょう。

  • v=spf1は、SPFレコードを含むことをサーバーに伝えています。SPFレコードは必ずこの文字列から始めなければなりません。
  • 続いて、SPFレコードの「ゲストリスト」の部分、つまり承認済みIPアドレスリストです。この例では、SPFレコードはサーバーに「ip4=192.0.2.0ip4=192.0.2.1はドメインを代表してメールを送信することを許可されている」旨を伝えています。
  • include:examplesender.netはincludeタグの例で、どの第三者組織がこのドメインに代わってメールを送信することを許可されているかをサーバーに伝えています。このタグは、「インクルード(include)されたドメイン(examplesender.net)のSPFレコードの内容をチェックすべきであり、そこに含まれるIPアドレスも許可済みと考えるべきだ」ということを示しています。SPFレコードには複数ドメインを含めることができますが、このタグは有効なドメインにしか使えません。
  • 末尾の-allは、「SPFレコードのリストにないアドレスはメール送信を許可されておらず、拒否すべき」であることをサーバーに伝えています。
    • この部分は~allでもよいのですが、その場合は「リストにないメールはセキュアでない、もしくはスパムであると表示されるが、受信はすべき」という意味になります。あまり使われませんが+allというオプションもあります。これは「お客様のドメインに代わってどのサーバーからでもメールを送信できる」ことを意味します。

この記事で取り上げた例はごくシンプルなものですが、もっと複雑なSPFレコードももちろんあります。SPFレコードの有効性を確保するために覚えておきたいことをいくつか、以下に挙げます。

  • 1つのドメインに関連するSPFレコードは1つしか存在できません。
  • レコードは、末尾をallという構成要素にするか、redirect:という構成要素(そのSPFレコードが別のドメインでホストされていることを意味します)を含めなければなりません。
  • SPFレコードの記述には大文字は使えません。

詳しくは、SPFレコードに関する公式ドキュメンテーションをご確認ください。

なぜSPFレコードを使うのか?

ドメインオペレーターがSPFレコードを使う理由はいろいろあります。

  • 攻撃防止:メール認証が行われなければ、企業もメール受信者もフィッシング、スパムメール、スプーフィング(なりすましメール)の危険に晒されます。SPFレコードを使えば、攻撃者がドメインを模倣しにくくなるため、そういった攻撃の可能性を軽減できます。
  • メール到達率の向上:SPFレコードを公開していないドメインは、送ったメールがバウンスしたりスパム判定される場合があります。メールのバウンスやスパム判定が続くと、ドメインが対象とするオーディエンスの受信箱にメッセージを届ける能力が損なわれ、顧客や従業員、その他の主体に対するコミュニケーションの努力が台無しになりかねません。
  • DMARCの遵守:DMARCは、許可を得たユーザーだけがメールを送るようにする検証システムです。DMARCポリシーでは、SPFやDKIMのチェックで不合格となったメールにサーバーがどう対処すべきかを定めています。それらのメールはDMARCポリシーの規定に従ってスパム判定されるか、拒否されるか、通常のメールとして配達されます。ドメイン管理者はメールアクティビティに関するレポートを受取、ポリシーの調整に役立てます。

The Cloudflare Email Security DNS Wizard makes it simple to set up the correct DNS TXT records and block spammers from using a domain. Read more about the Wizard here.

メール用DNSレコードの詳細はこちら: