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

​
仕組み

サーバーサイドのインストールでは、メールのルーティングが変更されるだけで、チームメンバーのメールボックスには手を加えません。各自のデバイスには何もインストールせず、メールクライアントにアドインも導入しません。代わりに、以下の設定によって送信メールフローに 1 ホップが追加され、メッセージが転送中に署名が付与されます。
  1. チームメンバーがメールを送信します。 Gmailは、使用したクライアントやデバイスを問わずメールを受け付けるため、同じルールでWeb、デスクトップ、Apple Mail、iOS、Androidをカバーできます。チームメンバーのメールボックス経由で送信するツールも対象です。HubSpotのセールスメールや、Gmailに接続されたその他のCRM・シーケンサーは、送信者アドレスが署名をインストール済みのチームメンバーのものであれば、追加設定なしで署名を取得します。Gmail経由ではなく独自のサーバーから送信するツール(HubSpotのマーケティングメールなど)は、このルールに到達しないため署名は付与されません。
  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. Select: “Email messages to affect” で “Outbound” と “Internal - sending” を選択c. 2番目の設定項目(“Add expressions…”)で、 マッチングを “If ALL of the following match the message” に設定し、ADD をクリックして、以下2つのAdvanced content match式を追加してください:
  • Location: Full headers、Match type: Does not contain text、Content: X-Scribe-Processed。これにより、同じメールが複数回処理されることを防ぎます。
  • Location: Envelope sender、Match type: Does not match regex、Regexp: .*@google\.com$。これにより、Google Forms の受信通知(forms-receipts-noreply@google.com から送信)などのシステムメールを除外します。これらはScribe経由でルーティングするとGoogleのSMTPリレーが拒否します。
d. 3番目の設定項目で、 本ガイドのパート1で作成したホストにルートを変更してください。e. 選択: “Require secure transport (TLS)”f. クリック: “Save”
コンテンツコンプライアンスフォームの設定

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

9

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

Compliance rule expression モーダルで、スクリーンショットのとおり情報を追加します:詳細コンテンツマッチ:
  • Location: Full headers
  • Match type: Not contains text
  • Content: X-Scribe-Processed
X-Scribe-Processed ヘッダーチェックが設定されたコンプライアンスルール式モーダル

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

10

DKIM を設定

送信ドメインに DKIM を設定して、メールが迷惑メールフォルダーに振り分けられるのを防ぎ、画像やリンクなどのアセットが欠落しないようにします。Scribe で Configure DKIM をクリックして設定を開始します。
Scribe の Configure DKIM ボタン

Scribe の Configure DKIM ボタン

11

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

署名一覧から、チームメンバー全員分の署名を一括でインストールするか、段階的な展開のため 1 つずつインストールできます。
Install Signatures ボタン付きの Scribe 署名一覧

Install Signatures ボタン付きの Scribe 署名一覧

​
IT・セキュリティ FAQ

IT チームがこの連携を確認する際に、最も多く寄せられる質問です。
コンテンツコンプライアンスルールに一致するメールのみです。組織からの送信メールおよび内部送信メールが対象になります。Content compliance フォームに入力すると、ルールには 2 つの除外条件が自動的に組み込まれます。
  • フルヘッダーにすでに X-Scribe-Processed を含むメッセージ。これにより二重処理を防ぎます。
  • エンベロープ送信者が .*@google\.com$ に一致するメッセージ。Google フォームの受領通知など Google のシステムメールが該当します。これらのメールを Scribe 経由でルーティングすると、Google の SMTP リレーで拒否されます。
組織外からの受信メールがScribeに転送されることはありません。
はい、双方向で暗号化され、設定によって強制されます。コンプライアンスルールは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から戻ってきたメッセージはルールに一致せず、通常どおり配信されます。第二の保護として、Scribeは本文にすでに署名が含まれているかを確認したうえで挿入します。仮に同じメッセージが2回到達しても、送信されるのは署名が1つだけのメッセージです。
署名は作成画面ではなく、メッセージがメールボックスを離れた後に付与されるためです。同じ理由で、送信者の送信済みフォルダーに保存されるコピーはScribeが処理する前のバージョンとなり、こちらにも署名は表示されません。受信者には常に完全な署名が届きます。作成中の表示がチームで重要な場合は、クラウドベースの連携も併せて接続してください。両方を接続するとScribeはクラウドベースを既定として使用するため、チームメンバーは作成中に署名を確認でき、サーバーサイドはクラウドベースが対応できないクライアントを引き続きカバーします。
はい、公開している場合は付きます。署名バリアントはサーバーサイド設置と連動し、Scribeは各メッセージの処理時に該当するものを選択します:
  • 返信時:件名がRe:、Fw:、Fwd:などの返信・転送プレフィックス(各言語のローカライズ版を含む)で始まる場合。
  • 社内:すべての受信者が送信者と同じドメインに属する場合。
  • プライマリ:上記以外のすべての場合。
Scribeは署名を挿入し、メッセージを再署名して、そのままGoogle Workspaceへ返します。チームメンバーが書いた内容には手を加えません。宛先、件名、添付ファイル、本文はそのまま通過します。この点に関するScribeの管理策は、SOC 2 Type IIプロセスの一環として検証されています。セキュリティレビューで求められる詳細は製品セキュリティおよびインフラセキュリティを、認証そのものについてはTrust Centerをご覧ください。
Google Adminでコンテンツコンプライアンスルールを無効化します。以降、メールは再びGoogle Workspaceから直接送信され、Scribeを経由せず署名も追加されません。ホストとSMTPリレーの設定は、削除するかどうかを判断するまで、使用されないまま残しておけます。

​
関連記事

  • 連携の概要:クラウド側・サーバー側を含む、Scribe署名を展開するすべての方法。
  • Microsoft 365(サーバー側):Scribeを経由してメールをルーティングし、すべてのデバイスをカバー。
  • 署名バリアント:Outlookおよびサーバー側向けの、返信用・社内用バリアント。