メールは別ルート。
ドメイン変更後にWebは見えるのにメールだけ届かない場合、MXやTXTなどメール関連DNSの引継ぎ漏れが代表的です。
確認する順番
- 送信・受信どちらの問題か確認
- MXを確認
- SPF等TXTを確認
- メールボックスを確認
- 外部アドレスと送受信テスト
5分で切り分ける｜Web・受信・送信・認証を分けて確認
YOHAKU 5-MINUTE CHECK
- Web表示：ホームページが見えてもメール設定は別系統なので、Web正常＝メール正常とは判断しない。
- 受信：外部アドレスから独自ドメイン宛てへ送り、届かなければMXとメールボックスを確認する。
- 送信：独自ドメインからGmail等へ送り、送信エラーや返送メールを保存する。
- 認証：届くが迷惑メールになる場合はSPF・DKIM・DMARCなどのTXT設定を確認する。
- 反映待ち：変更直後なら旧値・新値・変更時刻を記録し、短時間に何度も設定を変えない。
最初に症状を分けると、MX・SMTP・TXT・DNS反映を同時に触らずに済みます。
YOHAKU MAIL AUTH CHECK
届くけど迷惑メール？4つに分ける
- SPF：送信元として許可されたサーバーか
- DKIM：署名が正しく付いているか
- DMARC：表示上のFromドメインと、認証に合格したSPFまたはDKIMのドメインの整合を確認し、不合格時の扱いを定める
- 本文・送信運用：認証以外の迷惑メール要因がないか
DNSへ値を追加する前に、現在のレコードと利用中メールサービスの公式設定値を確認します。
切り分けは「受信・送信・認証・反映待ち」の4つに分ける
メール障害は一度に全部を触らず、まず症状を4つに分けます。受信できないならMXとメールボックス、送信できないならSMTPや送信元設定、迷惑メール扱いならSPF・DKIM・DMARC、変更直後ならDNS反映状況を優先して確認します。
| 症状 | 最初に見る場所 | 記録するもの |
|---|---|---|
| 外部から受信できない | MX・メールボックス | 送信時刻・宛先・返送エラー |
| 外部へ送信できない | SMTP・認証情報 | エラーコード・送信元 |
| 迷惑メールになる | SPF・DKIM・DMARC | 受信ヘッダー・判定結果 |
| 変更直後だけ不安定 | DNS反映状況 | 変更時刻・旧値・新値 |
特にドメイン移転では、Webだけ先に新環境へ向き、メールだけ旧環境を参照している状態が起こり得ます。変更前のDNS値を控えておくと復旧時の比較が早くなります。
関連記事
切替前後で比較する設定一覧
| 確認項目 | 見るポイント |
|---|---|
| MX | 受信先ホスト名と優先度が旧環境と意図どおりか |
| SPF | 現在使う送信元サービスが含まれているか |
| DKIM | 新しいメールサービス側で発行された値を登録済みか |
| DMARC | ポリシーとレポート先が意図どおりか |
| メールボックス | 対象アドレスが新環境側に作成済みか |
| 転送・自動返信 | 旧環境だけに設定が残っていないか |
切替後に必ず行うテスト
- 外部アドレスから独自ドメイン宛てへ送信する
- 独自ドメインからGmail等へ送信する
- 返信して往復できるか確認する
- 迷惑メールフォルダも確認する
- 失敗時は返送メールのエラーコードを保存する
同じドメイン内だけの送受信では問題を見逃す場合があります。Web表示が正常でもメール設定は別系統なので、外部との往復テストまで終えてから切替完了と判断します。
設定変更で避けたいこと
- MX・TXTを推測で書き換える
- 複数項目を同時に変更して原因を追えなくする
- エラーメールを削除してしまう
- 旧メールサービスを確認前に停止する
原因が絞れないときに伝えること
変更は1つずつ行い、変更前後で同じ操作を再確認します。原因が特定できない場合は、URL・発生時刻・変更内容を整理して契約先や担当者へ相談してください。
MX・SPF・DKIMだけでなく、更新・DNS・移管まで含めて管理場所を整理したい場合は独自ドメインの初心者ガイドへ戻って確認できます。
受信は成功、でも迷惑メール｜認証結果を比較する
自分が管理する外部アドレスで受け取ったテストメールのヘッダーを確認し、受信サービスが示すSPF・DKIM・DMARCの結果を記録します。メールアプリの送信完了表示だけで、相手の受信や認証成功を判断しません。
- SPFやDKIMはpass、DMARCはfail：表示上のFromドメインと認証ドメインの整合を確認する。SPFまたはDKIMのどちらかが認証に合格し、DMARCの整合条件も満たす必要があります。
- 認証はpass、迷惑メールに入る：本文や送信運用など別の要因も調べる。認証成功は受信トレイへの配信保証ではありません。
- ヘッダーを取得できない：返送エラーと送信時刻を残し、確認できない項目は未確認と記録する。
Google公式：送信者ガイドラインFAQ（2026年10月10日確認）。大量送信者向けの追加要件と、個別メールの認証判定は分けて読みます。
MAIL AUTH RESULT
届いた/届かないだけでなく認証結果も残す
- SPF：pass / fail / neutral
- DKIM：pass / fail
- DMARC：結果とポリシー
- 送信元ドメインとReturn-Path
受信できても迷惑メールへ入る場合は、配送経路だけでなく認証結果まで確認します。
よくある質問
ホームページが表示されていればDNSは正常ですか？
Web表示に必要なレコードが正常でも、メール用のMXやTXTが正しいとは限りません。Webとメールを分けて確認します。
DNS変更後は何をテストすべきですか？
外部アドレスとの送信・受信を両方向で試し、返送エラーがあれば内容を保存します。
旧メール環境を止める前の確認
チェック数だけで停止を決めず、利用している機能ごとの結果を確認します。メールサービス自体を変えていない場合は、新しいメールボックス作成など不要な作業を増やしません。
- 必要なアドレス・転送・自動返信を引き継ぎ、外部との送受信で意図した動作を確認したか。
- 新旧どちらへ届いているか確認し、旧環境に残るメールの保存・移行が必要か判断したか。
- 送信元として使うサービスごとに、認証結果や返送エラーを確認したか。
- 未解決の不達と未確認の機能が残っていないか。残っているなら停止前に契約先へ確認する。
旧契約の停止は、保存データ・契約条件・移行状況を確認して判断します。この記事の確認項目だけで解約完了を保証するものではありません。
DNS切替前に必ず残したいもの
MXやTXTを変更する前に、旧環境のレコード値をスクリーンショットやテキストで残します。障害時に元へ戻せるだけでなく、新旧設定の差分を比較しやすくなります。
同じホスト名に、v=spf1で始まるSPF用TXTレコードを複数作らないでください。複数の送信サービスを使う場合は、その公式手順に沿って一つのSPFレコードへ統合します。所有確認など、SPF以外のTXTレコードまで削除するという意味ではありません。Microsoft公式：SPFの設定（2026年10月10日確認）
よくある質問
MXを変えればすぐ新メールへ届きますか？
DNS反映には時間差が出ることがあります。切替直後は旧環境と新環境の両方を確認し、重要なメールがどちらへ届いているか見ます。
受信できるならSPF・DKIMは不要ですか？
受信設定と送信認証は別です。送信先で迷惑メール判定される場合はSPF・DKIM・DMARCなども確認します。
ホームページ移転とメール移転は同時にやるべきですか？
必須ではありません。障害時の原因切り分けをしやすくするため、可能ならWebとメールの変更を分けて進める方法もあります。
