HTMLだと、
意図した形式で表示するのは面倒ですので、
本記事の元であるWordで作成したPDFを貼り付けておきます。
このPDFファイルは、自由に再配布されてもかまいません。
ただし、再配布の際には、
入手元と著者名は明らかにしてください。
なお、上のPDFファイルの内容、また本文中の記述に、
誤字や脱字、誤った内容の記述など見つかりましたら、
下に示すフォームでご連絡いただければ幸いです。
1 なりすましメール対策「SPF」
本記事では、
自ドメインから送ったメールやメルマガの送信元メールアドレスが、
なりすましアドレスと扱われないようにする、
一つの方法について説明します。
メールを送信する際、受信するサーバーに対して
送信元情報として次の２つの情報を送ります。
- 送信元のドメイン名
- 送信元メールアドレス
そのドメインと無関係なメールサーバーを利用して
送信元を偽ったメールを送信しようとすると、
受信側でそのことを検出して自動的に受け取りを拒否することができます。
この仕組みをSPF(Sender Policy Framework)といいます。
メルマガを配信する場合では、
「メルマガ配信スタンド」と呼ばれるメールマガジン配信専用のサーバーから
メールが送られます。
ここで送信元メールアドレスに
あなたのブログやサイトの独自ドメインのメールアドレスに設定をしている場合では、
と、
ドメインが異なることから、なりすまし判定を受けてしまう、
つまりスパムとして扱われ、
読者にメールが届かないという可能性が高くなってしまっています。
このようなメールを受信するのか、受信拒否するのかは、
メールを受信する側の選択になります。
多くの携帯のキャリアメールは、デフォルト受信拒否で、
利用者が設定で受信できるようになっていますよね。
例えば、
といったような場合では、
送信元のメールアドレスからそのドメインは@マーク以降の「myprovider.invalid」ですが、
実際メールを送っているサーバーは「comserver.example」ということから
ドメインが異なります。
ここで、
これら異なるサーバーの情報を紐付けるために活躍するのが
「SPFレコード」というわけです。
2 SPFレコードの設定
SPFレコードは、DNSサーバーに設定します。
独自ドメインを持っていない場合、
当然ですが、DNSへのSPFレコード設定は不要というか、できません。
本記事では、
独自ドメインを持っていて、そこからメールを配信するが、
そのドメイン名を使わないメールを配信する時もある場合の
SPFレコード設定について説明していきます。
また、メルマガ配信時、
送信元メール・ドメインを独自ドメインのIPアドレスにする場合についても、
説明していきます。
また、
「エキスパートメールクラウド」、「アスメル」、と「オレンジメール」などの
メルマガ配信スタンドを例にして、その設定も説明していきます。
上記以外のメルマガ配信スタンドにつては、
それぞれのサポートページでご確認いただくか、
サポートに問い合わせれば設定値を教えてもらえます。
なお、
メルマガ配信スタンドによっては無料の代行設定サービスがありますので、
ご自分で設定が困難な方はそちらを利用されると良いでしょう。
2.1 設定に必要な情報
SPFレコード作成に必要な情報は、次の2つになります。
2.1.1 独自ドメインのメールサーバーIPアドレス
独自ドメインIPアドレスの確認方法については、割愛します。
2.1.2 メルマガ配信スタンドメール送信サーバーのIPアドレス
表2.1-1に、各メルマガ配信スタンドメール送信サーバーのIPアドレスを示します。
2.2 SPFレコードのフォーマット
2.2.1 基本フォーマット
独自ドメインでのメール配信、
また「エキスパートメールクラウド」、「アスメル」、「オレンジメール」でのメルマガ配信では、
下に示すフォーマットで設定します（たった、これだけです）。
ただし、
複数のメルマガ配信スタンドに対して設定する場合は、この限りではありません
（1行に複数のinclude機構を記述します）。
2.2.2 SPFレコードの設定例
配信元メールアドレスが独自ドメインだけの場合
配信元メールアドレスが、メルマガ配信スタンドのドメインだけの場合
2.3 SPFレコードをDNSサーバーに設定する
SPFレコードは、DNSサーバーに設定します。
以下に、Xサーバーの場合での例を示します。
ⅰ) まず、「サーバー管理ツール」にログインし、
「DNS設定」を選択します。
ⅱ) 複数のドメインがある場合には、
SPFレコードを設定するドメインを選択します。
ⅲ) 「DNSレコード設定」が表示されたら、
「DNSレコード追加」タブを選択します。
ⅳ) 表示された画面(図2.3-4)に、下に示すように設定します。
- ①の「ホスト名」は、そのまま（空欄）
- ②のタイプは、「TXT」を選択
- ③の内容に、2.2.2項で見てきた設定内容を入力します
- ④の優先度は、そのまま
2.4 SPFレコードの複数設定はNG
複数のメルマガ配信スタンドを利用されている方もいらっしゃるでしょう。
そういう方は、
全てのメルマガ配信スタンドに対してSPFレコードを設定したいと思われるでしょう。
そのような場合は、下に示すよう1行内に複数のinclude機構を記述します。
SPFレコードの設定は、１つしかできません。
SPFレコードが複数設定されている場合はエラーとなり、
せっかく設定したSPFが機能しないことになります。
SPFレコードの詳しいことについては、下に示すページをご覧ください。
本記事3章でも、もうちょっと触れてみます。
SPF（Sender Policy Framework）
http://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/
間違いから学ぶSPFレコードの正しい書き方
"http://salt.iajapan.org/wpmu/anti_spam/admin/operation/information/spf_i01/
2.5 SPFレコードのチェック
SPFレコードを間違って設定した場合でも、
直ちに受信拒否などの影響が出るわけではありませんので、
間違いに気付かない場合が多いようです。
そこで、公開したSPFレコードが正しいかどうかを
まずチェックすることをお勧めします。
SPFレコードによる認証結果を返す無料サービスがいろいろ存在しますので、
下にいくつかを紹介します。
PowerDMARC : SPFレコードチェッカー
https://powerdmarc.com/ja/spf-record-lookup
MX Lookup
https://mxtoolbox.com/NetworkTools.aspx
SPF Record Testing Tools
http://www.kitterman.com/spf/validate.html
Beveridge Hosting – SPF Test
https://bevhost.com/tools.htm
Sender Policy Framework : Tools
http://www.open-spf.org/Tools/
【SPF Record Testing Toolsでの確認例】
「SPF Record Testing Tools」でのSPFレコードチェックの例を示します。
SPFレコードが正しく編集されていれば、図2.5-2に示すように、
PASS sender SPF authorized
の文言が表示されます。
ちなみに、SPFレコードが正しく編集されていない場合、図2.5-3に示すように
softfail domain owner discourages use of this host
などと表示されます。
3 SPFレコードをもうちょっと詳しく
本節の内容は専門的になりますので、読み飛ばされてかまいません。
3.1 SPFレコードとは
SPFレコードとは、 ドメインの管理者がTXTレコードとして作成する短いテキストデータです。
このTXTレコードは、他のレコード（A、PTR、MXなど）と一緒に、DNSへ登録します。 たとえば次のようなものです。
3.2 SPFレコードの問い合わせタイミング
SPFレコードは、
そのドメインからのメール送信を許可されているのは
どういったサーバーなのかを、
受信サーバーに伝える役目を担います。
通常、SMTPの一連の通信手順のうち、
メール本文を送信する前の段階で問い合わせられます。
詳細な手順については、省略します。
3.3 SPFレコードを形作るもの
SPFレコードは、
様々な機構(mechanism)と検証子(qualifier)の組み合わせによってできています。
各機構は、左側に書かれているものから順番に評価されます。
3.3.1 SPFレコードの機構
ｖ
SPFのバージョン。
この機構は必須で、レコードの最初の機構にする必要があります。
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機構は、引数を取らず常に認証を通します。
%nbsp;
SPFレコードの末尾で使うのが一般的です。
たとえば認証結果を失敗にする検証子(qualifier)と組みあわせた「~all」は、
「これまでの機構によって認証が通らなかったIPアドレスは、全て認証失敗する」
ことを意味します。
redirect
redirectは、正確には機構ではなく変更子(modifier)です。
redirect先ドメインのSPFレコードを使って認証処理を行います。
redirect変更子を利用するならば、他の機構は使わないようにしましょう。
redirect変更子を使ったシンプルな例は次のとおりです。
機構のうちinclude、a、mx、ptr、exists、redirectは、
DNSの問い合わせを要求するため、
一つのSPFレコード内での使用は10回以下に制限されています。
なおinclude機構は再帰的に評価されるため、
たとえばinclude先のSPFレコードがさらに2つのinclude機構を含んでいたならば、
3回として数えます。
3.3.2 SPFレコードの検証子(qualifier)
表3.3-1に、SPFレコードの検証子を挙げておきます。
以上
