メール送信サービスを乗り換えたら通知メールが届かない？迷惑メール扱いを防ぐために発注者が確認したい6つの準備

2026年10月6日2026年10月11日

会員向けの通知メールや注文確認メールを送るシステムで、メール送信サービスを乗り換える。技術的には「設定を切り替えるだけ」と言われることが多い作業ですが、切り替えた翌日から「メールが届かない」「迷惑メールに入っている」という問い合わせが来ることがあります。

「システムのメール送信サービスを乗り換えるとき、迷惑メール扱いにならないよう何を準備すればいいのか分からない」

先に結論をお伝えします。迷惑メール扱いを防ぐ鍵は、乗り換えの「前」にあります。具体的には、①今どのメールをどこから送っているかの棚卸し、②送信元ドメインの認証設定（SPF・DKIM・DMARC）の移行計画、③切り替え後の到達確認と戻し方の取り決め、の3つを、開発会社と事前に決めておくことです。

この記事では、メール送信サービスの乗り換えを検討している発注者向けに、乗り換えで起きやすい問題、準備する6つのこと、そのまま使えるチェックリストと開発会社への質問例をまとめます。（執筆時点：2026年10月）

なぜ乗り換えたのに届かなくなることがあるのか

まず、システムが送るメールは、会社の普通のメールとは別の「送り方」をしていることを押さえておきましょう。

システムから自動で送るメール（会員登録の確認、パスワード再設定、注文確認、請求通知など）は、メール送信専用のサービスを経由して送られることが多くあります。このサービスを乗り換えると、メールを実際に送り出す「経路」が変わります。

受け取る側のメールサービス（Gmail・Yahoo!メール・各社の法人メールなど）は、「このメールは本当に名乗っている会社から出たものか」を確かめて、迷惑メールに振り分けるかどうかを判断しています。経路が変わると、この確認がうまく通らなくなることがあるのです。

送信元の「本人確認」をする3つの仕組み

この本人確認には、次の3つの技術（総称して「送信ドメイン認証」）が使われます。

仕組み	一言でいうと	乗り換えで起きやすいこと
SPF	「このメールを送ってよい送信元」を、会社のドメインの設定（DNS）に登録しておく	新しいサービスの送信元が登録されておらず、本人確認に失敗する
DKIM	メールに電子署名を付け、改ざんされていないことを確かめる	新サービス用の署名の設定を忘れ、署名なしで送ってしまう
DMARC	SPFとDKIMの結果をもとに、失敗したメールを「何もしない／隔離／拒否」のどれで扱ってほしいかを受信側に伝える	設定が「拒否」寄りの場合、本人確認に失敗したメールがそのまま届かなくなる

DMARCの失敗時の扱いについて、総務省の資料では受信側の処理が「何もしない」「隔離（迷惑メールとして扱う）」「拒絶（受信サーバーから削除する）」の3つに整理されています。

📰 出典：総務省「送信ドメイン認証技術（DMARC）に関する資料」（受信側の処理の整理）

「拒絶」の設定にしている場合、乗り換え後の認証設定に抜けがあると、メールが迷惑メールフォルダにすら入らず、届かないまま消えることがあります。システム側にエラーが出ないため、気づくのが遅れやすい点に注意が必要です。

受信側は、認証の整ったメールを前提にする流れです

なりすましメール（フィッシング）対策として、送信ドメイン認証の導入は官民で進められています。受信側のメールサービスも、認証の整っていないメールを厳しく扱う方向にあると言われています。大手メールサービスの送信者向け要件の詳細は変わることがあるため、最新の内容は各社の公式ヘルプで確認するようにしてください。

乗り換え前に準備したい6つのこと

1. 「どのメールを、どこから送っているか」を一覧にする

最初にやるのは棚卸しです。システムが送っているメールをすべて洗い出します。

会員登録の確認、パスワード再設定、注文確認、請求書の送付など、メールの種類
差出人のアドレス（例：noreply@自社ドメイン）
送信しているシステム（本体のシステム、管理画面、別の業務ツール、問い合わせフォームなど）
1日・月末などの送信数の目安

実はここで「開発会社も把握していなかったメール」が見つかることが少なくありません。古い機能や、別の担当者が追加した通知です。乗り換えで漏れると、その種類のメールだけが届かなくなります。

2. 送信元のドメインと、DNSの管理者を確認する

次に、差出人に使っているドメイン（メールアドレスの「@」より後ろ）と、そのドメインの設定（DNS）を誰が管理しているかを確認します。

SPFやDKIMの設定はDNSに書き込むため、DNSを管理している人（自社の情シス、ドメイン管理会社、前任の開発会社など）の作業が必要です。「誰に頼めば設定を変えられるのか分からない」まま乗り換え日を迎えると、当日に作業が止まってしまいます。

3. 認証設定（SPF・DKIM・DMARC）の現状を確かめる

今の設定がどうなっているかを、開発会社に確認してもらいます。

SPFに、新サービスの送信元を追加する計画があるか（SPFは登録できる項目数に上限があり、増やしすぎると失敗する場合があるため、開発会社に確認してもらう）
DKIMの署名を、新サービスで有効にする手順があるか
DMARCの失敗時の扱いは今どうなっているか（「何もしない」か、「隔離」か、「拒否」か）

乗り換えの前後で、古い送信元と新しい送信元の両方を一時的に認証できる状態にしておくと、切り替えの途中で届かなくなるリスクを減らせます。

4. 切り替えは「少しずつ」と「戻し方つき」で計画する

メール送信を一度にすべて切り替えると、問題が起きたときの影響が大きくなります。次のような進め方を開発会社と相談してください。

