フォームのメールが届かない。SPFやDMARCを足す前に確かめること

「届かない」が起きている段階を分ける

お問い合わせフォームから送られるメールには、2通あります。ひとつは会社の担当者宛に届く通知で、もうひとつは、問い合わせをした方に自動で返る受付の控えです。この2通は宛先も通る経路も違うので、片方だけ届かないということが起こります。

フォームのメールが届かないというご相談をいただいたとき、わたしたちが最初に伺うのは、どちらが届いていないのかという点です。担当者宛なのか、自動返信なのか、それとも両方なのか。ここが決まるだけで、見に行く場所が変わります。

さて、段階のほうも分けておきます。メールは、フォームのプログラムが送信の指示を出すところ、契約しているサーバーが外へ送り出すところ、相手のメールサーバーが受け取って振り分けるところを順に通っていきます。ところが、このどこで止まっても、送った側から見える症状は同じです。届かない、という一言になります。

なお、この記事が扱うのは送信する側から確かめられる範囲までで、相手の受信箱の中で何が起きたかには触れません。実際に1つずつ測って切り分けた記録のほうはお問い合わせフォームのメールが届かないとき、送信側で測れるのはどこまでかにまとめてありますので、症状がはっきりしている方はそちらが近いと思います。

ですから、原因を探しはじめる前に、届いていないのがどちらの1通なのかを確かめておくと、そのあとの手間がずいぶん変わります。

Gmailが全送信者に求めている水準

2024年2月から、Gmail宛のメールには送信する側の条件が課されるようになりました。この条件は2段階に分かれているのですが、そこが混ざったまま語られていることが多いように見えます。

Googleが公開している送信者ガイドライン（2026年7月29日に確認しました）では、次のように分かれています。

SPFというのは、そのドメインのメールをどのサーバーから送ってよいかを、DNSという住所録のような場所に書いておく仕組みです。DKIMは送るときに電子署名を付けておくもので、DMARCはその2つの判定に失敗したメールを受信側にどう扱ってほしいかを宣言するものなんですね。

ここで気をつけておきたいのは、お問い合わせフォームが1日に5,000件を超えることは、まずないという点です。つまりDMARCの設定も、Fromヘッダーのドメインを一致させることも、Gmailの公開している条件としては課されていません。ところが、届かないのはDMARCが無いからです、という説明はかなり広く出回っています。

一方で、GmailのFromヘッダーを騙らないことのほうは、件数に関係なくすべての送信者に課されています。自動返信の差出人欄に、問い合わせをした方が入力したGmailのアドレスをそのまま入れている作りは、ここに正面から当たります。

ですから、設定を足すかどうかを考えるより先に、自動返信の差出人欄に何が入っているかを見ておくほうが、順番としては前に来ます。

サーバー会社によっては、DNSに手が届かない

SPFやDMARCを設定しましょう、と書かれた記事はたくさんあります。ところが実際に管理画面を開くと、レコードを追加する項目そのものが見当たらない、ということがあります。

これは設定を見落としているわけではなく、DNSをどこで持っているかで決まります。ドメインのネームサーバーを、契約しているサーバー会社のものに向けている場合、レコードを1件ずつ編集することはできず、必要な設定は会社側で自動的に入る、という運用になっていることがあるんです。

わたしたち自身のサイトが、その形でした。id-techs.com のネームサーバーを引くと、契約しているサーバー会社のものが返ってきます。そしてSPFとDKIMとDMARCは自動で設定されると公式のドキュメントに書かれていて、そのかわり個別の編集はできません（2026年7月29日に確認しました）。

ですから、たとえばDMARCに認証結果のレポート宛先を足したいと思っても、DNSに1行書き足す作業では済みません。ネームサーバーごと別のところへ移すという判断が先に来ます。移せば編集できるようになりますが、メールの受信やほかのサービスの向き先も一緒についてくる話なので、フォーム1つのために決めるものではないように思います。

なお、自動で設定されているかどうかは、DNSを引いただけでは確かめきれないことがあります。DKIMのレコードは、セレクタと呼ばれる名前が分からないと引けないためです。確実なのは、実際に届いた1通のヘッダーを開いて、DKIM-Signatureという行があるかを見ることになります。

ですから、対策の中身を決めるより先に、自分のドメインのDNSがそもそも編集できる状態にあるかどうかを確かめておくと、実行できない手順を追いかけずに済みます。

問い合わせを失わない置き場所

ここまでは届けるための話でしたが、もうひとつ、届かなかったときに何が残るのかという問題があります。

多くのフォームは、メールを送る処理を終えた時点で送信完了の画面に切り替わります。この表示が根拠にしているのは、サーバーの配送プログラムがメールを受け付けたところまでで、相手の受信箱に入ったかどうかまでは見ていません。ですから、完了画面が出ていても届いていない、ということは起こりえます。

そのうえで、問い合わせの内容がメール1通にしか存在していないと、その1通が失われた時点で、問い合わせがあったこと自体が分からなくなります。送った方は完了画面を見ていますから、もう一度送ってはくれません。届かなかったことに、どちらも気づけないわけです。

対処としては、メールを送るのとは別に、フォームの内容をサーバー側にも控えておく形が考えられます。全件を残す場合は、氏名や連絡先を継続して保管することになりますので、保管する期間の決めごとと、プライバシーポリシーへの反映が必要になります。送信に失敗した回だけを記録しておく形なら、平常時は何も溜まりません。どちらにするかは、問い合わせの件数と、社内で誰が確認するかによって変わってきます。

そして、この先には届いたあとの話が続きます。問い合わせが来たことに誰がどう気づくのか、返信までにどれくらい置くのか、担当者が変わったときに窓口をどう引き継ぐのか。公開してからの運用をどう組むかについてはホームページは「公開してから」が本番。保守・運用がなぜ必要なのかのほうで扱っていますので、体制まで決める段階に入っている方は、そちらへ進んでいただくとよいと思います。