Microsoft 365で独自ドメインメールを使うときは、Microsoft 365管理センターに表示された値を、現在のDNS管理先へ登録します。ドメインを取得した会社とWebサーバー会社が、DNSの管理会社と同じとは限りません。最初に編集場所を特定することが大切です。

メールだけをMicrosoft 365へ移すのであれば、WebサイトのAレコードやCNAMEを変更する必要はありません。先に利用者とメールボックスを用意し、最後に受信先を決める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を削除するか、Microsoftの案内に沿って優先度を下げます。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 365管理センターに表示される二つのCNAMEをDNSへ登録します。参照先にはテナント固有の値が含まれるため、見本から推測しません。DNSへ反映された後に管理センターでDKIMを有効にし、外部宛てのテストメールで署名を確認します。

DMARCは、SPFまたはDKIMの認証結果と差出人ドメインの整合をもとに扱いを指定します。最初から強い拒否設定にすると、把握していない業務サービスのメールまで止める場合があります。まず送信元を洗い出し、集計レポートを受け取れる状態から段階的に進めます。

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

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

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

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

最後に、DNS管理者とMicrosoft 365管理者の担当を台帳へ記録します。MXとSPFを変更できる人を明記します。DKIMとDMARCの担当も必要です。メールボックスを作る人が別なら、次の入退社やサービス追加で誰が両方を確認するか決めておきます。