問い合わせフォームを実装して、テスト送信も通った。なのに「お客様からの通知が来ていない気がする」と相談が来る。調べると、フォーム自体は正しく動いていて、送られたメールが迷惑メールに振り分けられていた、あるいはそもそも受信側に弾かれていた、というケースが少なくありません。

フォームは、動いても届かなければ意味がありません。原因の多くはコードではなく、送信ドメイン認証（SPF・DKIM・DMARC）の設定不足にあります。この記事では3つの役割を噛み砕きつつ、どこを直せば受信箱に届くようになるのかを、私自身のフォーム構成を例に整理します。

通知メールが届かない理由とSPF・DKIM・DMARCの位置づけを示す図

なぜ「動いているのに届かない」が起きるのか

メールの世界では、差出人アドレスは簡単に詐称できます。そのため受信側（GmailやYahoo!メールなど）は、「本当にそのドメインが出したメールか」を認証情報で判定し、怪しければ迷惑メール送りにするか、受け取りを拒否します。

フォームからの通知メールが届かない典型パターンは、だいたいこの3つに集約されます。

  • 送信元サーバーがそのドメインの許可リストに載っていない（SPF未設定・不備）
  • 電子署名がなく、本物である証明ができていない（DKIM未設定）
  • 差出人アドレスのドメインと、認証に使うドメインがバラバラ

どれも「メールの中身」ではなく「送信元の身元」の問題です。文面をどう工夫しても、身元が証明できていなければ配信は安定しません。

SPF・DKIM・DMARCそれぞれの役割

3つはよく並べて語られますが、担当する仕事は別々です。用語だけ見ると難しく感じますが、役割で捉えると整理しやすくなります。

SPF・DKIM・DMARCそれぞれの役割を示す図
  • SPF（Sender Policy Framework）… そのドメインのメールを「どのサーバーから送ってよいか」を宣言する仕組み。許可リストのようなものです。
  • DKIM（DomainKeys Identified Mail）… メールに電子署名を付け、途中で改ざんされていないこと・本物のドメインから出たことを受信側が検証できるようにする仕組み。
  • DMARC（Domain-based Message Authentication）… SPFやDKIMの検証に失敗したメールをどう扱うか（何もしない／隔離／拒否）の方針をドメイン所有者が宣言する仕組み。なりすまし対策の総仕上げにあたります。

設定場所はいずれもドメインのDNSです。プログラムを書き換えるのではなく、DNSにレコードを追加する作業になります。ここが盲点で、フォームのコードをいくら見直しても直らない理由でもあります。

Gmail・Yahoo!の送信者ガイドラインという後押し

近年、GmailやYahoo!の送信者向けガイドラインで、ドメイン認証の要件が明確化されました。Googleの公式ガイドラインでは、Gmail宛てに送るすべての送信者に対し、SPFまたはDKIMのいずれかの設定が求められています。さらに1日あたり5,000通を超える「大量送信者」には、SPFとDKIMの両方に加えてDMARCの設定が必要とされています。

問い合わせ通知のような少量のメールでも、認証が整っていないと迷惑メール判定を受けやすくなる、という実感があります。件数の閾値や強制の細かな条件は運用側の裁量もあるため断定はしませんが、「最低限SPFかDKIM、できれば両方＋DMARC」を整えておくのが、届くための現実的な下準備だと考えています。

実務でどう直すか — 自作フォームの構成を例に

私のサイトの問い合わせフォームは、Cloudflare上で動くサーバーレス構成で、送信成功時に担当への通知メールと自動返信メールの2通を送り、あわせてChatworkのルームにも通知を飛ばしています。メール送信はGmailのAPI経由でおこなっているため、送信元は素性のはっきりしたドメインに寄せられ、認証を通しやすい構成になっています。

届く／届かないの分かれ目は、設定側にあります。実務で確認・修正するのは次のような点です。

届かない設定と届く設定を比較した図
  • SPFにメール送信サービスを追記する。フォームがどこ経由でメールを出すかによって、許可すべき送信元は変わります。
  • DKIM署名を有効化する。送信サービス側で鍵を発行し、指定されたレコードをDNSに登録します。
  • 差出人（From）のドメインを、認証に使うドメインと一致させる。ここがズレていると、SPFやDKIMが通っていてもDMARCの整合性で弾かれます。
  • DMARCレコードを宣言する。まずは方針を「none」にしてレポートを受け取り、様子を見ながら段階的に強めていくのが安全です。

フォームのコードを書くのと、届くように送信ドメインを整えるのは、別の作業です。両方を最初から見込んで設計しておくと、公開後に「通知が来ない」と慌てずに済みます。この領域は、サーバーレスなフォーム＋メール送信の実装や問い合わせフォームのスパム対策と地続きで、まとめて面倒な実装の外注として引き受けることも多い部分です。

まとめ — 「送れた」ではなく「届いた」を確認する

フォーム実装のゴールは、送信ボタンが動くことではなく、問い合わせが確実に受信箱まで届くことです。そのためには、コードだけでなく送信ドメイン認証まで含めて設計する必要があります。

  • 「動いているのに届かない」の多くは、SPF・DKIM・DMARCの不足が原因
  • 3つの設定場所はDNS。フォームのコードとは別作業
  • 差出人ドメインと認証ドメインの一致がDMARC整合の鍵

すでにフォームがあるのに通知が届かない、これから作るので最初から届く形にしたい。そうしたご相談は、お問い合わせフォームからお気軽にどうぞ。実装から送信ドメインの設計まで、まとめてお引き受けします。

本記事は2026年7月時点の情報です。GmailやYahoo!の送信者ガイドラインの具体的な要件は変更される場合があるため、実装時は各社の最新の公式情報をご確認ください。