サイトは開くのにメールが届かない｜MX・SPF・DKIM・DMARCの確認順
Webサイト移転後に独自ドメインのメールだけ止まった架空例で、受信と送信を分け、MX・SPF・DKIM・DMARCをどの順番で確認するか説明します。
この記事でわかること
# サイトは開くのにメールが届かない｜MX・SPF・DKIM・DMARCの確認順
この記事は、独自ドメインでホームページとメールを使っている小規模事業者・サイト担当者向けです。サイトを移転した後、ページは開くのに info@example.com のメールだけ届かなくなったという架空例を、設定を壊さずに切り分けます。
最後まで進めると、受信と送信を分けてテストし、現在公開されているDNSレコードをメール提供元の指定値と比較し、担当者へ渡せる確認メモを作れます。この記事の例示値を実際のDNSへコピーすることはしません。
今回の架空例
- ドメイン：example.com
- メール：info@example.com
- 変更内容：Webサイト移転のため、10月13日 09:00にネームサーバーを変更
- 変更後：example.com のサイトは表示できる
- 困りごと：外部から info@example.com へ送るとエラーが返る
- 方針：メール提供元は変更せず、既存契約を継続する
この例での完成状態は「たぶん直った」ではありません。外部アドレスから受信でき、独自ドメインから外部へ送信でき、送信側の認証結果も確認できた状態です。
1. まずWebとメールの経路を分ける
DNSは、ドメイン名をどのサービスへつなぐか示す案内表です。同じ example.com でも、Webサイトとメールは異なるレコードを使います。
| レコード | 主な役割 | 今回の確認 |
|---|---|---|
| A・AAAA・CNAME | Webサイトなどの接続先 | サイトが開くため、今回の受信障害とは分ける |
| MX | 受信メールを渡すメールサーバー | 最優先で照合する |
| SPF | 送信を許可したサーバーの一覧 | 外部へ送ったメールの認証を確認する |
| DKIM | 送信メールへ付けた電子署名を公開鍵で検証する | メール提供元の指定値と照合する |
| DMARC | SPF・DKIMの確認結果をもとに受信側へ扱い方を示し、報告を受ける | 送信元ドメインとの一致やポリシーを確認する |
CloudflareのDNS資料では、MXはメールサーバーへ届けるためのレコード、SPFは送信を許可するIPアドレスやドメインの一覧、DKIMは暗号学的な署名、DMARCは認証に合わないメールの扱いと集計報告のためのレコードと説明されています。
2. DNSを触る前に、変更前後の材料を残す
復旧を急いで現在のレコードを削除すると、元へ戻す手掛かりまで失います。先に次の表を埋めます。管理画面のスクリーンショットを保存する場合は、アカウント名、顧客情報、認証コードなどを写さないでください。
| 項目 | 架空例の記入 |
|---|---|
| 変更した日時 | 10月13日 09:00 |
| 変更したもの | ネームサーバー |
| Webの提供元 | 新しいWebホスティング |
| メールの提供元 | 既存のメールサービスを継続 |
| 受信テスト | 10:05、外部メールから送信するとエラー |
| 送信テスト | まだ未実施 |
| エラー全文 | 個人情報を除いて別メモへ保存 |
| 変更前のDNS | エクスポートまたは画面保存あり／なし |
ネームサーバーを変えた場合、新しいDNS管理先にWeb用レコードだけを作り、以前のMXや認証レコードを移し忘れることがあります。今回の例では、この可能性を最初に確認します。ただし、原因を決めつけて設定は変えません。
3. 「受信できない」「送信できない」「迷惑メール」を分ける
「メールが使えない」だけでは確認先が決まりません。別のメールアドレスを1つ用意し、次の順でテストします。テスト本文には実在する顧客名や契約情報を入れず、「受信確認 10月13日 10:05」のような識別用文字だけにします。
- 外部アドレスから info@example.com へ送る
- info@example.com から外部アドレスへ送る
- 外部側の受信箱と迷惑メールを確認する
- エラーが返った場合は、本文を省略せず保存する
- 各結果へ時刻を付ける
| 結果 | 最初に見る場所 |
|---|---|
| 外部から受信できない | MXの公開値、受信契約、メールボックスの状態 |
| 独自ドメインから送れない | 返送エラー、SMTP設定、メール提供元の障害情報 |
| 送れるが迷惑メールへ入る | SPF・DKIM・DMARC、送信元の評判、本文や送信方法 |
| 一部の相手だけ届かない | 相手側のエラー、フィルター、認証結果、送信ログ |
| メールソフトだけ接続できない | SMTP・IMAP・POPのホスト名、ポート、暗号化、DNSの接続先 |
一度に複数のDNSレコードを変えると、どの修正が効いたか分からなくなります。観察、比較、1つの修正、再テストの順に進めます。
4. 現在公開されているMXを確認する
DNS管理画面にMXが見えても、インターネットから同じ値が返るとは限りません。別のDNS管理先を見ている、変更がまだ反映中、入力名が違う、といった可能性があるためです。
Cloudflareの公式手順では、ターミナルを使える場合、次のように現在のMXを確認します。
~~~text
dig example.com mx +short
~~~
Windowsなどで dig が使えない場合は、メール提供元のDNS確認機能や、信頼できるDNS検索ツールを使います。検索結果へ秘密情報を入力する必要はありません。
確認は次の3列で行います。
| 比較対象 | 見る内容 | 合格条件 |
|---|---|---|
| メール提供元の設定資料 | MXの接続先と優先度 | 契約中の提供元が示す最新値 |
| DNS管理画面 | 種類・名前・値・優先度 | 入力内容が指定値と一致 |
| 外部からのDNS検索結果 | 実際に公開されているMX | 指定値が返る |
例示用の「mx1.mail-provider.example」は架空です。実際の接続先は、メール提供元の管理画面または公式資料から取得します。別サービスのブログや古い設定記事からコピーしません。
MXが空または違う場合
- 現在のDNSレコード一覧を保存する
- メール提供元で、自分の契約に対応したMXの値を確認する
- DNS管理画面の入力欄を、種類・名前・値・優先度に分けて照合する
- 既存値を削除する必要があるか、提供元の手順で確認する
- 修正後は公開値を再検索し、外部アドレスから受信テストする
Cloudflareは、MXの検索結果を管理画面およびメール提供元の指定値と比較し、一致しなければ提供元の資料を確認するよう案内しています。
5. 受信が直ったら、送信認証を確認する
MXを直して受信できても、SPF・DKIM・DMARCの確認は残ります。GoogleはGmail宛ての全送信者にSPFまたはDKIMを求め、大量送信者にはSPF・DKIM・DMARCを求めています。送信量が少なくても、3つを整えることを推奨しています。
SPF：送信を許可するサービスを1つの方針へまとめる
SPFはTXTレコードとして公開します。Cloudflareは、同じドメインにSPFレコードを複数置けないと説明しています。サイトのフォーム、通常のメール、予約システムなど複数サービスから送る場合、サービスごとに「v=spf1」で始まる行を追加するのではなく、すべての送信元を含む1つのSPFへまとめる必要があります。
まとめ方は契約中のメール提供元と送信サービスの公式手順に従います。include の値や末尾の「~all」「-all」を推測で変えません。
DKIM：提供元が発行したセレクターと公開鍵を使う
DKIMは送信側が秘密鍵で署名し、受信側がDNSの公開鍵で検証する仕組みです。レコード名は一般に「セレクター._domainkey.example.com」の形ですが、セレクターと値はメール提供元が発行します。以前のサービスのDKIMが残っているだけでは、新しい送信元の署名を確認できません。
DMARC：いきなり強い拒否へ進めない
DMARCはSPF・DKIMの結果と、利用者に見えるFromドメインとの整合を確認し、合わないメールの扱いを受信側へ伝えます。送信元を洗い出さず、いきなり強い拒否ポリシーにすると、正規のフォーム通知や外部配信サービスまで失敗する可能性があります。まず契約中サービスの手順とレポート受信体制を確認し、段階的に進めます。
6. Cloudflareを使う場合の追加確認
Cloudflareの通常のHTTPプロキシは、SMTP・IMAP・POP3を中継しません。mail.example.com のようなメール用ホスト名がCloudflareのIPへ向くプロキシ状態になっていると、メールソフトが接続できない場合があります。メール提供元が指定するレコードは、通常「DNS only」で解決させます。
ただし、Cloudflare Email RoutingやSpectrumなど別機能を明示的に使う構成は確認内容が変わります。機能を止める前に、現在の契約と用途を確認してください。
7. 修正後は往復と認証結果を記録する
今回の架空例では、次の表が埋まれば完了です。
| テスト | 結果例 | 完了判定 |
|---|---|---|
| 外部 → info@example.com | 10:40に受信 | 受信箱で本文を確認 |
| info@example.com → 外部 | 10:43に受信 | 迷惑メールではなく本文を確認 |
| MX公開値 | 提供元指定と一致 | 外部DNS検索でも一致 |
| SPF | pass | 実際に送ったメールの認証結果で確認 |
| DKIM | pass | 実際に送ったメールの認証結果で確認 |
| DMARC | pass | Fromドメインとの整合を確認 |
| Webサイト | 表示できる | 修正後もトップと問い合わせを確認 |
Gmailで受信テストした場合は、対象メールのメニューから「メッセージのソースを表示」相当の画面を開くと、SPF・DKIM・DMARCの結果を確認できます。メールサービスによって確認場所が違うため、見つからない場合は提供元のヘルプを参照します。
直らないときに担当者へ渡すメモ
~~~text
対象ドメイン：example.com
発生：10月13日 09:00のネームサーバー変更後
受信テスト：10:05 外部から送信、エラーあり
送信テスト：10:12 外部へ送信、受信できた／迷惑メールへ入った
公開MX：確認結果を記載
提供元指定MX：確認結果を記載
SPF・DKIM・DMARC：pass / fail / 未確認
エラー全文：個人情報を除いて添付
直前に変更した項目：ネームサーバーのみ
現在は変更していない項目：メール契約、メールソフト設定
依頼：DNS公開値とメール側ログのどちらに問題があるか確認してほしい
~~~
エラー番号、発生時刻、送受信の方向があれば、担当者は調査を始めやすくなります。パスワード、認証コード、DNS管理画面のログイン情報は送らないでください。
サイト公開とメール設定を一緒に整理したい場合
Webサイト移転時に、公開用DNSとメール用DNSを分けて確認したい場合は、同じ運営者のWeb制作サービス SITE PORT も選択肢です。以下は機能・成果・対応範囲を保証する案内ではなく、サイト構成の完成例と編集イメージを確認するページです。メール提供元固有の値は、その提供元の公式資料との照合が必要です。
サイトが開くからメールも大丈夫、と判断せず、受信・送信・認証・Web表示の4つを別々に完了させることが安全な公開作業につながります。
出典・確認情報
確認日：2026-10-13 ／ 公式情報の要点と編集部の提案を整理しています。価格・機能・条件は変更される場合があります。
Cloudflare DNS Docs：メール問題のトラブルシューティングCloudflare DNS Docs：DNSレコードの種類Cloudflare Learning Center：SPFレコードCloudflare Learning Center：DKIMレコードCloudflare Learning Center：DMARCレコードGoogle：Gmail宛てメール送信者のガイドライン