[SES入門] SPFを理解しよう！

# この記事について

皆さんはAWSのSESというサービスを利用していますか！？

コミュニケーションの手段として、EメールからSlackなどのツールが代替されてEメールはオワコンでは？ということも囁かれていますが、まだまだEメールは色々なところに使われており、滅びる気配がありません。アプリケーションやシステムにおいても、ユーザへの通知としてEメールを利用するケースが大半です！

AWSでは簡単に簡単にEメールを送信するためのサービスとしてSESと呼ばれるサービスが提供されています。

SESを利用する際、SPFという仕組みによってなりすましメールを防止します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/435280/c235200b-a49a-f979-e8a0-5007b2093c38.png)

本記事ではそのSPFについてSES初心者の人にもわかりやすく解説していきます！
SPFはSES固有の仕組みではなく、Eメールにおいて幅広く使われる仕組みでので、SPFについて理解したい人にもぴったりの記事だと思います！

# この記事の対象読者

- SESをこれから触る人、触り始めた人
- SPFについて理解していない人
- SPFについて復讐したい人

# Amazon SESとは

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/435280/e86f5332-8954-24a1-d776-2df1be8a9694.png)

Amazon SES（Simple Email Service）は、AWSが提供するEメール配信サービスです。SESを利用することで、ユーザは自前でメールサーバを構築/メンテナンスすることなくEメールの送信を行うことができるようになります。

AWSにてアプリケーション/システムを実装し、Eメール送信が要件にあるとすればまずSESの利用が検討されます。

# SPFについて

一言で表すと`なりすましメールを防止するための仕組み`です。

なりすましメールはスプーフィングメール(Spoofing email)とも呼ばれます。Eメールの送信元の情報を偽装して、あたかも他の送信元から送られてきたEメールのように見せかけます。なりすましメールはフィッシングサイトへの誘導、マルウェア/ウィルスの拡散、スパムメールなど悪意のある目的に利用されます。

よくあるケースはツールを利用してEメールの送信元メールアドレスを別のアドレスに書き換える方法です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/435280/01859090-849a-e1ee-7b1b-30a39bafd33e.png)

このようななりすましメールを防止するためのプロトコルがSPFです。
SPFはSES固有のものではなく、Eメールにおけるなりすましメール防止の標準的な仕組みです。

SPFはそれぞれ異なるメカニズムでなりすましメールを防止します。
それぞれについて説明します。

# MAIL FROMドメイン

SPFについて説明する前に、前提知識として理解が必要なMAIL FROMドメインについて説明します。

MAIL FROMドメインは`エンベロープfromのドメイン`を指します。

そもそもエンベロープとはなんでしょうか？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/435280/59b74264-c3f2-20a0-5b3d-6d0e4b840d2b.png)

Eメールを送信するとき、

```
送信者ー>メールサーバ->メールサーバ->受信者
```
と言う流れで配信されます。

メールサーバ間の通信に置いて、Eメール本体にエンベロープが付与されます。送信側メールサーバはこのエンベロープに書いてある宛先を元に受信側メールサーバに配信を行います。受信側メールサーバはエンベロープを取り除いて、受信者にメールを渡します。

そのためエンベロープは送信者/受信者から見えません。メールサーバのみが見ることができます。

- メール本体に書かれた宛先/送信元 =>  ヘッダーTo/ヘッダーFrom
- エンベロープに書かれた送信元 => エンベロープTo/エンベロープFrom

と呼ばれます。

メールのBCCの機能はこの仕組みを使っています。(BCCに指定した受信者のメールアドレスはヘッダーtoには含まれず、エンベロープtoだけに含まれる。こうすることで、受信者はBCCに指定されているメールアドレスを見ることができない）

では受信者はエンベロープFromを知ることができないのでしょうか？
答えばNoです。
受信側のメールサーバにてエンベロープFromをメールヘッダーのReturn-Pathとして記録します
そのため、受信メールのヘッダーからReturn-Pathを見れば、エンベロープFromがわかります。

Gmailでは受信したメールのオプションから「メッセージのソースを表示」をクリックすると、メールのソースを確認することができます。ソースの中にReturn-Pathが含まれているので、そこからエンベロープFromを確認することができます。

では一度整理します。

| 種別 | 説明 |
|:-:|:-:|
| ヘッダーFrom | 受信者が送信者を判断するメールアドレス  |
| エンベロープFrom | メールサーバが利用するメールアドレス  |
| MAIL FROMドメイン | エンベロープFromのメールアドレスのドメイン  |


# SPF

SPF(Sender Policy Framework)は`送信メールサーバのIPアドレスにより送信元が正常であることを認証する`ことにより、なりすましメールを防止します。

メールを送信する際、必ずメールサーバがメールを送信します。(SESなどのクラウドサービスを利用する場合でも、そのクラウドサービスプロバイダーが持つメールサーバが利用されます)

送信側のメールサーバのIPアドレス情報がメールに付与されます。

SPFでは受信側のメールサーバがEメールの送信元IPアドレスを確認して、それが正規のIPアドレスであるかを判断します。正規のIPアドレスである場合は認証成功とし、そうでない場合は認証失敗とします。(認証が失敗してもメールを受信できないわけではありません。ここでは深く説明しませんが、DMARC設定により認証失敗メールをどうするか制御することができます。)

ここで言う正規のIPアドレスとはEメールの`送信元メールアドレスのドメインにSPFレコードとして登録されているもの`を指します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/435280/60083fab-99ff-3b17-1cd8-3764367658de.png)

## SPFによる認証の流れ

