レンタルサーバ各社では、メールの自動転送機能の提供を行っているところが結構あります。
この機能は、とても便利で私も独自ドメインのメールをGmailで転送する用途で使用しています。
しかし、昨今のメールセキュリティ上、この自動転送は色々と問題が生じるようになってきており、迷惑メールフォルダに行ってしまうのはまだ可愛い方で、下手をすれば、メールそのものがサーバ上で拒否られてしまい、一部のメールが受信できないという問題が起きます。(実際Gmailが一番厳しく、メールが弾かれる率が高い)
今回はなぜレンタルサーバのメール転送はあまり使わないほうがいいのかをお伝えいたします。
レンタルサーバ会社が提供するメール転送の仕組み
簡単に説明すると、相手がメールを送信すると契約しているレンタルサーバへメールが届きます。そのメールをそのままFrom欄(差出人)を変更せず、自動的に自分が設定したメールアドレスへ転送してくれます。
ですので、メール転送を使っている利用者は、何も意識することなく「あ～〇〇からメールが来た～」という風に認識することができます。
しかしながら、昨今のメールセキュリティ上このFrom欄(差出人)を変更せず、自動転送することはおすすめできません。
厳密に言うとメールの転送は差出人を偽装している。
見出しのとおりですが、メールの転送は一度レンタルサーバへメールが届きます。その後、From欄(差出人)を変更せず転送を行っているため、厳密に言えば差出人を偽装していることになります。
例としてメールのヘッダーを見てみましょう。
こちらは、“google.com”が、”kanapon.me”(レンタルサーバはConoha Wing)へメールを送り”gmail.com”へFrom欄(差出人)を変更せずに転送している例になります。
感のいいガキのみなさんはもうおわかりだと思いますが、SPF認証がSoftFailになっています。(~allの設定になっている)
SPF認証とは…
差出人メールアドレス（ヘッダFrom）のIPアドレスと、送信元メールアドレス（エンベロープFrom）のドメインのSPFレコード（メール送信が許可されたメールサーバのIPアドレスのリスト）を、受信側のメールサーバで検証する方式。
送信ドメイン認証 – Wikipedia
簡単に言うと、送信者が、DNSサーバのTXTレコードにて、”わたしは、この送信元ホストもしくは、このIPアドレスから送信しますよ！それ以外は私ではありませんよ！”ということを明示します。これを登録したTXTレコードのことをSPFレコードと言います。
そして、受信側のメールサーバはそれに従い、送信されてきたメールの送信元ホストや送信元IPアドレスと、SPFレコードで明示されたホスト名やIPアドレスで送信しているかを確認をすることで、差出人を偽装していないかを判断する認証方式になります。
次に、メールヘッダの該当部分を見てみましょう。
google.com: domain of transitioning [email protected] does not designate 150.95.219.104 as permitted sender
Conoha Wingのレンタルサーバーである送信元IPアドレス(150.95.219.104)は”google.com”のSPFレコードにないし、許可してねーぞwwwwと言っています。
このことから、一度レンタルサーバが受信して再度メールを送信していることがわかり、From欄(差出人)も変更していないので偽装していることになります。
ですが、内容の改ざんを行っているわけではないのでDKIM認証は成功し、DMARC認証も成功しているため、メールが届いています。また、稀に届かないこともありますので注意が必要です。
しかしながら、SPF認証がFail判定になっているため、あまり気持ちのいいものではありません。
DKIM認証とは…
アメリカのYahoo!が提唱したドメインキーを使用した方式。送信元はメールに電子署名を付加し、受信側は送信元メールアドレスのドメインのDKIMレコード（公開鍵）を使って電子署名を検証する方式。
送信ドメイン認証 – Wikipedia
この認証方式は、秘密鍵で電子署名をし、DNSサーバに登録されているDKIMレコード(公開鍵)を使って認証し、メールの改ざんがないかどうかを確認する方式になります。
しかしながら、対応しているレンタルサーバが少ないことが挙げられます。2023年11月現在で対応しているレンタルサーバは、Conoha WingやXserver等があります。ユーザーが多いであろうロリポップや、さくらインターネットは対応しておらず、早く対応してほしいところではあります。(さくらインターネットは2018年から要望掲示板で言われていますが、いい加減対応してほしいところではあります。)
DMARC認証とは…
Domain-based Message Authentication, Reporting and Conformance (DMARC)は、電子メール認証プロトコルの一つ。電子メールのドメイン所有者が、保有するドメインを認証を通さずに利用されること(なりすましメール、フィッシングメール、詐欺メールその他の脅威)を防止できることを目的に設計された。
DMARC – Wikipedia
この認証は、SPF認証もしくはDKIM認証が失敗した時にどうするかを判断するもので、送信者側が任意に設定することができる認証方式です。検疫に設定すると迷惑メールフォルダ、除外に設定すると迷惑メールフォルダにすらいかず、受信メールサーバで拒否します。
また、そのレポートメールを受信することで、どういった挙動をしているかを管理することができます。
もう一つ例をご紹介しましょう。
このメールはDKIMが設定されてないレンタルサーバにて、SPF認証のレコードがないかつ、さらにDMARC認証が失敗した例になります。少し条件が異なりますが、SPF認証が失敗と同じ挙動になるため、一例といたします。
このDMARC設定は、“quarantine”つまり検疫に設定されており、迷惑メールフォルダへ移動しています。ですが、ここが“reject”つまり排除となると迷惑メールフォルダへ行かず、自動的にメールを拒否してしまいます。
以上のことから、From欄が変更されずメールを転送する場合、メール送信者側の設定次第で、SPF認証、DKIM認証、DMARC認証のいずれかが失敗するとメールが届かないという可能性が上がるというわけになります。これは、受信者側では操作することができず、メールが届かないという問題に発展します。
当たり前ですが、メールの送信者側もSPF認証、DKIM認証、DMARC認証は適切に設定して運用してな！！！！！改ざんあるいは偽装メールが送信されたら信用度低下するで！！！！
レンタルサーバのメール転送サービスなんで今も提供してるの？
そもそも、レンタルサーバはなぜメール転送サービスを提供しているのでしょうか？
それは便利だからです。
独自ドメインを作り、メールを受信させるためには、任意のメールソフトで受信をしなければ、メールを受信することができません。設定する必要もあり、めんどくさいですよね。なので、受信するだけなら、「いつものメールアドレスに自動転送かければ別にいいか～」というノリですることができます。
また、この機能はSPF認証(RFC7208が制定されたのは2014年)が制定される前に作られた機能であることから、その名残でそのまま提供しているということが推測できます。
適切なメールの受信したい場合はどうしたらいいの？
Gmailをメーラーとして利用しているのであれば、POP受信が可能のため、POPで受信することをおすすめします。そうすると、問題なくSPF認証等がクリアできるため、問題なくやり取りを行うことができます。ただし、GmailのPOP3受信の仕様では、15分に一度しかメールを受信することができないため、リアルタイムでのやりとりには不向きになります。
その他、iColud+のカスタムドメイン機能や、Microsoft 365、Google Workspaceを使うと良いでしょう。その際、DNSサーバ等の仕様をわかっていないとできませんので、この際に勉強するのもありです。
まとめ
いかがでしたでしょうか。
レンタルサーバのメール転送機能は実質的に差出人を偽装していることがわかりました。
私もメール転送を行っている身ではあるので、どこかのサービスでちゃんと受信できるように対策をしないとな…と感じているところです。
また、メールは差出人偽装などが容易にできる技術であるため、今上げたSPF認証、DKIM認証、DMARC認証は、もはや必須な領域に達しています。
DKIM認証は、提供されているレンタルサーバがホント少ないため、一刻も早く対応してほしいところではあります。
DMARC認証は、それぞれのセキュリティポリシーによって変わってくるため、よく考えて設定することをおすすめいたします。(私個人としては、rejectにすればいいと思っています)
コメント