FQDN（完全修飾ドメイン名）とは、mail.example.com のように、インターネット上の特定のコンピューターやサーバーを表す完全で正確な名前のことです。「完全修飾」という言葉が重要なポイントで、アドレスを省略せずに最後まで書き切り、ソフトウェアが推測したり補完したりする部分を一切残しません。
FQDN は、サーバーのセットアップ画面、TLS 証明書の入力フォーム、メールログなどに、説明もないまま登場する用語のひとつです。「FQDN」と書かれた入力欄、「HELO does not resolve」という警告、あるいは完全修飾名を要求してくる証明書に出くわしたことがある方に向けて、本記事では FQDN とは何か、どう読むのか、自分の FQDN をどう調べるのか、そしてそれがメールにどう影響するのかを解説します。
完全修飾ドメイン名は、ホストからルートに至るまで、ドメインネームシステム（DNS）上のただ一つの正確な位置を指定します。アドレスのどの部分も文脈から推測される余地を残しません。
たとえば社内ネットワークでは、mail とだけ入力すればマシンにアクセスできる場合があります。これは、コンピューターが既定の検索ドメインを自動的に付け足して mail.example.com に変換しているためです。この短縮形は便利ですが曖昧でもあります。mail はネットワークごとに別のものを指すからです。FQDN である mail.example.com はどこでも同じホストを意味します。だからこそ、外部に公開されるシステム、TLS 証明書、メールサーバーはいずれも完全修飾された形式を求めるのです。
この用語は、末尾にピリオドを付けた mail.example.com. という形で書かれることもあります。最後のドットは DNS のルートを表します。技術的にはすべての FQDN の一部ですが、たいていのソフトウェアが自動的に補ってくれるため、自分で入力することはほとんどありません。
FQDN はドットで区切られた一連のラベルで構成され、右から左へ、最も一般的なレベルから具体的なホストへと読み解きます。mail.example.com を例に見てみましょう。
.）です。DNS ツリーの最上位にあたります。com で、ルートのすぐ下に位置します。example で、com の中に登録された名前です。example.com 全体が、あなたが所有するゾーンとなります。mail で、example.com の中にある特定のマシンやサービスを指します。今度は逆方向に読むと、これは一本の経路になります。ルートから始まり、com へ、次に example へ、そして mail ホストへと絞り込まれていきます。すべての FQDN は、ラベルが 2 つでも 5 つでも、この同じ上位から下位への構造に従います。
この 3 つの用語は曖昧に使われがちで、混乱の大半を引き起こしています。これらは同じものではありません。
example.com のようなドメイン名は、あなたが登録し所有する名前です。これはゾーンを指し示します。一方、mail.example.com のような FQDN は、そのゾーンの中にある特定のホストを、ルートまで省略せずに名指しで指定します。簡単に言えば、ドメインは土地そのもので、FQDN はその上に建つ一棟の建物の正確な住所です。登録済みのドメインはそれ自体が FQDN になることもあります（example.com は名前解決できます。つまり、何かがそれを参照したときに DNS が応答を返します）が、実際に扱う FQDN の多くは、ドメインの下にあるホストを指します。
部分修飾ドメイン名（PQDN）は、意図的に不完全な名前です。これは mail や mail.example のような相対的な名前で、システムが設定済みの検索ドメインを使って欠けている部分を補ったときに初めて名前解決されます。PQDN は、全員が同じサフィックスを共有する管理されたローカルネットワークの内部であれば問題ありません。しかし、公開される用途には不向きです。その名前がネットワークの外に出た瞬間、それを補完するものが何もなくなるからです。セットアップ画面が FQDN を求めるとき、それはこの曖昧さを取り除くよう求めているのです。
有効な FQDN は、DNS のサイズと文字種の制限の範囲に収まっていなければなりません。そのルールは古くから変わらず安定しています。
mail.example.com の mail の部分）。Mail.Example.com と mail.example.com は同じ場所に名前解決されます。名前がこれらのルールに違反していると、DNS はそれを無効とみなし、名前解決されません。これは、メールサーバーのホスト名を選ぶときに知っておく価値があります。一見有効に見えても名前解決されない名前は、後々問題を引き起こすからです。
使用するコマンドはオペレーティングシステムによって異なります。
ipconfig /all を実行し、ホスト名とプライマリ DNS サフィックスを組み合わせます。システムのプロパティにあるフルコンピューター名の欄から読み取ることもできます。hostname -f を実行します。hostname -f（または hostname --fqdn）を実行します。マシンに対応付けられているすべての FQDN を一覧表示するには hostname -A を使います。サーバーについては一つ注意点があります。これらのコマンドが報告するのは、ローカルの設定にもとづいてマシン自身が認識している名前です。それは必ずしもパブリック DNS が示す名前や、メールサーバーが外部に向けて名乗る名前と一致するとは限りません。インターネットに公開されるものについては、ローカルのホスト名だけを信用するのではなく、その名前がパブリック DNS で名前解決されることを確認してください。
ほとんどの人にとって、FQDN は背景にあるネットワークの細部にすぎません。しかし、メールを運用したりトラブルシューティングしたりする人にとっては、メールが受信トレイに届くかどうかを左右する 3 つの場面に登場します。
あるメールサーバーが別のメールサーバーに接続するとき、ホスト名を含む HELO または EHLO という挨拶で自己紹介をします。受信側のサーバーは、その名前が mail.yourdomain.com のような、正しく名前解決できる FQDN であることを期待します。localhost、IP アドレス、あるいは名前解決されない名前で挨拶すると、設定不備のインフラと受け取られ、SPF・DKIM・DMARC がすべて合格していてもメールをスパムへ押しやることがあります。このハンドシェイクの詳しい解説は、EHLO と HELO の解説にまとめています。
メールボックスプロバイダーは逆引き DNS も確認します。送信元の IP アドレスには、FQDN を指す PTR レコードが設定されていて、なおかつその FQDN が同じ IP に名前解決で戻ってくる必要があります。この往復は正引き確認済み逆引き DNS（FCrDNS）と呼ばれ、PTR が欠けていたり一致していなかったりすることは、大量配信メールがフィルタリングされるよくある原因です。ドメインのメール設定全体が、認証も含めてどのような状態にあるかを確認するには、下のフォームから無料でチェックしてみてください。
認証も完全修飾名に支えられています。SPF は MAIL FROM ドメインに加えて HELO のアイデンティティも評価でき、関係するレコードはすべて FQDN に対して公開されます。DMARC 自体は、表示される From ドメインのアライメントを確認するため、FQDN がきれいに整っていても、アライメントの合っていないドメインを合格させることはありません。FQDN が取り除いてくれるのは、本当の認証失敗の隣で DMARC 集計レポートを散らかしてしまう補助的なシグナルのノイズです。具体的には、欠落した PTR レコード、名前解決されないホスト名、想定外の送信ホストなどです。どれがどれなのかを整理しているなら、DMARC・DKIM・SPF の違いで、この 3 つがどう組み合わさっているかを解説しています。
自社インフラの FQDN の問題は、直接的に表に出てくることはめったにありません。それらは、認証の失敗、想定外の送信元、あるいは DMARC レポート上の不審なトラフィックとして表面化します。DMARCeye は、お客様の DMARC 集計レポートを読み取り、自社ドメインとして送信している IP アドレスやホスト名と突き合わせます。これにより、設定不備や見覚えのない送信元を見つけ出し、失敗を特定のインフラに結びつけ、修正によって認証と到達率が実際に改善したことを確認できます。
FQDN は小さな細部にすぎませんが、インターネットが、そしてすべての受信メールサーバーが、自分がどのホストと通信しているのかを正確に把握するための手がかりです。ホスト名を完全修飾され、名前解決できる状態にしておくことは、メールを正当に見せ続けるための、比較的手間のかからない方法のひとつです。