MTA-STSとTLS-RPT設定

地味にハードルの高い、MTA-STSの設定から紹介していきます。

設定すべきポリシーの確認

Google Workspaceの管理画面で…例の如く「MTA-STS」と検索すると設定画面（Gmailのコンプライアンス設定）が見つかります。下の方に「MTA-STS」というメニューがあるので確認します。

これは設定済の画面ですが…こんな感じで「おすすめの設定値」を表示してくれます。ポリシー設定値について詳しくはこちらをご確認ください。

上と下はDNSレコードを登録するだけなので簡単ですが…ポリシーの定義は色々準備が大変なので後述します。

2つのDNSレコードですが、設定はこんな感じです。

「_mta-sts」「_smtp.tls」というホスト名はそれぞれ固定なので、Googleのオススメ値をセットすれば良いです。TLS-RPTのruaは、DMARCと同じでも別でも構いません。

そして意外と面倒なポリシー設置

MTA-STSのポリシー設置は、以下のような手順で行います。

なんか簡単そうに見えなくもないですが…多くの会社にとっては

という地味に難易度の高い準備が必要になります。

どんなソリューションで対処すべきか…

どこかのレンサバに会社のホームページを置いていて、「mta-sts」なるサブドメインをバーチャルドメインとして追加できる場合は…比較的簡単にファイル設置が可能かもしれません。Googleソリューションしか使ってない（弊社の場合は、会社ホームページまでGoogleサイトで済ませてますし…）場合、以下の選択肢から検討することになると思います。

契約状況によっては無料（有料の場合も格安）な１が最初の選択肢になるかと思います。ただ私はChromebookで端末Adminでないアカウントで仕事をする都合が多く、そうでない管理者も「Firebase CLIをPCにインストールして操作」することがハードルになるケースもあるかと思います。

2はMTA-STSのためだけにやるには大げさですし、3はとっても良い選択肢な気がしますが…TLS有効化のためにはロードバランサーが必須でロードバランサーが月2〜3000円くらいしてしまうので、折角GCSが安くてもコスパがバク下がりです。

ということで、マニアックではありますが…4の方法を紹介したいと思います。

まだGoogle Cloud利用開始していない場合は…

Google Workspaceを利用していても、まだGoogle Cloudを使ったことのない場合も、Google Cloudにアクセスして無料サービスを使うことは簡単にできます。有料サービスを使う場合は「請求先アカウント」の紐づけが必要となります。Google Workspaceを直接クレジットカード払いで使っている場合は、同じようにクレジットカードを使っての請求先アカウントを作ります。Google Workspaceの利用料を代理店経由で支払っている場合は、代理店に相談してみてください。

初めて使う場合は、ルートの組織に対する権限設定の見直しやフォルダ構成の検討などが必要なのですが、今回はそこは飛ばします。要望があれば記事にしますね。

GAE（Google App Engine）の設定手順

GAEはGoogle Cloudの最初のサービスで…最近はCloud Runにすっかり持っていかれている間がありますが、とっても安定した現役のPaaSです。

まずは、プロジェクトを作成します。「mta-sts」「mta-sts-web」などのわかりやすい名前をつけ、請求先アカウントを紐づけます。

アプリケーションの作成

上部の検索窓を使って「AppEngine」を検索して、ダッシュボードからアプリケーションを作成します。

リージョンは大阪（asia-northeast2）をオススメします。Googleのガイドを見ると…東京（asia-northeast1）は著しいレイテンシが出る可能性があるとのことなので…。ホントかなぁ…。

App Engineデフォルトサービスアカウントをとりあえず選んで置きます。

この設定の次に開発言語を選ぶランタイムの指定などがありますが、スキップししちゃって良いです。

必要ファイルの準備

ローカル環境にこんなディレクトリ構成でファイルを用意します。

mta-sts/

　├ website/

　│　├ index.html

　│　├ .well-known/

　│　│　└ mta-sts.txt

　│　└ bimi/

