MXの参照先がCNAMEではいけない理由｜Zone Apexとは別の制約

結論 — 名前解決できていても、修正の対象です

診断結果に「MXがCNAMEを指しています」と表示された方への結論を先に書きます。

これは、MXレコードに書いたホスト名そのものが、別の名前への転送（CNAME）になっている状態です。メールが今すぐ止まる不具合ではないため、深刻度は「要確認」として表示しています。ただし、DNSの仕様がこれを禁止しているため、直しておく必要があります。

紛らわしいのは、この状態でも名前解決自体は成功することが多い点です。転送先にIPアドレスがあれば、たどった結果としてIPアドレスは得られます。「引けているのだから問題ないのでは」と感じるかもしれませんが、SMTPの仕様は、この場合の動作を定義していません。つまり、届くかどうかが送信側の実装次第になります。

なお、この記事が扱うのは「MXが参照するホスト名がCNAMEである」問題だけです。ドメイン本体（example.jp のような、サブドメインを付けない名前）にCNAMEを置けないという、よく知られた制約とは別の話です。混同しやすいので、後の節で違いを整理します。

どの部分がCNAMEなのかを具体例で示します

MXレコードは「優先度」と「メールを受け取るサーバーのホスト名」の組です。問題になるのは後半のホスト名です。

次のような設定を考えます。

example.jp.        MX     10 mail.example.jp.
mail.example.jp.   CNAME  mailhost.provider.example.
mailhost.provider.example.  A  192.0.2.25

このとき、example.jp 宛のメールを送ろうとする側は、まず example.jp のMXを引いて mail.example.jp を得ます。次に mail.example.jp のIPアドレスを引きますが、そこにあるのはCNAMEです。この「MXが参照する側の名前がCNAMEになっている」状態が、診断で検出している問題です。

正しい形は、MXが参照するホスト名がAレコード（またはAAAAレコード）を直接持っている状態です。

example.jp.        MX     10 mailhost.provider.example.
mailhost.provider.example.  A  192.0.2.25

診断結果は次のように表示されます。括弧の中が、CNAMEになっているホスト名です。

要確認  MXがCNAMEを指しています (mail.example.jp)
        MXの指す先はCNAMEであってはいけません (RFC 2181 §10.3)。
        CNAMEが返る場合の挙動はRFC 5321 §5.1で標準の範囲外とされており、
        配送の挙動を保証できません。Aレコードを直接持つホスト名を
        指定してください。

ここで押さえておきたいのは、この所見が「名前を解決できるかどうか」とは独立している点です。解決できない場合は別の所見（「MXのホスト名が解決できません」）が出ます。CNAMEをたどった先にAレコードがあれば解決自体は成功するため、両方が同時に出ることもあれば、この所見だけが出ることもあります。

直し方

MXが参照するホスト名を、Aレコードを直接持つホスト名に変更します。ただし、手順の順番が重要です。

1. まずメールサービスの公式な設定値を確認する

利用しているメールサービスの管理画面やドキュメントに、設定すべきMXの値が案内されています。まずこれを確認してください。

2. 公式の値と現在の値が違うなら、公式の値に戻す

現在のMXが公式の案内と違っているなら、公式の値に直すだけで解決します。サービスの移転時に古い設定が残っている場合や、独自のホスト名を経由させる設定を後から入れた場合に、この形になりがちです。

3. 自分で両方のDNS名を管理している場合だけ、CNAMEの参照先に置き換える

mail.example.jp も、その転送先も、どちらも自分で管理しているなら、CNAMEをたどった先の名前をMXに直接書けます。RFC 2181 §10.3自身が、この対処を挙げています。

It is trivial for the DNS administrator to avoid this by resolving the alias and placing the canonical name directly in the affected record just once when it is updated or installed. （エイリアスを解決し、正規の名前を該当レコードに直接書けば、DNSの管理者はこれを簡単に回避できます。設定や更新のときに一度行うだけで済みます）

ここで注意が必要なのは、転送先が第三者のメールサービスのホスト名である場合です。事業者側が転送先を変更したとき、直接書いた値は自動では追随しません。次の 4 に進んでください。

4. 公式がCNAMEでの設定しか案内していない場合は、事業者に確認する

まれに、事業者のドキュメントがMXの参照先としてCNAMEを含む構成を案内していることがあります。この場合、勝手に転送先を固定すると、事業者側の変更に追随できなくなります。案内どおりの設定で警告が出ている旨を、事業者に問い合わせてください。

なぜ規格の外なのか

2つのRFCが、それぞれ別の角度からこの構成を否定しています。

RFC 2181 §10.3 — 参照先をエイリアスにしてはいけない

