社畜の所業

社畜の所業

Microsoft365の機能について解説をしていきたいと思います。このブログの情報をご活用いただければ幸いです。たまに他の情報も取り入れていきたいと思います。

※このサイトはPR記事を含みます。
トップ > Microsoft365 > 【Microsoft365参考書】DNSサーバーの役割とは？MXレコードの仕組みを徹底解説

【Microsoft365参考書】DNSサーバーの役割とは？MXレコードの仕組みを徹底解説

Microsoft365

DNSサーバーの役割とは？MXレコードの仕組みを徹底解説

「昨日まで届いていたメールが、急に届かなくなった」
「テナント移行した途端、NDR(配信不能レポート)の嵐になった」

Exchange Online を管理していると、一度は必ずぶつかるのがこの「メールが届かない問題」です。そして、その原因の多くは実はDNSにあります。

この記事では、Microsoft 365 管理者が最低限おさえておくべき「DNSサーバーとは何か」から、「テナント移行時になぜDNSが重要なのか」、そして「実際のNDRエラーコードからどう切り分けるか」まで解説します。

 

 

 

DNSサーバーとは？郵便配達で考えるとわかりやすい

Microsoft 365 の観点で一言でいうと、DNSサーバーとは「インターネット上の電話帳」のようなものです。

Microsoft 365 を利用する際は、この電話帳に「このドメインのメールは Microsoft 365 に届けてください」と登録しておくことが非常に重要になります。

例えば、Outlook から user@contoso.com へメールを送信するとき、メールサーバーはまず「contoso.com のメールはどこに届ければいいの?」をDNSサーバーに問い合わせます。すると、DNSサーバーは「contoso.com のメールは contoso-com.mail.protection.outlook.com ですよ」と回答します。その結果、メールは無事 Exchange Online に到達するわけです。

封筒の例え
DNSが無い場合、封筒に「○○市○○区○○様」と書いても、住所録が無ければ配達員は行き先を調べられません。
DNSがある場合は、住所録に「contoso.com → Microsoft 365」と登録されているので、配達員(メールサーバー)は迷わず届け先を判断できます。

 

 

 

Microsoft 365でよく出てくるDNSレコード一覧

Microsoft 365管理者としては、以下の5つを覚えておけば十分です。

レコード 用途
MX メール配送先
TXT ドメイン所有確認、SPF
CNAME Autodiscover 等
SRV Teams/Skype の自動検出
A ホスト名→IPアドレス変換

この中でも、Microsoft 365 で最も重要なのは MXレコードです。

 

 

Exchange Online管理者が知るべきMXレコード

Exchange Online では、以下のようにMXレコードがメールの配送先を決定しています。

contoso.com
  ↓ (MXレコード)
contoso-com.mail.protection.outlook.com

この一本の矢印が、実は日々の運用の中で最も重要な設定です。ここが正しく設定されていないと、どれだけメールボックスを作っても、どれだけライセンスを割り当てても、メールは1通も届きません。

 

 

 

SPFレコード(TXT)の役割

SPFレコードは「このドメインからメールを送信して良いサーバー」を定義するものです。SendGridなどの外部送信サービスや、Exchange Online自体を利用する際に重要な役割を果たします。設定漏れがあると、送信したメールが相手先で迷惑メール判定されるリスクが高まります。

 

 

Autodiscover(CNAME)の仕組み

Autodiscoverは以下のように設定されます。

autodiscover.contoso.com
  ↓
autodiscover.outlook.com

これはOutlookの自動設定に利用される仕組みです。ユーザーがメールアドレスとパスワードを入力するだけでOutlookが接続できるのは、実はこのCNAMEレコードのおかげなのです。

 

 

 

テナント移行時にDNSが超重要な理由

テナント移行を経験したことがある方なら、この重要性は身にしみているはずです。

移行前:

contoso.com → Aテナント

移行後:

contoso.com → Bテナント

このように、MXレコードを切り替える必要があります。DNSを変更しない限り、新しいメールは旧テナントへ届き続け、Bテナント側のExchange Onlineはメールを一切受信できません。

そのため、テナント移行では「DNS切替」が本番切替作業の中心と言っても過言ではありません。切替タイミングを誤ると、移行直後にメールロスト事故につながる可能性もあるため、慎重な計画が必須です。

 

 

「送信側のDNS」と「受信側のMX」よくある誤解

メール送信時に参照されるのは「送信側メールサーバーが設定しているDNSサーバー」です。ただし、調べる対象は受信側ドメインのDNS情報(MXレコード)です。この2つを混同している管理者は意外と多くいます。

