はじめに
らすみんです。
普段はWeb系のエンジニアとして、コードと向き合う毎日を送っています。そんなある日、独立した友人から一本の連絡がありました。
「会社のメールアドレスを作ったんだけど、うまく送れないみたいで。ちょっと見てくれない？」
これが、長い旅への入り口でした。
「メールでしょ？まあ、なんとかなるだろう」と軽く考えていた私は、この後10時間以上にわたって、DNS、Microsoft 365、PowerShell、そしてGmailの巨大な壁と格闘することになるとは、知る由もなかったのです。
これは、私と同じように、畑違いのインフラ問題に突然直面してしまったすべてのエンジニアに贈る、生々しい戦いの記録です。
序章：すべての始まりは、謎のエラー「Incorrect country code SG」
最初に友人から見せられたのは、Outlookからメールを送信した際に出るというエラーメッセージでした。
IvalidRecipientsException: メッセージに対して指定された受信者が無効です: ... Client host rejected: Incorrect country code SG
「シンガポールからの接続が拒否…？」
正直、さっぱり分かりませんでした。しかし、エラーメッセージに Microsoft や Outlook の文字が見えたので、私は「これはMicrosoft 365の内部的なセキュリティ設定の問題に違いない」と当たりをつけました。
このエラーこそが、私たちを壮大なミステリーの迷宮に誘い込む、巧妙で、あまりにも紛らわしい「偽の手がかり」でした。このエラーの本当の意味が明らかになるのは、すべての謎が解けた、物語の最後のことになります。
第一章：本当の犯人は誰だ？お名前.comとDNSの深淵
Microsoft 365の管理画面という名のラビリンスに潜り、「接続フィルターポリシー」や「迷惑メール対策ポリシー」といった設定を、来る日も来る日も眺め続けました。しかし、何をどうやっても状況は改善しません。設定を保存しようとしても、なぜか反映されない。PowerShellを使えと言われても、コマンドが認識されない…。
完全に手詰まりになった私は、藁にもすがる思いで、外部の診断ツール「MXToolBox」を使ってみることにしました。
友人のドメイン example.com を入力して、Enterキーを押した瞬間、私は自分の目を疑いました。
画面に並んだ、無数の**「Problem」と「Warning」**の文字。
No DMARC Record found, The remote name could not be resolved ...
そう、本当の問題はMicrosoft 365の内部ではなく、その大元であるDNSにあったのです。
友人は、Microsoft 365にドメインを追加しただけで、ドメインを管理しているお名前.com側で、Microsoftが指示したDNSレコードの設定を一切行っていなかったのです。これが、すべての問題の【真のスタート地点】でした。
我々が目指すべきだった「完璧なDNSレコード」
この戦いを通じて学んだ、Microsoft 365を運用するためのDNSレコードの完成形がこちらです。
これを、お名前.comのDNSレコード編集画面に、一つずつ設定していく必要がありました。
1. MXレコード (メールの宛先)
これが最も重要です。これが設定されていないと、メールはMicrosoft 365に届きません。
| ホスト名 | TYPE | 優先度 | VALUE |
|---|---|---|---|
@ |
MX | 0 | example-com.mail.protection.outlook.com |
2. SPFレコード (送信元認証)
「Microsoft 365から送るメールは本物ですよ」と証明するための身分証明書です。
| ホスト名 | TYPE | VALUE |
|---|---|---|
@ |
TXT | v=spf1 include:spf.protection.outlook.com -all |
3. DMARCレコード (なりすまし対策)
SPFやDKIMのチェックが失敗したメールをどう扱うかのルールブックです。
| ホスト名 | TYPE | VALUE |
|---|---|---|
_dmarc |
TXT | v=DMARC1; p=none; rua=mailto:postmaster@example.com |
4. CNAMEレコード (自動設定用)
Outlookなどのメールソフトが、サーバー設定を自動で見つけるために使います。
| ホスト名 | TYPE | VALUE |
|---|---|---|
autodiscover |
CNAME | autodiscover.outlook.com |
5. Aレコード (ドメインの存在証明)
Webサイトが無くても、「このドメインは存在しますよ」と示すために、お名前.comが提供する仮のIPアドレス（パーキングページのIP）を設定しました。
| ホスト名 | TYPE | VALUE |
|---|---|---|
@ |
A | (プロバイダーのパーキングIPなど) |
私たちは、これらのDNSレコードを、お名前.comの管理画面に設定していきました。
第二章：PowerShellの迷宮と、コマンド変更の罠
DNSを完璧にしたにも関わらず、Microsoft 365の管理画面は依然として沈黙を続けていました。「設定を保存できない」問題は解決しません。これは、最初にDNSが不健全な状態でテナントが作られてしまった「後遺症」でした。
こうなれば、最後の手段はPowerShellです。
しかし、ここでも新たな壁が立ちはだかりました。
# 実行しようとしたコマンド
Set-ConnectionFilterPolicy -Identity "Default Connection Filter Policy" -IPAllowList "..."
# 表示されたエラー
Set-ConnectionFilterPolicy : 用語 'Set-ConnectionFilterPolicy' は...認識されません。
なぜだ！公式ドキュメントにも載っているコマンドのはずなのに！
途方に暮れた私は、別のAIアシスタントにセカンドオピニオンを求めました。そして、衝撃の事実が判明します。
Set-ConnectionFilterPolicy は、オンプレミス版の古いコマンドであり、現在のクラウド版 (Exchange Online) では廃止されていたのです。
現在の正しいコマンドは、こちらでした。
# 現在の正しいコマンド
Set-HostedConnectionFilterPolicy -Identity "Default" -IPAllowList "..."
第三章：最後のボス、Gmailと共有メールボックス
数々の壁を乗り越え、ついにメールの送受信が正常にできるようになった！…と思ったのも束の間、最後のボスたちが姿を現しました。
ボス1：Gmailの迷惑メールフィルター
「Yahooには届くのに、Gmailにだけ届かない（迷惑メールに入る）」という謎現象。
これは、新しく作られたドメインの「信頼度（レピテーション）」が低いために、Gmailの厳しいセキュリティAIにブロックされていたのが原因でした。
解決策は、技術ではなく「信頼」でした。
- Google Postmaster Toolsにドメインを登録する。
- 届いたメールを「迷惑メールではない」と報告してもらう。
- 時間をかけて、健全な送信実績を積む。
ボス2：3人目のライセンス問題
友人の会社は3人チーム。しかし、Microsoft 365のライセンスは2人分しかありません。
「3人目のメンバー（仮にuser03@example.comとします）は、どうやってメールを使えばいいんだ…？」
ここで光を当ててくれたのが、**「共有メールボックス」**という機能でした。
- ライセンス不要で作成できる。
- ライセンスを持つユーザーにアクセス権を付与することで、そのユーザーが代理で送受信できる。
これにより、コストを抑えつつ、3人全員がメールを使える、最高の運用体制を構築することができました。
第四章：失われた過去のメールを救え！Classic Outlookの大冒険
すべてが解決したかに見えましたが、友人から「過去のメールが全部消えた！」という悲鳴が。
これは、副作用で、古いメールボックスへのリンクが切れてしまったのが原因でした。
データの救出作戦は困難を極めましたが、最終的に**Windows版の「Classic Outlook」**だけが持つ、強力なインポート/エクスポート機能にたどり着きました。
Classic Outlookに、お名前.comの古いメールサーバー情報を手動で設定し、過去のメールをすべてPCにダウンロード。それを.pstファイルとしてエクスポートし、新しいMicrosoft 365のアカウントにインポートする。
この「データの引っ越し」作業を完遂したことで、失われたはずの過去のメールを、すべて取り戻すことができました。
終章：私が10時間の戦いで得たもの
長かった戦いは、ついに終わりました。
メールは正常に送受信でき、過去のメールもすべて移行し、運用体制も整いました。
振り返れば、最初の原因は、友人が**「DNSレコードを設定していなかった」**という、たった一つのことでした。
そして、あの最初の謎のエラー「Incorrect country code SG」は、Microsoft 365が、間違ったMXレコードを頼りに、古いお名前.comのサーバーへ接続しに行き、そこで拒否されていた、という事実の表れだったのでした。
「いい経験を時間で買った」
今回のトラブルシューティングは、私にとってまさにそういうものでした。
Web系エンジニアである私が、インフラ、クラウド、セキュリティといった未知の領域に足を踏み入れ、そして何より、身近な友人の役に立てた。これ以上の経験はありません。
もし、あなたが過去の私と同じように、不可解なメールトラブルの迷宮に迷い込んでいるのなら、この記事が、その暗闇を照らす一本の松明になることを、心から願っています。
最後まで読んでいただき、ありがとうございました。