ホームページの移転に合わせてネームサーバーを変更したところ、サイトは問題なく表示された。しかし、会社のメールアドレスに送ったメールが届かない。送信相手にはエラーが返っている。
この状態では、ホームページではなく、メールの配送先を決めるDNS設定に問題が残っていることがあります。
サイトが表示されていても、メールの設定まで正常とは限りません。Webサイトとメールでは参照するDNSレコードが違うためです。慌てて設定を何度も書き換える前に、どこで問題が起きているかを順番に調べます。
サイトは表示されるのにメールだけ届かない理由
独自ドメインには、ホームページの表示先とメールの配送先を別々に指定できます。
たとえば、ホームページをレンタルサーバーに置き、メールはGoogle WorkspaceやMicrosoft 365で使う構成です。この場合、Webサイトとメールは同じドメインでも別のサーバーへ接続されます。
主なDNSレコードの役割は次のとおりです。
| レコード | 主な役割 | 設定に問題があると起きること |
|---|---|---|
| A・AAAA | ドメインとWebサーバーのIPアドレスを結び付ける | サイトを表示できない |
| CNAME | 別のホスト名へ接続する | www付きURLや外部サービスが動かない |
| MX | 受信メールの配送先を指定する | 独自ドメイン宛のメールが届かない |
| TXT | SPF・DKIM・DMARCなどの情報を登録する | 送信メールが迷惑メール扱いされたり拒否されたりする |
| NS | どのネームサーバーがDNS情報を管理するかを示す | 参照されるDNS設定全体が切り替わる |
ネームサーバーを変更すると、参照されるDNSの管理場所も変わります。旧サーバーに登録していたMXレコードが、新しいDNSへ自動的に引き継がれるとは限りません。
新しい管理画面でAレコードだけを設定すると、サイトは表示されます。しかし、MXレコードがないため、メールの配送先を見つけられない状態になります。
Cloudflareの公式資料でも、ネームサーバー変更前に不足しているDNSレコードを手動で追加するよう案内されています。
最初に「届かない範囲」を調べる
メールトラブルは、受信・送信・特定の相手・問い合わせフォームなど、問題が起きる範囲によって調べる場所が変わります。
最初に次のテストを行ってください。
| 起きている症状 | 最初に調べる場所 |
|---|---|
| 外部からのメールを受信できない | MXレコード、メールアカウント |
| 受信できるが送信できない | SMTP設定、パスワード、ポート番号 |
| 送信はできるが相手に届かない | SPF、DKIM、DMARC、迷惑メール判定 |
| 社内の同じドメイン間だけ届かない | メールサーバー内の配送設定 |
| 問い合わせフォームからだけ届かない | Webサーバーのメール送信設定 |
| 一部の相手からだけ届かない | 相手側のエラーメール、受信拒否、DNSのキャッシュ |
Gmailなどの外部アドレスから会社のメールアドレスへ送り、届くかを試します。次に、会社のアドレスからGmailへ送ります。
送信者にエラーメールが返った場合は、削除せずに保存してください。「domain not found」「mailbox unavailable」「550」などの表示が、原因を探す手掛かりになります。
設定を直す前に残しておく情報
原因が分からないままDNSレコードを追加・削除すると、最初の問題に別の問題が重なります。変更前に、現在の状態を記録しておきます。
残しておきたい情報は次のとおりです。
- 現在指定されているネームサーバー
- DNSレコードが表示されている管理画面
- 変更前のDNSレコード
- 利用中のメールサービス
- メールを使っているアドレスの一覧
- ネームサーバーを変更した日時
- メールが届かなくなった日時
- 送信者へ返ったエラーメール
- 旧メールサーバーへログインできるか
管理画面はスクリーンショットで保存します。旧サーバーの契約やメールアカウントも、復旧が終わるまでは削除しないでください。
DNSの切り替え途中では、送信元によって旧メールサーバーと新メールサーバーのどちらかに届くことがあります。旧サーバーを先に解約すると、そこへ届いたメールを読めなくなります。
編集しているDNS管理画面が正しいか確かめる
よくある間違いが、現在使われていないDNS管理画面を編集しているケースです。
ドメインを取得した会社、レンタルサーバー、Cloudflareなど、それぞれにDNS設定画面があることも珍しくありません。ただし、実際にインターネットから参照されるのは、現在のNSレコードで指定されたネームサーバーの設定です。
たとえば、ネームサーバーをレンタルサーバーからCloudflareへ変更した後、以前のレンタルサーバーでMXレコードを直しても反映されません。
次の順番で確認します。
- ドメインに設定されている現在のネームサーバーを調べる
- そのネームサーバーを管理しているサービスを特定する
- 該当サービスのDNS管理画面を開く
- MXレコードが登録されているかを見る
ドメインの契約先とDNSの管理先は、必ずしも同じではありません。「ドメインを買った会社の画面だから正しいはず」とは限らない点に注意が必要です。
MXレコードが正しい配送先を向いているか調べる
MXレコードは、独自ドメイン宛のメールをどのメールサーバーへ届けるか指定するものです。
利用しているメールサービスの公式マニュアルを開き、現在公開されているMXレコードと見比べます。別のブログに掲載された設定例ではなく、契約中のサービスが案内している値を使ってください。
確認する項目は次の5つです。
- MXレコードの名前またはホスト名
- 配送先のサーバー名
- 優先度
- 古いMXレコードが残っていないか
- メールサービス側でドメインが有効になっているか
Google Workspaceの場合、送信側のサーバーはドメインのMXレコードを調べて配送先を決めます。設定値や入力方法はGoogle Workspaceの公式手順で確認できます。
DNS管理画面によっては、名前の欄に「@」を入れるものと、空欄にするものがあります。配送先の末尾に「.」が必要な画面もあります。見た目が違っても、画面の入力ルールに従えば同じ設定になることがあります。
一方、古いメールサービスと新しいメールサービスのMXレコードを根拠なく混在させるのは危険です。優先度によって別々のサーバーへ配送され、届くメールと届かないメールが分かれることがあります。
MXレコードだけでなくメールアカウントも見る
MXレコードが正しくても、配送先のメールサーバーに対象のアカウントが存在しなければ受信できません。
たとえば、MXレコードを新サーバーへ切り替えたものの、新サーバー側に「info@example.jp」を作っていない場合です。送信者には、宛先が存在しないことを示すエラーが返ることがあります。
次の点をメールサービスの管理画面で確かめます。
- 対象のメールアドレスが作成されているか
- アカウントが停止されていないか
- メールボックスの容量が上限に達していないか
- 転送先のアドレスが間違っていないか
- エイリアスとして作ったアドレスが残っているか
- ドメインの所有権確認が終わっているか
旧サーバーで使っていたメールアドレスは、新しいサーバーへ自動作成されない場合があります。部署別のアドレスや問い合わせ用アドレスも含めて一覧にすると、作り忘れを見つけやすくなります。
「反映待ち」で直る状態と直らない状態を分ける
DNSを変更すると、以前の情報がインターネット上に一時的に残ります。保存される時間はTTLによって決まります。
ただし、設定値そのものが間違っている場合は、何日待っても直りません。
反映待ちと考えられるのは、次のような状態です。
- 正しいDNS管理画面にMXレコードを登録済み
- メールサービス公式の設定値と一致している
- メールアカウントも作成済み
- 確認する場所によって新旧の値が混在している
反対に、公開されているMXレコードが空欄だったり、旧サーバーを向いたままだったりする場合は設定の修正が必要です。
設定を変えるたびに待ち時間も分かりにくくなります。一つ修正したら、公開されているDNS情報を見て結果を追います。短時間に複数の値を入れ替え続けるのは避けてください。
送信だけ失敗する場合はTXTレコードも調べる
受信はできるのに、送ったメールが相手へ届かない場合は、MXレコードだけを見ても原因が分からないことがあります。
送信メールでは、SPF・DKIM・DMARCなどの設定が関係します。
- SPF：そのドメインから送信してよいサーバーを示す
- DKIM：メールに電子署名を付け、送信元を確かめられるようにする
- DMARC：SPFやDKIMの確認に失敗したメールの扱いを受信側へ伝える
ネームサーバー変更時にTXTレコードを移し忘れると、これらの情報も失われます。その結果、送信は完了したように見えても、相手側で迷惑メールに入ったり、受信を拒否されたりします。
複数のサービスからメールを送っている会社では、SPFを単純に二つ登録しないよう注意が必要です。利用中のメール配信サービスや問い合わせフォームの送信方法まで洗い出し、公式マニュアルに沿って一つの設定へまとめます。
問い合わせフォームからだけ届かない場合
ホームページの問い合わせフォームから送られたメールだけが届かないなら、Webサーバー側の配送設定も調べます。
Webサイトとメールを別のサーバーで使っていると、Webサーバーが同じドメイン宛のメールを外部へ送らず、自分のサーバー内に配送してしまうことがあります。この場合、外部のGmailから送ったメールは届くのに、サイトのフォームから送った通知だけ届きません。
確認したいのは次の項目です。
- フォームから送信する宛先
- 送信元として設定したメールアドレス
- SMTP送信を使っているか
- Webサーバー側のメール配送設定
- エラーログに送信失敗が残っていないか
- 迷惑メールフォルダへ入っていないか
DNSを直した後は、通常のメール送受信だけでなく、問い合わせフォームからもテスト送信してください。
メールを復旧させる順番
設定が複数のサービスにまたがっている場合は、次の順番で進めると混乱しにくくなります。
- 現在のネームサーバーを特定する
- 実際に参照されているDNS管理画面を開く
- 変更前後のDNSレコードを比べる
- 利用中のメールサービスを特定する
- 公式マニュアルどおりにMXレコードを設定する
- 必要なメールアカウントが存在するか調べる
- SPF・DKIM・DMARCの設定を戻す
- 外部アドレスとの送受信を試す
- 問い合わせフォームから送信する
- 旧メールサーバーに届いたメールがないか見る
復旧後は、Gmailなど一つの宛先だけで終わらせず、複数の経路で試します。
最低限、次の組み合わせで送受信できれば、見落としを減らせます。
- Gmailから会社アドレスへの送信
- 会社アドレスからGmailへの送信
- 同じ独自ドメイン同士の送受信
- ホームページの問い合わせフォーム
- 届いたメールへの返信
- 転送設定を使っているアドレス
自力で戻せないときに整理しておくもの
ドメインの取得先、現在のDNS、Webサーバー、メールサービスが別々になっていると、どの管理画面を直すべきか分かりにくくなります。
相談時には、次の情報をまとめておくと原因調査が進みやすくなります。
- ドメイン名
- ドメインの契約先
- ネームサーバーを変更した日時
- 変更前と変更後のネームサーバー
- Webサイトを置いているサーバー
- メールに使っているサービス
- 現在のDNSレコード
- 変更前のDNSレコード
- 届かないメールアドレス
- 送信者へ返ったエラー内容
パスワードや認証コードは、公開された問い合わせ欄へ書かないでください。ログインが必要な場合は、依頼先と安全な共有方法を決めてから渡します。
まとめ
ネームサーバー変更後にサイトは表示されるのにメールが届かない場合、最初に見るのは現在のネームサーバーとMXレコードです。
ホームページ用のAレコードが正しくても、メール用のMXレコードが引き継がれていなければ受信できません。送信だけ失敗する場合は、SPF・DKIM・DMARCやメールソフトのSMTP設定も調査対象になります。
まずは現在参照されているDNS管理画面を特定し、利用中のメールサービスが指定する値と比べてください。設定を何度も書き換えず、一つずつ直して外部から送受信を試すことが、早く元の状態へ戻す近道です。
