さくらレンタルサーバーのサービスは DNS の「SPFレコード」に対応しています。
そこで今回はレンタルサーバーで今後対応が当たり前になる「SPFレコード」について詳しく解説をします。
以下の記事は具体的な Amazon Route 53（DNS サーバー）への SPF レコードの設定方法です。
【メール】【DNS】SPF（Sender Policy Framework）レコードの設定方法【Route 53】
SPFレコードとは何か？
SPF は「Sender Policy Framework（送信者ポリシーフレームワーク）」の略です。
SPF は送信者（送信元メールアドレス）のドメインの詐称を防ぐための認証の仕組みです。
例えば、本来のメールアドレスは「dckleclekjsadad@ckjaakndsaiwe.xyz」などプログラムがランダムに作成したようなメールアドレスですが、送信元ドメインを偽装することで「keiri@japan-commercial.com」などのようにいかもに存在していそうなドメインに見せることができます。
（もちろん「dckleclekjsadad@ckjaakndsaiwe.xyz」より「keiri@japan-commercial.com」の方がメール開封率は上がります）
このように偽装されると信用してしまいますが、SPFレコードを使うことで送信者のメールアドレスが他のドメイン名になりすましていないか検出することができます。
SMTPプロトコルは送信元を偽装できる仕様
相変わらず迷惑メールが多いですが、なぜここまで迷惑メールが多いのかというと SMTP プロトコルの仕様に原因がありました。
SMTPプロトコルでは送信者のメールアドレスが２つ使われます。
１．メールのFromヘッダーに表示されるメールアドレス
２．MAIL FROMコマンドの引数となるメールアドレス
そのため、「受信者の目で見える送信元のメールアドレス」と「実際に送った送信者のメール」が異なっていても問題なくメールが送信できます。
人間は送信元メールアドレスを見て信頼する
例えば、ここ最近「標的型攻撃メール」による被害が発生しています。
記憶に新しいところでは2015年5月「日本年金機構」が標的型攻撃メールの被害に遭い、125万人の個人情報が漏えいされました。
具体的に言うと、標的型攻撃メールは特定企業の特定部署宛（例えば株式会社●●の人事部や経理部など実在するような部署名）にスパムメール（迷惑メール）を送ってきて、「添付ファイルを今すぐ開封するよう」「URLを今すぐクリックするよう」促します。
添付ファイルを開封したり、URLをクリックした瞬間にウィルス感染したり、情報がインターネット上に流出してしまいます。
しかもこのような標的型攻撃メールを送る送信者は、送信元をそれらしい組織名（特定社団法人●●の理事の●●など）で、その組織のそれらしいメールアドレス（account@japan-local-community.orgなど）で詐称して送信してきたりすることもあります。
存在するかのような組織名とメールアドレスとメール文言を見て信頼して添付ファイルを開いたり、URLをクリックしてしまうだろうことは想像できます。
実際人間は
- 送信元メールアドレス
- 送信先メールアドレス
- 件名
を確認して信頼できるメールかどうかを判断します。
しかし送信元を偽装することでメール受信者を信頼させ、添付ファイルを開いたりURLをクリックさせることができます。
簡単にメール送信元を偽装できてしまう、これがスパムメール・迷惑メールの被害が後を絶たない原因になっています。
SPFレコードを利用することで偽装できなくなる仕組み
SPFレコードを利用することで送信元メールアドレスが偽装できなくなります。
その「仕組み」を説明します。
SMTPプロトコルは仕様上、送信者になりすますことが可能です。
そこで、メール送信者はあらかじめ送信元のIPアドレスをDNSのサーバーに登録しておきます。
受信者は実際に受け取ったIPアドレスがDNSサーバーに登録されているかを確認し、正規のIPアドレスから送信されたかを確認します。
つまりメールを受信した相手が、メール送信元が信頼できるかをSPFレコードでチェックできます。
もしSPFレコードをチェックして、DNSサーバーに登録されていなかった場合は、偽装している可能性があるためメールの受信を拒否したり、迷惑メールフォルダに振り分けるなど対策をすることができます。
逆にメールサーバーを運営している場合は、迷惑メール（スパムメール）として分類されないために DNS サーバーに SPF レコードを登録するなどの対策をすることができます。
SPFレコードの書き方
SPFレコードの書き方ですが、
- SPF RR
- TXT RR
の2つの書き方があります。
なぜ2つの書き方があるのかと言いますと、本来SPFレコードを使用するのが標準ですが、SPFレコードに対応している新しいリゾルバが少ないため、「SPF RR」でも「TXT RR」でも利用できるようになっています。
優先度は「SPF RR」の方が優先度が高く、「SPF RR」と「TXT RR」の両方が存在しているなら「SPF RR」のレコードが読まれます。
SPFレコードに対応していないリゾルバの場合は「TXT RR」に従います。
| tama-chan.com. IN TXT “v=spf1 ip4:123.123.123.123 -all” tama-chan.com. IN SPF “v=spf1 ip4:123.123.123.123 -all” |
上記のSPFレコードはSMTPサーバーのIPアドレスが「123.123.123.123」がメールアドレスのドメイン「tama-chan.com」のメールを送信しますよということをレコードにしています。
SPFレコードのチェックを「送信ドメイン認証」と呼んでいる
SPFレコードによるチェックを「送信ドメイン認証」と呼ぶことがあります。
「認証」と呼ぶと何やら「アカウント」と「パスワード」で正規のアカウントかどうかを認証しているようなイメージがあると思いますが、単純に「SPFレコードのIPアドレス」と「送信元メールサーバーのIPアドレス」が同じかどうかを確認しているだけです。
DNS の SPF レコードの Lookup（DNS ルックアップ）は 10 回が限度なので注意
自宅サーバーでメールサーバーや DNS サーバーを構築して運用しているくらいなら問題ないですが、大規模なシステムの場合や外部のメール配信業者を利用している場合、SPF レコードの「include」が問題になることがあります。
■include を利用する例
include を使う例としては、例えば以下の場合です。
- メールのドメインは yamachan.com
- メールアドレスは yama@yamachan.com
- メールサーバーは山ちゃんの自宅にあるが、インターネットへのメールは外部業者のメール配信サービスを利用している
- 外部業者のメールサーバーの FQDN は mail.tamachan.com なので、メールのドメインと実際に配信するドメインが異なる
- メール配信をする外部業者はちゃんとした業者なので mail.tamachan.com のグローバル IP と FQDN を SPF レコードとして DNS サーバーに登録している
SPF レコード記述例
|
yamachan.com IN TXT “v-spf1 include:mail.tamachan.com ~all” |
RFC 7208 にて DNS ルックアップは 10 回までに制限されている
RFC 7208 にて a、mx、ptr、exists、
SPF レコードのチェックサイトです。
SPF Record Testing Tools
https://www.kitterman.com/spf/validate.html
なぜ DNS ルックアップは 10 回に制限されているのか？
DNS ルックアップを無制限にしてしまうと、SPF レコードの記述ミスでループしてしまうとか、DOS 攻撃に利用される危険性があるため、わざと少ない回数に制限しています。
どうしても DNS ルックアップが 10 回超えてしまう場合
「DNS ルックアップが 10 回を超えてしまう場合は、10 回以内に減らしましょう」と言われても、どうしても 10 回以内に減らせない場合があります。
その場合は、メールアドレスのドメインからサブドメインを作成する（例：yama@yamachan.com の場合、yama@mail.yamachan.com というようにサブドメインを設定する）ことで DNS ルックアップ 10 回制限を回避することができます。
送信元メールアドレスの詐称を防止する主要な方法３つ
送信元メールアドレスの詐称を防止するための方法は
- SPF
- DKIM
- Sender ID
などがあります。
SPFは「RFC4408」で標準化されています。
https://www.ietf.org/rfc/rfc4408.txt
日本語への翻訳版
http://salt.iajapan.org/wpmu/anti_spam/admin/tech/rfc/rfc4408/page-1/
まとめ
DNSサーバー（ネームサーバー）のSPFレコードと聞くと何やら難しいイメージがありますが、図解だと分かりやすく単純な仕組みだと感じたと思います。
参考にさせていただいたサイト
一般財団法人インターネット協会
コメント