Google社が発表した「メール送信者のガイドライン」の改定。
この改定によりメール認証技術の導入が大きく関心を寄せられる結果となりました。
ガイドライン自体の改定については別記事で解説をしますが、そのドメイン認証技術のひとつ「SPF」について解説していきます。
SPF(Sender Policy Framework)とは?
SPF(Sender Policy Framework)とは送信ドメイン認証技術の1つで、送信元ドメインが詐称されておらず正しいメールサーバーから送信されているかを検証することのできる技術です。
SPFについては RFC4408 で規格化されています。
SPFの仕組み
SPFはメール送信者ドメインが管理するDNSサーバーにSPFレコードを登録することで、あらかじめ「このメールサーバーから送信するよ!」と宣言しておくことで実現しています。
メール受信側では「実際に接続してきたIPアドレス」と「メール送信者がSPFレコードで公開しているIPアドレス」の2つを比較することで、正しいメールサーバーから送信されているかを確認しているわけです。
SPFが登録されていなかったらどうなるの?
SPFが登録されていなかったり、DNSへの登録方法が間違っていた場合などは、受信者によっては迷惑メールフォルダに振り分けられたり、受信自体を拒否される場合があります。
また、当然ながら、受信側でSPFレコードを問い合わせた結果、接続元IPアドレスとSPFレコードの情報が合致しない場合は「なりすましメール」として同様に迷惑メールフォルダに振り分けられたり、受信自体を拒否されます。
すでにSPFレコードは世界的にも普及しているため、メールをプロバイダが用意するメール等ではなく、自身でメールサーバーを用意して利用する際には必ずSPFレコードを設定するようにしましょう。
SPFにも弱点が?
SPFにもなりすましではないのに、なりすましとして扱われてしまうパターンが存在します。
代表的なのは以下の2つのシーンです。
- 第三者が「送信者からのメールをそのまま転送したメール」を受信した場合
- 第三者のメーリングリストを経由して受信した場合
上記のように第三者がいったん受信をしてから転送してきた場合、「差出人は元のメール送信者」のまま、「接続元IPアドレスが変わる」状態となってしまうため、転送先ではSPF認証に失敗します。
そのため、転送する際はメールを添付ファイルとして送信するなど、送信者側でも配慮することで受信率をあげることができます。
この問題を解決するために、DKIM認証、DMARC認証を併用して応用したARC認証という別の技術がありますが、こちらは別記事で紹介したいとおもいます。
いかがでしたでしょうか?
今回は実際の記述例などの解説は他の技術系ブログ様にゆだねておりますが、簡単な概要はご理解いただけましたか?
送信ドメイン認証技術の中ではもっとも基本的な技術となりますので、知っておいて損することはないはずです!
この記事が1人でも役にたてていたら嬉しいです!
コメント