Microsoft 365で独自ドメインメールを使うには、ドメインの所有権を確認するTXT、受信先を指定するMX、送信元を認証するSPF・DKIMなどをDNSへ登録します。設定値は自社の管理画面に表示されたものを使います。

メールだけを移すなら、Webサイト用のAレコードやネームサーバーまで変える必要はありません。利用者のメールボックスを作ってからMXを切り替える、という順番が大切です。MX変更だけでは過去メールは移らないため、データ移行は別に行います。

ネームサーバーからDNSの管理場所を特定する

請求書に書かれたドメイン会社だけを見て、DNSの編集場所を決めない方が良いです。現在指定されているネームサーバーを確認すると、どの事業者がDNSゾーンを公開しているかを判断できます。制作会社がCloudflareなど別のDNSサービスを設定している場合もあります。

編集前に、現在のレコードを画面とテキストで保存します。対象はMXやTXTだけではありません。Webサイトに使うAとAAAAも含めます。CNAMEを加えたゾーン全体を記録すると、誤って別レコードを消した場合に戻しやすくなります。

Microsoft 365管理センターの「設定」「ドメイン」から対象ドメインを開くと、登録すべき値を確認できます。テナントごとに値が異なるものがあるため、他社の記事にある例をそのまま入力しません。

所有権確認はメール切り替えと分ける

最初にドメインの所有権を確認します。Microsoft公式の設定手順では、管理センターに表示されたTXTレコードをDNSへ追加する方法が案内されています。この確認用TXTは、通常は現在のWebサイトやメール配送先を変更しません。

所有権を確認できたら、独自ドメインを使う利用者と共有メールボックスを作成します。現在使っている個人用アドレスを洗い出します。代表アドレスと転送専用も分けておきます。旧メールサービスにしか存在しないアドレスが残ったままMXを切り替えると、その宛先の新着メールを受け取れません。

過去メールの移行もMX変更とは別の作業です。MXを変更すると新しいメールの配送先は変わりますが、旧サーバーに保存されたメールが自動でMicrosoft 365へ移るわけではありません。旧サービスに保存されたメールが必要なら、対応する移行方法も確認します。

MXを変更する前に受信先をそろえる

MXレコードは、そのドメイン宛ての新しいメールをどこへ届けるか決めます。Microsoft公式のDNS手順も、MX変更前に全利用者のメールボックスを作るよう案内しています。

登録するMXの値は、Microsoft 365管理センターに表示されたものを使います。以前のメールサービスを示すMXが残っていると配送が分かれる可能性があります。通常の全面移行では旧MXを置き換えます。旧サービスを予備として残す場合は、両方で同じ宛先を受信できる配送設計が必要です。単に優先度を下げるだけでは、旧環境へメールが入る原因になります。MXは数字が小さい方を優先する仕組みなので、DNS管理画面の表記も確認してください。

Webサイトを現在のレンタルサーバーへ残す場合は、AレコードとWeb用CNAMEを維持します。ネームサーバーをMicrosoftへ変更する作業でもありません。メールに必要なレコードだけを編集すれば、Webとメールを別サービスで運用できます。

SPFは一つのレコードへ送信元をまとめる

SPFは、そのドメインからメールを送ってよいサービスをDNSのTXTへ記録する仕組みです。Microsoft 365だけから送る場合は、管理センターが示す値を登録します。Webフォームや配信サービスも同じドメインで送るなら、その送信元も含める必要があります。

すでにSPFがある場合は、新しいSPFレコードを追加しません。Microsoftも、一つのSPFレコードへ既存サービスとMicrosoft 365の値を統合するよう案内しています。二つの v=spf1 が存在すると正しく評価されないため、現在の送信サービスを確認してから編集します。

レンタルサーバーから送るWordPress通知を残すかも、この段階で決めます。残す場合はサーバー会社の指定をSPFへ反映します。Microsoft 365経由へ統一する場合は、フォーム側のSMTP設定と送信上限を確認します。

DKIMとDMARCは送信テストと一緒に進める

DKIMはMicrosoft Defenderポータルの設定画面で対象ドメインの値を確認します。指定された二つのCNAMEをDNSへ登録し、反映後にDKIM署名を有効にします。参照先にはテナント固有の値が含まれるため、見本から推測しない方が良いです。

DMARCは、SPFまたはDKIMの認証結果と差出人ドメインの整合をもとに扱いを指定します。最初から強い拒否設定にすると、把握していない業務サービスのメールまで止める場合があります。まず送信元と集計レポートを確認します。一般的なメールのやり取りでは転送などもあるため、拒否方針を一律の目標にはしません。用途ごとの考え方は下記のメール認証の記事で説明しています。

SPF、DKIM、DMARCの役割は「SPF・DKIM・DMARCとは？メール認証の設定方法と確認手順」でも説明しています。Microsoft 365の設定値だけでなく、会社が使うすべての送信経路を対象にすることが重要です。

社内外の送受信で切り替えを確認する

DNS画面に値が見えただけでは完了にしません。社内のMicrosoft 365利用者同士、外部から自社、社内から外部の順で送受信します。代表アドレスや共有メールボックスも一件ずつ確認し、転送や自動応答を使う場合はその動作も見ます。

外部宛てメールではヘッダーを確認し、SPFとDKIM、DMARCの結果を記録します。失敗している場合はレコードを増やすのではなく、実際に送信したサービスと認証対象のドメインを照合します。DNSの反映待ちと設定誤りを分けるため、変更時刻も残してください。

受信だけができない場合はMXと宛先の作成状況、外部への送信だけが迷惑メールになる場合は送信認証を中心に調べます。DNS設定はすべてをやり直すのではなく、止まっている経路に絞って確認すると原因を見つけやすくなります。