SPF・DKIMを設定したのにフォームのメールがGmailに届かない原因と確認手順｜DMARCアライメントの切り分けフロー

この記事のポイント

• 自動返信メールがGmailに届かない主因は、SPF・DKIMの未設定ではなく、Fromと認証ドメインの不一致（DMARCアライメント）である。
• Gmailの「メッセージのソースを表示」で spf=pass・dkim=pass・dmarc=fail の組み合わせが出たら、設定漏れではなくドメインのずれを疑う。
• 通知メール（自社宛）はFromの入力者アドレスと転送、自動返信（ユーザー宛）はアライメントと、原因が別物なので分けて診断する。
• 広告費をかけて得た問い合わせを守るには、メールだけに頼らず、サイト側の送信ログ保存とチャット通知を併用するのが確実である。

「SPFもDKIMも設定済みです」と制作会社やサーバー担当から聞いたのに、フォームの自動返信がGmailだけ届かない。広告で集めた問い合わせが静かに消えているかもしれない、という状況です。

ここで多くの方が前提にしている「設定したのだから認証は通っているはず」という理解が、実はずれています。認証が通っていることと、Gmailがそのメールを受け入れることは別の話で、間に入るのが DMARCアライメントです。この記事では、自動返信メール Gmail 届かない SPF DKIM 設定済み というケースに絞り、ヘッダーを読んで原因を1つに絞り、修正を依頼するところまでを扱います。

SPF・DKIMを設定済みなのにGmailへ届かないのはなぜ？

SPF・DKIMを設定済みなのにGmailへ届かない主因は、メールのFromに表示されるドメインと、SPFやDKIMが認証したドメインが一致していないこと（DMARCアライメントの不一致）です。認証そのものは passしていても、DMARCの判定で落ちると、Gmailは拒否や迷惑メール扱いに振ります。

結論：passしていても「ドメインが揃っていない」と落ちる

SPFは「送信元サーバーが許可されているか」を、DKIMは「署名が正しいか」を見ます。ただしDMARCは、その認証に使われたドメインが、受信者の目に見えるFromのドメインと揃っているかまで確認します。

たとえばFromは info@自社ドメイン なのに、実際の送信はレンタルサーバーの初期ドメインで行われ、SPFもそのドメインに対してpassしている。この場合、SPFは「passだがFromと別ドメイン」なので、DMARC上は不合格になります。DKIM側も、署名ドメインがサーバー側のものならFromとは揃いません。

海外では、splitforms のブログ記事「Why Your Contact Form Emails Go to Spam (2026 Fix)」などで、SPFもDKIMもPASSなのにDMARCだけFAILなら認証漏れではなくアライメント不一致と読む、という診断の型が紹介されています。日本語の解説は「設定したか」で止まることが多いため、この読み方を知っているだけで原因特定の速さが変わると考えます。

まず3分で確認：通知メールと自動返信のどちらが届かないか

最初にやるのは、どちらが届いていないかの確認です。

• 自社宛の通知メールが届かない：Fromの入力者アドレス、転送、受信側の拒否を疑う（第5章）
• 問い合わせた人宛の自動返信が届かない：アライメントを疑う（第2〜4章）
• 両方届かない：まず自動返信側の修正を先にして、様子を見る

自分のGmailアドレスでフォームから送信テストをすれば、自動返信の状態はその場で見られます。

何も変えていないのに急に届かなくなる背景（Gmailの要件強化の流れ）

Googleは「Gmail メール送信者のガイドライン」で、2024年からすべての送信者にSPFまたはDKIMを、大量送信者にはSPF・DKIM・DMARCの全てを求めています。さらにProofpointのブログでは、2025年11月から要件未達メールへの対応が段階的に強まり、一時エラー（4.7.x系）での遅延から、恒久エラー（5.7.x系）での拒否へ寄せていくと紹介されています（2026年時点の公開情報）。

つまり、設定を触っていなくても、以前は迷惑メール扱いで済んでいたものが、ある日から拒否に変わり得ます。日本でも同じ構造で起きるため、「昔から同じ設定」は安全の根拠になりません。

DMARCアライメントとは？SPF・DKIMのpassと何が違うのか

図1: DMARCアライメントの判定の仕組み

DMARCアライメントとは、ヘッダーFrom・Return-Path（エンベロープFrom）・DKIM署名ドメインの関係が揃っているかを見る仕組みです。DMARCは、SPFまたはDKIMのどちらか一方が「passかつFromと揃っている」ことを求めます。passだけでは足りず、揃っていることが条件です。

