Carpe Diem

備忘録

メールにおけるSPFのドメイン認証の仕組み

概要

SPF(Sender Policy Framework)はメールのなりすましを防ぐための送信ドメイン認証の手法です。

さらに細かく説明すると

SMTPTCPコネクションの送信元IPアドレス送信元メールアドレス(エンベロープFrom)のドメインのTXTレコードに含まれるIPアドレスが合致するかどうかを確認する手法です。

この仕組みを図を交えながら説明します。

事前知識

前もって知っておいた方が良いことを書きます。

エンベロープFromとヘッダFrom

From 役割
エンベロープFrom バウンスを処理する場合などに使われるシステムが利用するアドレス
ヘッダFrom メールクライアントでFromとして表示される人間が利用するアドレス

SPFはこのエンベロープFromが正しいかチェックする仕組みです。

SPF, DKIM, DMARC

SPF

今回説明する送信ドメインが正しいかチェックする仕組みです。

DKIM

署名検証によってメールが改ざんされていないか、正しい送信者ドメインかをチェックする仕組みです。

DMARC

SPFDKIMを利用する際に満たすべき基準(SPFはエンベロープFromとヘッダFromのドメインが一致すべき、など)を定義したものであり、またSPFDKIMで認証失敗した際に

  • 受信拒否する
  • 隔離する
  • そのまま通す

といった判断をするための設定です。

認証失敗した際の設定は送信者側のドメインのTXTレコードで指定できます。

SPFの検証フロー

SPFの検証フローは以下です。

f:id:quoll00:20200916101938p:plain

説明すると

  1. ドメイン所有者があらかじめSPFレコード(実際はTXTレコード)を設定
  2. エンベロープFromであるReturn-Pathからドメインを取得
  3. そのドメインSPFレコードを取得
  4. SPFレコードに送信サーバのアドレスが含まれているか確認

となります。

別のメール送信サーバがエンベロープFromを改ざんしていた場合

別の悪意あるメールサーバ(IP: 2.2.3.4)が送信元をexample.comドメインにしてメールを送ったとします。

f:id:quoll00:20200915235716p:plain

しかしSPFレコードのチェックで許可IPには含まれない送信元IPであることで、SPFでのドメイン認証に失敗します。

また悪意あるユーザはexample.comドメイン所有者でないため、SPFレコードを改ざんすることもできません

これらの点からSPFは送信元が正しいことを保証できると言えます。

ドメインとは別サービスでメールを送る場合

自前でメールサーバを構築するのは大変なので、例えばMailgunというメールサービスを使ってメール送信をしたい、となった場合以下のようなフローになります。

前提としてhogehoge.devというドメインを所有するサービスを運営しているとします。なので

From
エンベロープFrom hogehoge.dev
ヘッダFrom hogehoge.dev

になるイメージです。

f:id:quoll00:20200916001837p:plain

具体的にdigしながら見てみましょう

hogehoge.devのTXTレコードにはmailgun.orgに聞いて、と設定

自分で所有しているドメインなのでDNS設定が可能ですね。

$ dig hogehoge.dev txt
;; ANSWER SECTION:
hogehoge.dev.          300     IN      TXT     "v=spf1 include:mailgun.org ~all"

mailgun.orgのTXTレコードを確認

mailgunのSPF TXTレコードはすでにSaaS側で設定済みです。

$ dig mailgun.org txt
;; ANSWER SECTION:
mailgun.org.            900     IN      TXT     "v=spf1 include:spf1.mailgun.org include:spf2.mailgun.org -all"
mailgun.org.            900     IN      TXT     "google-site-verification=FIGVOKZm6lQFDBJaiC2DdwvBy8TInunoGCt-1gnL4PA"

更にspf1.mailgun.orgspf2.mailgun.orgに委譲されている事が分かります。digすると

$ dig spf1.mailgun.org txt
;; ANSWER SECTION:
spf1.mailgun.org.       503     IN      TXT     "v=spf1 ip4:104.130.122.0/23 ip4:146.20.112.0/26 ip4:141.193.32.0/23 ip4:161.38.192.0/20 ~all"

このように許可IPリストが取得できます。

エンベロープFromを自ドメインにしないパターン

例えばAmazon SESはカスタムMAIL FROMを設定しないとReturn-Pathxxxxx@amazonses.comになります。

f:id:quoll00:20200916005535p:plain

なので

From
エンベロープFrom amazonses.com
ヘッダFrom hogehoge.dev

と、エンベロープFromとヘッダFromが異なる状態になります。

amazonses.comAWSが所有するドメインなので、AWS側でSPF TXTレコードが設定済みです。

$ dig amazonses.com txt | grep spf
amazonses.com.          900     IN      TXT     "v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 ip4:69.169.224.0/20 ip4:23.249.208.0/20 ip4:23.251.224.0/19 ip4:76.223.176.0/20 -all"

なので結論エンベロープFromのSPFドメイン認証も通ります。

f:id:quoll00:20200916005955p:plain

ドキュメントでも多くのメール送信者にとってはこのレベルの認証で十分である、と言っています。

By default, messages that you send through Amazon SES use a subdomain of amazonses.com as the MAIL FROM domain. Sender Policy Framework (SPF) authentication successfully validates these messages because the default MAIL FROM domain matches the application that sent the email— in this case, Amazon SES.

While this level of authentication is sufficient for many senders,

ref: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/mail-from.html

そのためSESでは自ドメインSPFレコードを設定しなくても良いというエンジニアもいます。

しかしエンベロープFromとヘッダFromのドメインが一致しない場合DMARCに準拠しておらず、メール自体の信頼性は下がります。

メールヘッダーに含まれる From アドレスのドメインは、送信側メールサーバーが受信側メールサーバーに指定する MAIL FROM ドメインと合致する必要があります。

Amazon SES での DMARC への準拠 - Amazon Simple Email Service

特にキャリアメールはチェックが厳しいので、エンベロープFromとヘッダFromを一致させた方がメールの到達率が上がります

まとめ

SPFの仕組みを様々なケースで図を交えて説明しました。
次回はDKIMあたりを説明しようと思います。

参考