メインコンテンツへスキップ
一元的なワンクリックインストール。 チームメンバーの操作は不要です。ユーザーがメール作成時に署名を目にすることはありません。署名の挿入はScribeのセキュアなサーバーで処理されます。
対応プラットフォーム: Web、デスクトップ、Apple Mail、iOS、Android

​
仕組み

サーバーサイドのインストールでは、メールのルーティングが変更されるだけで、チームメンバーのメールボックスには手を加えません。各自のデバイスには何もインストールせず、メールクライアントにアドインも導入しません。代わりに、以下の設定によって送信メールフローに 1 ホップが追加され、メッセージが転送中に署名が付与されます。
  1. チームメンバーがメールを送信します。 Gmailは、使用したクライアントやデバイスにかかわらずメールを受け付けるため、同じルールがウェブ、デスクトップ、Apple Mail、iOS、Androidに適用されます。チームメンバーのメールボックス経由で送信するツールも対象です。HubSpotの営業メールや、Gmailに接続されたその他のCRMやシーケンス配信ツールでも、差出人アドレスがメール署名をインストール済みのチームメンバーのものであれば、追加設定なしでメール署名が付加されます。HubSpotのマーケティングメールなど、Gmailを経由せず独自のサーバーから送信するツールにはこのルールが適用されず、メール署名は付加されません。
  2. Google WorkspaceがメールをScribeに転送します。 以下の手順で作成するコンテンツコンプライアンスルールは、送信メールと内部送信メールに一致し、TLS経由でScribeのホストsmtp.server.scribe-mail.comに転送します。
  3. Scribeがメール署名を追加します。 Scribeは状況に適したバリアントを選び、チームメンバーの公開済みメール署名を挿入します。その後、変更後もメールの認証が通るよう再署名し、X-Scribe-Processedヘッダーを付加します。
  4. メールがGoogle Workspaceに戻ります。 ScribeはSMTPリレーサービスを通じてメールを戻します。このサービスは、Scribeの2つのIPアドレスからのTLS接続のみを受け付けるように設定されています。
  5. Google Workspaceがメールを配信します。 X-Scribe-Processedヘッダーによりコンプライアンスルールへの再一致が防がれるため、メールは通常のメールと同じように受信者へ配信されます。
Scribe は、署名と独自のヘッダーを追加します。追加されるのは、X-Scribe-Processed、リレーにメッセージを戻す先を伝えるルーティングヘッダー、更新された DKIM-Signature、ARC チェーン、および書き換え後の本文に対応する Content-Type です。受信者、件名、添付ファイル、チームメンバーが書いた本文はそのまま維持されます。

​
インストールガイド

これは上級者向け機能です。この連携の設定には IT サポートが必要です。
  • メール作成時にユーザーには署名が表示されません。
  • 署名を挿入するために、メールは Scribe のセキュアなサーバーを経由して処理されます。Scribe がメールの内容を読んだり編集したりすることはありません。
  • クラウド型連携とサーバー側連携を併用できます。両方が接続されている場合、メール作成時にユーザーが署名を確認できるよう、Scribe は既定でクラウド型連携を使用します。
1

ホストを追加

Scribe のセキュアなサーバー経由でメールをルーティングするため、Google Workspace の Gmail でホストを作成します。Google Admin で アプリ → Google Workspace → Gmail に移動し、‘Hosts’ をクリックします。
Google Admin の Gmail Hosts セクション

Google Admin の Gmail Hosts セクション

2

"ADD ROUTE" リンクをクリックしてフォームに入力

次の情報をフォームに入力します:a. Name: Scribeb. Select: “Single host”c. Host name or IP:
d. Port: 25e. Select: 下のスクリーンショットのとおりに選択
Scribe ホスト設定のメールルート編集フォーム

Scribe ホスト設定のメールルート編集フォーム

3

SMTP リレーサービスを設定

Scribe から返送されたメールを受信者にルーティングするため、Google Admin で アプリ → Google Workspace → Gmail に移動し、‘Routing’ をクリックします。
Google Admin の Gmail Routing セクション

Google Admin の Gmail Routing セクション

4

"SMTP relay service" の下の Configure をクリック

次のページで、“SMTP relay service” の下にある Configure をクリックします。
SMTPリレーサービスのConfigureボタン

SMTP relay service の Configure ボタン

5

SMTPリレーのフォームを入力

以下の情報でフォームを入力してください:a. Description: Receive from Scribeb. Authentication: “Only accept mail from the specified IP addresses” にチェックを入れ、次を追加します:
および
c. Select: “Require TLS encryption”d. Click: “Save”
SMTPリレーサービスの設定フォーム

