SPFレコードの書き方とは？ 記述例を総まとめ

Eメールは、多数の顧客へ効率よくアプローチできる優れた手段です。しかし近年、増え続けるスパムメールや「なりすましメール」の対策として迷惑メールフィルターが強化された結果、内容に問題がないメールにもかかわらず、メールが届かないケースが散見されます。メールの不達を防ぐためにも、送信ドメイン認証の導入は必須といえるでしょう。
とりわけ、送信ドメイン認証の中でも特に普及率が高いSPFについては、もし自社のドメインに導入していない場合は早急に実装すべきでしょう。ここでは、SPFレコードに関する基礎知識と具体的な実装方法（SPFレコードの記述方法）について紹介しています。

SPFとは？

SPFとは

SPF（Sender Policy Framework）とは、送信元IPアドレスの正当性を検証する送信ドメイン認証技術の方式です。メールはその仕組み上、送信元を偽る「なりすまし」が容易であり、標的型攻撃やフィッシング詐欺などに悪用され、大きな問題となっています。そのため、IPアドレス・ドメインの「身元」が正しいか確認するために送信ドメイン認証が必要とされています。

複数ある送信ドメイン認証の中でも、現在もっとも利用されているのがSPFです。SPFは、送信ドメインのDNSにSPFレコードを追加するだけで実装できるので、比較的容易に導入ができ、なりすましメール対策としてはもっとも有効と言われています。

実際に、一般財団法人日本データ通信協会と株式会社日本レジストリサービスの共同調査によれば、2020年3月まででjpドメイン全体におけるSPFレコードの実装率は64.6%となっています。

参考：総務省「特定電子メール等による電子メールの 送受信上の支障の防止に資する技術の 研究開発及び電子メール通信役務を提供する電気通信事業者によるその導入の状況」 https://www.soumu.go.jp/main_content/000693813.pdf(2020/02/28確認)

「なりすまし」はなぜ起きるか

「なりすましメール」とは迷惑メールの一種で、送信元を偽装して送られてくるメールの総称です。そもそもなぜそのような「なりすまし」が可能なのでしょうか？

メールの送信元（差出人）には、実は「ヘッダFrom」と「エンベロープFrom」の２種類が存在しています。そのうち「ヘッダFrom」の情報は送信者が自由に書き換えることができるので、赤の他人のドメイン／メールアドレスを名乗ることも可能なのです。これはメールの転送や代理送信、BBC機能など、柔軟なメール配信を実現するための仕様なのですが、それを悪用したのが「なりすまし」です。われわれが普段メールソフトでメールを開いた時に確認できる差出人は「ヘッダFrom」なので、注意深くしていてもメールソフト上で「なりすまし」を見破ることは難しいのです。

※ヘッダFromとエンベロープFromの詳細については、以下の記事をご覧ください。
「エンベロープFrom」と「ヘッダFrom」の違いとは？｜ベアメールブログ

「なりすまし」を防ぐ送信ドメイン認証

そこで送信者情報の偽装対策として開発された技術が「送信ドメイン認証」です。送信側がメール送信に利用するドメインに対してあらかじめ設定しておき、受信側がメールを受信した時に検証することで、送信者情報が偽装されていないことを確認します。

現在利用されている送信ドメイン認証技術は3種類あり、認証方法や目的がそれぞれ異なっています。

SPF	送信メールサーバーのIPアドレスを元に認証し、送信元サーバーの正当性を確認する
DKIM	送信メールサーバーで作成した電子署名を元に認証し、配送経路上でメールのヘッダや本文を改竄されていないか確認する
DMARC	SPFとDKIMの認証結果を利用し、認証失敗したメールの取り扱いを送信元ドメインの所有者が指定できる

SPFとDKIMのそれぞれの特徴について、詳細は以下の記事を参考にしてみてください。
ドメイン認証技術「SPF」「DKIM」の特徴・メリット・デメリットとは｜ベアメールブログ

SPFの仕組み

SPFの認証プロセスは以下のような流れとなります。

0. SPFレコード（メール送信に利用するサーバーのIPアドレス情報）を、送信ドメインのDNSサーバーに登録しておく
1. メールを送信する
2. 受信側メールサーバーがDNSサーバーに問い合わせ、SPFレコードを要求する
3. SPFレコードと受信したメールの実際の送信元IPアドレスを照合し、一致すれば認証成功となる

SPFレコードを設定しないリスクとは

それでは、SPFレコードを設定していないとどのようなデメリットがあるのでしょうか。

自社のドメインが「なりすまし」に利用されるリスクがある

送信ドメイン認証の仕組みを入れていないと、悪意のある第三者が自社のドメインになりすましてメールを送信することを防げず、顧客に被害が及ぶ危険性があります。結果として自社の社会的な信用を失いかねません。

携帯キャリアやメールプロバイダから迷惑メールと判断されるリスクがある

