有料ASP脱却の代償:独自ドメイン移行でメールが止まった日

SaaS固定費
有料ASPから脱却
既存ドメイン移行
サーバー移転
WordPress再構築

AIの活躍によってSaaS系のサービス固定費に意味があるのかと思う今日この頃。
私は有料ASPからの脱却を考えていました。

既存ドメインを利用しサーバー移転をし、再構築。
ここまでは思い切った決断ですが、未来に続く為には既存ビジネスモデルの打破を苦労してでも経営者が突き進んでいく必要があると私は考えます。

そうして大事故の発生です。
サイトは表示できるのに、独自ドメインのメールが一切届かない。受注や問い合わせに直結する箇所が突然止まりました。
「終わったかもしれない」と一瞬本気で思った出来事です。
地味に一番こわかったこと
うちはネットショップを複数展開しているので、その数だけ受信用メールアドレスがあります。
つまり、ここが止まると1アドレスが止まるのではなく「全部止まる」
問い合わせも受注も、確認メールも、現場のやり取りも、一斉に沈黙しました。

独自ドメイン移行でメールが届かない原因と復旧手順(実録)

WordPress移行
DNS/ネームサーバー
MX/SPF
メール運用
グループウェア連携

「今日こそ早く帰る予定だったのに…」
既存サービスからWordPressへ寄せた瞬間、メールが一切届かないという“あるある地獄”に落ちました。それは移行がうまくいったなと思った夕方に起きた出来事です。

この記事では、私が実際に地獄にハマった状況を題材に、
なぜメールが届かなくなるのか、そしてどこを直せば復旧するのかを、同じ沼にハマる人向けに整理します。

この記事の結論(先に答え)
Web表示(Aレコード)とメール受信(MXレコード)は別腹。
「受信箱を見るためのサーバー(IMAP/POP)」を「配送先(MX)」に入れると、配送が迷子になりやすい。
正しいMX(配送先)に直し、送信側(SMTP)に合わせてSPF(TXT)も整えると復旧します。

起きたこと:サイトは見えるのにメールが死んだ

ドメインをWordPress側へ寄せた後、WordPress自体は動いているのに、独自ドメイン宛のメールが届かない。
送信元を変えても、迷惑メールにも入らず、Webメールにも見当たらない。

ポイント
「ホームページが表示される=DNSが全部正しい」ではありません。
WebはAレコード、メールはMXレコード。片方だけ正しくても、もう片方は普通に壊れます。

まず整理:メールの住所録はどこが持ってる?

いちばん最初に確認すべきは「ネームサーバー(NS)」です。
ネームサーバーはそのドメインのDNSの台帳がどこにあるかを決めます。

  • NSがサーバーA → DNS(A/MX/TXTなど)はサーバーAのDNS設定が正
  • NSがサーバーB → DNSはサーバーB側が正
  • NSを混ぜる(ns1だけ別など)は基本NG。人によって見える世界が変わり、再現性のない不具合になります

やったこと:nslookupで“世界が見てるMX”を確定する

体感で「たぶん直ってる」は危険です。
Windowsならコマンドプロンプトで、今、外部から見えるMXを確認できます。

nslookup -type=mx example.com

※注意:上のexample.comは例です。自分のドメインに置き換えてください。

この結果が、メール配送の「行き先」です。
ここが期待と違うなら、どれだけWebメールを更新しても届きません(そもそも郵便配達が別の住所に行ってる)。

落とし穴:IMAP/POPのサーバー名をMXに入れていた

私が最初にやってしまったのがこれ。
メールサービスの案内に出てくる「受信(IMAP/POP)」のサーバー名を、そのままMXに入れてしまった。

なぜ危険?
IMAP/POPは「メールボックスを見に行く先」。
MXは「外部からメールを運んでくる配送先」。
この2つは同じとは限らず、配送が失敗してメールが届かない状態になりやすいです。

復旧:正しいMX(配送先)に直す

結局、MXはサービス側が指定する「配送先」へ設定し直しました。
その後、再度 nslookupMXが正しく見えていることを確認。

復旧チェック

  1. DNS設定でMXを修正
  2. nslookup -type=mx 自分のドメイン で外部からの見え方を確認
  3. Gmailなど別経路から独自ドメイン宛にテスト送信
  4. Webメールで受信確認(受信箱・迷惑メール・隔離)

仕上げ:送信(SMTP)に合わせてSPF(TXT)も整える

受信が復旧しても、次に起きがちなのが「送信が迷惑メール行き」問題。
送信サーバー(SMTP)に合わせて、SPF(TXT)も正しく整えました。

SPFの考え方(ざっくり)
「このドメインから送って良い送信サーバーは誰?」をDNSに宣言するのがSPFです。
送信経路が変わったのにSPFが古いままだと、メールが弾かれたり迷惑判定されやすくなります。

グループウェアに反映させる場合の考え方

「グループウェアに反映させたい」と言っても、グループウェアがメールサーバーそのものか、取り込み管理の箱かでやることが変わります。

  • 受信サーバー(MX)を持つタイプ:指定されたMXへ向ける
  • 取り込み管理タイプ:受信はメールサービス側、グループウェアはIMAP/POPで取り込む

今回の学び:帰宅ボタン直前にイベントが発生する

本当にそう。帰るつもりだったのに、DNSは気まぐれ猫みたいに暴れます。
でも、今回のように「NS」「MX」「SPF」を分けて考えて、nslookupで外部からの見え方を確定すると、
再現性のある手順で必ず戻せます。

最短チェックリスト(保存推奨)

  • NS(どこがDNSを管理しているか)
  • MX(配送先。IMAP/POPとは別)
  • SPF(送信サーバーに合っているか)
  • 確認コマンド:nslookup -type=mx 自分のドメイン
同じ症状で詰まったら
「Webは見えるのにメールが届かない」「MXとSPFがややこしい」「グループウェア連携が不安」など、状況を聞いて最短で整理します。
お問い合わせ:https://pl-ow.com/contact/

※この記事は実体験ベースのため、各サービスの仕様変更や契約プラン差異で表示が異なる場合があります。
迷ったら「今のNS/MX/SPFの実値」と「メールの送信経路(どのSMTP)」を先に固定すると最短です。

関連記事

TOP