こんにちは、さきです！

自分でメールサーバーを運用しているのですが、最近DMARCのレポートにfail、つまり認証失敗の記載がたくさん....。

これは「なりすましメール」で私のドメインがスパムメールに使用されているということです。

認証失敗時のレポートを見ると、送信元はインドネシア。

ずっと日本にいる私がインドネシアからメールを送るわけがないので、そういう意味でもこれは間違いなく「なりすまし」されています！

というわけで、今回対策としてDMARCのポリシーを変更しました！

なりすましメールは誰でも簡単に送れてしまう！

メールの送信元（from）は、実は手紙を送る際に偽の住所を書くくらい簡単に誰でも書き換えることができてしまいます。

ですので、基本的に送信元メールアドレスの情報は信頼性が低く、送信元だけを見て正規のメールかなりすましかを判別するのは不可能です。

そこで登場するのが、送信ドメイン認証という技術です。

メール送信元ドメインを認証し、正規のメールかどうか判別できる

ドメインの管理者ならDNSレコードを書き換えることができるはず。なので、ドメインのDNSレコードと実物のメールの情報を照らし合わせて認証するのが送信ドメイン認証です。

こちらの記事でも紹介していますが、「SPF」と「DKIM」という技術を使うことで、高精度にドメインの認証を行なうことができます。

送ったメールが「迷惑メールフォルダ」に入る原因は？メールの認証方式「SPF」と「DKIM」って？

メールを送った相手から返事がない、後日話を聞いてみたらなんと、自分のメールが迷惑メールフォルダに放り込まれていた…なんて経験はありませんか？今回は、メールが迷惑フォルダに振り分けられる原因と、その対策について書きたいと思います！迷惑メール認定されることが多いのは、独自ドメインを使っているケースです。

GoogleやYahoo!はこれらの認証を通らなかったメールをデフォルトで迷惑メールフォルダ行きにするようになっていて、送信ドメイン認証はメールサーバーを立てる上で必須設定のひとつになっていきそうな気配です。

送信ドメイン認証をサポートする機能「DMARC（ディーマーク）」

送信ドメイン認証を採用する上でとても重要な機能、DMARC（ディーマーク）というものがあります。

DMARCは、送信ドメイン認証の結果がpass（合格）だったりfail（不合格）だったりといった結果のレポートを、ドメインの持ち主（管理者）にメールで通知してくれます。

記事冒頭にも書きましたが、今回色々となりすましスパム対策を行なうことになったきっかけも、DMARCのレポートがfailだらけになっていたからです...。

今回はDMARCでレポートを受け取っていたからこそ、早めに対策に乗り出すことができました。

DMARCポリシーで認証を通らなかったのメールの扱いを設定できる

DMARCにはポリシーという設定項目があり、この設定値によって認証を通らなかったメールを受信側がどう扱うか、指定しておくことができます。

ただし、あくまで推奨値でしかなく強制力は無いので、メールソフトやサービスによっては指示と異なる挙動をしたりします。

それこそGoogleやYahoo!なんかは認証不合格のメールはデフォルトで迷惑メール行きになるので、もしDMARCポリシーに「認証不合格だとしても、何もしないで普通のメールとして扱ってね」と設定していても無視されるわけですね。

今回行なった「なりすまし」対策

冒頭に書いたように、今回はDMARCポリシーを変更しました。

今まではこんな感じで

「p=none;」というように、認証不合格でも何もしない、という記述にしていました。これを

というような感じで、「p=quarantine;」としました。

pというのはポリシーのpで、3つの設定値があります。

• none（何もしないで普通のメールとして扱う）
• quarantine（とりあえず受信はするけれど、迷惑メールフォルダ等に隔離する）
• reject（そもそも受信すらしないで拒否する）

大抵の大手サービスやメールソフトは特に何も設定せずともquarantineの動作になると思いますが、そうじゃないものも多少はあるので、一応の対策です。

rejectはよっぽどの場合に使おうと思ってます。今現在はfailレポートも一日数件レベルなので。

送信ドメイン認証には穴がある

ここまで、送信ドメイン認証は万能であるような流れで説明してきましたが、実は送信ドメイン認証には穴があります。

