【DNS入門】M365設定で学ぶ！MX・CNAME・TXTレコードとメールセキュリティの基本

今回は、AWSのRoute 53などのDNS管理サービスを触っていると必ず遭遇する「DNSレコード」について、Microsoft 365（M365）の導入を例に挙げて整理してみました。

特にメール周りの設定（SPF/DKIM/DMARC）は、最近のセキュリティ対策として必須の知識ですので、この機会にしっかりとおさらいしておきましょう！

DNSの基本：Route 53とホストゾーン

まず、DNS（Domain Name System）を管理する場所についてです。AWSではRoute 53を使いますが、ここで重要になるのが「ホストゾーン」という概念です。

パブリックホストゾーン：インターネット上の誰もが参照できる「公開された住所録」。
プライベートホストゾーン：VPC内など、特定の社内ネットワーク内だけで有効な「身内限定の住所録」。
ネームサーバ：住所録の実体となるサーバです。Route 53でホストゾーンを作成すると、自動的に4つのネームサーバが割り当てられ、世界中にドメイン情報を発信してくれます。

設定が正しく反映されているかは、nslookupや、より詳細な情報が得られるdigコマンドで確認する癖をつけておくとトラブルシューティングに役立ちます。

M365を独自ドメインで運用する場合、以下のレコード設定を指示されることが一般的です。

その名の通り「メールの配送先」を指定するレコードです。M365のメールサーバ（Exchange Online）を指すように設定します。

「別名（エイリアス）」を定義するレコードです。 M365では接続先のサーバ情報が定期的にアップデートされますが、CNAMEで「名前」を紐付けておけば、裏側のIDが変わっても私たちのドメイン設定を書き換える必要がなくなるというメリットがあります。

ドメインに任意のテキスト情報を追加するレコードです。主に「このドメインは安全ですよ」という証明（セキュリティ設定）に使われます。

上記のレコードを総称してMSレコードと呼ばれます。MSレコードはM365のサーバを指定する際のレコードの総称（MX、CNAME、TXT）を指します。

「なりすましメール」や「迷惑メール判定」を防ぐために、以下の3セットは現在の必須設定と言えます。

「どのサーバからメールを送るか」を事前に宣言する仕組みです。受信側は、届いたメールが宣言通りのサーバ（M365など）から来ているかを確認します。

メールそのものに「電子署名（鍵）」をかける仕組みです。

SPFやDKIMが失敗した時の「後処理」を決めるルールです（TXTレコードで設定）。

※メール受信フローの③をより詳細に表してます

クラウド（Route 53）が主流になる前、あるいは今でも自前で構築する際に登場する用語もあわせて覚えておくと便利です。

DNS設定は、一見複雑に見えますが「住所録にどんな情報を載せるか」を決めているだけです。特にM365などのSaaSを導入する際は、今回紹介したレコードの役割を理解しておくと、スムーズに作業が進みます。

インフラエンジニアへの第一歩として、まずは自分のドメインをdigコマンドで覗いてみることから始めてみてはいかがでしょうか？