問い合わせフォームのメール到達性の知識マップ(知識グラフ)
問い合わせフォームの通知メール
問い合わせフォームの送信を受けて、サイト側システムが担当者へ送る通知メール。利用者本人がMUAから送っているのではなく、サイト側が作成する点が設計上の前提になる。
フォーム通知メール
DMARCのアラインメント
DMARCの判定基準。SPFやDKIMで認証されたドメインが、From:ヘッダのドメインと整合しているかどうかを表す。
Fromヘッダ
メッセージの作者を表す本文ヘッダ。RFC 5322は作者のものでないアドレスをFrom:に入れるべきではないと定める。
Reply-Toヘッダ
返信先を作者とは別にしたいときに使う本文ヘッダ。
DMARC
SPFやDKIMの成否だけでなく、それらの認証済みドメインがFrom:ドメインと整合しているかを見て、受信メールの扱いを判定する仕組み。
Domain-based Message Authentication, Reporting, and Conformance
SPF(Sender Policy Framework)
SMTPセッション中のMAIL FROM(エンベロープ送信者)が、そのドメインの送信元として許可されたIPかをDNSのTXTレコードで検証する仕組み。
DKIM(DomainKeys Identified Mail)
メッセージの一部ヘッダと本文に署名を付け、受信側がDNSの公開鍵で検証する認証方式。署名ドメインはDKIM-Signatureのd=で表される。
利用者アドレスをFromに使う設計
問い合わせフォームで、フォーム利用者のメールアドレスをそのままFrom:に入れてしまう設計。認証済みドメインとFrom:ドメインが食い違う典型的な失敗パターン。
Fromなりすまし設計
DMARCの失敗(dmarc=fail)
DMARCのアラインメント判定が通らず、受信側でメールが隔離・拒否・警告扱いになりうる状態。
メール転送によるSPF失敗
メール転送で最終受信者から見た送信元IPが、元の送信ドメインのSPFに載っていない中継サーバーになりやすく、正当なメールでもSPFが失敗する現象。
転送によるSPF破損
Return-Path(エンベロープ送信者)
SMTPのエンベロープで渡す配送用の差出人。最終配送時にはこの逆経路がReturn-Pathとして1つだけ残されるべきで、送信側が最初からReturn-Pathヘッダを持ったメッセージを作るべきではない。
エンベロープ送信者
PHPのmail()関数
PHPの標準的なメール送信関数。Fromヘッダが必要で、追加パラメータでsendmail -f相当のエンベロープ送信者指定ができる。
メールヘッダインジェクション
外部入力に含まれるCR/LFをサニタイズせずヘッダへ組み込むと、攻撃者がBcc:などの追加ヘッダを差し込めてしまう脆弱性。
CRLFインジェクション
共有ホスティングのローカルMTA
共有ホスティングが提供するローカルの送信基盤。送信IPのPTR未設定、共有IPの評判悪化、DKIM未対応などで到達率が落ちやすい。
共有IPの送信基盤
PTRレコード(逆引き)
送信元IPアドレスからホスト名を引くための逆引きDNSレコード。受信側のレピュテーション判定に使われる。
逆引きDNS
SendGridのDomain Authentication
SendGridで送信ドメインを認証する設定。Automated SecurityをONにするとCNAMEベースでDKIMなどの認証レコードが生成される。
DKIMセレクタ
DKIMの公開鍵をselector._domainkey.example.comのように引くための識別子。鍵ローテーションのために使われ、複数の公開鍵を同じドメインに共存させられる。
Amazon SESのカスタムMAIL FROM
Amazon SESで、既定のamazonses.comサブドメインではなく自ドメイン配下のMAIL FROMを設定し、サイトドメインとのSPFアラインメントを取る機能。
Mailgunの送信ドメイン検証
Mailgunで送信ドメインを検証する設定。SPF用TXTとDKIM用TXT、MXレコードの追加が必要になる。
DMARCポリシーモード
DMARCのp=で指定するポリシー。noneは監視のみ、quarantineは隔離推奨、rejectはSMTP中の拒否推奨を意味する。
Authentication-Resultsヘッダ
受信側MTAがSPF・DKIM・DMARCなど認証結果を記録する内部ヘッダ。生ヘッダを確認することで不達原因を切り分けられる。
Senderヘッダ
実際にメッセージを送出した主体を表す本文ヘッダ。作者と送信主体が同じなら使うべきではない。
返信先を利用者へ向けたいだけならReply-To:で十分で、これにより返信のしやすさを確保しつつFromは自ドメインに固定できる
DMARCのアラインメント判定は、From:ヘッダのドメインとSPF/DKIMで認証されたドメインを突き合わせて行うため、判定の起点としてFrom:ヘッダを前提とする
DMARCはSPFの認証結果とFrom:ドメインのアラインメントを判定材料の1つとして使う
DMARCはDKIMの認証結果とFrom:ドメインのアラインメントも判定材料として使う
DMARCの合否は、SPF/DKIMが個別にpassするかだけでなく、認証済みドメインがFrom:ドメインとアラインしているかで決まる
フォーム利用者のアドレスをそのままFrom:に入れると、認証されるのはサイト側ドメインなのにFrom:は別ドメインというズレが起き、DMARCのアラインメントに失敗する
転送で送信元IPがSPFに載っていない中継サーバーになりSPFが失敗すると、DKIMがない場合はDMARCも失敗する
DKIMは本文や署名対象ヘッダーが変わらない限り転送後も生き残りやすいため、転送でSPFが壊れてもDMARCの判定を救い、DMARC失敗を軽減する
SPFは主にSMTPセッション中のMAIL FROM、最終的にReturn-Pathとして残る差出人を検証する
送信にPHPのmail()を使う場合、Return-Path:ヘッダを自分で書くのではなく、sendmail -f相当の追加パラメータでエンベロープ送信者を指定する
フォーム入力をサニタイズせずヘッダへ差し込むと、CR/LFを含む値からBcc:などの追加ヘッダを注入できてしまう
共有ホスティングのローカルMTAは送信IPのPTR未設定や共有IPの評判悪化、DKIM未対応などにより到達率が落ちることがある
共有ホスティングでは送信IPのPTR(逆引き)が正しく設定されているかを確認することが到達率改善の基本になる
SendGridのDomain AuthenticationはCNAMEでDKIMセレクタを委譲する仕組みで実現される
Amazon SESでサイトドメインとのSPFアラインメントを取るには、既定のamazonses.comではなくカスタムMAIL FROM用のドメインを設定する
Mailgunの送信ドメイン検証では、SPF用TXTとセレクタ付きDKIM用TXT、MXレコードの設定が必要になる
DMARCはp=none(観測)・quarantine(隔離)・reject(拒否)というポリシーモードで構成する
DMARCのアラインメントが取れているかは、受信メールのAuthentication-Resultsヘッダでspf/dkim/dmarcの合否を確認することで判定できる
作者(From)と実送信主体が同じ場合、Sender:ヘッダは通常不要で、問い合わせフォームの通知メールでは常用すべきではない
フォーム利用者のメールアドレスをFrom:にそのまま使う設計は、問い合わせフォーム通知では推奨されない非推奨パターンである
DKIMの公開鍵はselector._domainkey.example.comのようにセレクタで引かれ、セレクタは鍵ローテーションのために使われ複数の公開鍵を同じドメインに共存させられる