ヘッダーFromとReturn-Path（エンベロープFrom）の違い

ヘッダーFromは、受信者のメールソフトに表示される差出人です。Return-Pathは、配送の裏側で使われるエラー返送先で、SPFが検証するのはこちらのドメインになります。封筒の宛名と、封筒の裏に書いた差出人住所のような関係だと考えると分かりやすいです。

見た目のFromを自社ドメインにしても、Return-Pathが別ドメインならSPFのアライメントは崩れます。

レンタルサーバーで起きやすい「Return-Pathがサーバー初期ドメインのまま」問題

PHPのmail関数でそのまま送ると、Return-Pathにサーバーの初期ドメイン（xxxx.サーバー会社のドメイン のような形）が入る構成があります。エックスサーバー、さくらのレンタルサーバ、ロリポップのような国内のレンタルサーバーでも、設定や送信方法によって起こり得ます。ここでSPFは初期ドメインに対してpassするので、「SPFは通っている」という報告は嘘ではありません。ただしFromの自社ドメインとは揃っていない、というのが実態です。

Bluehost Help の「Gmail Now Enforces DMARC and SPF Alignment」でも、共有ホスティングの利用者向けにアライメントの考え方が明示されています。国内の公式ヘルプは、この言葉をほとんど使っていません。だからこそ、担当者の説明と実態が噛み合わなくなりやすい部分だと言えます。

DKIMの作成者署名と第三者署名の違い

DKIMには、自社ドメインで署名する作成者署名と、サーバー会社やサービス側のドメインで署名する第三者署名があります。第三者署名はdkim=passになりますが、署名ドメインがFromと違うためアライメントは取れません。

つまり dkim=pass の表示だけでは安心できず、「どのドメインで署名されたか」を見る必要があります。

届いたメールのヘッダーで原因を特定するやり方

ヘッダーを読んで原因を絞る

原因は、Gmailの「メッセージのソースを表示」にある Authentication-Results の3項目（spf・dkim・dmarc）を読めば、ほぼ1つに絞れます。推測で設定を触り回るより、実際に届いた1通を読むほうが早いです。

Gmailで「メッセージのソースを表示」を開く手順

1. フォームのテスト送信で、自分のGmailに自動返信を届ける
2. 届いたメールを開き、右上の三点メニューを押す
3. 「メッセージのソースを表示」を選ぶ
4. 上部の SPF・DKIM・DMARC の表示と、Authentication-Results: の行を見る

Google Admin Toolbox のメッセージヘッダー解析ツールに貼り付けると、配送経路の遅延も含めて読みやすくなります。ソース内の Return-Path: と From: のドメインが同じか、header.d= の署名ドメインがFromと同じかも、あわせて確認してください。

判定表：spf・dkim・dmarcの組み合わせ別に疑う場所

spf	dkim	dmarc	疑う場所
pass	pass	pass	認証は問題なし。迷惑メール判定や内容、通知側の転送を見る
pass	pass	fail	Fromと両方のドメインが不一致。FromをReturn-Path・署名ドメインに合わせる
pass	fail／なし	fail	Return-Pathが別ドメイン、かつ自社DKIM未有効。両方を直す
fail	pass	pass	DKIMが揃っているので通る。SPFの記載漏れを後で直す
fail	fail／なし	fail	送信元が許可されていない。SPFとDKIMの設定自体を確認
なし	なし	none／なし	認証情報が付いていない。送信経路が想定と違う可能性

この表で重要なのは、2行目の「pass・pass・fail」です。設定済みなのに届かない相談は、このパターンに当てはまることが多いと言われます。

そもそも届かずヘッダーが見られない時（別宛先へのテスト送信とエラーメール550-5.7.26の読み方）

完全に不達の場合は、Gmail以外のアドレス（独自ドメインのメールや別のフリーメール）にもテスト送信し、そちらでヘッダーを確認します。認証結果は宛先によらず近い値が出るので、診断に使えます。

エラーメール（バウンス）に 550-5.7.26 が含まれていたら、Gmailが「未認証、またはDMARCの方針により受け入れない」と判断した合図です。本文の説明文と、書かれているドメインを確認してください。送信側サーバーのメールログ（管理画面で見られる場合）にも同じ拒否が残ります。

自動返信メール（ユーザー宛）が届かない時の直し方

図2: 自動返信の修正は4ステップ

