MXレコード確認(無料)
どのドメインのMXレコードと優先順位も数秒で確認。無料・登録不要。MXの欠落や設定ミスは、受信メールが届かないよくある原因です。
MXレコードとは
MX(Mail Exchange)レコードは、ドメイン宛てのメールを受信するサーバーを指定するDNSレコードです。各レコードには優先度の値があり、送信側のサーバーは値の小さい順に試します。MXレコードがないと、送信側はRFC 5321の暗黙のMXルールにより、ドメインのAまたはAAAAレコードを使います。多くはメール機能のないWebサーバーのため、配信はすぐには失敗せず、何日も再送した末に失敗します。
結果の見方
| 結果 | 意味 | 対処法 |
|---|---|---|
| MX(メール交換)レコードあり | メールサーバーが1つ以上公開されています。優先順に表示しています。 | すべてのホストが利用中のプロバイダーのものか確認します。廃止したホストが残っていると、配信がそこへ向かうことがあります。 |
| MXレコードなし | メールサーバーが公開されていません。送信側はRFC 5321の暗黙のMXルールでAまたはAAAAレコードを使いますが、まずメールサーバーではないため、配信は時間をかけて失敗します。 | メールプロバイダーのMXレコードを公開します。メールを受信しないドメインなら、代わりにnull MXを公開します。 |
| null MX(優先度0、ホスト .) | RFC 7505に基づき、メールを受信しないことを意図的に宣言しています。Web専用や送信専用のドメインなら正しい設定です。 | 意図どおりなら対応不要です。メールを受信するなら、プロバイダーの実際のMXレコードに置き換えます。 |
| 優先度の異なる複数のホスト | 送信側は優先度の値が最も小さいホストから試し、届かなければ次のホストへ移ります。 | 予備のホストが実際にこのドメインのメールを受け付けるか確認します。配信を拒否する予備は、予備がないより悪い状態です。 |
| 広告用ドメイン | 広告用ドメインのリストにあり、診断の対象外です。 | 組織が実際にメールを送受信するドメインを使います。 |
| ドメインを診断できません | ドメインが存在しないか、公開DNSで名前解決できません。 | 綴りを確認し、ネームサーバーが公開クエリに応答するか確かめます。 |
このツールで確認できること
PalisadeのMXレコード確認でわかるのは、ドメインのMXレコードについて公開DNSが返す内容です。公開されているホスト、その優先順位、そして null MX でメールを受信しないと宣言しているかどうかです。ホストへの接続はしないため、サーバーが今接続を受け付けているか、特定のメールが届いたか、受信後に受信側がどう振り分けるかはわかりません。
MXが決めるのは受信経路だけです。 送信 メールが信頼されるかは別の問題で、SPF、DKIM、DMARCで決まります。MXを含む4つは セキュリティスコア で一度に確認できます。
レコードの公開から、確実に届くメールへ
正しいMXレコードがあれば、メールは自社のサーバーに届きます。難しいのは、自社のメールを相手に受け入れてもらうことです。その判断には根拠が必要です。どの送信元がドメインを使っているか、それぞれがSPFかDKIMで一致しているか、受信側が何を報告しているか。PalisadeはDMARC集計レポートを優先順位付きのワークフローに変えます。担当者は送信元の特定、アライメント失敗の調査、提案されたレコード変更のレビューを進め、各ドメインのポリシーを強化できます。
MSP向けにはマルチテナントで設計。全顧客ドメインのチェック、修正、ポリシー強化を1つの管理画面で行えます。 顧客ドメイン単位の料金 は規模に応じて単価が下がり、顧客のメール送信量による課金はありません。
関連するチェックと用語
メール認証ナレッジベース
MXレコードの仕組みは?
MXレコードは、ドメイン宛てのメールを受信するサーバーのホスト名を指します。IPアドレスを直接指すことはありません。各レコードには優先度の値があります。送信側のサーバーはMXレコードを照会し、値の最も小さいホストから試します。そのホストが使えなければ、次のホストを試します。
MXレコードを複数公開する理由は?
複数あれば、メインのホストに届かないときの配信先を確保できます。送信側は優先順にリストを試すため、2つ目のホストがあれば、一時的な障害で不達や遅延が起きるリスクを減らせます。
ドメインのMXレコードの設定方法は?
ドメインのDNSを管理するプロバイダーの管理画面を開き、受信ホストごとにMXレコードを1つ追加して、それぞれに優先度の値を設定します。指定するホスト名自体も、AまたはAAAAレコードで名前解決できる必要があります。
null MXレコードとは?
優先度0、ホストが「.」(ルートラベル)のMXレコード1つだけの状態がnull MXで、RFC 7505で定義されています。メールを一切受信しないという意図的な宣言で、Web専用や送信専用のドメインには正しい設定です。送信側はアドレスレコードを使って何日も再送することなく、すぐにメールを拒否します。
MXレコードがない・誤っているとどうなりますか?
メールがすぐ止まるわけではありません。RFC 5321では、MXレコードのないドメインは、自身を指す優先度0の暗黙のMXがあるとみなされ、送信側はAまたはAAAAレコードを使います。多くはメール機能のないWebサーバーのため、配信はすぐには失敗せず、何日も再送した末に失敗します。メールを受信しないドメインならnull MXを公開すれば、送信側は最初の試行で明確な応答を得られます。
MXレコードの変更が反映されるまでの時間は?
変更は、キャッシュの有効期限が切れるにつれて浸透します。期限はレコードのTTLで決まります。すべてのリゾルバーのキャッシュが切れるまで、古い値を使う送信側も残るため、変更が完全に行き渡るまで旧ホストでもメールを受け付けてください。
MXとWebサイトを同じサーバーにできますか?
技術的には可能ですが、通常は分けたほうが性能とセキュリティの両面で有利です。Webの障害でメール配信まで止まることもありません。
MXレコードはメール認証に影響しますか?
直接は影響しません。MXは受信経路を、SPF、DKIM、DMARCは送信メールの認証を決めます。ただし両者は関係します。受信に使うホストは送信にも使う同じプラットフォームであることが多く、そのプラットフォームをSPFで許可し、DKIMで署名させる必要があります。
MXでよくある間違いは?
MXレコードにホスト名でなくIPアドレスを指定する、AやAAAAレコードのないホストを指す、移行後も旧プロバイダーのホストを残す、null MXを公開すべきドメインでMXを丸ごと削除する、といったものです。
自社ドメインで外部のメールプロバイダーを使えますか?
はい。MXレコードをそのプロバイダーが指定するホスト名に向け、移行が終わったら旧プロバイダーのレコードを削除します。送信メールの認証が切れないよう、SPFとDKIMも同時に更新してください。
DMARC、SPF、DKIMのタグと仕組みを1か所でまとめて解説します。
DMARC
- vバージョン
- バージョンタグはDMARCレコードに必須で、値は「DMARC1」に限られます。値が正しくない場合やタグがない場合、DMARCレコードは無効とみなされ、無視されます。
- pポリシー
- DMARCポリシータグは、DMARCに失敗したメールについて3つの値を取ります。noneは隔離・拒否を求めず、quarantineは不審なメールとしての扱いを、rejectは受信拒否を求めます。最終的な処理は受信側が決め、p=noneでも別の仕組みで振り分けや拒否をする場合があります。集計レポートは、ruaタグで別途要求します。
- rua集計レポートの送信先
- 集計レポートの送信先を「mailto:」形式のURIで指定します。受信側のメールボックスプロバイダーがこの宛先に集計レポートを送ります。必須ではありませんが、省略するとレポートは届きません。
- ruf失敗レポートの送信先
- 失敗(フォレンジック)レポートの送信先を「mailto:」形式のURIで指定します。失敗レポートを送る受信側プロバイダーはここへ届けますが、送らない事業者も多くあります。このタグがないと失敗レポートは届きません。
- spspポリシー
- サブドメインのポリシーは、特に指定がない限り、前述のメインドメインのポリシータグ(p=)を継承します。指定できる値はドメインのポリシーと同じく「none」「quarantine」「reject」です。ただし、現在の運用ではあまり使われていません。
- adkimDKIMアライメント
- DKIM署名のアライメント、つまりDKIMのドメインとヘッダーFromの送信元ドメインとの一致を指定するタグです。値は「r」(relaxed)と「s」(strict)です。既定の「r」はドメインの部分一致を許容し、「s」はドメインの完全一致を求めます。
- aspfSPFアライメント
- SPFアライメント、つまりSPFのドメイン(送信元)とヘッダーFromのドメインとの整合性を指定するタグです。値は「r」(relaxed)と「s」(strict)の2つです。既定は「r」で、ドメインの部分一致を許容します。一方「s」では、ドメインの完全一致が必要です。
- fo失敗レポートの条件
- 失敗レポートのオプションは「0」「1」「d」「s」です。既定の「0」は、SPFとDKIMのアライメントがどちらもパスしない場合にのみ失敗レポートを生成します。「1」は、SPFかDKIMのどちらかがパス以外の結果になった場合に使います。「d」はDKIMの検証失敗、「s」はSPF関連の問題についてレポートを生成します。失敗レポートを実際に受け取るには、「ruf」タグの指定が必要です。
- rf失敗レポートの形式
- 失敗レポートの形式は「afrf」と「iodef」の2つから選べます。
- pct適用割合(旧仕様)
- 旧来の適用割合タグは、DMARCに失敗したメールの一部にだけquarantineやrejectを適用するよう受信側に求めるものでした。受信側の実装がばらついたため、RFC 9989でpctは廃止されました。新しいレコードでは省略し、集計レポート、ポリシー全体の変更、送信量の少ないサブドメインで段階的に移行します。
- riレポート間隔
- レポート間隔は、XMLレポートを受け取る頻度を秒単位で指定します。標準値は86400秒で、1日1回のレポートにあたります。ただし、指定した間隔にかかわらず、インターネットサービスプロバイダー(ISP)は通常、独自のスケジュールでレポートを送ります。多くの場合、それも1日1回です。
SPF
- v
- バージョンタグの値は「spf1」のみです。誤りや欠落があると、SPFレコードは無視されます。
- ip4
- そのドメインでメール送信を許可するIPv4アドレスを指定します。
- ip6
- そのドメインの名義でメール送信を許可するIPv6アドレスを指定します。
- a
- ドメインのIPアドレス(Aレコード)で送信元を検証します。指定がなければ現在のドメインが対象です。
- mx
- メールサーバーのMXレコードで送信元を検証します。指定がなければ現在のドメインが対象です。
- ptr
- 接続元IPのホスト名をPTRで照合します。DNSルックアップが多すぎるため、RFC 7208では非推奨です。
- exists
- 指定したドメインにAレコードが存在するかを確認します。
- include
- 正確なSPFレコードに欠かせないタグです。指定したドメインやサブドメインを、正規の送信元として受信側に示します。
- all
- SPFレコードの末尾に置くメカニズムです。限定子(~、+、-、?)で、記載のない送信元からのメールの扱いを受信側に示します。RFC 7208では必須ではなく、ない場合の結果はneutralです。
DKIM
- v
- 任意のタグです。指定する場合は値を「DKIM1」とし、レコードの先頭に置きます。
- p
- 公開鍵のタグです。DKIMの設定時に生成される文字列で、空のままでは有効になりません。
- t
- フラグをコロン区切りで列挙するタグです。定義済みのフラグは「y」と「s」で、未定義のフラグは無視されます。
- s
- レコードが対象とするサービスの種類を示すタグです。指定がない種類や不明な種類は、受信サーバーが無視します。
- h
- 許可するハッシュアルゴリズムを指定するタグで、既定ではすべて許可します。一覧は送信側が決め、受信側は不明なアルゴリズムを無視します。
- n
- 管理者向けの任意のメモ欄です。必要なときだけ使うことを推奨します。