메인 콘텐츠로 건너뛰기
중앙 집중식 원클릭 설치. 팀원이 별도로 조치할 필요가 없어요. 사용자는 이메일을 작성할 때 서명을 볼 수 없어요. 서명 삽입을 위해 이메일은 Scribe의 보안 서버를 거쳐 처리돼요.
지원 플랫폼: Web, Desktop, Apple Mail, iOS, Android

작동 방식

서버 측 설치는 메일 라우팅을 변경하며, 팀원의 메일함은 건드리지 않아요. 팀원의 기기에는 아무것도 설치되지 않고, 이메일 클라이언트에서 실행되는 부가 기능도 없어요. 대신 아래 설정은 발신 메일 흐름에 한 단계를 추가하며, 서명은 메시지가 전송되는 도중에 삽입돼요.
  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의 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에서 Apps → 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에서 Apps → 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. 선택: “Require TLS encryption”d. 클릭: “Save”
SMTP 릴레이 서비스 설정 양식

SMTP 릴레이 서비스 설정 양식

6

생성한 호스트로 이메일 라우팅

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. 두 번째 구성 항목(“Add expressions…”)에서 일치 조건을 **“If ALL of the following match the message”**로 설정한 다음, ADD를 클릭하고 다음 Advanced content match 표현식 세 개를 추가하세요:
  • 위치: 전체 헤더, 일치 유형: 텍스트를 포함하지 않음, 콘텐츠: X-Scribe-Processed. 이메일이 여러 번 처리되지 않도록 해요.
  • 위치: 봉투 발신자, 일치 유형: 정규 표현식과 일치하지 않음, 정규 표현식: .*@google\.com$. Google Forms 접수 확인 메일(forms-receipts-noreply@google.com에서 발송)과 같은 시스템 메일을 제외해요. 이 메일이 Scribe를 거치면 Google의 SMTP 릴레이에서 거부돼요.
  • 위치: 발신자 헤더, 일치 유형: 정규 표현식과 일치하지 않음, 정규 표현식: .*@google\.com$. Google Calendar 알림처럼 Google이 팀원을 대신해 보내는 메일을 제외해요. 이런 메일의 봉투 발신자는 팀원이므로 앞의 표현식으로는 걸러지지 않지만, From 주소는 calendar-notification@google.com이에요. Scribe를 거치면 google.com의 DMARC 정책을 위반해 알림이 거부되고, 팀원은 알림 대신 반송 메일을 받게 돼요.
Google은 가장 최근에 추가한 표현식을 맨 위에 표시해요. 따라서 세 가지를 모두 추가하면 아래 스크린샷처럼 표에 발신자 헤더, 봉투 발신자, 전체 헤더 순으로 표시돼요.d. 세 번째 설정 항목에서 경로를 이 가이드의 1부에서 만든 호스트로 변경하세요.e. 선택: “Require secure transport (TLS)”f. 클릭: “Save”
콘텐츠 규정 준수 양식 설정

Content compliance form configuration

9

규정 준수 규칙 표현식 추가

각 표현식은 별도의 규정 준수 규칙 표현식 대화상자에서 추가해요. 첫 번째 표현식에는 스크린샷에 표시된 정보를 입력하세요:고급 콘텐츠 일치:
  • 위치: 전체 헤더
  • 일치 유형: 텍스트를 포함하지 않음
  • 콘텐츠: X-Scribe-Processed
X-Scribe-Processed 헤더 확인이 설정된 규정 준수 규칙 표현식 대화상자

Compliance rule expression modal

나머지 두 조건도 같은 방식으로 추가하세요. 위치는 하나는 “Envelope sender”, 다른 하나는 “Sender header”로 설정하고, 둘 다 일치 유형은 “Does not match regex”, 정규식은 .*@google\.com$로 설정하세요.
10

DKIM 설정

이메일이 스팸 폴더로 분류되거나 이미지와 링크 같은 요소가 누락되지 않도록 발신 도메인에 DKIM을 설정하세요.Scribe에서 DKIM 설정을 클릭해 설정을 시작하세요.
Scribe의 DKIM 설정 버튼

Configure DKIM button in Scribe

11

팀 이메일 서명 설치

이메일 서명 목록에서 모든 팀원의 이메일 서명을 한 번에 설치하거나, 하나씩 설치해 단계적으로 적용하세요.
이메일 서명 설치 버튼이 있는 Scribe 이메일 서명 목록

Scribe signatures list with Install Signatures button

IT 및 보안 관련 자주 묻는 질문

IT 팀이 이 연동을 검토할 때 가장 자주 묻는 질문이에요.
콘텐츠 규정 준수 규칙과 일치하는 이메일만 전달돼요. 조직에서 외부로 보내는 이메일과 조직 내부로 보내는 이메일이 해당돼요. 콘텐츠 규정 준수 양식에 값을 입력하면 다음 세 가지 제외 조건이 규칙에 포함돼요.
  • 전체 헤더에 X-Scribe-Processed가 이미 포함된 메시지예요. 같은 메시지가 두 번 처리되지 않도록 제외해요.
  • 봉투 발신자가 .*@google\.com$와 일치하는 메시지예요. Google Forms 접수 확인 이메일 같은 Google 시스템 이메일이 해당돼요. 이 이메일이 Scribe를 거쳐 전달되면 Google의 SMTP 릴레이가 거부해요.
  • From 주소가 .*@google\.com$와 일치하는 메시지예요. Google Calendar 알림처럼 Google이 팀원을 대신해 보내는 이메일이 해당돼요. Scribe는 google.com을 대신해 서명할 수 없으므로, 이 이메일이 Scribe를 거쳐 전달되면 google.com의 DMARC 정책을 충족하지 못해요.