自動返信メールの修正は、From固定、Return-Pathの一致、DKIM作成者署名、DMARC公開の順に進めるのが最短です。上から順に直すと、どの時点で dmarc=pass になったかも分かります。

Fromを自社ドメインの実在アドレスに固定する

フォームの設定で、Fromに入力者のメールアドレスを入れている場合は、まずここを noreply@自社ドメイン や info@自社ドメイン に固定します。Contact Form 7 なら、メールタブの「送信元」を自社ドメインのアドレスにし、入力者アドレスは [your-email] を追加ヘッダーの Reply-To に入れます。

Return-Pathを自社ドメインに揃える（PHP mailの第5引数・SMTP送信への切り替え）

自作フォームでPHP mail関数を使っているなら、第5引数でエンベロープFromを指定できます。

mail($to, $subject, $body, $headers, "-fnoreply@example.com");

サーバーによってはこの指定が許されない場合があります。その場合は、SMTP送信に切り替えるのが確実です。WordPressなら WP Mail SMTP のようなプラグインで、自社ドメインのメールアカウントのSMTP情報を設定すると、Return-Pathも揃いやすくなります。

サーバーパネルでDKIMを有効化し、DMARCをp=noneで公開する

サーバーのコントロールパネルで、自社ドメインのDKIM署名を有効にします。画面の名称はサーバー会社ごとに違うので、「DKIM」「メール認証」の項目を探してください。次に、DNSに _dmarc のTXTレコードを追加します。

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none は「判定結果は集めるが、拒否や隔離は求めない」設定で、まず安全に公開できる形です。

DNSを外部で管理している場合の注意（レコードの入れ先が違う）

ドメインを別会社で管理していると、サーバーのパネルでDKIMをオンにしても、DNSにレコードが入らず署名が機能しません。パネルで表示されたレコードを、実際にDNSを管理している会社の画面へ追加します。この手間の違いは、サーバーとドメインを別会社で持つ場合のDNS設定の手間でも触れています。TXTレコードが反映されない場合は、DNSのTXTレコードが反映されない時の確認手順が参考になります。

通知メール（自社宛）が届かない時の原因は何が違う？

自社宛の通知メールが届かない原因は、Fromに入力者のアドレスを入れていること、サーバーからGmailへの自動転送でSPFが崩れること、Google Workspace側で拒否されていることの3つが中心です。自動返信と違い、アライメントの前に「送り方」を見ます。

Fromに入力者のアドレスを入れている（Reply-Toへ移す）

通知メールのFromに、問い合わせた人のGmailアドレスが入っていると、自社サーバーはGoogleの代理送信を許可されていないため、Gmailに拒否されやすくなります。Fromは自社ドメインに固定し、入力者のアドレスはReply-Toに移します。返信ボタンを押せば入力者宛になるので、運用上の不便は出ません。

サーバーのメールをGmailへ自動転送している場合にSPFが崩れる仕組み

通知を自社ドメインのメールボックスで受け、Gmailへ自動転送している場合、転送の時点で送信元サーバーのIPが変わります。そのため元の送信者のSPFは転送先では通らなくなり、DKIMが維持されていないと、DMARCもfailになります。転送をやめ、Gmailから直接受信設定をするか、通知先を直接Gmailアドレスに指定する方法を検討してください。

Google Workspaceなら管理コンソールのメールログ検索で確認する

受信側がGoogle Workspaceなら、管理者が管理コンソールの「メールログ検索」で、消えたメールの配送状況を追えます。Googleの Knowledge Center の「Troubleshoot Gmail not getting contact form messages」でも、原因はフォームではなく送信側の配送システムにあるとして、このログの確認が案内されています。拒否理由が見えるので、推測が要らなくなります。

直したあとの確認方法と、どこまでやれば十分か

テスト送信で届いて一安心

修正後の合格ラインは、複数の宛先で dmarc=pass を確認できることです。そこから先は小規模サイトでやりすぎない線引きを決めておくと、運用が軽くなります。

再テストの合格ライン：dmarc=passを3宛先で確認

Gmail、独自ドメインのメール、別のフリーメールの3宛先に送信し、Gmailでは「メッセージのソースを表示」で dmarc=pass を確認します。自動返信と通知の両方でやってください。

外部チェックツールの使いどころと限界（Postmaster Toolsは送信量が少ないと出ない）

