問い合わせformのmailはFrom addressだけで判断せずSPFとDKIMの管理者を確認する

問い合わせformのmailが届かないときは、WordPressやform pluginの送信結果だけで原因を決めません。画面に表示する差出人address、実際にmailを送るserver、差出人domainのDNS、受信側の判定は別の段階です。自社domainを差出人に使うなら、どのserverがそのdomainを使って送信してよいかをSPFで確認し、DKIMの署名と公開鍵を誰が管理するかも確認します。

利用者がformを送った直後に完了画面が表示されても、事業側の受信boxへ通知が届くとは限りません。反対に、mailが届いたとしても、送信元domainの設定が将来も正しく維持されるとは限りません。問い合わせを受けるためのmailは、見た目のFrom address、送信経路、domainのDNS、受信確認を一つの設定として扱わず、担当と所有者を決めます。

RFC 7208は、SPFを、domainの管理者がMAIL FROMまたはHELOのidentityにdomain名を使うことを許可するhostをDNSで示す仕組みとして定義しています。RFC 6376は、DKIMの署名を検証するための公開鍵をDNSから取得する仕組みを定めています。どちらも「mailが必ず届く」設定ではありません。送信に使うdomainとserverについて、受信側が確認できる情報を用意するための仕組みです。

From addressと実際の送信serverは別に見る

formの設定画面では、Fromへinfo@example.jpのようなaddressを入れられます。しかし、そのaddressを表示しただけで、web serverや外部mail serviceがexample.jpの送信を許可されるわけではありません。問い合わせ内容をweb serverのmail機能から送るのか、SMTP serverへ渡すのか、外部の配信serviceを使うのかで、確認する場所が変わります。

説明用の仮例として、formの通知をcontact@example.jpからstaff@example.jpへ送る場合を考えます。WordPressがweb serverのmail機能で送るのか、contact@example.jpのmail serviceへSMTP接続して送るのかを確かめます。送信経路が変われば、SPFへ含めるべきhostも、DKIM署名を付ける側も変わります。form pluginの画面だけを見ても、この経路は分かりません。

利用者がformへ入力したemail addressを、そのままFromへ入れる設計も慎重に扱います。受信した担当者が利用者へ返信しやすいように見えても、自社domainではないaddressを自社serverから差出人として送ることになります。問い合わせを受けるためのaddressと、返信先を示すaddressを分けられるなら、どちらの役割なのかを明確にして設定します。実際に使うheaderの組み合わせは、利用するformやmail serviceの仕様で確認します。

SPFは送信に使うdomainとhostの一覧を確かめる

SPFでは、domainの管理者がDNS recordで、どのhostがそのdomainをMAIL FROMまたはHELOとして使えるかを示します。domainのweb siteを制作会社が管理し、mailを別の事業者が管理している場合、web serverを変えただけでSPFの許可範囲が古くなることがあります。反対に、使わなくなったmail serviceをいつまでも許可したままにすると、どの経路が正規なのか分かりにくくなります。

SPFを確認するときは、recordの文字列だけを保存して終わりにしません。どのmail service、web server、予約system、newsletter serviceが、自社domainを使って送信するかを書き出します。次に、それぞれが現在も使われているか、設定を変更できるaccountを誰が持つかを確認します。DNSの設定を一つにまとめることと、送信経路を一つにすることは別です。複数のserviceを使うなら、それぞれの目的と送信domainを説明できるようにします。

新しいformを公開するとき、test mailが一度届いたからSPFの確認を省かない方がよいでしょう。testは、指定した受信boxでmailを見つけられるかを確かめる作業です。SPFは、送信経路が差出人domainを使う許可を持つかを確認する作業です。確認する対象が違います。server移転、mail service変更、domain移管のたびに、同じ差出人domainを使う送信経路を見直します。

DKIMは署名と公開鍵の組を管理する

DKIMでは、送信側がmailへ署名を付け、受信側がDNSから公開鍵を取得して検証します。RFC 6376では、署名に含まれるdomainが、その公開鍵を公開するDNS名に対応することを定めています。ここで重要なのは、DNSのTXT recordだけを追加しても、送信側が対応する署名を付けなければ検証できないことです。反対に、送信serviceが署名を付けても、公開鍵が正しく公開されていなければ受信側は確認できません。

問い合わせformの通知でDKIMを使う場合は、どのserviceが署名を付けるかを確認します。web serverが直接送信するのか、SMTP serviceが送信時に署名するのか、外部のmail serviceが署名するのかで、鍵の作成とDNSへの登録を担当する相手が違います。selectorと呼ばれる識別子を含むDKIM recordを複数持つ場合も、どれがどのserviceの鍵かを記録します。鍵を更新したとき、古い設定をいつ外すかも決めます。

DKIMの検証結果だけで、問い合わせmailの内容が正しい、受信者が読んだ、迷惑mailへ入らないとは言えません。署名は、送信domainに関連する鍵で検証できるかを確認する材料です。宛先address、受信boxのrule、mail本文、添付file、送信量、serverのerrorなどは別に確認します。技術的な認証と、問い合わせへ実際に対応できる状態を一つの成功として扱いません。

domainとDNSを誰が確認できるかを残す

SPFとDKIMはDNSを使います。そのため、WordPressの管理者権限だけを持っていても、必要な変更を確認できないことがあります。domainを取得したaccount、DNS recordを管理するservice、mail service、web server、form pluginの管理者が別々なら、誰がどこを変更できるかを一覧にします。外部へ制作や運用を頼んでも、domainとDNSの所有情報まで渡したことにはなりません。

問い合わせmailに問題が出たとき、最初にformを作り直すより、次の順で経路を確かめます。

1. formからtest mailを送り、完了画面、送信日時、宛先、返信先を記録する。
2. 実際のmail headerを確認し、From、Reply-To、送信に関わったserver、DKIM signatureの有無を分けて見る。
3. 差出人domainのSPF recordと、現在送信に使うhostまたはserviceを照合する。
4. DKIMの署名を付けるserviceと、DNSにある公開鍵のrecordを対応させる。
5. 受信boxと迷惑mailを確認し、受ける担当者が対応できることまでtestする。

この順序は、SPFやDKIMを急いで追加するためのものではありません。現在の送信経路とdomainの管理者を取り違えないための確認です。最初の一手は、問い合わせformから一通testを送り、差出人domain、送信service、返信先、DNSを管理するaccountの四つを書くことです。