具体例で見てみましょう。送信者が user@companyA.com、受信者が user@companyB.com の場合です。

  1. 送信側(companyA)のExchange Onlineが「companyB.comのメールはどこへ届ければいいの?」と、自社が使うDNSサーバーへ問い合わせる
  2. DNSサーバーが「companyB.comのMXレコードは companyB-com.mail.protection.outlook.com」と回答
  3. 送信側メールサーバーがそのホストへSMTP接続してメールを配送

つまり、受信側に別々のDNSサーバーが存在していても、送信側は「自分のDNSサーバー」に問い合わせるだけです。そのDNSサーバーがルートDNS・.com DNS・ドメイン権威DNSを内部的にたどって、最終的な回答を取得してくれます。

送信側からすると「自分のDNSに聞いたら答えが返ってきた」というシンプルな動きに見えるわけです。

テナント移行でMXを新テナントへ切り替えると、世界中の送信元メールサーバーが順次その新しいMXレコードを参照して配送先を切り替えていきます。これがいわゆる「DNS伝播(DNS Propagation)」です。

つまりメール配送で本当に重要なのは「送信側がどのDNSを使っているか」ではなく、「受信ドメインのMXレコードが何を指しているか」なのです。

 

 

 

メール送信時のDNSエラー3パターン

実際の現場でよく遭遇するDNSエラーは、大きく分けて次の3パターンに分類できます。

①送信側DNSサーバーの障害

送信メールサーバーが利用しているDNSサーバー自体が応答しないケースです。

送信サーバー → DNS問い合わせ → DNSサーバー応答なし
例: DNS query failed / Host not found / DNS server unavailable

②受信側ドメインのDNS設定不備

実は現場で最も多く遭遇するのがこちらです。例えば受信側ドメインのMXレコードが削除されていると、送信側DNSが正常に動作していても配送は失敗します。

送信側DNS → 正常に問い合わせ → 受信側ドメインにMXが無い → 配送失敗

③DNSの名前解決結果が不正

MXレコードは正しく設定されているのに、その参照先ホスト名のAレコードが存在しないケースです。

MXはある → 接続先サーバー名も取得できた → IPアドレスに変換できない → 配送失敗

Exchange OnlineのNDR(配信不能レポート)では、以下のようなエラーコードで状況を読み解けます。

エラーコード例 推定される原因
450 4.4.317 Cannot resolve MX record 受信側ドメインのMX解決に失敗
451 4.4.0 DNS query failed 送信側または中継経路でのDNS検索失敗
550 Domain does not exist 受信ドメイン自体が存在しない/DNSで見つからない

 

 

 

管理者としての切り分け方法(nslookup実践)

実際にトラブルが起きた際は、コマンドプロンプトを利用し以下の手順で切り分けるとスムーズです。

Step1: 受信ドメインのMXレコードを確認

nslookup -type=mx contoso.com

コマンドプロンプトにて上記のコマンドを実行し、正常であれば「contoso-com.mail.protection.outlook.com」のようなMXレコードが返ってきます。返ってこない場合は受信側DNSの問題を疑いましょう。

Step2: 別のパブリックDNSサーバーでも確認

nslookup -type=mx contoso.com 8.8.8.8
nslookup -type=mx contoso.com 1.1.1.1

結果が異なる場合は、社内DNS・ISPのDNS・DNSキャッシュのいずれかに問題がある可能性が高いです。

経験則として、メール配送で「DNSエラー」と表示された場合、体感としては送信側DNSサーバー障害よりも、受信側ドメインのMXレコード不備や、設定変更直後(テナント移行・MX切替)の方が圧倒的に多いです。そのため、以下の順で調査すると切り分けが早く進みます。

  1. NDRのエラーコードを確認する
  2. 対象ドメインのMXレコードを確認する
  3. MXが指すホスト名の名前解決を確認する

 

 

 

まとめ

Microsoft 365 管理者の観点で最低限押さえておきたいポイントを整理します。

  • DNSサーバー = インターネットの電話帳。ドメイン名とサービスの対応表を持っている
  • Exchange Onlineのメール配送はDNSに依存しており、特にMXレコードがメール受信の要
  • メール送信時に問い合わせるのは「送信側が設定しているDNS」だが、調べる対象は「受信側のMXレコード」
  • テナント移行では、MXレコードの切替(DNS切替)こそが本番作業の中心
  • DNSエラーは「送信側DNS障害」「受信側DNS不備」「名前解決不正」の3パターンに大別できる
  • トラブル時は nslookup でMXレコードを段階的に確認するのが最速の切り分け方法

「メールが届かない」というトラブルは緊急性が高く、原因調査に追われがちです。しかし、DNSとMXレコードの仕組みさえ理解していれば、慌てずに「送信側の問題か、受信側の問題か」を切り分けられるようになります。ぜひ日々の運用にお役立てください。