mail-tester のような外部ツールは、送信設定の見落としを一括で拾うのに便利です。一方、Google Postmaster Tools は、SendLayer のブログでも触れられているとおり、一定の送信量がないとデータが出ません。フォームメール程度の量では、期待しすぎないほうが良いと考えます。

DMARCポリシーをnoneから強めるべきかの判断

フォーム送信だけのドメインなら、p=none のままでも要件は満たせます。メルマガなど他の送信元が混在しているうちは、quarantine や reject に上げると正規メールまで落とす恐れがあります。送信元を全て把握してから段階的に検討する、が無難です。

問い合わせを取りこぼさないための再発防止

再発防止の要点は、メール1本に依存しない受け皿を作ることと、定期的にテストすることです。広告費をかけて得た問い合わせが、メールの不達で機会損失になるのは避けたいところです。

送信内容をサイト側に保存する・チャットやシートにも通知する

フォームの送信内容をサイト側のデータベースに保存し、さらにチャットツールやスプレッドシートへ同時に通知しておけば、メールが落ちても問い合わせ自体は残ります。件数が合わない場合は、GA4でコンバージョンが計測されない時の原因切り分けで計測側も確認できます。

月1回のテスト送信をルーティンにする

月に1回、Gmailへテスト送信して dmarc=pass を確認する。この程度で十分です。サーバー変更やDNS変更の直後も同様に確認します。

制作会社・サーバー担当に渡す修正依頼チェックリスト

• Fromを自社ドメインの実在アドレスに固定する
• 入力者のアドレスはReply-Toに設定する
• Return-Pathを自社ドメインに揃える
• DKIMを自社ドメインの作成者署名で有効にする
• DMARCを p=none で公開する
• 修正後、Gmailでソースを表示し dmarc=pass のスクリーンショットを共有する

発注時に仕様へ含めておくと抜けにくくなります。広告成果を守るLP・サイト発注仕様書の作り方も参照してください。メールが届くようになったら、次は問い合わせフォームのCV率診断と改善の優先順位に進めます。スパムが多い場合はreCAPTCHAを入れてもスパムが止まらない時の切り分けが隣接する話題です。

よくある質問

Q：自動返信メールがGmailにだけ届かず、他のメールアドレスには届くのはなぜですか？

Gmailは送信者要件の適用が厳しく、認証やアライメントの不備が最初に表面化しやすいためです。他の受信側も同様の方向に追随する流れがあるので、今は届いている宛先でも、あとから落ちる可能性があります。

Q：お問い合わせフォームからのメールが、何も変更していないのに突然届かなくなったのはなぜですか？

受信側の要件強化が段階的に進んだためと考えられます。以前は遅延や迷惑メール扱いで済んでいたものが、拒否に変わることがあります。

Q：550-5.7.26というエラーメールが返ってきました。何を直せばよいですか？

未認証、またはDMARCで拒否された合図です。SPFかDKIMのpassと、Fromドメインとの一致を順に確認してください。

Q：SPFとDKIMは両方必要ですか？DMARCは1日5,000通未満でも設定した方がよいですか？

要件上、少量送信ならどちらか一方でも足ります。ただし、両方とDMARC（p=none）まで入れておくほうが、片方が崩れた時にも守られるため安全だと考えます。

Q：WP Mail SMTPなどのSMTPプラグインを入れれば解決しますか？

Return-Pathが揃いやすくなり、解決するケースは多いです。ただしFromが入力者のアドレスのままだと直りません。

Q：Fromに入力者のメールアドレスを入れないと、返信するときに不便ではありませんか？

Reply-Toに入力者のアドレスを入れれば、返信ボタンでそのまま返せます。Fromは自社ドメイン固定が前提です。

Q：共有IPのレンタルサーバーだと届きにくいですか？専有IPに変えるべきですか？

まず認証とアライメントを直すのが先です。IPの評判が原因と切り分けられてから検討する順番で十分です。詳細はサーバーのIPアドレスの共有と専有の違いをご覧ください。

Q：迷惑メールフォルダに入る場合と、まったく届かない場合で原因は違いますか？

迷惑メール入りはヘッダーが読めるので診断しやすいです。完全不達は拒否の可能性が高く、送信側のログとエラーメールを見る必要があります。

SPF・DKIMの設定とフォームのメールが噛み合わない問題は、制作会社とサーバー担当の間で責任の所在が曖昧になりがちです。真策堂ではこうした観点で、ヘッダーの読み取りから修正依頼の整理まで、ご相談を受けています。