SPFレコードは正しく設定しよう~Webフォームの自動返信メールが届かない原因
はじめに
このところ、複数のお客様より「WebフォームからGmail宛てのメールが届かない」というお問い合わせがありました。
調べてみると、GmailのSPFチェックが厳しくなったようで、メールが届かない原因は、
- SPFレコードがない。
- SPFレコード情報が正しくない。
- メール送信時のエンベロープFromアドレス設定が正しくない。
ということです。
SPFについては、
「エンベロープFromアドレスのドメインについて、送信メールサーバーの情報を登録する」
というだけのシンプルなルールで特に難しくないように思いますが、特に、Webフォームからのメール送信は、うまくいかないことが多いようです。
ここでは、SPFのしくみと、Webサイトのフォームからのメールが届かない原因について、僕が思うことをまとめます。
SPFのしくみ
SPFのしくみとその設定方法については、既に多くの情報がありますが、以下のサイト・記事は、説明がわかりやすいと思います。
(参考)
・Gmailへのメール送信がエラーになって返ってくる現象でお困りのお客様へ – さくらインターネット
https://help.sakura.ad.jp/notification/n-2595/
・DNSに登録しよう – ウェブサイト制作会社のディレクター社長が思ったままに書くブログ
https://www.ni4.jp/2023/02/09-130100.html
今一度まとめると、こんな感じです。
1. SPFは、メール送受信において、送信者ドメインの正当性を検証するしくみ。
2. エンベロープFromアドレスのドメインのDNSで、SPFレコードに、送信メールサーバーの情報を登録する。
→「SPFレコードにないサーバーからメールが届いた場合、それはニセモノなので、スパムメール扱いしてください!」という宣言。
3. メール宛先の受信メールサーバー側で、SPF情報と送信メールサーバーの情報を比べて、スパムメールかどうか判断する。(SPFのチェックを行うか、チェックした結果でどうするかは、受信メールサーバーの設定による。)
4. 「送信メールサーバー」とは、受信メールサーバーにSMTP接続するサーバーのこと。メール送信時に他の送信メールサーバーを経由する場合は、経由する送信メールサーバー(メールリレーサーバー=SMTPサーバー)の情報を登録する。
これまでお客様にうかがった限り、2と4のところの理解が難しいのかな、という印象です。
- 「エンベロープFrom」アドレスを正しく設定していない。(「ヘッダFrom」は設定している。)
- SPFレコードの送信メールサーバー情報に抜けがある。
- フォームのメールがどのように送信されているか、把握できていない。
Webサイトのフォームからのメールが届かない原因
Webサイトのフォームからの自動送信メールが届かない原因としては、以下の3つがほとんどだと思われます。
- SPFに、Webサーバーの情報が登録されていない。
- SPFに、経由する送信メールリレーサーバーの情報が登録されていない。
- エンベロープFromアドレスを正しく設定していない。
1. SPFにWebサーバーの情報が登録されていない。
これは、ドメインのWebサーバーとメールサーバーが別のサーバーのときに起こりやすいです。
Webサーバーから直接メールを送信するのに、Webサーバーの情報がSPFレコードに存在しないのですから、受信メールサーバー側でのSPFのチェックでは当然NGとなります。
2. SPFに送信メールリレーサーバーの情報が登録されていない。
Webサーバー --> 外部メールサーバー --> 宛先の受信メールサーバー
例えば、WordPressサイトで、WP Mail SMTPプラグインなどを使用して、Gmailなどの外部のメールサーバー(SMTPサーバー)を経由して送信する場合、受信メールサーバーにとっての送信元メールサーバーは、その「外部のメールサーバー」となります。
その「外部のメールサーバー」の情報をSPFレコードに登録しましょう。
3. エンベロープFromアドレスを正しく設定していない。
WordPressサイトの場合、これが原因であることが非常に多いと思います。
送信元メールアドレスには、「エンベロープFrom (Return-Path)」と「ヘッダFrom」があります。
(参考)
・「エンベロープFrom」と「ヘッダFrom」の違いとは? – ベアメールブログ
https://baremail.jp/blog/2021/05/25/1377/
そして、SPFのしくみで参照されるのは、「エンベロープFrom」のドメインですので、メール送信時に「エンベロープFrom」を正しく設定する必要があります。
例えば、フォームで Contact Form 7プラグインを使用している場合、プラグイン設定画面で指定した「送信元アドレス」は、「ヘッダFrom」となります。
「エンベロープFrom」は、Webサーバー側のメール送信ソフトウェア(Postfixなど)により、設定されてしまいます。
(Xserverであれば、~@svxxxx.xserver.jp など)。
Contact Form 7プラグインで、「エンベロープFrom」を設定するには、以下の2つの方法があるようです。
- functions.php で、「エンベロープFrom」を設定する処理を追加する。
- WP SMTP Mailプラグインを使用して、「送信元アドレスを返信先 (return-path) として設定」を有効にする。
具体的な方法は、以下の記事などを参照してください。
(参考)
・Contactform7プラグインでReturn-Pathのメールアドレスを設定する – WEB系フリーランスBLOG えるぺぐ
https://lpeg.info/wordpress/contactform7_returnpath.html
・フォームからのメールが迷惑メール判定されたらWP Mail SMTPプラグインを試してみよう – LOLIPOP!
https://lolipop.jp/media/how-to-setup-wp-mail-smtp-plugin/
フォームでMW WP Formプラグインを使用している場合は、「Reply-to(メールアドレス)」だけではなく、「送信元(E-mailアドレス)」「Return-Path(メールアドレス)」を設定しましょう。
その他、アプリケーション実装でメールを送信する場合は、しっかり「エンベロープFrom」をセットしましょう。
おわりに
SPFのしくみと、Webサイトのフォームからのメールが届かない原因について、僕が思うことをまとめました。
くどいようですが、SPFについては、
「エンベロープFromアドレスのドメインについて、送信メールサーバーの情報を登録する」
というだけの話です。
メール送信設定や経路を正しく理解して、難しければサーバー管理者や詳しい人に確認して、正しくエンベロープFromアドレスとSPFレコードを設定しましょう。
また、僕は直接確認していませんが、ネット上には、
- SPFレコードにはホスト名ではなくIPアドレスの登録が必要。
- Gmail宛てのメールが届かないときは、SPFレコードに include:_spf.google.com を追加しよう。
というような、(すべてのケースに当てはまるわけではない)誤った情報もあるようですので、注意しましょう。
また、Webフォームからの自動送信メールは、メール受信サーバー側のSPFチェックの厳格化や、メール送信経路の問題、プラグインの不具合等により、いつの間にか届かなくなる場合がありますので、定期的にテストしましょう。
さらに個人的な意見をいえば、フォーム記入者への自動返信メールは、第三者によるなりすましでのスパムメール送信が可能ですので、あまり好ましくないと思っています。
フォーム記入者への自動返信メールは止めて、「数日以内に必ず返信する」旨のメッセージを表示して、迅速に対応することと、フォーム以外の問い合わせ経路を確保するのがよいのではないでしょうか。
(2023.12.26追記)
2023年秋ごろ、Googleから、Gmail宛てに送信する場合のガイドラインが発表されました。
詳しくは、Googleの公式サイトを参照してください。
・メール送信者のガイドライン ? Gmailヘルプ
https://support.google.com/mail/answer/81126?hl=ja
(2023.12.26追記ここまで)
補足
※この項は、2024.1.30に追記しました。
「SPFのしくみで参照されるのは、「エンベロープFrom」のドメインです」と書きましたが、厳密には違うようです。
RFC4408の日本語訳によれば、受信メールサーバー側のSPF検査については、以下のとおり記載されています。
少なくとも“MAIL FROM”アイデンティティを検査しなければならない(MUST)が、事前に“HELO”アイデンティティも検査することが推奨される(RECOMMENDED)
(出典)
・RFC4408 Page6 – 迷惑メール対策委員会
https://salt.iajapan.org/wpmu/anti_spam/admin/tech/rfc/rfc4408/page-6/
また、「“MAIL FROM”アイデンティティ」「“HELO”アイデンティティ」については、以下のとおり記載されています。
“MAIL FROM”アイデンティティは、SMTP MAILコマンド([RFC2821]を参照)に由来する。このコマンドはメッセージに“reverse-path”を提供する。
“HELO”アイデンティティは、SMTPのHELOコマンドまたはEHLOコマンドに由来する([RFC2821]を参照)。これらのコマンドはSMTPセッション中にSMTPクライアント(送信ホスト)に提供される。
(出典)
・RFC4408 Page5 – 迷惑メール対策委員会
https://salt.iajapan.org/wpmu/anti_spam/admin/tech/rfc/rfc4408/page-5/
「“MAIL FROM”アイデンティティ」は「エンベロープFrom」なので、SPFチェックで使用されるのはよいとして、「“HELO”アイデンティティ」を使用することもあり得る、ということですね。
「“HELO”アイデンティティ」はどんな値(文字列)かというと、MTA(メール転送エージェント)のソフトウェアによると思いますが、Postfixでしたら、smtp_helo_name パラメータで設定されている文字列です。
デフォルトでは、myhostname パラメータの値がそのまま設定されます。
もうひとつ、「エンベロープFrom (Return-Path)」と書きましたが、
Return-Path ヘッダは、受信側のメールサーバーが「“MAIL FROM”アイデンティティ(エンベロープ From)」を記述する、とのことです。
(参考)
・エンベロープ From と Return-Path と Errors-To と – CUSTOMERS MAIL CLOUD
https://blog.smtps.jp/entry/2018/04/18/112026
いろいろ勉強になりました。
(関連記事)
・Gmail メール送信者のガイドラインとPostfixの送信時TLS接続設定
https://inaba-serverdesign.jp/blog/20231222/postfix-sendmail-tlsencryption.html