Loading article…
メール エクスチェンジャーレコード（MXレコード）は、ドメイン名に代わって電子メールメッセージを受信するメールサーバーを指定します。これは、ドメインネームシステム（DNS）のリソースレコードです。複数のMXレコードを設定することが可能で、通常は負荷分散と冗長性のために複数のメールサーバーを指定します。
リソースレコードは、ドメインネームシステム（DNS）の基本情報要素です。MXレコードはそのうちの1つであり、ドメインには以下のように1つ以上のMXレコードを設定できます。
ドメインTTLクラスタイプ優先度ホストexample.com. 1936 IN MX 10 onemail.example.com. example.com. 1936 IN MX 10 twomail.example.com.MXレコード[ 1 ]の特徴的なペイロード情報は、優先度値（上記では「優先度」と表記）とメールサーバーのドメイン名（上記では「ホスト」）です。
優先度フィールドは、どのメールサーバーを優先するかを指定します。この場合、値は両方とも 10 なので、メールはonemail.example.comとtwomail.example.comの両方に均等に流れることが期待されます。これは一般的な構成です。ホスト名は、DNS の1 つ以上のアドレスレコード(A または AAAA) に直接マッピングされ、 CNAME レコードを指してはなりません。[ 2 ]
インターネット経由で電子メールメッセージが送信されると、送信側のメール転送エージェント（MTA）は、各受信者のドメイン名のMXレコードをドメインネームシステムに問い合わせます。この問い合わせにより、そのドメイン宛ての受信メールを受け入れるメール交換サーバーのホスト名とその優先度の一覧が返されます。送信側のエージェントは、次にSMTP接続を確立しようとし、最も低い「優先度」値を持つホストから順に試します。必要に応じて、システムでは1つのドメインに対してメールゲートウェイの高可用性クラスタを構築できます。[ 3 ]
MXメカニズムは、代替ポート番号でメールサービスを提供する機能を提供しておらず、また、各メールサーバーに重み付け値を割り当てることによって、優先順位が異なる複数のメールサーバー間でメール配信を分散する機能も提供していません。
RFC 5321 によると、番号が最も小さいレコードが最も優先されます。[ 4 ]この表現は紛らわしい場合があるため、優先度番号は距離と呼ばれることもあります。距離が小さいほど優先されます。古い RFC である RFC 974 では、2 つのサーバーの優先度番号が同じ場合、それらは同じ優先順位を持つと示されているため、これら 2 つの用語は互換的に使用されます。
優先順位番号は符号なし[ 5 ] 16ビット[ 5 ] [ 6 ]フィールドであるため、有効な値の範囲は0から65535です。
最も単純なケースでは、ドメインにはメールサーバーが1つだけ存在する場合があります。たとえば、MTAがexample.comのMXレコードを検索し、DNSサーバーがmail.example.comのみを優先度番号50で返した場合、MTAはリストされているサーバーへのメール配信を試みます。この場合、50という数値はSMTP仕様で許可されている任意の整数値になります。
MXクエリに対して複数のサーバーが返された場合、優先順位番号が最小のサーバーを最初に試行する必要があります。同じ優先順位番号を持つMXレコードが複数ある場合は、優先順位の低いエントリに進む前に、それらすべてを試行する必要があります。SMTPクライアントは、配信試行が成功するまで、リスト内の関連するアドレスを順番に試行（および再試行）できる必要があります。 [ 4 ]
受信メールの負荷を複数のサーバーに分散させる標準的な方法は、セット内の各サーバーに同じ優先度番号を返すことです。優先度が等しいサーバーの中からメールを送信するサーバーを決定する際には、「送信側SMTPは、特定の組織の複数のメール交換サーバーに負荷を分散させるために、サーバーをランダム化する必要があります」。ただし、特定のサーバーを優先する明確な理由がある場合は除きます。[ 4 ]
別の方法として、マルチホームサーバーを使用する方法があります。マルチホームサーバーでは、1 つのホストが複数の IP アドレスを返します。[ 3 ]この方法では、負荷分散の負担が SMTP 送信者ではなく DNS にかかります。この場合、DNS は、メール交換機の A レコードを照会するクライアントに、特定の順序で IP アドレスのリストを提示します。RFC では SMTP 送信者が A レコードクエリで指定された順序を使用することが要求されているため、DNS サーバーは、ラウンドロビン DNS、メールサーバーの負荷、または非公開の優先順位スキームなど、任意の方法に基づいて負荷分散を慎重に操作できます。
スパマーは、ドメインのバックアップ（遠距離）MXサーバーにはスパム対策フィルターの効果が弱いという前提に基づき、意図的に最初にそのサーバーにメールを送信することがあります。nolistingと呼ばれるスパム対策技術は、この動作を前提としています。
SMTP RFC [ 4 ]では、どのような種類の配信失敗が、より遠い MX レコード (優先度値が高いもの) を介して配信を再試行する結果となるべきかについて、曖昧な点があります。
サーバーが一時的な障害を、明示的に4xxエラーを送信するか、予期せず接続を終了することによって示す場合（RFCのセクション3.8によれば、これは451エラーとして扱われる必要がある）、セクション4.5.4.1には次のように記載されている。
送信者は、特定の宛先への送信が一度失敗した場合、再試行を遅らせなければならない。
しかし、送信者が再試行する場合、RFCでは、同じサーバーに再試行すべきか、より「遠い」MXレコードに再試行すべきかについては何も述べていません。セクション5.1には次のように書かれています。
検索が成功した場合、複数のMXレコード、マルチホーミング、またはその両方により、マッピングの結果、単一のアドレスではなく、複数の代替配信アドレスのリストが生成されることがあります。信頼性の高いメール送信を実現するには、SMTPクライアントは、配信が成功するまで、このリスト内の関連する各アドレスを順番に試行（および再試行）できる必要があります。
SendmailやPostfix 2.1以降などの一部のサーバー[ 7 ]は、挨拶の失敗など、一時的な配信失敗が発生した後に、次に遠いMXサーバーへの接続を試みます[ 8 ] 。一方、qmailやPostfix 2.0以前などの他のサーバーは、最短距離のMXレコードで指定されたサーバーに全く接続できなかった場合にのみ、より遠いMXレコードを使用します。RFCでは具体的な規定がないため、この違いはあるものの、どちらの動作も有効です。
MXレコードが存在しない場合、メール送信者はアドレスレコード（例：example.com）への配信を試みます。
これはRFC 5321のセクション5.1に基づいています。そこには次のように記載されています 。
RFC 821は1982年に公開されました。当時、HOSTS.TXTからDNSへの移行はまだ始まっていなかったため、DNSについては軽く触れているだけです。DNSを初めて記述したRFC 883は、その1年以上後の1983年後半に公開されました。このRFCでは、実験的でほとんど使用されていなかったMDレコードとMFレコードについて説明されています。RFC 897とRFC 921によると、DNSへの移行は1983年に開始されましたが、HOSTS.TXTの段階的廃止は1985年末まで予定されておらず、完全に廃止されたのは1990年代後半でした。
1986 年 1 月、RFC 973 と RFC 974 は MD レコードと MF レコードを非推奨とし、MX に置き換え、A へのフォールバックを伴う MX ルックアップを定義しました。RFC 974 では、クライアントが各 MX ホストでWKSルックアップ[ 9 ]を実行して、実際に SMTP をサポートしているかどうかを確認し、サポートしていない場合は MX エントリを破棄することを推奨しています。しかし、RFC 1123 では、WKS をチェックすべきではないと変更されました。
つまり、SMTPは少なくとも1年間はHOSTS.TXTを使用しており、その後MXが登場するまでさらに数年間はA、MD、MFを使用していたということです。MDとMFは使いにくかったため、ほとんどの人はAレコードのみを使用していました。このような状況では、 Aレコードを使用するメールサーバーのインストールベースが相当数あったため、AへのフォールバックがないMXは機能しなかったでしょう。MXの初期の使用は他のネットワークへのゲートウェイを識別することでしたが、1990年代初頭にDNSが十分に確立されるまで広く使用されることはありませんでした。[ 10 ]
廃止された項目:
各 MX に対して、リストされているドメイン名が実際に目的のメールサービスをサポートしているかどうかを確認するために WKS クエリを発行する必要があります。サービスをサポートしていないドメイン名をリストしている MX RR は破棄する必要があります。この手順はオプションですが、強く推奨されます。