WEBフォームなどからのメールのヘッダFromはユーザのメールアドレスで大丈夫か？

最近のGmailのメール送信者のガイドラインの変更等もあり、ユーザ側の送信ドメイン認証の設定が強化された場合や、受信メールサーバで送信ドメイン認証の検証の強化が行われた場合に、WEBフォームなどのシステムから内部へのメールが届かない場合が発生するのではないかと想像している。

# この記事の主旨
「内部へのメールのヘッダFromのアドレスがユーザの入力したアドレスになっていないか？なっている場合、そのままで大丈夫な状況か？」確認しませんか？

# はじめに
これまでの経験上、WEBフォームから内部へのメールが届いていない状況に遭遇し、また、自分でもWEBフォームから内部へのメール送信を行うシステムを作成・管理しているので、気づいた点を書いた。

ユーザの入力メールアドレスをヘッダFromにして送信するメールに対する送信ドメイン認証は、意外と盲点となっているような気がしている。

# 前提
以下の2つの図のような、WEBサーバに問い合わせWEBフォームがあり、そこにユーザが記入した内容を元に、ユーザ向けに控えのメール・内部向けに問い合わせ内容がメールで届くという形を想定
![20231220-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354637/69d52f22-237f-8c39-4a46-d8ca067c85b6.png)
![20231220-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354637/d2c90843-5f09-b77c-0445-7943f2e7f042.png)

上記2つの、WEBサーバが直接メールを出す場合でも、APIを使って別サーバがメールを出す場合でも同じなので、以下は1つ目のWEBサーバが直接メールを送信する場合だけで記述します。

# メールのヘッダ
![20231220-3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354637/4787fb95-9061-cecd-437d-e1172eddf2d4.png)
上記図のように、ユーザ向けの控えと内部向けの問い合わせメールのヘッダは、以下になると想定します。
```:ユーザー向けの控え
EnvFrom: webmaster@www.example.com
From: support@example.com
To: user@example.jp
```

```:内部向けの問い合わせメール
EnvFrom: webmaster@www.example.com
From: user@example.jp     <- ユーザのメールアドレス
To: support@example.com
```
## 注意のヘッダ（内部向け問い合わせメールのヘッダFrom）
今回のポイントは、内部向けの問い合わせメールのヘッダFromがユーザが入力したユーザのメールアドレスになっていることです。これは、内部の受信者が対応するときに、単純に返信を行うだけで、ユーザのメールアドレスが宛先になるため、このような設定にしている場合も多いと考えています。

# 送信ドメイン認証でどうなるか？
## 控えのメールに対する送信ドメイン認証
適切な設定ならば、特に問題ない。

## 内部向けの問い合わせメールに対する送信ドメイン認証 
下記のような送信ドメイン認証(SPF,DKIM,DMARC)の設定をしていた場合は要注意と考えます。
```:ユーザ example.jp のDMARC設定
DMARC: p=reject; rua=postmaster@example.com
```
```:example.com のSPF,DMARC設定
SPF: ip4:(送信メールサーバのIP) ip4:(webserverのIP) -all
DKIM: (適切設定)
```

この場合、図の右下のメールサーバ（内部のメールサーバ）で送信ドメイン認証の検証を行うと、
```:送信ドメイン認証の検証結果
SPF: PASS
DKIM: PASS(example.com / 第三者署名)
DMARC: FAIL
```
SPF：webserverのIPは、EnvFrom のドメイン(example.com)のSPFに含まれるはず
DKIM：www.example.com ドメインexample.comでDKIM署名されているはず
DMARC：ヘッダFromのドメイン(example.jp) != EnvFromのドメイン(example.com)のため、SPFアライメント失敗。
ヘッダFromのドメイン(example.jp) != DKIM署名のドメイン(example.com)のため、DKIMアライメント失敗。
そのため、DMARCはFAIL
結果: ヘッダFrom のドメイン(example.jp)のDMARCのポリシーにより、**REJECT**

# DMARCの結果 = REJCET ということは
* 右下のメールサーバ（内部のメールサーバ）は、自社のフォームからのメールを拒否。
* 問い合わせ内容はどこへ？
* DMARC rua リポートが example.jp へ
![20231220-4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354637/cc6319d8-fba8-f177-b2d3-142242a66c27.png)

# 考察
* WEBサーバが、ユーザドメインのメールを転送しているのと、類似の状況？
* ユーザのドメイン(example.jp)からみると、DMARCレポートより、WEBサーバが迷惑メールを送っているのと、類似の状況？
* WEBサーバが直接ではなく、APIなどで外部メール送信サービスがメールを送信しても、ヘッダFromがユーザメールアドレスならば、同じ状況
* 右下のメールサーバ（内部のメールサーバ）が、Google Workspace や MS365 などでも、DMARCの検証を行うならば、同じ状況
* 右下のメールサーバ（内部のメールサーバ）が、プロバイダ等のサーバなどでも、DMARCの検証を行うならば、同じ状況
* 右下のメールサーバ（内部のメールサーバ）を自前サーバにした場合は、WEBサーバのIPをホワイトリスト等で許可すれば、問題は発生しない。（しかし、WEBサーバ変更毎に対応必要）
* WEBサーバ自身にメールを保存するようにする。（WEBサーバでメールサーバも動作させると同じ？・取得が一定間隔毎になる？）
* EnvFromのドメインをユーザのドメイン(example.jp)にした場合は、ユーザドメインのSPF設定に依存（-all ならば、同じ状況）
* WEBサーバで、ARCヘッダ付与で対応可能？
* ヘッダFrom をユーザのメールアドレスでなく、自社のドメイン(example.com)にする。（内部の受信者・システムでの対応が必須となりそう）

# まとめ
以下の条件がそろうと、メールが届かない場合が発生する可能性があると推測。
* WEBフォームなどからのメールのヘッダFromにユーザのメールアドレスを設定
* ユーザのドメインのDMARCのポリシーがreject
* WEBフォームなどからのメールを受信するメールサーバがDMARCの検証を実施し、ポリシー通りに処理

# 確認ポイント
「WEBフォームなどから内部へのメール届いているか？」
* WEBフォームの設置者
「内部へのメールのヘッダFromのアドレスがユーザの入力したアドレスになっていないか？なっている場合、そのままで大丈夫な状況か？」
- メールサーバ管理者・WEBフォームの設置者
「WEBフォームからのメールの経路を確認しなくて大丈夫か？」
- メールサーバ管理者
「送信ドメイン認証で拒否を行うサーバが、WEBフォームなどからのメールの経路に存在しているか？存在しても大丈夫な状況か？」

# おわりに
ご指摘等ありましたら、是非お願いいたします。