なりすましメールをはじめとした迷惑メールを防ぐ手段として、携帯キャリアやメールプロバイダは送信ドメイン認証を採用しています。SPFを導入していない場合、受信側のメールサーバーはそのメールの正当性を確認することができません。そのため、SPFレコードが未設定だと正当なメールにもかかわらず迷惑メールと判断され、送信制限やブロックの対象になったり、迷惑メールフォルダに振り分けられたりする可能性が高まります。

SPFレコードの具体的な設定方法、記述例

SPFレコードは、DNSに登録するリソースレコードの一種で、TXTレコードとして所定の文法に従ってSPFの認証情報を指定します。前述した通り、携帯キャリアやメールプロバイダの迷惑メールフィルターにブロックされないためには、SPFレコードの設定が今では必須と言えます。

しかしSPFレコードを誤った書式（文法）で設定を行うと受信側サーバーで「PermError(無効扱い)」になり、せっかく登録したにもかかわらず認証が行われません。ここでは、実際にSPFレコードの具体的な設定方法と記述例を解説していきます。

SPFレコードの設定方法

まずは、対象となるドメインと、SPFレコードを設定する上で必要なメールサーバー情報を洗い出し、整理します。

●自社で管理しているドメイン

ここではメール送信に利用していないものも含め、すべてのドメインを確認することをお薦めします。自社でメール送信に利用していなくとも、なりすましに悪用されてしまう恐れがあるからです。

●自社のメールを送信しているすべてのサーバー

例えば以下のようなサーバーが該当します。
　・オンプレミスのメールサーバー
　・Webサーバーやアプリケーションサーバー
　・外部のメールサービス
　・その他メールを送信する外部サービスなど

情報が整理できたら、それぞれのドメインのDNSサーバーに、そのドメインでメール送信しているサーバー情報をSPFレコードの書式で記述し、「TXTレコード」として設定します。DNSサーバーへの設定手順は、利用しているDNSサーバー（オンプレミス・クラウドサービス・ドメイン登録事業者のDNS・ホスティング事業者のレンタルDNSなど）によって異なりますので、自社のドメイン管理者に確認してください。

SPFレコードの基本書式

SPFレコードの基本書式は、次のとおりです。なお、ひとつの文字列（” ”で囲まれた部分）の最大文字数は255文字です
ドメイン.　IN TXT ” 【SPF version】 【qualifier】【mechanism】:【値】 ”

例えば、ドメイン「XXX.co.jp」のIPアドレス「192.168.10.1」から送信されたメールのみを認証させたいときは、次のようなSPFレコードを追記します。
XXX.co.jp.　IN TXT ” v=spf1  +ip4:192.168.10.1  –all”

この例をもとに、各項目の意味を見ていきましょう。

●【SPF version】

先頭の【SPF version】は、SPF自体のバージョンを記載する部分ですが、原則として「v=spf1」と記載します。「v=spf1.0」といった記載は文法エラーになりますので注意してください。

●【qualifier】

次の 【qualifier】は、後続の【mechanism】にマッチしたとき、その認証結果をどのように処理するのか内容を設定します。記述内容と処理内容の関係は、次のとおりです。

・「+」⇒正常なメールとして処理

・「⁻」⇒不正メールとして処理され、配信拒否の可能性あり

・「~」⇒不正メールとして処理されるが、配信される

・「?」⇒SPF指定なしとして処理される

上の例では、IPアドレス「192.168.10.1」を「+」（正常なメール）として扱い、それ以外のIPアドレスは「-all」で全て拒否しています。

ただし、厳密には受信側サーバーの設定に依存するため、「~」を記載しても、メールが到達しない可能性もあります。また、qualifierは省略可能であり、省略した場合は全て「+」（正常なメール）として処理されます。

●【mechanism】および【値】

【mechanism】と【値】は、いわば判定ルールです。この2つに合致していた場合、前述の【qualifier】の内容に従って処理が行われます。主要な設定内容と記載例は次のとおりです。

・「ip4:192.168.10.1」

IPv4 におけるIPアドレス「192.168.10.1」を条件指定する場合。指定したIPアドレス「192.168.10.1」とメール送信元のIPアドレスが一致するかを確認。

※ip6 と記載することで、IPv6での指定も可能。

・「a:XXX.co.jp」

ドメイン「XXX.co.jp」のAレコードを条件指定する場合。指定したドメインのAレコードに設定されているIPアドレスとメール送信元のIPアドレスが一致するかを確認。

・「include:ZZZ.co.jp」

他ドメイン「ZZZ.co.jp」のSPFレコードを参照して認証させる場合。例えば、外部のメール送信業者を利用する場合、普段利用しているものと異なるサーバーからメールが送られるため「include」を使用する。

・「redirect=YYY.co.jp」

リダイレクト先「YYY.co.jp」のSPFレコードを用いて認証させる場合。

・末尾に「all」と記載

全て合致と判断させる場合。

実際の記述例

【mechanism】の部分で、include や redirect など、やや特殊な動きをするメカニズムを指定するとエラー判定の温床になります。そのため、できるだけ簡潔に記載することが大切です。

