メールマガジンを配信しても、エラーや迷惑メール扱いとなってしまう……そんな経験をお持ちの方も多いのではないでしょうか。実は、自社から配信したメールが迷惑メールと判定される原因の一つに、「SPF」の設定ミスがあります。
そこで今回は、迷惑メールと判定されないための正しいSPFの設定方法や確認方法を分かりやすく解説します。SPFレコードの記述例も記載していますので、ぜひ参考にしてみてください。
SPFとは
SPF（Sender Policy Framework）は、メールを送信しているサーバーが正当なものであるかどうかを確認し、不正なサーバーからのメール受信を防ぐための仕組みです。組織からメールを送る可能性のあるすべてのサーバーのIPアドレスを「SPFレコード」として記述し、送信元ドメインのDNSに登録します。
受信サーバは、メール送信元サーバのIPアドレスが、送信元ドメインのSPFレコードに含まれているかをチェックし、該当していれば正規のメール送信元と判断します。これにより、フィッシング詐欺やスパムメールのリスクを軽減できます。
SPFレコードの設定をする前に
SPFレコードはメールを送信するサーバーのIPアドレスをリスト化したもので、送信元ドメインごとに1つだけ設定します。もし、同じ送信元ドメインで複数のシステム（メール配信サービスや自社サーバーなど）を使ってメールを送信する場合は、それらすべてのシステムのIPアドレス情報を一つのSPFレコードにまとめて記述する必要があります。
メールを配信するシステムは、例えば以下のようなシステムが該当します。
- 組織で設置・運用しているメール配信サーバ
- 組織が使用しているワークグループシステム/サービス
- Google WorkspaceやMicrosoft Office365など
- 組織のWebサイトをホストするサーバ
- Webフォーム入力後の自動応答メールが送信されることがあります
- 顧客管理（CRM）、顧客サポート、請求管理などの業務システム
- その他メールマガジン配信等の一括配信システム
新たにメール配信サービスを導入する際は、SPFレコードの設定・更新が必要となります。DNSの管理を別の担当者がおこなっている場合や、他のシステムの状況が把握できない場合は、DNSの管理者にSPFレコードの設定・更新を依頼すると良いでしょう。DNSの管理者は本ブログを参考に、SPFレコードの設定・更新をおこないましょう。
SPFレコードの設定・更新
メール配信サービスを導入する際は、以下の流れでSPFレコードの設定・更新をおこないます。
1．ドメインを管理しているDNSサービス事業者の確認
まず、メールの差出人となるメールアドレスを決定します。そして、決めた差出人メールアドレスのドメイン名部分（メールアドレスの@より後ろの部分）を管理するDNSに対して設定をおこないます。ドメインを管理しているDNSサービス事業者が不明な場合は、組織のシステム管理者に確認しておきましょう。
注意する点として、例えば企業Webサイトをホストしているサービスと、ドメイン名を管理しているサービスは別の場合、この2つを混同していると設定できません。ドメインを管理しているサービスが何かを明確にしておきましょう。
2．導入するサービスのSPFレコード情報の取得
次に、導入するメール配信サービスの事業者からSPFレコードに設定する情報（メール配信サーバのIPアドレス情報など）を入手しましょう。
3．登録済みSPFレコードの存在確認
新たに導入するサービスと、既に稼働中のメール配信サービスが同じ差出人ドメインを使用している場合、SPFレコードがDNSに登録済みとなっているはずです。既にSPFレコードが登録済みかどうかを確認しましょう。
確認方法の例：
SPFレコードの確認方法は様々ですが、ここではMENAInfoSec社「PowerDMARC」のサービスサイトを例にとります。
|
4．SPFレコードが存在しない場合
このドメインを差出人としてメールを配信するシステムが他に存在しない場合、SPFレコードは定義されていないため見つかりません。この場合、前述の「導入するサービスのSPFレコード情報の取得」 で得た情報とともに、メール配信サービス事業者がSPFレコードの記述例を提示していることが多いため、提示内容通りにDNSにSPFレコードを設定しましょう。
DNSへの登録方法については後述の「6．SPFレコードをDNSに登録する」に進んでください。
5．SPFレコードが既に存在している場合
このドメインを差出人としてメールを配信するシステムが他にもある場合、SPFレコードが既に定義されています。この場合は、前述の手順「登録済みSPFレコードの存在確認」でコピーした既存のSPFレコード文字列に対して、後述 「SPFレコードの編集」を参考に、新たに加えるシステムのSPFレコードを追記します。
既存のSPFレコードには、他のメール配信システムに関する重要な情報が含まれています。誤って削除してしまったり意図しない変更が加わってしまったりすると、他のメール配信システムのSPFが成立しなくなり、そのシステムからのメール配信ができなくなってしまいます。SPFレコードの更新には注意が必要です。
6．SPFレコードをDNSに登録する
前述の「4．SPFレコードが存在しない場合」または「5．SPFレコードが既に存在している場合」で取得・作成したSPFレコードをDNSに登録します。DNSへの登録方法は、DNSのサービス事業者によって異なります。ご利用のサービスのSPF設定方法を参照し、ここまでの手順で作成したSPFレコードの文字列を登録しましょう。
以下は代表的なサービスのSPF設定方法を説明した記事です。ご利用のDNSサービスが提供するSPF設定方法、もしくは「DNSのTXTレコード」の設定方法を参考に、SPFレコードの設定を進めましょう。
さくらインターネット
https://help.sakura.ad.jp/domain/2306/
お名前.com
https://help.onamae.com/answer/20690
Xserver
https://www.xserver.ne.jp/manual/man_mail_spf.php
DNSにSPFレコードを登録すると、その情報がインターネット上で伝播し、メール配信先は設定されたSPFレコードを取得できるようになります。なお、伝播は通常、数分から数時間程度かかるため、設定後すぐに反映されないこともあります。SPFレコードをDNSに登録できたら、前述「登録済みSPFレコードの存在確認」で示される方法で、登録・更新したSPFレコードが取得できるかを確認しましょう。
7．メールを送る
DNSへのSPFレコードの登録が完了すると、受信側でSPFレコードを元にした迷惑メールの判定がおこなわれるようになります。実際にメールを送り、SPFレコードが機能しているかを確認しましょう。SPFレコードが受信側で機能しているかどうかを調べる方法は様々ですが、ここではGoogle社Gmailを例に確認方法を説明します。
設定を終えたメール配信システムから、Gmailのメールアドレス宛にメールを送信し、受信を確認します。配信したメールが受信ボックスに届くか迷惑メールと扱われるかはまだ分からないため、両方のフォルダを確認しておきましょう。配信したテストメールを受信したら、そのメールを選択後、右上のメニューから「原文を表示」を選択します。
ブラウザの別画面が開かれ、「元のメッセージ」としてメールの諸元が表示されます。その欄の中に、以下のように「SPF: PASS」と表示されていましたら、おめでとうございます！SPFの設定は完了です。
もしSPFが正しく設定されていない場合、以下のような状況が考えられます。いずれの場合も、前述の「ドメインを管理しているDNSサービス事業者の確認」から、これまでにおこななった手順に間違いがないか確認しながら設定をおこなってください。
SPF: の 評価結果 | 状態 |
NONE | DNSからSPFレコードを取得できませんでした。 |
‘FAIL’ / ‘SoftFAIL’ | DNSからSPFレコードを取得しましたが、認証できませんでした。 |
参考：
インターネットの標準仕様では、SPFレコードを登録するドメインはEnvelope-From:に指定されるメールアドレスのドメインであり、差出人として受信者に表示されるHeader-From:のメールアドレスのドメインではありません。ただし、日本の携帯電話事業者など、一部のメールボックス事業者はEnvelope-From:だけでなく、Header-From:であるメール差出人のドメインに対してもSPFレコードの設定を要求しています。メールの差出人のドメインに対してSPFレコードを登録する手順については以下を参照してください。
https://www.docomo.ne.jp/service/imode_mail/notice/sender_id/
https://www.au.com/mobile/service/attention/spf-record/
SPFレコードの編集
SPFレコードは、差出人のドメイン1つに対して1つのSPFレコードで記述する必要があります。そのため、同じドメインを差出人として使用する複数のメール配信システムがある場合は、それぞれの情報を1つのSPFレコードに統合して記述する必要があります。
この章では、新たにメール配信サービスを導入しSPFレコードを設定する場合を例に取り、SPFレコードの記述方法や注意点について解説します。
SPFレコードの書式
SPFレコードは以下のような文字列で構成され、各部分は半角スペースで区切られます。また、すべての文字は半角英数記号で記述します。
基本的な記述の例：
v=spfv1 ip4:198.51.100.2 ~all部分ごとの解説
v=spfv1 | SPFレコードの先頭を表す固定で必須の文字列。 |
ip4:198.51.100.2 | メール送信がおこなわれるサーバのIPアドレスの定義。 |
~all | メカニズムで定義されたIPアドレス以外のサーバの場合の扱いを表します。SPFレコードの末尾に配置します。 |
新たなサーバの定義を追加する
メカニズムの列挙
既に存在するSPFレコードに新たな定義を追加する場合、「メカニズム」部分に新しいメール配信システムの設定を追加します。これにより、他のメール配信サービスの設定と新しく追加するサービスの設定を一つのSPFレコードにまとめます。
例えば、既に「v=spfv1 ip4:198.51.100.2 ~all」という既存のSPFレコードが存在している状態で、新たに登録するシステムのIPアドレスとして
- 新システムB：「v=spfv1 ip4:203.0.113.5 ~all」
- 新システムC：「v=spfv1 ip4:203.0.113.6 ~all」
であると情報が提供された場合、このメカニズム部分だけをコピーし、既に存在するメカニズムと半角スペースで区切り列挙します。これらをすべて列挙すると「v=spfv1 ip4:198.51.100.2 ip4:203.0.113.5 ip4:203.0.113.6 ~all」となります。
メカニズム部分の表記
メカニズム部分は上記で示した例以外にもいくつかの表現方法があります。また、これらの文字列の前に +(プラス) -(マイナス) ~(チルダ) ?(疑問符) の文字が付く場合があります。これらはまとめて1つのメカニズムであり、上記SPFレコードの指定方法に従って取り扱います。
表記例 | 解説 |
ip6:2001:db8::1 | IPv6でのIPアドレスの表記です。 |
ip4:198.51.100.0/30 | IPv4, IPv6アドレスの範囲を表す表記です。 /（スラッシュ）、それに続く数字で一つのメカニズムです。 |
include:spf.example.com | 他のドメインのSPF設定を取り込みます。 このような設定が使われる場合があります。 |
a:example.com | 指定のドメインのAレコードが指すサーバである事を表します。 この指定がおこなわれることがあります。 |
mx:example.com | 指定のドメインのMXレコードが指すサーバである事を表します。 この指定がおこなわれることがあります。 |
all | 列挙されているメカニズムに該当しない「その他の場合」を表します。 |
SPFレコード編集時の注意点
SPFレコードは機械的に処理されるため、内容は文法に従って記述する必要がありますが、文法的に間違っていても人の目にはその間違いがすぐに分からない場合もあります。SPFレコードの状況がわからない場合は、上述の「登録済みSPFレコードの存在確認」手順で紹介されているSPFレコードの確認をおこなって、指摘事項がないかを確認してください。
以下に過去に見られた間違いのケースをご紹介します。
表記例 | 解説 |
v=spfv2 ip4:198.51.100.2 ~all | 先頭は必ず “v=spfv1” でなければなりません。 |
v=spfv1 ip4:198.51.100.2 ~all v=spfv1 ip4:198.51.100.5 ~all | 一つのドメインに内容が異なるSPFレコードが複数存在していると、動作が不定となります。 DNSとしては登録を受け付けますが、SPFレコードは必ず1つだけ定義されていなければなりません。本ブログの「登録済みSPFレコードの存在確認」以降の手順を参考に、SPFレコードを編集して1つにまとめましょう。 |
v=spfv1 ip4:198.51.100.5~all | 「メカニズム」は必ず半角スペースで区切られていなければなりません。 半角スペースで区切られていない場合、SPFレコードは正しく動作しません。 |
v=spfv1 ip4;198.51.100.5 ~all | 文法に従った文字でなければなりません。 例えば ‘:’ (コロン) と ‘;’ (セミコロン) の違いでも誤りとなります。 |
v=spfv1 includ:spf.example.com ~all | スペルミスも誤動作の原因となります。 左の例では、正しくは include: です。 |
v=spfv1 include:spf.example.com ~all | include等で指定したドメインを参照した結果、以下のような状況となる場合、エラーとなります。
a, mx, include等他のドメインを参照する動作は、仕様により10回までの制限があります。関連するシステムが増えSPFに登録するメカニズムの数が増えると、超えてしまう場合があります。 本エラーは、SPFレコードの文字の間違いではないため、文字列の確認だけではエラーの原因は判明しません。「登録済みSPFレコードの存在確認」手順をおこない、問題がないかを確認しましょう。 |
SPFレコード設定後の迷惑メールとの戦い
SPFレコードの定義が完了し、メールが問題なく送信できるようになっても、迷惑メール送信者はその設定の隙間をついて送信者になりすます可能性があります。送信側のSPF・DKIM・DMARCといったメール認証技術が万全となった際には、なりすましメールを高い精度で排除できるようになりますが、様々なシステムを使って同一ドメインからメール送信する場合、特に大規模な組織で複数の部門がそれぞれ独自のシステムを運用している場合は、認証設定を全体で統一するには時間と労力がかかるのが実情です。
そこで、SPF・DKIM・DMARCは設定変更中にメールが届かない状況を回避しつつ、準備が完了したら受信要件を段階的に厳しくするという運用を想定して技術仕様が策定されています。
1．SPFレコードのallメカニズムの初期設定
組織のシステム状況に合わせてallメカニズムの頭に付く記号を設定します。初期段階でのallメカニズムの限定子は ~all (チルダ) を設定します。この設定は、SPFレコードに記載されていない送信元からのメールについては、迷惑メール扱いにはなるものの受信は許可するという動作になります
そのため、設定がまだ完全でない段階でも、メールが届かなくなるリスクを避けながら運用を始めることができます。ただし、SPFが認めないメール配信元も同様に届くことが認められるため、過渡的な設定と言えます。
基本的な記述の例：
v=spfv1 ip4:198.51.100.2 ~allこのallメカニズムの頭についている記号は限定子と呼ばれ、それぞれ以下の意味を表しています。
記号 （限定子） | 解説 |
~ （チルダ） | このメカニズムに一致する送信元は、迷惑メールの可能性があるとする。 ~all とすると、同SPFレコードで列挙されているメカニズムが指すサーバ以外からのメール配信でも、自身が送っている可能性がある事を示唆します。 |
- （マイナス） | このメカニズムに一致する送信元は、送信元として認めないで拒否する。 -all とすると、同SPFレコードで列挙されているメカニズムが指すサーバ以外からのメール配信は、全て受信が拒否される事を指示します。 |
+ （プラス） | このメカニズムに一致する送信元は送信元として認める。 +all（もしくは限定子を省略したall）とすると、どんなメール送信元でも認めることになりますので、この設定を採用することはまずありません。 |
2．SPFレコードの設定確認
組織内にある、同一の差出人ドメイン名を使用しているすべてのメール配信システムを網羅したSPFレコードが定義できているかを確認します。SPFが成立していないシステムが組織内に残っている場合は、前述で示した手順を実施してSPFに対応しましょう。
3．DKIM、DMARCを設定する
DKIM、 DMARCの設定をおこない、運用します。DKIMは作成者署名による運用を強く推奨します。DKIM、DMARCについては以下の記事をご参照ください。
4．SPFレコードの~all（チルダ）設定の変更を検討する
SPF、DKIM、DMARCの設定が、同一ドメインを使うすべてのメール配信システムに適用されていることを確認し、DMARCのセキュリティレベルを最も厳しくした状態で運用ができていることを確認後、SPFレコードの ~all（チルダ）メカニズムを -all（マイナス） メカニズムに変更します。
これにより、最終的なメールのセキュリティ設定が完成します。この状態が整えば、特殊なケース（システム乗っ取り等）を除いて、メール受信側はなりすましメールを見抜けるようになります。
メール配信環境の運用
ネットワークの構造とセキュリティ
SMTPメールクライアント（MUAといいます）等を使用して、手元の端末からメールを配信している場合、通常は組織が利用・運用しているSMTPサーバを経由してメールの送信がおこなわれます。しかし、出張先やリモート環境など組織のネットワークが利用できない場合、その組織のものではないSMTPサーバに接続しながらも、差出人は組織のメールアドレスを使用してメールを送信する場合があります。
このような場合、差出人は組織のメールアドレスであるにもかかわらず、SMTPサーバは関係のない外部サーバを使用しているため、SPF認証が成立せず、受信側でなりすましメールと判定される可能性が高くなります。このような運用は、結果的になりすましでメールを配信する構図とほぼ同じ構図になってしまっており、信頼性やセキュリティの観点からも大きなリスクとなります。そのため、できるだけ早くこのような運用は見直し・廃止しましょう。
こうした問題を回避し、かつセキュリティを担保するためには、以下の点に注意が必要です。
- 組織のSMTPサーバは、組織のネットワークからのみ送信を受け付ける
SMTPサーバがスパムメールの踏み台サーバとして悪用されるリスクがあります。 - 組織のネットワーク外からメールを送信する場合は、VPNなどで組織のネットワークに接続後に、組織のSMTPサーバにメールを送信する
また、Webメールサービスを利用する場合、メールはWebメールをホストするサーバからSMTPサーバに送信されるため、SMTPサーバへ接続するシステムが限定できます。その結果、SMTPサーバへの配信動作を手元の端末からおこなう必要がなくなるため、前述のVPN等を使用せずにシンプルにセキュリティを担保できるシステム構造を実現できます。
メールを配信していたサービスの利用を止める時
これまでの説明とは逆に、メールを配信していたシステムの使用を止める場合は、そのシステムのサーバ情報をSPFレコードから取り除く必要があります。前述の「SPFレコードの編集」を参考に、SPFレコードの該当するサーバに関する情報のみを速やかに取り除き、DNSのSPFレコードを更新するようにしましょう。
SPF設定やレコード記述にお困りなら｜メール配信サービスのアララ メッセージへ
本記事では、SPFレコードをDNSに正しく設定することで、「なりすましメール」などの迷惑メールを防げることをご紹介しました。メールの到達率を保ちつつ、適切な認証設定をおこなうことは、企業の信頼性向上などにもつながります。
また、当社が提供する「アララ メッセージ」は、大量・高速配信や高い到達率を実現するだけでなく、SPFに加えてDKIMやS/MIMEなどの迷惑メール対策も備えたメール配信システムです。配信したメールが迷惑メールと判定されることにお困りの方はもちろん、これからメール配信を始める方にも最適なサービスです。ぜひご検討ください。
まとめ
SPFとは、メールの送信元サーバが正規のものかを検証する技術で、なりすましメール扱いされないための対策として有効です。しかし「SPFレコード」の記述を誤ってしまうと、メールの到達率を下げる原因になりかねないため、正確な設定が不可欠です。また、SPFで確かめられる範囲は送信元サーバのIPアドレスのみであり、送信者自身の当人性やメール内容の完全性を保証するためには、他のセキュリティ技術との組み合わせは必須です。
なりすましメール対策をしつつ、大量のメールを安定して届けたいという企業様には、高い到達率と安全性、万全のサポート体制が揃ったアララ メッセージの利用がおすすめです。
導入事例はこちら
関連コラム