運営する上で気を付ければ回避できるレベルのものですが、そこまで手が回らなかったり、またはDNSの書き換えを気軽にできない企業などではこのあたりが問題となってきます。

ちょっと掘り下げて説明します。

そもそも正規のメールとは何か

「正規のメール」という言葉を何度も使いましたが、そもそも正規のメールとはなんでしょうか。

イメージ論で言うならば「なりすましされていないメール」のことなんですが、技術的な観点から見るとちょっとややこしいことになります。

例えばWebサイトのお問い合わせフォームがあるとします。私の「さきブログ」にもありますね。

お問い合わせをした際に自動返信メールがお問い合わせした人に送信されたりしますが、この自動返信メールの送信ロジックを少し考えてみましょう。

ここでは、WEBサーバーとメールサーバーは「それぞれ別に存在する」ものとしてお話しします。

WEBサーバーから自動返信するケース

まずは、実装が比較的簡単（そして、WordPressのデフォルトの状態）である、お問い合わせを設置してあるWEBサーバーからそのまま自動返信を行なうケースを考えてみましょう。次図をご覧ください。

このように、ユーザーとのやり取りは全てWEBサーバーが担当していて、メールサーバーは全く関与していません。

だからなんだ、と思った方、ちょっと上の方で載せた「なりすましメールのイメージ」をもう一度ご覧ください。

お気づきでしょうか。

赤い矢印（左側の人に送られてくるメール）だけ見ると「メールサーバーは全く関与していない」「メールサーバーではない、別のサーバーからメールが送られている」という具合に、実は全く同じことになっています。

イメージ的には上の図（ WEBサーバーから自動返信を行なう際のイメージ ）は正規のメールなんですが、送信ドメイン認証的には不正ななりすましメールとなってしまうわけです。

この他、メールを大量送信する必要のあるサービスで外部メールサービス（メーリングリストなど）を利用したりしても同じ現象が起きます。

メールサーバーを経由した自動返信のケース

では、同じくお問い合わせの例で、今度はメールサーバーを経由させた場合の図を見て下さい。

この場合はメールがメールサーバーから送られてくるので、送信ドメイン認証に成功します。

「メールを送る指示」の部分は、WEBサーバーからメールサーバーにSMTPでログインしてメールを送信しています。スマホなんかでGmail等を使う人も多いと思いますが、それと同じ原理です。

ただこれは若干の知識が必要になるのと、設定を間違えるとメールが全く送信できなくなったりするので、WEBサーバーから直接メール送信するのに比べると手間ではあります。

メーリングリスト等を使用する場合はCNAMEのDNSレコードを設定したりすることで対処することができます。

多少手間でも、後々を考えるとちゃんとしておいた方がいい

GoogleやYahoo!の動向を見るに、今後新しいメール認証技術がスタンダードにならない限り、現行の送信ドメイン認証でやりくりしていくしかありません。

今はまだなんとかなっていても、送信ドメイン認証にちゃんと対応していない場合、将来的にメールが全く届かなくなったりしても不思議ではないと思います。

特に今はコロナの影響で業種問わずオンラインの需要が高まっていて、メールの重要度も上がっています。

まだギリギリメールが届いている今のうちに対策しておいた方が良さそうです。

まとめ

私のドメインがなりすましメールに使われたことを発端として、送信ドメイン認証とDMARC、それらの持つ構造的な穴についての記事でした。

元はと言えばスパムやなりすましメールを送る悪意ある人がいなければいい話なんですが、そんな話はあるわけないですね....。

私のメールサーバーにも毎日ものすごい量、スパムメールを転送（リレー）させようとしてくる中東あたりからのアクセスがあります。それだけ悪意ある人が多いということです。

サーバーを公開したら3日で標的にされるとはよく言いますが、実際にログを見るとやっぱり不安になりますね（それにしても、よく個人のサーバー見つけますよね！）。

でもちゃんと対策していれば大丈夫です。

送信ドメイン認証の導入なんかもお仕事でお受けしていますので、もしお困りの方がいらっしゃったらぜひお問い合わせからご相談下さい！

それではまたね！

さき