メール送受信に関する仕組みやドメイン設定のこと

メール送受信に関する仕組みやドメイン設定のこと

August 25, 2021

作業にあたり掲題の件で調べることがあった。頻繁に使用する知識でもないため、忘れた時のためにここに記録しておく。

メール送信について #

送信元の偽装 #

メール受信時に表示される送信元アドレスを偽装する（実際の送信元とは異なるアドレスを表示する）ことは簡単に行える。表示される送信元には送信者が任意の内容を設定できるためである。なぜこのようなことが起きるのか、以下の記事がわかりやすい。

なぜ、嘘のメールアドレスが書けるの？

メールの配送に、メール本体に書かれている宛先は使われない

太郎さん “taro@example1.co.jp” は、花子さん “hanako@example.jp” にメールを出そうとしています。このとき、メールの仕組みの中では、相手に届けるメール本体の外側に「エンベロープ（封筒）」が作られ、エンベロープ側に “実際に配送に必要な情報” が書き込まれます。

そして、メールは作成されたエンベロープの情報に従って配送されます。当該メールが花子さんがいる “example.jp” のメールサーバに到達し、花子さんのメールフォルダに格納された時点でエンペロープはお役ご免となり、捨てられます。以上が、正常なメールの流れだと思ってください。

では次に、おそらく皆さんが疑問に思うこと、すなわち、「メール本体に書かれた宛先とエンペロープに書かれる宛先は同一になるのでは？」ということと、「差出人にいい加減なメールアドレスを書いたらどうなるのか？」ということを考えてみましょう。

通常、一般的なメールソフトを使ってメールを書く場合、宛先や差出人にはメールを書いた人が入力した宛先や内部的に管理されたその人自身のメールアドレスが使われます。宛先には太郎さんが書いた “hanako@example.jp” が、そして差出人には太郎さんが使っているメールソフトが持っている太郎さん自身のメールアドレス “taro@example1.co.jp” が使われることになります。

しかし、実際には “メール本体に書かれる宛先や差出人” と “エンベロープに書かれる宛先や差出人” が同一である必要はありません。メールの配送途中において、メール本体はいっさい参照されないからです。そして、メールの受信側でもチェックされることはありません。

したがって、「メール本体に書かれた宛先とエンペロープに書かれる宛先は同一になるのでは？」の答えとしては、「それぞれにはまったく別のことが書ける」ということになります。不正に迷惑メールを出す人々は、この仕組みを悪用してエンベロープには真面目に宛先を書くけれど、メール本体にはいい加減な、もしくは相手を騙すためのメールアドレスを書くわけですね。

財団法人インターネット協会 迷惑メール対策委員会

では、どのように送信元の正当性を担保するのか、それに関しても同記事で言及されている。

差出人の正当性を確認できるようにするためには？

ここまでの説明で、私たちが見るメールに書かれている宛先とか差出人には本当のことが書かれていなくてもいいということが分かってしまいました。では、私たちはどうすればいいのでしょうか？

その答えのひとつは、メールを管理している人たちに「送信ドメイン認証を行って」と言うことでしょう。

送信ドメイン認証とは、差出人が称しているメールアドレスが本当か否かを判定するための技術のことです。仕組みは単純で、たとえば差出人が “taro@example1.co.jp” のアドレスだった場合、 “example1.co.jp” が管理しているメールサーバからメールが出てくるはずですよね。そこで、受て取り手となるメールサーバがメールを受信したとき、その接続先もしくはエンペロープを見て差出人のドメイン名を特定し、本当にそのドメイン名が使っているメールサーバから来たものかを判定するわけです。これにより、かなりの確率でメールアドレスの偽称を見破ることができます。

財団法人インターネット協会 迷惑メール対策委員会

送信ドメイン認証 #

送信元の正当性評価方法は SPF や DKIM や DMARC と複数ある。 以下が詳しい。

送信ドメイン認証（SPF / DKIM / DMARC）の仕組みと、なりすましメール対策への活用法

それぞれの要点のみを引用する。

SPF とは：送信元メールサーバの IP アドレスで判別

送信ドメイン認証には、大きく 3 つの種類があります。1 つめが IP アドレスを利用して受信したメールの送信元が詐称されていないかどうかを確認する「SPF（Sender Policy Framework）」です。

具体的には、メール送信時に利用するサーバの IP アドレスを送信側の DNS に「SPF レコード」として事前に登録。受信側はメール受信時に送信側の SPF レコードと照合し、なりすましかどうかを判断します。

DKIM とは：電子署名を付与してなりすましを検知

2 つめが電子署名を利用してメール送信元が詐称されていないかどうかを確認する「DKIM（DomainKeys Identified Mail）」です。送信側が送信するメールに電子署名を付与し、 受信側はそれをメール受信時に検証することで、 なりすましやメールの改ざんを検知します。

DMARC の活用：認証失敗時の対応策を定義し“守り”を固める

SPF、DKIM の認証結果を活用する仕組みとして近年注目されている技術が、3 つめの「DMARC（Domain-based Message Authentication、Reporting and Conformance）」です。

これは SPF や DKIM の認証が失敗した場合の対応策を定めたもの。送信側は受信側の認証失敗時の推奨アクションを DNS に「DMARC ポリシー」として宣言しておき、受信側は認証失敗時にこの DMARC ポリシーを参照して、受信メールをどう扱うか判断します。

IIJ エンタープライズ IT COLUMNS

実際の設定例 - Amazon SES #

アプリケーションからメールを送信する場合は、Gmail などではなく別のメール送信サービスを利用するケースがほとんどと思われるが、私の場合は Amazon SES をよく使っている。

SES を利用を開始する際に DKIM を設定する手順がある。これまで見てきた知識があるとその必要性や仕組みがよくわかる。以下は手順の参考までに。

メール受信について #

メールを受信するためにはドメインに MX レコードを設定する。受信にのみ使うレコードであり、送信には関係ない。（MX レコードがなくともメール送信が行えることを私は知らなかった。）

MX レコードは郵便局のような役割を果たすもので、誰かがメールを送信すると、MX レコードに指定されたメールサーバにメールが配送される。

MX レコードには複数の値を設定することが可能で、それぞれに優先値を割り当てる。優先値は 065535 の範囲内で設定し（一般的には 110 の範囲が利用される）、値が小さいほど優先度が高い。

私は Google Workspace の受信設定でドメインの MX レコードを変更することが多いため、以下に Google Workspace の記事を、合わせて MX レコードの補足説明として、お名前.com の記事も載せておく。

なお、Amazon SES 利用時には 以下のような MX レコードの設定も促される。

10 inbound-smtp.us-east-1.amazonaws.com

先述の通り、メール送信だけであれば MX レコードは関係ない。そのため、SES を送信専用で使うのであれば、MX レコードの設定は不要となる。