鹿色のIT雑記

エンジニアの鹿色がIT技術を追いかけていくブログです

Gmailからのなりすましメールってありえるんだろうか？SPFレコードってなんだろう？

技術 情報セキュリティ

SPFレコードってみなさん聞いたことありますか？

自分は初めて聞きました。

ので、備忘録も兼ねてブログに記事を残しておきます。

 

 

SPFレコードって何者？

Sender Policy Frameworkのことで、メールを送信しているメールサーバのIPアドレスと、実際に送信した送信元メールアドレスのドメインとの対応をDNSの情報で検証するための情報のことのようです。

いや、どういうこと？となると思うのですが、要はメール送信サーバのなりすましを検知するための仕組みに利用するもののようです。

 

メールの送信元サーバってなりすませるの？

普通にスマホやPCでメールクライアントを利用して送信する場合は、あまり操作できない部分ではありますが、コマンドを利用することでなりすましができるようです。

というのも、メールクライアントでは、メール送信のために必要な情報をクライアントの中で組み立てて送信してくれるので、こちらでの修正の余地が少ないですね。

一方で、メールの送信コマンドを利用してメールを送る場合は、メール送信のために必要な情報を自分で組み立てられるので、そこでなりすますことができます。

 

メール送信のために必要な情報って？

SMTPというプロトコルでメールを送信するために必要な情報は、おおよそ以下のとおりです。

  • HELO
  • MAIL
    • 送信元メールアドレスを記載
  • RCPT
    • 宛先メールアドレスを記載
  • DATA
    • ヘッダに送信元メールアドレスを含む
    • メールの本文
  • QUIT

ここで、MAILとDATAの両方に送信元メールアドレスが出てきますが、MAILの方に記載されているものは、RCPTと合わせてエンべローブアドレスと呼ばれており、実際の送信元のアドレスが記載されています。

一方、DATAに記載されているものは、データとして送信されるものなので、任意に変更することができます。

封筒で手紙を送るときをイメージすると、封筒の外側には正しい住所を書かないと届かなかったり、返送できなかったりするので、正しいものが書かれており、中の手紙はデタラメなことが書いてあっても良いといったところでしょうか。

なりすましに気づくことってできるの？

ここで、今回のタイトルのSPFレコードが出てきます。

SPFに対応しているドメインであれば、DNSサーバにSPFレコードを問い合わせることで、正しいメールサーバから送信されてきたかを判定することができます。

 

例えば、GMAILのSPFは、以下のように設定されているようです。

$ dig gmail.com txt

gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"

redirectが指定されているのでややこしいですが、_spf.google.com配下に登録されているものが正しい送信元メールサーバのようです。

さらに掘っていくと、どのipv4のレンジで指定されているものが正しいものか判定するところまで見つけられます。

$ dig _spf.google.com txt

_spf.google.com.    300    IN    TXT    "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

$ dig _netblocks.google.com txt

_netblocks.google.com.    300    IN    TXT    "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

ここで、~allは、softfailを示すようなので、正規のメールサーバでないものが送信していることを通知できるようです。

が、これだけでは気づくことができないので、DMARCという仕組みで、正規のメールサーバでないものが送信している場合の挙動を決めることができます。

 

こちらもDNSサーバに入っている設定で、_dmarcプレフィックスを付与することで取得できます。

gmailの場合は、p=rejectとなっているので、上記でfailになった時点でメールが破棄されるようですね。

$ dig _dmarc.google.com txt

_dmarc.google.com.    300    IN    TXT    "v=DMARC1; p=reject; rua=mailauth-reports@google.com"

なので、gmail.comドメインから送信されてきているメールについては、メールサーバ側での検証がしっかりとされていれば、なりすましは無い。と考えて良さそうです。

流石ですね！

ちなみに、ruaには検証がエラーとなった場合の処理が書かれていて、レポート用メールアドレスが記載されていますね。

 

感想

メール周りの技術にはかなりDNSの技術が関連していて面白いですね。

ドメインに責任を持たせるという考え方は、わかりやすくて良いなと思いました。

なりすましや迷惑メールの無い安全な世界になると良いのですが…