SPFによる認証の流れは以下の通りです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/435280/c76fd4d7-ae8b-2f50-382b-f51d74797953.png)

前提として送信者はEメールの送信元であるドメイン(aaa@hoge.comが送信元であれば、hoge.com)にSPFレコードを登録されている必要があります。

それではSPFによる認証の流れを見ていきましょう。

### ①送信側メールサーバから受信側メールサーバにメールを送信する

Eメールの送信時に、送信側のメールサーバはメールヘッダーに自身のIPアドレスを書き込みます。

### ②受信側メールサーバがメールを受信して、DNSサーバにSPFレコードを問い合わせる

受信側メールサーバはメールを受信して、MAIL FROMドメイン※を確認します。そしてMAIL FROMドメインを管理するDNSサーバに対してSPFレコードを参照します。

MAIL FROMドメインについては本記事上部にて説明しております。

### ③DNSサーバがSPFレコードを返す

DNSサーバは自身のSPFレコードを受信側メールサーバに返却します。

### ④受信側メールサーバはメール送信元IPアドレスとSPFレコードのIPアドレスを比べる

受信側メールサーバはメールヘッダーのIPアドレスと返却されたSPFレコードのIPアドレスを比較します。
SPFレコード内のIPアドレスにメールヘッダーのIPアドレスが含まれていたら、SPF認証合格と判定します。

## なりすましメールを受信した場合

なりすましメールの送信者はヘッダーFromのメールアドレスを偽装して、なりすましメールを送信します。
受信側のメールサーバはMAIL FROMヘッダーを確認して、SPFレコードを参照します。
メールの送信元IPアドレスがSPFレコードにないことため、SPF認証失敗と判定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/435280/246c40e4-182a-a9bd-0de5-a458d1fdc9a1.png)

## SPFレコード

SPFレコードはTXTレコードとしてドメインに登録します。
以下のような形で登録されます

```
hoge.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ip4:192.0.2.3"
```

この例では192.0.2.1/192.0.2.2/192.0.2.3の３つのIPアドレスがSPFレコードに登録されています。

# SESにおけるSPF

SESではデフォルトの状態では、何もしなくてもSPF認証が合格するようになっています。

> Amazon SES から送信するメッセージには、MAIL FROM ドメインとして amazonses.com のサブドメインが自動的に使用されます。デフォルトの MAIL FROM ドメインがメールを送信するアプリケーション (この場合 Amazon SES) と一致するため、これらのメッセージは SPF (Sender Policy Framework) 認証に合格します。

[Amazon SES における SPF を使った E メールの認証
](https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-spf.html)

SESではカスタムMAIL FROMドメインという設定があります。
このカスタムMAIL FROMドメインにはメールのMAIL FROMドメインとして利用したドメインを設定することができます。カスタムMAIL FROMドメインを設定しない場合、デフォルトである「amazonses.com」というドメインがMAIL FROMドメインになります。

amazonses.comのドメインにはSPFレコードが登録されており、SESが利用するメールサーバのIPアドレスがSPFレコードに含まれているため、SPF認証に合格します。

実際にdigコマンドで調べてみると、複数のIPアドレスがSPFレコードに登録されていることがわかります。

```
❯ dig +short amazonses.com 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 ip4:52.82.172.0/22 ip4:54.240.64.0/19 ip4:54.240.96.0/19 ip4:76.223.128.0/19 -all"
"google-site-verification=aOJq8aXEtCO23r176f6iOTGt-RVuPv81XPtBuIzRTx0"
"mailru-verification: 71ab435de908d6ed"
```


カスタムMAIL FROMドメインを設定する場合は、どのドメインにSPFレコードを登録する必要があります。

DMARCに準拠するためにはヘッダーFromのドメインとMAIL FROMドメインが一致する必要があります。

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

[Amazon SES での DMARC への準拠 - Amazon Simple Email Service Classic](https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/send-email-authentication-dmarc.html#send-email-authentication-dmarc-spf)

DMARCについては別の記事にしようと思っていますが、SPFと同じようになりすましメールを防ぐための仕組みの１つです。
SPFだけでなく、DMARCなどと複数の仕組みを用いることでなりすましメールを高い精度で防げるようにするのが一般的です。

# 最後に

SPFについて、SES初心者の人でもわかりやすく説明させていただきました！
これを見て、SPFを理解して、SESをどんどん使い倒してください！

また、記事について何か分かりにくいとかコメントがあれば、ご指摘お待ちしています！

# 参考

[Amazon SES における SPF を使った E メールの認証
](https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-spf.html)[Using a custom MAIL FROM domain](https://docs.aws.amazon.com/ses/latest/dg/mail-from.html)
[Amazon SES での DMARC への準拠 - Amazon Simple Email Service Classic](https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/send-email-authentication-dmarc.html#send-email-authentication-dmarc-spf)
[SPF（Sender Policy Framework） : 迷惑メール対策委員会](https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/)
[「エンベロープFrom」と「ヘッダFrom」の違いとは？](https://baremail.jp/blog/2021/05/25/1377/)
[メールヘッダの一覧](https://atmarkit.itmedia.co.jp/fnetwork/rensai/netpro03/mail-header.html)
[なぜ送信元アドレスを変更できるの？ – ヘッダとエンベロープの違い –](https://www.y-ml.com/column/archives/2686)
[エンベロープ From と Return-Path と Errors-To と](https://blog.smtps.jp/entry/2018/04/18/112026)
[メールのソースを表示しメールヘッダーを確認する](https://www.howtonote.jp/gmail/sent/index13.html#google_vignette)