問い合わせフォームの​メールが​届かない​ときの​直し方。​SPF・DKIM・DMARCと、​差出人の​決め方

Gmailが、​送る​側に​求めている​こと

フォームの​メールが​届かない、と​聞いたら、​最初に​思い出してほしいのが​この​決まりです。
Gmailは​2024年2月1日から、​@gmail.com などの​個人用の​アカウントに​メールを​送る​送信者に、​次の​ことを​求めています​（⁠Gmail ヘルプ：メール送信者の​ガイドライン、​2026年10月4日確認）。

満たさない​メールは、​届かなかったり、​迷惑メールに​分類されたりする​ことが​ある、とされています。
Yahooも、​自社の​メールの​ドメインに​向けて、​同じ​時期に​同じ形の​要件を​出しています。
日本の​ Yahoo!メールとは​別の​会社です​（⁠Yahoo Sender Hub：Sender Best Practices、​2026年10月4日確認）。

問い合わせフォームの​通知の​数なら、​関係するのは​たいてい左の​列です。
左の​列でも、​SPF か​ DKIM の​どちらもない​送信は、​要件を​満たしていません。

SPF・DKIM・DMARCを、​ひとことで

3つとも、​ドメインの​設定に​ TXT という​種類の​記録を​足して​使います。

SPF の​最後の​ ~all は、​記録に​ない​サーバーから​来た​メールを​迷惑メールとして​扱うよう、​受け取る​側に​伝える​書き方です​（⁠Google Workspace 管理者ヘルプ：SPF を​設定する、​2026年10月4日確認）。
DMARC の​ p= には、​そのまま​届ける​ none、​迷惑メールに​入れる​ quarantine、​受け取らない​ reject の​どれかを​書きます​（⁠Google Workspace 管理者ヘルプ：DMARC を​設定する、​2026年10月4日確認）。
Googleは、​SPF と​ DKIM を​設定してから​48時間あけて​ DMARC を​入れるよう​書いています​（同じ​ページ）。

SPF で​気を​つけたい​決まりが​2つあります。
1つの​ドメインに​ SPF の​記録は​1つだけです。
メールの​送信サービスを​足すたびに​ v=spf1 から​始まる​行を​増やすと、​記録が​2つに​なり、​SPF の​判定​その​ものが​エラーに​なります​（⁠RFC 7208、​3.2節と​4.5節）。
足すときは、​いまある​1行の​中に​ include: を​書き足します。
もう​1つは、​include や​ a、​mx のように、​判定の​たびに​DNSを​引く​書き方は、​合わせて​10個までという​上限です​（同じ​RFCの​4.6.4節）。

フォームで​起きやすい​原因

送ってきた​人の​アドレスを、​差出人に​している

フォームの​通知を​「お客様から​届いた​メール」のように​見せたくて、​入力された​アドレスを​ From に​入れる​作りが​あります。
たとえば​入力が​ @gmail.com なら、​自社の​サーバーが​「gmail.com からの​メール」を​名乗って​送る​ことになります。
SPF も​ DKIM も、​gmail.com の​名前では​通りません。
Gmailは、​From に​ Gmail の​アドレスを​偽って​使う​ことを​はっきり​禁じていて、​DMARC の​検疫​（quarantine）を​当ては​めると​書いています​（メール送信者の​ガイドライン）。

直し方は、​差出人を​自社の​ドメインの​アドレスに​固定し、​入力された​アドレスを​返信先​（Reply-To）に​入れる​ことです。
受け取った​側で​「返信」を​押せば、​送ってきた​人に​返せます。

自社の​ドメインの​名前で、​別の​サーバーから​送っている

レンタルサーバーの​フォームや、​外部の​フォームの​サービスから、​自社の​ドメインの​アドレス​（info@ など）を​差出人にして​送っている​場合です。
その​サーバーが​自社の​ドメインの​ SPF に​入っていない、​その​サービス用の​ DKIM の​鍵を​置いていない、の​どちらかだと、​認証に​落ちます。
フォームの​設定画面と、​ドメインの​設定​（DNS）の​画面は、​たいてい別の​会社の​管理画面に​あるので、​片方だけ直して​終わりやすい所です。

サイトの​引っ越しで、​SPF の​意味が​変わる

これは​私たちの​ドメインで​実際に​手を​入れた​所です。
2026年9月に、​wwwなしの​ bundlyze.co.jp を​別の​置き場所へ​移す準備を​していて、​SPF の​記録に​ +a:bundlyze.co.jp という​指定が​入っている​ことに​気づきました。
これは​「bundlyze.co.jp の​サイトの​アドレス​（Aレコード）が​指すサーバーに、​メールの​送信を​許す」という​意味です。
サイトの​置き場所を​移すと、​移した​先の​サーバーが、​自動的に​メールを​送って​よい​相手に​なってしまいます。

当時は、​同じ​サーバーを​指す別の​指定が​ SPF に​すでに​入っていて、​その​1つを​消しても​送信には​困らない​ことを​確かめました。
そこで​9月14日、​サイトの​向き先を​変える​前に、​その​指定だけを​ SPF から​消しています。
順番を​逆に​すると、​短い​あいだでも、​他人の​サーバーに​送信を​許すことに​なるからです。
サイトの​作業でも、​SPF に​ a の​指定が​あるなら、​メールの​側に​影響が​出る​ことがあります。

届いた​メールの​ヘッダーで、​どこで​落ちたかを​見る