社内宛て・テストアドレス宛てに新サービスから送り、Gmail・Yahoo!メール・携帯キャリアのメールなど複数の受信先で届き方を確認する
影響の小さい種類のメール（社内向け通知など）から先に切り替える
問題がなければ、会員向けの重要なメール（パスワード再設定、注文確認）へ広げる
古い送信元をすぐには止めず、一定期間は戻せる状態を残す

「何が起きたらどこまで戻すか」を、切り替えの前に決めておくことが大切です。

5. 切り替え後の「届いているか」を測る方法を決める

届いたかどうかは、システムの画面だけでは分かりません。「送信に成功した」と表示されても、受信側で迷惑メール扱いになっていることがあるからです。

送信サービスの管理画面で、配信の失敗（バウンス）や苦情の件数を見られるか
DMARCの集計レポート（認証の成功・失敗を受信側が知らせてくれる仕組み）を受け取る設定があるか
お客様から「届かない」と言われたときの問い合わせ窓口と調査の手順があるか

切り替え後の1〜2週間は、送信数、失敗数、問い合わせ件数を毎日確認する担当者を決めておくと安心です。

6. 料金と制限（送信数・保存期間・サポート）を比べる

乗り換えの理由は、サービス終了や料金、機能など、会社によってさまざまです。比べるときは、月額料金だけでなく次の点も確認してください。

月・日あたりの送信数の上限と、超えたときの扱い
送信ログの保存期間（問い合わせ調査に使えるか）
サポートの対応時間と、障害時の連絡方法
将来の提供終了や仕様変更の予告がどのくらい前に出るか

メール送信機能のサービス終了を例に、乗り換え候補の選び方は次の記事で整理しています。

たとえばMicrosoftは、Azure Communication Servicesのメール機能について、2028年9月30日の提供終了までに移行するよう案内しています（2026年10月時点の公式ドキュメントによる）。

📰 出典：Microsoft Learn「Retirement and breaking changes guide for Azure Communication Services」

このように、乗り換えには期限に追われて急いで切り替えるパターンと、余裕を持って計画できるパターンがあります。期限が先であれば、その間に上記の準備を進められます。

乗り換えでやりがちな失敗

本番のメールだけ確認して、テストをしない

設定の画面上は問題なく見えても、実際に届くかは送ってみないと分かりません。必ずテスト送信を行い、複数の受信先で届き方を確認します。

認証設定を開発会社だけに任せてしまう

DNSの設定は、ドメインの管理者でないと変更できません。開発会社が設定内容を伝えても、自社側の作業が遅れると切り替え日が延びます。誰がいつDNSを変更するかを計画に入れてください。

古い送信元の設定をすぐに消してしまう

切り替え直後に旧サービスの認証設定を消すと、戻す必要が出たときに戻せません。しばらく並行して残しておくのが安全です。

案内メールの文面や差出人名を変えて、迷惑メール扱いになる

乗り換えと同時に、メールの件名・差出人名・文面・リンク先を大きく変えると、受信側に不審なメールとみなされやすくなることがあります。乗り換えでは中身を変えず、変更は別のタイミングで行うほうが原因を切り分けやすくなります。

発注者がやることチェックリスト

☐ システムが送っているメールの種類と差出人アドレスを、開発会社と一緒に一覧にした
☐ 送信元ドメインのDNSを誰が管理しているか確認し、変更の担当者と日程を決めた
☐ SPF・DKIM・DMARCの現状と、乗り換え後の設定計画を開発会社から書面でもらった
☐ 切り替えの段取り（テスト → 影響の小さい種類 → 重要なメール）と、戻す条件を決めた
☐ 切り替え後の1〜2週間、配信失敗数・苦情・問い合わせを確認する担当者を決めた
☐ 旧サービスの設定は、安定稼働を確認するまで残す方針にした
☐ 乗り換え先の送信数上限、ログの保存期間、サポート内容を確認した

開発会社への質問例

打ち合わせでそのまま使える質問です。

「今のシステムから送っているメールを、種類・差出人・送信元ごとに一覧にしていただけますか？」
「乗り換えにあたって、SPF・DKIM・DMARCはどう変更しますか？自社側で必要なDNSの作業と、その期限を教えてください」
「切り替え前後で、Gmailなど複数の受信先に届くかどうかをどう確認しますか？」
「問題が起きたときに、旧サービスへ戻す手順と、戻す判断の基準はどうなっていますか？」
「切り替え後に、配信の失敗や迷惑メール扱いを見つけるための仕組みと、確認する頻度を教えてください」

「メールは『送れた』ことより『届いた』ことが大切です。事前に一覧と戻し方を決めておくと、切り替え当日が落ち着いて進められます」

まとめ：メールの乗り換えは「届くこと」を前提に、前もって準備する

メール送信サービスの乗り換えで迷惑メール扱いを防ぐには、設定を切り替える前の準備が欠かせません。

今送っているメールと送信元を棚卸しする
ドメインのDNSの管理者と、変更の担当・日程を決める
SPF・DKIM・DMARCの移行計画を確認する
少しずつ切り替え、戻し方を決めておく
切り替え後は「届いたか」を測る仕組みを用意する
料金だけでなく、送信数・ログ・サポートも比べる

専門的な設定は開発会社が行いますが、誰がDNSを変更するか、いつ切り替えるか、戻す条件は何かを決めるのは発注者の大切な役割です。まずは、今システムが送っているメールの一覧づくりから始めてみてください。

なお、法令や各メールサービスの要件の個別の適用については、専門家や各社の公式窓口にご確認ください。

システム発注の相談をする

あわせて読みたい関連記事

この記事を書いた人

朝野貴朗 - TOMONO TAKAAKI

株式会社THIRD HERO代表取締役　朝野貴朗
Webシステム開発を中心に、toC向けサービスサイトの運営、ツール開発などを行ってまいりました。

問い合わせ