上の例では、IPアドレスを【mechanism】として使用していますが、その他にも「ホスト名」や「ネットワーク指定」「サブドメインへの個別指定」などが可能です。

FDQN（ホスト＋ドメイン名）での記載例

IPアドレスではなく、ホスト名で指定しています。このとき、省略形ではなくFDQN（ホスト＋ドメイン名）で記載することを忘れないようにしてください。

XXX.co.jp.　IN TXT ”v=spf1  a:www.XXX.co.jp  -all”

ネットワーク指定での記載例

メールを送信する可能性があるホストが属するネットワークを、CIDR方式を用いて指定します。

XXX.co.jp.　IN TXT ”v=spf1  ip4:198.168.10.0/28  -all”

サブドメインへの個別指定

アナウンスやキャンペーンなど、業務の種類ごとにサブドメインを設けている場合は、サブドメインごとにSPFレコードの個別指定が可能です。

XXX.co.jp.　IN TXT” v=spf1  +ip4:192.168.10.1  -all”

shop.announce.XXX.co.jp.　IN TXT”v=spf1  +ip4:192.168.10.2  -all”

メールを送信しない場合の記載例

Webサイトのためだけに利用しているドメインなど、メールを送信しない場合は「メールを使わない」と宣言することでなりすましを防止することができます。

XXX.co.jp.　IN TXT” v=spf1  -all”

エラーを回避するためのポイント

よくある誤記載の例としては、次のようなものが挙げられます。いずれもごく単純な内容ですが、それだけに見逃されがちなポイントです。

ひとつのドメインに対して複数行の設定がある

SPFレコードは1つのドメインに対して1行になるように記載します。したがって、複数行にわたる記載はエラーになります。

誤)

XXX.co.jp.　IN TXT ”v=spf1  +ip4:192.168.10.1  -all”

          ”v=spf1  +ip4:192.168.10.2  -all”

正)

XXX.co.jp.　IN TXT ”v=spf1  +ip4:192.168.10.1  +ip4:192.168.10.2 -all”

勘違いによる記載ミス

IPv4アドレスを使用する時「ip4」ではなく「ipv4」と記載したり、ホスト名をFQDN（ホスト＋ドメイン名）ではなく省略形で記載したりするなど、思い込みによる記載ミスに注意しましょう。

相互参照によるループ

<mechanism>の部分でincludeを指定すると、他のドメインで指定したSPFを流用できるため、設定作業の簡略化が可能です。しかし、相互参照に陥ってしまうと処理がループし、エラーになります。

例)

XXX.co.jp.　IN TXT ”v=spf1  include:ZZZ.co.jp  -all”

ZZZ.co.jp.　IN TXT ”v=spf1  include:XXX.co.jp  -all”

SPFレコードの確認方法と注意点

SPFレコードが正しく設定されているか確認するためには、次のような方法があります。

オンラインツールでの確認

例えば、無料のSPFレコード確認サイト「SPF Record Testing Tools」（https://www.kitterman.com/spf/validate.html?）では、送信ドメインやSPFレコードを指定することでその有効性を確認することができます。
「Domain name」欄に送信元ドメインを入力し、「Get SPF Record」をクリックするだけで、自動的にチェックされます。また、同時にSPFレコードの構文チェックもされるため、設定の見直しにも活用できます。

送信メールのヘッダでの確認

実際に送ったメールがSPFの認証に合格しているか、送信したメールのヘッダを受信者に見てもらうことでも確認できます。メールのメッセージヘッダを表示してもらい、「spf=pass」となっていれば合格です。SPFがpassしていなかった場合はSPFレコードの記述に間違いがないか確認しましょう。

コマンドラインでの確認

OSによってコマンドは異なりますが、コマンドラインを使って確認することもできます。

以下の記事で詳しく解説していますので、そちらをご確認ください。
なりすましメール対策「SPF」「DKIM」の具体的な確認方法｜ベアメールブログ

DNSルックアップ回数の確認

SPFレコードを設定する際に注意したいのはDNSルックアップ（DNSの参照）回数です。DNSルックアップ回数は最大10回に制限されているため、それを超える場合はSPF検証に合格せずエラーになってしまいます。

ルックアップが発生するのは、レコード内の「a」「mx」「include」「redirect」で指定されている対象です。特に注意したいのは「include」を含んでいる場合で、includeタグで参照したドメインのSPFレコードにさらに参照がある場合、それもルックアップの回数としてカウントされるため、気づかずに参照回数が10回をオーバーしていたということも起き得ます。

DNSルックアップ回数も「SPF Record Testing Tools」（https://www.kitterman.com/spf/validate.html?）などのオンラインツールで確認することができるので、こちらも併せて確認するようにしましょう。

まとめ

本稿では、SPFレコードの設定方法・記述例などについて解説してきました。メール到達率は、マーケティングや広報、顧客とのコミュニケーションの質に影響するため、きわめて重要な指標です。しかし、送信ドメイン認証が正しく機能していなければ、メール到達率は改善しません。メール到達率が思わしくない場合は、まずSPFレコードの設定を見直してみてはいかがでしょうか。