推測で​設定を​触る​前に、​実際に​届いた​1通を​見ます。
パソコンの​Gmailなら、​メールを​開いて、​返信アイコンの​横の​その​他アイコンから​「メッセージの​ソースを​表示」を​選ぶと、​ヘッダーの​全体が​出ます​（⁠Gmail ヘルプ：詳細ヘッダーから​メールの​経路を​確認する、​2026年10月4日確認）。

探すのは​ Authentication-Results という​行です。
受け取った​サーバーが、​認証の​結果を​書き込む欄として​決められています​（⁠RFC 8601）。
中身は​おおよそ次のような​形です。
ドメインは​例です。

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.co.jp;
  spf=pass smtp.mailfrom=bounce@mail.example.co.jp;
  dmarc=pass header.from=example.co.jp

Android の​ Gmail アプリでは、​メールの​詳細に​「送信元」と​「署名元」が​出ていれば​認証されていて、​差出人の​名前の​横に​疑問符が​出る​ものは​認証されていない、という​見分け方も​あります​（⁠Gmail ヘルプ：Gmail の​メールが​認証されているかどうかを​確認する、​2026年10月4日確認）。

確かめる​順番

私は、​次の​順で​見ていきます。

1. フォームから​1件送り、​通知が​受信箱・迷惑メールの​どちらに​入ったか、​そもそも​届いていないかを​分ける
2. 届いた​1通の​ヘッダーで、​spf・dkim・dmarc の​結果を​見る
3. From が、​送ってきた​人の​アドレスに​なっていないかを​見る。​なっていれば、​自社の​アドレスに​固定して​ Reply-To に​移す
4. フォームの​メールを​送っている​サーバーや​サービスを​確かめ、​その​名前が​ SPF の​1行に​入っているか、​DKIM の​鍵が​置かれているかを​見る
5. SPF の​記録が​1つだけか、​DNSを​引く​指定が​10個を​超えていないかを​見る
6. 通知の​送り先が、​迷惑メールを​自動で​消す設定や、​転送の​途中で​弾かれる​設定に​なっていないかを​見る

1で​「届いていない」なら、​ヘッダーは​見られません。
その​場合は、​フォームの​サービスや​サーバーの​送信の​記録​（ログ）から、​送れているのに​届いていないのか、​送る​前に​失敗しているのかを​見ます。

私たちの​フォームの​送り方

この​サイトの​問い合わせフォームは、​送信を​受けると、​メールの​送信サービスを​通して、​社内の​アドレスに​通知を​送ります。
差出人は​ noreply@bundlyze.co.jp に​固定していて、​入力された​アドレスは​返信先​（Reply-To）に​入れています。
返信先に​入る​値には、​改行などの​制御文字を​取り除いてから​使っています。
ヘッダーに​余計な​行を​差し込まれないためです。

自社の​ドメインの​名前で​送ると​決めたのは、​2026年7月20日です。
記録では、​その日、​送信サービスを​使う​ための​鍵が​まだ​設定されておらず、​フォームの​送り先が​エラーを​返す状態だったので、​いったん外部の​無料の​フォーム送信サービスに​切り替えました。
ただ、​問い合わせの​個人情報を​外部の​無料の​サービスに​通さないと​決めて、​4分後に​元に​戻しています。
送信サービスでは​自社の​ドメインの​確認が​6月に​済んでいたので、​自社の​ドメインの​名前で​送る​形に​しました。
差出人の​既定を​ noreply@ に​したのは、​その​2日後に​送信の​仕組みを​引っ越した​ときです。
制御文字を​取り除く​処理と、​次に​書く​記録の​仕組みは、​8月24日に​フォームを​作り直した​ときに​足しました。

10月4日に​ドメインの​設定を​引くと、​送信サービス用の​ DKIM の​公開鍵と、​送信サービスが​使う​送信用の​サブドメインの​ SPF が​置かれていました。
差出人の​ドメインで​ DKIM の​署名を​付ける​ための​準備です。
実際に​署名が​通っているかは、​届いた​通知の​ヘッダーで​確かめるのが​確実なので、​次に​問い合わせが​届いた​ときに​見るつもりです。

もう​1つ、​メールより​先に、​原則として​問い合わせの​中身を​記録に​残す作りに​しています。
メールの​側で​何か​あっても、​問い合わせ​その​ものは​消えません。

フォームが​止まっていないかを​日ごろ​見張る​方法は予約・問い合わせフォームが​止まっていないか、​見張る​方法に、​入力の​しやすさの​見直しは問い合わせフォームを​見直す​チェックリストに、​問い合わせが​減った​ときに​原因を​探す順番はホームページからの​問い合わせが​減った​ときに​書いています。

bundlyzeは、​大阪市北区の​グラングリーン大阪を​拠点に、​大阪・兵庫を​中心とした​関西の​会社からの​ご相談に​対応していて、​打ち合わせは​Web会議でも​対面でも​できます。
全国から​オンラインでも​ご相談いただけます。
この​記事を​書いた​津嘉山は、​業務システム開発と​AWSを​専門と​する​エンジニアで、​この​サイトの​問い合わせの​受け口を​自分で​作り、​ドメインの​引っ越しでは、​サイトの​向き先より​先に​ SPF を​自分で​書き直しました。

フォームから​1件送り、​届いた​メールの​ Authentication-Results の​行を​読んでみる​ところから​始めてください。