会員登録の確認メールやパスワード再設定のメールが「届かない」「迷惑メールフォルダに入っていた」とお客様から問い合わせが来る。しかも開発会社に聞くと「システムからは送信できています」と言われ、話が噛み合わない。メール送信のある業務システムやWebサービスでは、よくある困りごとです。
「システムから送る確認メールが届かない・迷惑メールに入ると言われた。何を確認すればいいのか」
先に結論をお伝えします。「送信できている」ことと「相手の受信箱に届く」ことは別の話で、後者には「送信ドメイン認証（＝このメールは本当にそのドメインの持ち主が送ったものだと、受け取る側が確かめるための仕組み）」の設定が深く関わります。発注者が見るべきは、プログラムではなく、①送信元のドメイン ②認証の設定 ③送信サービス ④届かなかった時の調べ方 ⑤誰が運用するか、の5つです。
この記事では、技術に詳しくない発注者の方が開発会社と話すために、チェックリストと質問例をまとめます。（2026年10月時点の一般的な内容です。各メール事業者の基準は変わることがあります。）
なぜ「送信できているのに届かない」が起きるのか
メールは郵便に似ています。開発会社のシステムが「ポストに投函した」状態を「送信できた」と呼んでいても、相手先（GmailやYahoo!メールなど）が「差出人を信用できない」と判断すれば、迷惑メールフォルダに入れたり、受け取りを断ったりします。
近年は、なりすましメール対策のために、受け取る側が送信元を確かめる動きが強まっています。特にGmailは、2024年2月から送信者向けのガイドラインを強化したことで知られています。
📰 出典：Google Workspace 管理者ヘルプ「メール送信者のガイドライン」
一般に、大量送信者（Gmail宛てに1日5,000通以上など）には、送信ドメイン認証（SPF・DKIM・DMARC）の設定や、迷惑メールの報告率を低く保つことなどが求められると説明されています。大量に送っていない場合でも、認証が整っていないメールは迷惑メール扱いになりやすいと言われます。正確な条件は、最新の公式ページでご確認ください。
発注者が開発会社に確認する5つのこと
1. 送信元のメールアドレスとドメインは誰のものか
「noreply@自社ドメイン」のように自社で管理するドメインから送るのか、開発会社や送信サービスのドメインを借りるのかで、信頼のされ方や、契約終了後の扱いが変わります。ドメインの名義・管理者が誰なのかも、あわせて確認しておきましょう。
2. SPF・DKIM・DMARCは設定されているか
3つとも送信ドメイン認証の仕組みです。名前を覚える必要はありません。「3つとも設定済みですか」と聞けば十分です。
| 名前 | 一言でいうと |
|---|---|
| SPF | このサーバーからの送信は正しい、と宣言する名簿 |
| DKIM | メールに電子的な署名を付け、改ざんされていないことを示す |
| DMARC | 認証に失敗したメールをどう扱ってほしいかを、受け取る側へ伝える |
設定は、ドメインを管理している場所（DNS＝ドメインの情報を登録する場所）で行います。発注者の会社がドメイン管理会社と契約している場合、開発会社が設定したくても、発注者側の操作や承認が必要になることがあります。ここで止まっていないかが、実は最大の落とし穴です。
3. どの送信サービスを使っているか（容量・料金・運用）
システムのサーバーから直接送るのではなく、メール配信用のサービス（AWSのAmazon SESなど）を使うのが一般的です。選択肢の候補を挙げると次のようになりますが、どれが一番かは用途次第です。
- 送信数や届けたい相手（個人のGmail中心か、企業宛てか）
- 月額費用と、送信数が増えた時の料金
- 送信が拒否された時の記録（ログ）を確認できるか
AWS上で使う場合の仕組みや費用の考え方は、AWSの月額費用の見積もりは高い？安い？発注者が見るべき内訳と開発会社への質問も参考になります。
4. 届かなかった時、原因をどう調べるのか
「届かない」と言われた時に、誰が・何を・どこまで調べられるかを決めておきます。
- 送信ログ（いつ・どの宛先に送ったか、相手先が受け取ったか断ったか）が残るか、何日分か
- 受信側のエラー（バウンス＝宛先不明や受信拒否で戻ってきた通知）を、システムが記録しているか
- お客様に「迷惑メールフォルダの確認」「受信拒否設定の確認」を案内する文面が用意されているか
5. 運用は誰が担当し、保守契約に含まれるか
認証の設定は、一度やれば終わりではありません。送信サービスの変更、ドメイン更新、サーバー移行のたびに見直しが必要になります。「届かない」問い合わせへの調査が、保守費用に含まれるのか、別料金なのかも事前に決めておきましょう。
やりがちな失敗
- 開発・テスト環境のメールだけ確認して本番を確認しない：テストでは自分たちのアドレスにしか送らないため、問題に気づけません。
- 社内メールアドレスだけで確認する：社内のメールサーバーは受信が緩く、届いて当然に見えます。GmailやYahoo!メールなど、お客様がよく使うサービスのアドレスでも試してください。
- 文面が原因なのに、設定だけ疑う：件名や本文に宣伝のような言い回しが多い、リンクが不自然に多いなどで迷惑メールに入ることもあります。
発注者がやることチェックリスト
- ☐ メールの送信元ドメインが自社管理か、名義が誰かを確認した
- ☐ SPF・DKIM・DMARCの設定状況を、開発会社に書面（メールなどでも可）で報告してもらった
- ☐ ドメインのDNS設定を、誰が操作・承認するかを決めた
- ☐ 本番環境から、GmailやYahoo!メールなど複数のアドレスへテスト送信して届き方を確認した
- ☐ 届かなかった時の調査担当・調査にかかる費用・連絡の流れを決めた
- ☐ 送信ログを何日分残すか確認した
開発会社への質問例
- 「システムからのメールは、SPF・DKIM・DMARCがすべて設定済みですか。設定内容を教えてください」
- 「送信元ドメインはどなたの名義で、DNSの設定は私たちと御社のどちらが行いますか」
- 「お客様から『メールが届かない』と連絡があった時、御社で何を調べて、どのくらいで回答いただけますか」
- 「メールの送信ログとエラーの記録は、何日分、どこで確認できますか」
- 「メール送信サービスを後から変更する場合、どんな作業と費用が発生しますか」
まとめ
- 「送信できている」は「受信箱に届く」とは別。受け取る側が送信元を信用できるかが鍵。
- 確認するのは、送信元ドメイン・SPF/DKIM/DMARC・送信サービス・調査の方法・運用の担当の5つ。
- 設定はドメインを管理する発注者側の協力が必要になることが多い。早めに窓口を決める。
メールの届き方は、公開後に問い合わせで初めて発覚しがちです。見積もりや要件定義の段階で「メール送信の設定と、届かない時の調査」を範囲に入れておくと、後からの追加費用や行き違いを減らせます。
あわせて読みたい関連記事