SMTPリレーサービスの設定フォーム

6

作成したHost経由でメールをルーティング

Google Adminで Apps → Google Workspace → Gmail に移動し、‘Compliance’ をクリックしてください。
Google AdminのGmail Complianceセクション

Google AdminのGmail Complianceセクション

7

"Content compliance" の下のConfigureをクリック

次のページで、“Content compliance” の下の Configure をクリックしてください。
Content complianceのConfigureボタン

Content complianceのConfigureボタン

8

Content complianceのフォームを入力

スクリーンショットのとおりにフォームを入力してください:a. Description: Route to Scribeb. 選択: “Email messages to affect”で”Outbound messages”と”Internal outbound messages”を選択してください。**c. 2つ目の設定項目(“Add expressions…”)で、一致条件を”If ALL of the following match the message”**に設定し、ADDをクリックして、次の3つの詳細なコンテンツ一致式を追加してください。
  • 場所:Full headers、一致タイプ:Not contains text、コンテンツ:X-Scribe-Processed。これにより、メールが複数回処理されるのを防ぎます。
  • 場所:Envelope sender、一致タイプ:Does not match regex、正規表現:.*@google\.com$。これにより、Googleフォームの受信確認(forms-receipts-noreply@google.comから送信)などのシステムメールを除外します。これらのメールはScribe経由でルーティングされると、GoogleのSMTPリレーで拒否されます。
  • 場所:Sender header、一致タイプ:Does not match regex、正規表現:.*@google\.com$。これにより、Googleカレンダーのリマインダーなど、Googleがチームメンバーに代わって送信するメールを除外します。これらのメールのエンベロープ送信者はチームメンバーであるため、前の式では除外されませんが、Fromアドレスはcalendar-notification@google.comです。Scribe経由でルーティングされるとgoogle.comのDMARCポリシーを満たせず、リマインダーは拒否され、チームメンバーには代わりにバウンスメールが届きます。
Googleでは最新の式が先頭に表示されるため、3つすべてを追加すると、下のスクリーンショットのように表はSender header、Envelope sender、Full headersの順になります。**d. 3番目の設定項目で、**ルートをこのガイドのパート1で作成したホストに変更します。e. 選択:“Require secure transport (TLS)”f. クリック:“Save”
コンテンツ コンプライアンスのフォーム設定

コンテンツ コンプライアンスのフォーム設定

9

コンプライアンス ルールの式を追加

各式は、それぞれ個別のコンプライアンス ルールの式のモーダルで追加します。1つ目の式は、スクリーンショットのとおりに情報を入力してください。高度なコンテンツ一致:
  • **場所:**Full headers
  • **一致タイプ:**Not contains text
  • **コンテンツ:**X-Scribe-Processed
X-Scribe-Processedヘッダーのチェックを設定したコンプライアンス ルールの式のモーダル

コンプライアンス ルールの式のモーダル

同じ方法で残りの2つを追加します。一方はLocationを”Envelope sender”、もう一方は”Sender header”に設定し、どちらもMatch typeを”Does not match regex”、正規表現を.*@google\.com$にします。
10

DKIMを設定

送信ドメインのDKIMを設定すると、メールが迷惑メールフォルダーに振り分けられたり、画像やリンクなどのアセットが表示されなくなったりするのを防げます。ScribeでConfigure DKIMをクリックして設定を開始します。
ScribeのConfigure DKIMボタン

ScribeのConfigure DKIMボタン

11

チームのメール署名をインストール

メール署名の一覧から、チームメンバー全員のメール署名を一括でインストールするか、段階的に展開するために1つずつインストールします。
Install Signaturesボタンが表示されたScribeのメール署名一覧

Install Signaturesボタンが表示されたScribeのメール署名一覧

​
IT・セキュリティに関するよくある質問

ITチームがこの連携を確認する際によく寄せられる質問です。
コンテンツコンプライアンスのルールに一致するメール、つまり組織からの送信メールと内部送信メールのみです。コンテンツコンプライアンスのフォームに入力すると、ルールには次の3つの除外条件が組み込まれます。
  • 完全なヘッダーにすでにX-Scribe-Processedが含まれているメッセージ。これにより、同じメールが二重に処理されることはありません。
  • エンベロープ送信者が.*@google\.com$に一致するメッセージ。Googleフォームの受信確認など、Googleのシステムメールが該当します。このメールをScribe経由でルーティングすると、GoogleのSMTPリレーで拒否されます。
  • Fromアドレスが.*@google\.com$に一致するメッセージ。Googleカレンダーのリマインダーなど、Googleがチームメンバーに代わって送信するメールが該当します。Scribeはgoogle.comとして署名できないため、このメールをScribe経由でルーティングするとgoogle.comのDMARCポリシーに適合しなくなります。
