こんにちは、インフラエンジニアの小林です。
本日はメールの認証技術について解説します。
なぜメールの認証技術が必要か?
もともと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日) です。
まとめ
- メールの認証技術には、SPF / DKIM / DMARC などがある
- SPFは、送信元のIPと、エンベローブFROMに書かれたドメインのSPFレコードを検証する
- DKIMは、添付された電子署名と、
d
タグのドメインの証明書を検証する - SPFもDKIMもヘッダFROMを検証しない
- DMARCではSPFやDKIMの認証後に、エンベローブFROMや、
d
タグのドメインとヘッダFROMが一致しているかからに検証する - さらに、DMARC では送信先が検証後の取り扱いや、レポートメールの設定をDMARCポリシーで設定できる
また、SPF、DKIMの弱点として「転送やメーリングリストに対応していない」というものもあります。こちらは ARC(Authenticated Received Chain) という仕組みにより解決できますが、今回は割愛いたします。
長くなりましたが、以上となります。皆様のメールの設定の際の一助になりましたら幸いです。