なぜメールの認証技術が必要か?

もともとSMTPプロトコルには本人確認の仕組みが無く、誰でも自由に名乗ることができました。

しかし、大量の広告メールを送信するSPAM業者や、詐欺師たちが なりすましメール を利用するようになったため、それが問題になりました。

そのため、届いたメールが本当に送信者のものなのか? それを確認するため、メール認証技術が発展していきました。

現在のメールの認証技術

現在、メジャーなメールの認証技術は SPF、DKIM、DMARC の3つがあります。

これらは、それぞれ異なる形でなりすましを検証しており、相互に弱点を補完しあう形になっています。

それでは、それぞれの認証技術について見ていきましょう。

SPF

SPFは Sender Policy Framework の略で、差出人のIPとメールのIPの一致を検証することで、なりすましではないことを確認する仕組みです。

送信側は、メールが送信されるサーバのIPアドレスを開示し、受信側は、SMTP通信が来たIPアドレスと開示されたIPアドレスの一致で検証を行います。

検証の流れ

サーバがメールを受信した時、以下の方法で検証が行われます。

SMTP通信が来たIPアドレスを記録
SMTPの MAIL FROM (エンベローブFrom) に設定されたドメインを記録
記録した、ドメイン名のDNSのTXTレコードを確認
TXTレコードに書かれたIPアドレスと、 SMTP通信が来たIPアドレスが一致するか確認
一致していれば、正しい送信先から来たと判断

SPFレコードの例

受信側は、ドメイン名のDNSのTXTレコードにあるSPFレコードの内容を確認します。

SPFレコードは以下のような内容です。書かれているいずれかのIPアドレスが送信元のIPに一致するならば、検証は成功となります。

v=spf1 mx: mx.example.com ip4:192.168.0.1 ip4:192.168.0.2 include:example.com -all

v : バージョン
mx : ここで指定したドメインのMXレコードの値も正規のIPとして扱います
ip4 : 送信元として正しいIPアドレス(IPv4)。なお ip6 で ipv6も設定可能です
include : 他に参照すべきドメイン
- 他のSaaSなどを利用する時や、IPアドレスが書ききれないときに利用します
- 例えば、Amazon SES なら include: amazonses.com など
-all : all は、他に書かれていないIP。修飾子で処理を決定します
- + : 成功(Pass)
- ? : 中立(Neutral)
- ~ : 弱い失敗(SoftFail)
- - : 失敗(Fail)
- 上記の値により受信側はメールの処理を決定しますが、これ以外の要素も加味して不審なメールかどうかを判断します

SPFの弱点

SPFがチェックするのは、あくまで SMTP通信時の MAIL FROM (エンベローブFrom) のメールアドレスなので、我々がメールを受信した時に見る From (ヘッダFrom)の偽装には関与しません。

DKIM

DKIM は DomainKeys Identified Mail の略で、電子署名の仕組みを使いメールの改ざんを検証する仕組みです。

検証の流れ

送信側は暗号鍵のペアを用意して、復号用の鍵を公開します
メール送信時に暗号用の秘密鍵で、メールヘッダとメール本文をhash化したものを暗号化します(これを 電子署名 と呼びます)
送信側は、メールヘッダ DomainKey-Signature に電子署名など、検証に必要な情報を添付します
受信側は、 DKIM-Signature ヘッダに書かれたドメインから公開鍵を取得します
受信側は、公開鍵にて電子署名を複合します。復号内容と、メールヘッダとメール本文の内容が一致すれば、メールが改ざんされていないと判断できます

`DKIM-Signature` の内容

例として、steam から来たメールの DKIM-Signature にて内容を解説します。

DKIM-Signature には ; 区切りで認証に必要な情報が格納されています。

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=steampowered.com; s=smtp; h=Date:Message-Id:Content-Type:Subject: MIME-Version:Reply-To:From:To:Sender:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; b=********; bh=********;

v=1 : バージョン情報。現状は 1 固定
a=rsa-sha256 : 電子署名の暗号化アルゴリズム
q=dns/txt : 公開鍵の取得方法。現状は dns/txt のみ
c=relaxed/relaxed : ヘッダ/本文をhash化する前に、正規化する時のアルゴリズム
d=steampowered.com; s=smtp; : 公開鍵を取得する時のドメイン情報。 #{s}._domainkey.#{d} となる。この場合は、smtp._domainkey.steampowered.com
b=〜 : 電子署名データ
bh=〜 : 電子署名データのhash値。電子署名の改ざん防止のためにあります。

DKIMの弱点

DKIMもヘッダFromの内容は確認しません。そのため、ヘッダFrom偽装によるなりすましには対応できません。

ここまでのまとめ

それぞれの弱点で説明したように、 SPFで、DKIMでも、ヘッダFromの偽装を防ぐことはできません

SPF : エンベローブFROMのドメインを検証
DKIM : d タグのドメインを検証

その問題を解決するため、DMARCでは上記2つのいずれかのドメインとヘッダFromのドメインの一致を確認する機能があります

DMARC

DMARCは、Domain-based Message Authentication, Reporting, and Conformance の略です。

DMARCでは、SPFとDKIMそれぞれの検証ドメインと、ヘッダFrom のドメインを比較して、なりすましを防ぎます。

そのため、DMARCは、SPFやDKIMの検証が行われることが前提 となります。

さらにDMARCには、送信側で認証が失敗した時の処理の指定や、送信側に送る検証レポートを制御する機能があります。

まとめるとDMARCには、以下の機能があります。

受信側
- SPFやDKIMによる検証に加えてヘッダForm のドメインの一致も検証する
- 送信側の指定に従い、検証が失敗したメールを処理する
- 送信側の指定に従い、検証レポートをメールする
送信側
- 検証が失敗したメールを処理を指定する
- 検証レポートの送信先や送信頻度を指定する

DMARCポリシー

検証失敗時のメールの処理や、レポートの扱いはDMARCポリシーで指定します。

DMARCポリシーは _dmarc.#{メールのドメイン名} の TXT レコードに記載され、以下のような内容です。

v=DMARC1; p=reject; sp=none; pct=100; rua=mailto:dmarc@example.com; ri=86400;

v=DMARC1 : バージョン情報
p=reject : 認証に失敗したメールの取り扱い
- none : 何もしない( 受信側がSPAM判定をしないわけではない。メールサーバは様々な要因を加味して、SPAM判定を行います)
- quarantine : 「隔離」するように依頼します。メールサーバはユーザの「迷惑メールフォルダ」などにメールを送る可能性がありますが、none と同じように、様々な要因を加味して判定を行います。
- reject : 受信拒否するように依頼します
sp=none サブドメインの認証に失敗したメールの取り扱い
pct=100 : 認証に失敗したメールの内、何% を p= で指定した状態にするか指定します
rua=dmarc@github.com : 検証レポートの送信先
ri=86400 検証レポートの受信頻度を秒で指定できます。デフォルトは 86400 (1日) です。