RFC 2181 §10.3「MX and NS records」は、次のように書いています。

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. （NSリソースレコードの値として使われるドメイン名、およびMXリソースレコードの値の一部として使われるドメイン名は、エイリアスであってはなりません）

理由も同じ節に書かれています。MXやNSを問い合わせたとき、DNSサーバーは応答の追加情報として、参照先のAレコードを一緒に返す仕組みを持っています。参照先がCNAMEだと、この自動的な付加が働きません。その結果、送信側は追加の問い合わせを自分で行う必要が生じます。

なお、この規定は小文字の "must not" で書かれています。RFC 2181（1997年7月）は、RFC 2119の大文字キーワード規約を本文で採用していないためです。表記は小文字ですが、条件を付けずに禁止しており、意味に曖昧さはありません。

RFC 5321 §5.1 — CNAMEが返る場合は標準の範囲外

SMTPの仕様であるRFC 5321 §5.1「Locating the Target Host」は、さらに踏み込んでいます。

That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) ... Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. （そのドメイン名を問い合わせたとき、少なくとも1つのアドレスレコード（AまたはAAAAなど）が返らなければなりません。それ以外の応答、とりわけ問い合わせたときにCNAMEレコードを返す値は、この標準の範囲外です）

「標準の範囲外」という表現が重要です。規格は、この状況で送信側がどう振る舞うべきかを定めていません。したがって、どう扱われるかは送信側のソフトウェアの実装次第になります。

SiteKensaが「配送に失敗します」と断定せず「配送の挙動を保証できません」と表示しているのは、この違いによるものです。実際に失敗するMTAの事例を確認したうえで書いているわけではないため、確認できる事実の範囲を超えないようにしています。

「ドメイン本体にCNAMEを置けない」問題とは別です

「MX」と「CNAME」で検索すると、ドメイン本体（Zone Apex）にCNAMEを置けないという話が多く見つかります。これは今回の問題とは別の規定です。

根拠はRFC 1034 §3.6.2で、「あるノードにCNAMEレコードがある場合、他のデータが存在してはならない」という一般的な規則です。ドメイン本体には必ずSOAレコードとNSレコードが存在するため、その帰結として、ドメイン本体にCNAMEを置けません。Zone Apex専用の規定があるわけではありません。

2つの違いを整理します。

対処の方向が異なる点にご注意ください。ドメイン本体の制約を回避するための機能（CNAMEフラットニングやALIASレコード）は、今回の問題の解決策ではありません。

digで自分で確認する方法

手元のコマンドでも確認できます。3段階に分けて引きます。

まず、MXが参照しているホスト名を調べます。

$ dig +short MX example.jp
10 mail.example.jp.

次に、そのホスト名にCNAMEがあるかを調べます。

$ dig +short CNAME mail.example.jp
mailhost.provider.example.

ここで何か返ってきたら、そのホスト名はCNAMEです。この記事の問題に該当します。何も返らなければ該当しません。

最後に、Aレコードを引いて確認します。

$ dig +short A mail.example.jp
mailhost.provider.example.
192.0.2.25

ホスト名だけでなくIPアドレスも返っているのは、DNSサーバーがCNAMEをたどった結果を一緒に返しているためです。「Aレコードを引いたらIPアドレスが返ってきたから問題ない」と判断できないのは、この表示のためです。CNAMEが混ざっていないかまで見てください。

問題のない状態では、dig CNAME は何も返さず、dig A はIPアドレスだけを返します。

自動生成の設定値を出さない理由

SiteKensaは、多くの所見についてそのまま貼れるDNSレコードの値を生成します。ただし、この所見については生成しません。

正しいMXの値は、利用しているメールサービスによって決まります。公開されているDNSの情報から分かるのは「今どうなっているか」だけで、「本来どうあるべきか」は分かりません。CNAMEをたどった先の名前を機械的に提示することはできますが、それが事業者の推奨する設定である保証はなく、前の節で書いたとおり、事業者側の変更に追随できなくなる可能性があります。

判断できない値を、判断できたかのように提示しないことを方針にしています。この所見については、公式の設定値を確認していただくほうが確実です。

判定できない場合について

DNSの問い合わせが一時的に失敗すると、参照先がCNAMEかどうかを判定できません。その場合は「メールサーバーのホスト名を確認できませんでした」と表示します。これは設定が誤っているという意味ではなく、調べられなかったという意味です。時間をおいてもう一度診断してください。

修正したら再診断する

MXレコードを変更したあとは、MXレコードの診断でもう一度確認してください。

DNSの変更は、すぐには全ての経路に行き渡りません。変更直後に古い値が表示されても、設定を触り直す必要はありません。この見分け方はDNSが反映されないときの確認方法で説明しています。

メールが届かない原因の切り分け全体については、独自ドメインのメールがGmailに届かないときの確認手順をご覧ください。