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

この記事の主旨

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

はじめに

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

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

前提

以下の2つの図のような、WEBサーバに問い合わせWEBフォームがあり、そこにユーザが記入した内容を元に、ユーザ向けに控えのメール・内部向けに問い合わせ内容がメールで届くという形を想定

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

メールのヘッダ

上記図のように、ユーザ向けの控えと内部向けの問い合わせメールのヘッダは、以下になると想定します。

ユーザー向けの控え

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 へ

考察

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フォームなどからのメールの経路に存在しているか？存在しても大丈夫な状況か？」

おわりに

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

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