조직 외부에서 들어오는 메일은 Scribe로 라우팅되지 않아요.이 가이드에 세 번째 제외 조건이 추가되기 전에 규칙을 만들었다면, 팀원이 Calendar 알림에 대해 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는 고정 IP 주소 두 개에서 처리된 메일을 반환하며, SMTP 릴레이 서비스는 이 두 주소만 허용하도록 구성되어 있어요.
DKIM에 영향을 주며, 가이드의 Configure DKIM 단계에서 이를 처리해요. 서명을 삽입하면 메시지 본문이 바뀌기 때문에, 메시지가 발송되기 전에 Google Workspace가 적용한 DKIM 서명이 무효화돼요. 따라서 Scribe가 메시지를 다시 내보낼 때 새로 서명해요.DKIM을 구성하면 처리된 모든 메시지에 두 가지가 추가돼요.
  • 새 DKIM-Signature: Scribe가 도메인용으로 생성하고 scribe._domainkey 레코드로 게시한 키로 서명돼요. 본문과 함께 From, To, Cc, Subject, Message-ID 헤더를 포함해요.
  • ARC 체인 (RFC 8617): ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal. Scribe가 메시지를 받았을 때의 인증 결과를 기록하므로, 수신 서버는 변경 사항을 변조로 판단하지 않고 승인된 중개자가 메시지를 수정했다는 것을 알 수 있어요.
Google Workspace가 여전히 최종 전송을 담당하고 Google의 자체 발송 인프라에서 수신자에게 메일을 전달하므로 SPF에는 영향이 없어요.DKIM 레코드가 검증된 후에만 다시 서명해요. 그래서 이 가이드에서는 해당 단계를 선택이 아닌 필수로 안내해요. 이 단계를 건너뛰면 수신자는 원래 DKIM 서명을 더 이상 검증할 수 없는 메일을 받게 돼요.
두 가지 방식으로 방지해요. Scribe는 처리하는 모든 메시지에 X-Scribe-Processed 헤더를 추가해요. 콘텐츠 규정 준수 규칙은 전체 헤더에 이 헤더가 없는 메시지에만 적용되므로, Scribe에서 돌아온 메시지는 더 이상 규칙에 해당하지 않고 정상적으로 전달돼요.두 번째 안전장치로, Scribe는 이메일 서명을 삽입하기 전에 본문에 이미 이메일 서명이 있는지 확인해요. 같은 메시지가 두 번 도착해도 이메일 서명은 하나만 포함된 채로 발송돼요.
이메일 서명은 작성 창이 아니라 메시지가 메일함을 떠난 뒤에 추가되기 때문이에요. 같은 이유로 발신자의 보낸편지함에 저장된 사본도 Scribe가 처리하기 전 버전이라 이메일 서명이 보이지 않아요. 수신자는 항상 전체 이메일 서명이 포함된 메일을 받아요.팀에서 작성 중에도 이메일 서명을 확인해야 한다면 클라우드 기반 연동도 연결하세요. 두 방식이 모두 연결되면 Scribe는 클라우드 기반 연동을 기본으로 사용해 팀원이 작성 중에 이메일 서명을 볼 수 있게 해요. 서버 측 연동은 클라우드 기반 연동이 지원하지 않는 클라이언트를 계속 지원해요.
네, 해당 변형을 게시하면 적용돼요. 이메일 서명 변형은 서버 측 설치에서도 사용할 수 있어요. Scribe는 각 메시지를 처리할 때 다음과 같이 변형을 선택해요:
  • 회신용: 제목이 Re:, Fw:, Fwd: 등 회신 또는 전달 접두사(현지화된 형태 포함)로 시작하는 경우.
  • 내부용: 모든 수신자가 발신자와 같은 도메인에 있는 경우.
  • 기본: 그 외 모든 경우.
Scribe는 서명을 삽입하고 메시지를 다시 서명한 뒤 Google Workspace로 바로 돌려보내요. 팀원이 작성한 내용에는 관여하지 않아요. 수신자, 제목, 첨부 파일, 본문은 변경 없이 그대로 전달돼요.이와 관련된 Scribe의 통제 항목은 SOC 2 Type II 프로세스의 일환으로 검증돼요. 보안 검토에 필요한 세부 정보는 제품 보안과 인프라 보안을, 인증 자체는 트러스트 센터를 참고하세요.
Google Admin에서 콘텐츠 규정 준수 규칙을 비활성화하세요. 그러면 메일이 Scribe를 거치지 않고 서명도 추가되지 않은 채 다시 Google Workspace에서 바로 발송돼요. 호스트 및 SMTP 릴레이 항목은 삭제 여부를 결정할 때까지 사용하지 않은 상태로 그대로 둘 수 있어요.

관련 문서

  • 연동 개요: 클라우드 또는 서버 측에서 Scribe 서명을 배포하는 모든 방법.
  • Microsoft 365(서버 측): 메일을 Scribe로 라우팅해 모든 기기에 서명 적용.
  • 서명 변형: Outlook 및 서버 측을 위한 회신용·내부용 변형.