組織向けのOffice365には「外部ユーザーの招待」がある。Teamsでも、Sharepointでも外部ユーザーを招待してファイルなりチャットができればいろいろ便利（組織のセキュリティポリシーが許してくれれば、だけど）。
外部ユーザーを招待するにあたり、先方がOffice365を使っているか、そうでないかによって準備や条件が変わってくる。先方がOffice365ユーザーなら、先方のアカウント管理者がアカウントを管理してくれているので退職すればアカウント削除してくれるはずだし、アクセス元制限かけているケースも多いはず。
先方が法人向けのOffice365を使っていないなら、マイクロソフトアカウントを作成してもらい、そのマイクロソフトアカウントに対して共有するしかない。マイクロソフトアカウントは個人のものなので、退職しようが何しようがとりあえずは使えちゃうし、アクセス元制限もない。
というわけで、先方ドメインが365を使っているかを(ある程度）確認してみる。
MXレコードを確認する
MXレコード見て、.mail.protection.outlook.com.というレコードか、確認する。
のところは、ドメイン名のドットをハイフンに置き換えたものになっている。
例えばcontoso.comなら、"contoso-com.mail.protection.outlook.com."という記述だけならおおむね使ってる。
ただし、メールセキュリティサービスを入れている場合は、違う場合がある。実はさっきのcontoso.comだけど、"mail.global.frontbridge.com."となっていた。そういう場合は、TXTレコードも確認する。
TXTレコードを確認する
TXTレコードで見る場所は2か所。SPFレコードと、TXT="MS=xxxxxx"という個所。
SPFレコードに"include:spf.protection.outlook.com"という文字列が含まれていれば、送信元にOffice365が含まれている可能性が高い。
Office365にドメイン登録する際にドメインの所有者確認でTXT="MS=xxxxxx"(xxxxxxは365管理センターで指定された数字の羅列）を使うケースが多いので、これが含まれていたらOffice365を使っている可能性が高い。
注：あくまで可能性でしかない
MXレコードやTXTレコードが当てはまる場合、可能性が高い。
ただし、あくまで可能性なので「昔使ってたけど今使っていない」ケースもありうる。
注：招待したらマイクロソフトアカウントでログインされちゃった
「招待メールのリンクをひらいたらサインアップ求められたので、サインアップしたらそれはマイクロソフトアカウントでした」とか、「わざわざ招待のURLのリンクを開いてマイクロソフトアカウントで開いたよ」ということも十分ありうる。
その場合はいろいろとめんどくさいけど、社内の365管理している人に依頼して、Azureポータルでゲストユーザーを調べてもらう。"外部のAzure Active Directry"となっていれば安心だけどそうじゃないなら要注意。