組織外から届く受信メールがScribeにルーティングされることはありません。このガイドに3つ目の除外条件が追加される前にルールを作成した場合、チームメンバーのカレンダーのリマインダーに対して、550 5.7.26 Unauthenticated email from google.com is not accepted due to domain's DMARC policyと表示されるバウンスメールが返されることがあります。これを止めるには、Google Adminでルールを編集し、Senderヘッダーの式を追加してください。
はい。送受信の両方向で暗号化されており、設定によって強制されます。コンプライアンスルールではScribeにメールを渡す際に Require secure transport (TLS) を使用し、SMTPリレーサービスではScribeからメールが戻される際にRequire TLS encryptionを使用します。
送信方向では、メールフローがポート25でScribeホストに接続します:
受信方向では、Scribeは処理済みのメールを2つの固定IPアドレスから返します。SMTPリレーサービスが受け入れるよう設定されているのは、この2つのアドレスのみです:
影響するのはDKIMで、ガイドのConfigure DKIMの手順で対処します。署名を挿入するとメッセージ本文が変更されるため、送信前にGoogle Workspaceが付与したDKIM署名が無効になります。そのため、Scribeはメッセージを送り返す際に再署名します。DKIMを設定すると、処理されるすべてのメッセージに次の2つが追加されます:
  • 新しいDKIM-Signature:Scribeがドメイン用に生成した鍵で署名され、scribe._domainkeyレコードとして公開されます。本文に加え、From、To、Cc、Subject、Message-IDの各ヘッダーが対象です。
  • ARCチェーン(RFC 8617):ARC-Authentication-Results、ARC-Message-Signature、ARC-Seal。これらはScribeが受信した時点でメッセージに含まれていた認証結果を記録するため、受信側のサーバーはその変更を改ざんではなく、承認された中継者による変更として判別できます。
SPFには影響しません。最終的な配信は引き続きGoogle Workspaceが行い、メッセージはGoogle独自の送信インフラから受信者に届くためです。再署名はDKIMレコードが検証された後にのみ行われます。そのため、ガイドではこの手順を任意ではなく必須としています。この手順を省略すると、受信者には元の署名が検証できなくなったメールが届きます。
仕組みは2つあります。Scribeは処理するすべてのメッセージにX-Scribe-Processedヘッダーを付与します。コンテンツコンプライアンスルールは、完全なヘッダーにこのヘッダーを含まないメッセージのみに一致するため、Scribeから戻ってきたメッセージは一致せず、通常どおり配信されます。2つ目の安全策として、Scribeは署名を挿入する前に、本文にすでに署名が含まれているかを確認します。メッセージが2回届いた場合でも、署名が1つだけ付いた状態で送信されます。
署名は作成画面ではなく、メッセージがメールボックスを離れた後に追加されるためです。同じ理由で、送信者の送信済みフォルダーに保存されるコピーはScribeが処理する前のバージョンであるため、こちらにも署名は表示されません。受信者には常に完全な署名が届きます。作成中に署名が表示されることがチームにとって重要な場合は、クラウドベースの連携も接続してください。両方を接続すると、Scribeはデフォルトでクラウドベースを使用するため、チームメンバーは作成中に署名を確認できます。また、クラウドベースでは対応できないクライアントは、引き続きサーバーサイドでカバーされます。
はい、公開していれば付きます。署名バリアントはサーバーサイドのインストールでも機能し、Scribeは各メッセージを処理する際にいずれか1つを選択します:
  • 返信時(On-reply):件名がRe:、Fw:、Fwd:など、返信や転送の接頭辞(各言語の表記を含む)で始まる場合。
  • 社内(Internal):すべての受信者が送信者と同じドメインに属する場合。
  • プライマリー(Primary):上記以外のすべての場合。
Scribeは署名を挿入してメッセージに再署名し、そのままGoogle Workspaceに戻します。チームメンバーが書いた内容には手を加えません。受信者、件名、添付ファイル、本文は変更されずにそのまま渡されます。これに関するScribeの管理体制は、SOC 2 Type IIのプロセスの一環として検証されています。セキュリティ審査で求められる詳細は製品のセキュリティとインフラストラクチャーのセキュリティを、認証そのものはTrust Centerをご覧ください。
Google Adminでコンテンツコンプライアンスルールを無効にしてください。メールは再びGoogle Workspaceから直接送信され、Scribeを経由せず、署名も追加されません。ホストとSMTPリレーのエントリーは、削除するかどうかを決めるまで、未使用のまま残しておけます。

​
関連記事