MXレコードをIPアドレスで直接ポイントするのではなく、レコードをポイントして、メールサーバーのIPアドレスをポイントする必要があることを理解しています。A

しかし、原則として、なぜこれが必要なのですか？

MXレコード全体の考え方を指定することであるホストまたはホストドメインのメールを受け入れることができます。RFC 1035で指定されているように、MXレコードにはドメイン名が含まれています。したがって、DNSで解決できるホストを指す必要があります。IPアドレスは、修飾されていないドメイン名として解釈され、解決できないため、使用できませんでした。

仕様が最初に書かれた1980年代のこの理由は、今日の理由とほぼ同じです。ホストが複数のネットワークに接続され、複数のプロトコルを使用する場合があります。

80年代に、TCP / IPを使用する（比較的新しい）インターネットと、他のプロトコルを使用することが多い他のレガシーネットワークの両方に接続するメールゲートウェイが存在することは珍しくありませんでした。この方法でMXを指定すると、DNSレコードを許可して、Chaosnetなどのインターネット以外のネットワーク上のそのようなホストに到達する方法を識別できます。しかし実際には、これはほとんど起こりませんでした。事実上すべての人がネットワークをリエンジニアリングして、代わりにインターネットの一部になりました。

今日、状況はホストが複数のプロトコル（IPv4およびIPv6）および各プロトコルの複数のIPアドレスによって到達される可能性があることです。1つのMXレコードに複数のアドレスをリストすることはできないため、唯一のオプションはホストをポイントすることで、そのホストのすべてのアドレスを検索できます。（パフォーマンスの最適化として、DNSサーバーは、信頼できるレコードがある場合、応答の追加セクションでホストのアドレスレコードを送信し、ラウンドトリップを節約します。）

また、メールエクスチェンジャーがサードパーティ（Google AppsやOffice 365など）によって提供されている場合に発生する状況もあります。MXレコードをホスト名にポイントしますが、サービスプロバイダーがメールサーバーのIPアドレスを変更する必要がある場合があります。ホストをポイントしているため、サービスプロバイダーはこれを透過的に行うことができ、レコードを変更する必要はありません。

プロトコルとしてのDNSにはいくつかの異なるタイプの値があり、これらは交換できません。

DNSは、レコードのタイプとそのようなレコードが保持するデータのタイプとの間の厳密なマッピングを持つバイナリプロトコルであることに注意することが重要です。

たとえば、次のレコードは、IPv4アドレス（データの4バイト固定長）を保持します。レコードは、IPv6アドレス（データの16バイトの固定長）を保持します。
A
AAAA

MXレコードは、他の一方で、保持している名前（形式のラベルの配列<int number of bytes> <label> <int number of bytes> <label> <int 0>、可変長）。

そうではありません可能性のためにMX、レコードがデータとしてIPアドレスを持っています。

推測としてこれを捨てます。もちろん、私はインフルエンザにかかっているので、たぶん私は気が狂います。

RFC 974の状態：

LOCALのメーラーの最初のステップは、REMOTEのMX RRのクエリを発行することです。メーラーがメッセージを送信しようとするたびに、この手順を実行することを強くお勧めします。希望は、ドメインデータベースの変更がメーラーによって急速に使用され、したがってドメイン管理者がドメインデータベースを変更するだけで、欠陥のあるホストの転送中メッセージを再ルーティングできるようになることです。

IPの代わりに名前を要求することにより、このプラクティスを強制的に奨励します。名前は同じままでかまいません。ロードバランシングまたはDRの場合、MXレコード自体を変更してDNSの伝播を待つことを心配する必要はありません。

一部のメールサーバー（eximなど）では、純粋なIPアドレスを指すMXレコードへの送信が明確に許可されていないため、準拠するには代わりにFQDNを使用する必要があります。これは、ほとんどのサーバーがMXレコードにIPではなくホスト名が含まれることを期待しているためです（Aレコードの目的です）。

編集：詳細を述べると、DNSの各レコードには、各レコードが保持できるデータの種類に関する厳しい要件があります。MXレコードの場合、ホスト名のみです。

IN RFC 1025 MXレコードは、AレコードまたはCNAMEのRR（リソースレコード）のみを指します。

したがって、メールを送信するメールサーバーはMXレコードのRRを要求し、mxレコードはサーバーのAレコードをリストし、メールサーバーは前方参照を行ってAレコードを取得し、smtpを介してリストされているサービスホストにメールを転送しますそのドメインのメールを「喜んで」受信するメールサーバー。

あなたの質問-メールがIPアドレスに送信されない理由

応答-信頼のため

メールに関するルールの多くは、送受信されるメッセージが実際に有効であるドメイン間の信頼を維持するために進化しました。これはすべて、最終的にスパムを減らすことです。

• 逆IPルックアップ
• その問題の前方参照

メールサーバーを構築するための基盤に必要なこれらのすべてのコンポーネントには、信頼できる通信を作成し、信頼できない通信を減らすために少なくともいくつかの小さなコンポーネントがあります。

リファレンス-RFC 1035および974

https://www.ietf.org/rfc/rfc1035.txt35

https://www.ietf.org/rfc/rfc974.txt

MXレコードの目的は、アプリケーション（メール転送）が使用されるホストについて学習できることです。アプリケーションレベルでは、ホスト名を使用するのが適切です（IPアドレスではありません）。

また、DNSにバリアントタイプレコードの構想を追加すると、複雑化のてこが発生するため、問題、実装の失敗、セキュリティの課題の入り口になります。たとえば1.2.3.4.example.com.、有効なホスト名です（はい、RFC1034、3.5の観点からもそうです）。MXexample.comのバインド構成ファイルでこのホストを指定すると次のようになります

.  MX 10  1.2.3.4

そして、おそらくそれはIPを持つMXレコードとまったく同じになるはずです。また、DNSデータグラムで情報を転送する場合でも、いくつかの風変わりなアドインが必要です。最も簡単な方法は、明確化のために、新しいリソースレコードタイプを導入することMXAです。しかし、もう一度、なぜ新しいレコードタイプのような負担を導入するのか

. MXA 10 5.6.7.8

常に置き換えることができます

. MX 10 dummy
dummy A 5.6.7.8

（そして、MXAレコードを知らないDNSクライアントでもサポートされますか？）