なぜGSuiteを導入したのか
- 社内のファイルサーバをクラウドへ移行し、在宅勤務環境の整備。
- COVID-19はたまたまで、これが直接的な原因ではない。
検討しなければならないこと
- GSuiteのドメインは既に存在しているので、メールサーバの移行が必要。
- メールサーバを移行し、メール不通による業務停止に陥ることは避ける必要がある。
- 移行後の検証を行う為、既存のメールサーバからも送受信し、Gmailからも送受信可能な、並行運用期間を持たせる。
GSuiteの導入～移行までに何をしたか
各社員のアカウントを作成
これは特に説明は不要だと思いますが、必要数分（既存メールサーバのアカウント）のアカウントをGSuiteに作成しました。
但し、アカウントを作成してもGmailでメールを参照することは出来ません。これは、まだDNSのMXレコードは既存のメールサーバを指定しているため、Gmail側にメールは配信されていません。
また、既存メールサーバのメーリングリストアドレスについても、GSuiteのグループとして作成し、既存のメールサーバのメーリングリスト同様に、アカウントをグループに所属させました。
既存メールサーバにメール転送を設定
アカウントを作成してしまえば、GSuiteの機能は利用できます。
但し、メールについては、Gmailへ配信されないため、DNSのMXレコードの修正が必要になります。
そこで、MXレコードの更新を実施すればいいのですが、まずは並行運用することにしました。
そのため、既存メールサーバに、Gmailへの転送設定を追加しました。
GSuiteアカウントを作成すると、メールアドレスのエイリアスが割り当てられます。
メールアドレスがot-nemoto@example.comであれば、ot-nemoto@example.com.test-google-a.comというエイリアスが割り当てらます。
これを既存メールサーバの転送設定にアカウント分追加していきます。
また、メーリングリストについては、メーリングリストから、各アカウントへ転送（ot-nemoto@example.com）し、その後、各アカウントからGmailのエイリアス（ot-nemoto@example.com.test-google-a.com）へ転送となるので、メーリングリストに転送設定は追加しませんでした。
これで、各アカウントおよびメーリングリストのメール受信をGmailから取得することが出来るようになりました。
また、メール送信についは、各指定したメールサーバでそれぞれ送信可能です。
SPFレコードの修正
並行運用中に、一部ドメインへのメールが送信できないという報告がありました。
これは一部のGmailへ移行したユーザからのもので、既存のメールサーバ経由でのメール送信は問題ないため、対象ドメインに対してのメールは、既存のメールクライアントから送信し対応しているとのことでした。
結果、一部ドメインの受信メールサーバではSPF認証をpassしない場合には、許可しない設定となっていることが原因でした。
SPFとは送信元のドメインを認証する仕組みです。
送信元IPアドレスが、SPFレコードに指定したIPアドレスの範囲であるかどうかをチェックします。
対象ドメインのSPFレコードが以下のような場合
example.com. IN TXT "v=spf1 include:spf.example.com ~all"
include された先のSPFレコードを更に参照し、IPアドレスの範囲を取得します。
そこで以下のように、gmailからのメールサーバも送信元として許可するように、SPFレコードを修正しました。
example.com. IN TXT "v=spf1 include:spf.example.com include:_spf.google.com ~all"
SPFレコードから、送信サーバのIPが何であればいいのかについては、以下のように確認出来ます。
dig TXT _spf.google.com
# ...
# ;; ANSWER SECTION:
# _spf.google.com. 300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
dig TXT _netblocks.google.com
# ...
# ;; ANSWER SECTION:
# _netblocks.google.com. 144 IN TXT "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
この設定変更をすることで、一部ドメインで拒否されていたメールも、Gmailから送信することが可能になりました。
グループの設定を修正
検証作業をしている中で、GSuiteで設定したグループをメーリングリストとして、メールの受信が可能かどうかの検証の中で、外部からメーリングリストへのメールが送信できないことがわかりました。
既存のメールサーバへの転送設定だけでは気づきにくい部分です。
検証方法としては、GSuiteでグループ設定をすると、これらにもアカウントと同様にエイリアスが割り当てられるので、そのエイリアスを送信先に指定しメールを送信した際に気付きました。
グループを作成した際、デフォルトのパーミッションは、
となっています。
これだと、アカウントの内部でグループをメーリングリストとしてやり取りすることは可能ですが、
外部との連絡に利用しているようなメーリングリストとしては設定が不足しています。
以下のように変更しました。
これで、外部に公開しているメーリングリストも受信可能となりました。
各種メールクライアントの設定
「Gmailに移行したので、あとよろしく。」だと、メールが受信出来なくなった。という声が出るのは必然です。
また、正式に全体に周知したとしても、あとはググってという具合には、残念ながら行きません。
自分で調べて誰もがどうにかなるという問題でもないのも在りますし、各自がこの作業をすると全体通しての工数が大幅持って行かれます。
Gmailをブラウザで利用するように、移行してくれている方もいれば、既存のメールクライアントで作業したい。という人は少なくないので、既存のメールクライアントでも受信できるようにしました。
こちらの設定は、組織では、「安全性の低いアプリへのアクセスの管理をユーザーに許可する」にし、
ユーザのデフォルトの設定では、「安全性の低いアプリのアクセス」を無効にするようにしました。
これで、既存メールクライアントで受信したユーザは、「安全性の低いアプリのアクセス」を有効にし、自身のアカウントとパスワードで、メールクライアントから送受信させるようにしています。
もちろん、「安全性の低いアプリのアクセス」を無効にしたまま、アプリコードを発行し、メールクライアントの設定をしてもらう方法もありますが、2段階認証が必須であることから、各ユーザの利便性とのトレードオフを考え、まずは、必要であれば利用しやすい方法を選択して貰う方法としました。
但し、安全性の低いアプリのアクセスについては、推奨ではないため、運用後に再検討する必要があるかもしれません。
それでは移行します
検証後、最後にDNSのMXレコードの修正を行いました。
既存のMXレコードを、
example.com. IN MX 10 ASPMX.L.GOOGLE.COM.
example.com. IN MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. IN MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. IN MX 30 ALT3.ASPMX.L.GOOGLE.COM.
example.com. IN MX 30 ALT4.ASPMX.L.GOOGLE.COM.
と変更しました。
さいごに
以上、私が並行運用～移行までに対応した方法になります。
既存メールサーバとGSuiteとの並行運用のポイントとしては、
- MXレコードをGmailのメールサーバに更新するまでは、Gmailにメールは届かないので、Gmailのエイリアスドメインを利用し、既存メールサーバに転送設定をする。
- SPF認証を厳密している受信サーバもあるので、送信元として許可するサーバにgmailの送信サーバをSPFレコードに追加する。
- グループは細かく権限の設定が可能。外部からのメーリングリストとして利用している場合には、デフォルトではなく、外部からの投稿を公開を有効にする必要がある。
- 既存メールクライアントで受信し運用したい方もいるので、その方法は利便性等を考慮し、ルールを決めて提供できるようにする。
運用後にトラブルが発生するようなことがあれば、また別途展開して行きます。
起こしたくは無いですけどね。