概要

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

さらに細かく説明すると

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

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

事前知識

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

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

From	役割
エンベロープFrom	バウンスを処理する場合などに使われるシステムが利用するアドレス SMTPのMAIL FROMコマンドで指定されるreverse-path メールボックスに受信すると`Return-Path`ヘッダとして挿入される
ヘッダFrom	メールクライアントでFromとして表示される人間が利用するアドレス

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

Gmailでパッと確認したいときはメールの詳細部分を表示すると良いです。

SPF, DKIM, DMARC

SPF (Sender Policy Framework)

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

DKIM (DomainKeys Identified Mail)

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

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

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

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

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

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

SPFの検証フロー

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

説明すると

ドメイン所有者があらかじめSPFレコード（実際はTXTレコード）を設定
MAIL FROMコマンドで設定されたアドレス（＝エンベロープFrom）からドメインを取得
そのドメインのSPFレコードを取得
SPFレコードに送信サーバのアドレスが含まれているか確認

となります。

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

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

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

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

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

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

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

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

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

になるイメージです。

具体的に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.orgやspf2.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を設定しないとMAIL FROMはxxxxx@amazonses.comになります。
MAIL FROMはメールボックス受信後Return-Pathヘッダとして挿入されるため、メールのソースを見ると以下のように表示されます。

なので

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

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

amazonses.comはAWSが所有するドメインなので、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 ドメイン認証も通ります。

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

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で使うSPFアラインメントに準拠しておらず、メール自体の信頼性は下がります。