　│　 　└ bimi_logo.svg
　└ app.yaml

ルートのmta-stsというフォルダは、自由に命名してもらって良いです。index.htmlは最低限…

<!DOCTYPE html>

<html lang="en">

  <head>
    <title>mta-sts</title>

    <meta charset="UTF-8">

  </head>

  <body>

    <h1>mta-sts</h1>

  </body>

</html>

こんなのでも良いので何か置いてください。

「.well-known」という（ドットから始まる名称の）フォルダを作れない場合は「well-known」としておいても良いです。mta-sts.txtは前述のMTA-STSポリシーを記載したテキストファイルです。

bimi/bimi_logo.svgは別記事で解説しますので、ここではスルーしてください。

app.yamlは、AppEngineをデプロイするのに必要な定義ファイルです。とりあえずこんな内容にしておいてください。

runtime: python312


handlers:

- url: /

  static_files: website/index.html

  upload: website/index.html


- url: /

  static_dir: website


Cloud Shell上に展開

必要ファイルの準備が終わったら、画面上部のアイコンをリクックしてCloud Shellを起動して、Cloud Shell上にローカルと同じ環境を作ります。

本当は…ローカルからCloud Build使ってデプロイしたり…そこまで行かなくてもZIPに固めてアップロードしてから展開するなど…やり方は色々あると思いますが、ここでは細かく解説しません。

エディタとターミナルをうまく切り替えてローカル環境を再現してください。大抵はエディタの「右クリックからUpload」と「New Folderボタン」で何とかなります。

.well-knownフォルダの作成は、ターミナルから

mkdir .well-known

として作るなり、

mv well-known/ .well-known/

などでリネームするなりしてみてください。

アプリのデプロイ

ここまでできたらターミナルでapp.yamlのいるディレクトリに移動して

gcloud app deploy

を実行します

Do you want to continue (Y/n)?

と出たら、Yを選びます。もし途中でエラーが出た場合は、エラーメッセージをGeminiに貼り付けて解説してもらってください。もしかして自動的に生成されるCloud Storageに対して、AppEngineのデフォルトサービスアカウントの閲覧権限がなかったりするかもしれません。その時は、Google Cloud内の検索窓から「Cloud Storage」を検索して、当該バケットを見つけて「権限」タブを選択肢、デフォルトサービスアカウントに対して「Storageオブジェクト閲覧者」の権限を付与した上でデプロイを再実行してください。

TLSの設定

ここまで来ると、必要ファイルがGoogleの用意したURLで公開されます。しかしMTA-STSのポリシー公開をするにはカスタムドメインによるTLSアクセスが必要となります。

AppEngineの設定メニューからカスタムドメインタブを選びカスタムドメインを追加クリックします。

コモンネーム（mta-sts.ezworks.orgを使いたい場合はezworks.orgにあたる部分）の所有者証明が必要になります。弊社の場合は…企業サイトをGoogleサイトで済ませていたりするので特別な操作は不要でしたが、必要に応じて対処しやすい所有者確認を実施してください。

所有者確認ができたらドメインを選択した上で、使いたいFQDNをプロジェクト（本画像では、プロジェクト名が「mta-sts-gae」になってます）に紐づけます。

紐づけが完了すると、必要なDNSレコードが表示されます。特別な事情がなければCNAMEだけ設定すれば良いです。

こんな感じで設定できたら、あとは自動的にTLS設定が終わるのを待ちます。

「SSLセキュリティ」のところに処理中の表示が出ます。早い時は数分…遅いと1時間程かかることもあります。正常終了すると証明書IDに数字が入ります。気長に待ちましょう。

証明書が無事発行されたら、ポリシーを公開したURL（弊社の場合「https://mta-sts.ezworks.org/.well-known/mta-sts.txt」）にアクセスしてポリシーが見られるか確認してください。

問題なければGoogle Workspaceの管理コンソールに戻り、「MTA-STS」で検索し、検証機能を使って、設定が有効か確認します。