Hoppa till huvudinnehåll
Central enklicksinstallation. Ingen åtgärd krävs av teammedlemmarna. Användarna ser inte signaturerna när de skriver e-post. Dina e-postmeddelanden bearbetas via Scribes säkra servrar för signaturinjektion.
Plattformar som stöds: webb, dator, Apple Mail, iOS, Android

Så fungerar det

Installation på serversidan ändrar routningen av din e-post, inte dina teammedlemmars brevlådor. Ingenting installeras på deras enheter, och inget tillägg körs i deras e-postklient. I stället lägger konfigurationen nedan till ett extra steg i ditt utgående e-postflöde, och signaturen läggs till varje meddelande medan det är på väg.
  1. En teammedlem skickar ett e-postmeddelande. Gmail tar emot det oavsett vilken klient eller enhet personen använde, så samma regel täcker webben, datorn, Apple Mail, iOS och Android. Verktyg som skickar via en teammedlems brevlåda omfattas också: säljmejl från HubSpot och alla andra CRM-system eller sekvensverktyg som är anslutna till Gmail får signaturen utan extra konfiguration, så länge avsändaradressen (From) tillhör en teammedlem vars signatur du har installerat. Ett verktyg som skickar från sina egna servrar i stället för via Gmail, till exempel HubSpots marknadsföringsmejl, når aldrig den här regeln och får ingen signatur.
  2. Google Workspace dirigerar meddelandet till Scribe. Regeln för innehållsefterlevnad som du skapar nedan matchar utgående och internt utgående e-post och dirigerar den till Scribe-värden, smtp.server.scribe-mail.com, via TLS.
  3. Scribe lägger till signaturen. Scribe infogar teammedlemmens publicerade signatur och väljer rätt variant för sammanhanget. Sedan signeras meddelandet om så att det fortfarande autentiseras efter ändringen, och det förses med headern X-Scribe-Processed.
  4. Meddelandet återvänder till Google Workspace. Scribe skickar tillbaka det via SMTP-relätjänsten, som är konfigurerad att bara ta emot anslutningar från Scribes två IP-adresser och bara via TLS.
  5. Google Workspace levererar det. Headern X-Scribe-Processed hindrar efterlevnadsregeln från att matcha en andra gång, så meddelandet skickas till mottagaren på samma sätt som alla andra meddelanden.
Scribe lägger till signaturen och sina egna headers: X-Scribe-Processed, en routningsheader som talar om för relätjänsten var meddelandet ska lämnas tillbaka, en uppdaterad DKIM-Signature, en ARC-kedja och Content-Type som matchar den omskrivna brödtexten. Dina mottagare, ämnesrad, bilagor och texten som din teammedlem skrev skickas vidare oförändrade.

Installationsguide

Det här är en funktion för avancerade användare. IT-support krävs för att konfigurera den här integrationen.
  • Användare ser inga signaturer när de skriver ett e-postmeddelande.
  • Dina e-postmeddelanden bearbetas via Scribes säkra servrar för att installera signaturer. Scribe kan inte läsa eller redigera dina e-postmeddelanden.
  • Du kan kombinera molnbaserad integration med serversidesintegration. Om båda är anslutna använder Scribe som standard den molnbaserade integrationen så att användare ser sina signaturer när de skriver e-post.
1

Lägg till värd

Skapa en värd i Google Workspace Gmail för att dirigera e-post via Scribes säkra servrar. I Google Admin, gå till Apps → Google Workspace → Gmail och klicka sedan på ‘Hosts’.
Google Admin Gmail Hosts-sektionen

Google Admin Gmail Hosts-sektionen

2

Klicka på länken "ADD ROUTE" och fyll i formuläret

Fyll i formuläret med följande uppgifter:a. Namn: Scribeb. Välj: “Single host”c. Värdnamn eller IP:
d. Port: 25e. Välj: alternativen som i skärmbilden nedan
Formuläret Edit mail route med Scribe-värdkonfiguration

Formuläret Edit mail route med Scribe-värdkonfiguration

3

Konfigurera SMTP-reläet

För att ta emot e-post tillbaka från Scribe för dirigering till mottagare, gå till Apps → Google Workspace → Gmail i Google Admin och klicka sedan på ‘Routing’.
Google Admin Gmail Routing-sektionen

Google Admin Gmail Routing-sektionen

4

Klicka på Configure under "SMTP relay service"

På nästa sida klickar du på Configure under “SMTP relay service”.
Konfigurera-knappen för SMTP-reläet

Knappen Configure för SMTP relay service

5

Fyll i SMTP-reläformuläret

Fyll i formuläret med följande uppgifter:a. Beskrivning: Receive from Scribeb. Autentisering: Markera “Only accept mail from the specified IP addresses”. Lägg till:
och
c. Välj: “Require TLS encryption”d. Klicka på: “Save”
Konfigurationsformulär för SMTP-relätjänsten

Konfigurationsformulär för SMTP-relätjänsten

6

Dirigera e-posten via den skapade värden

I Google Admin, gå till Apps → Google Workspace → Gmail och klicka sedan på ‘Compliance’.
Google Admin Gmail Compliance-sektionen

Google Admin Gmail Compliance-sektionen

7

Klicka på Configure under "Content compliance"

På nästa sida, klicka på Configure under “Content compliance”.
Configure-knappen för Content compliance

Configure-knappen för Content compliance

8

Fyll i Content compliance-formuläret

Fyll i formuläret enligt skärmbilden:a. Beskrivning: Route to Scribeb. Välj: “Outbound messages” och “Internal outbound messages” under “Email messages to affect”c. I det andra konfigurationsobjektet (“Add expressions…”): ställ in matchningen på “If ALL of the following match the message”, klicka sedan på ADD och lägg till dessa tre uttryck av typen Advanced content match:
  • Location: Full headers, Match type: Not contains text, Content: X-Scribe-Processed. Det förhindrar att din e-post bearbetas flera gånger.
  • Location: Envelope sender, Match type: Does not match regex, Regexp: .*@google\.com$. Det utesluter systemmejl som kvitton från Google Formulär (från forms-receipts-noreply@google.com), som Googles SMTP-relä avvisar om de dirigeras via Scribe.
  • Location: Sender header, Match type: Does not match regex, Regexp: .*@google\.com$. Det utesluter mejl som Google skickar för en teammedlems räkning, till exempel påminnelser från Google Kalender. Kuvertavsändaren är teammedlemmen, så det föregående uttrycket fångar inte upp dem, men deras From-adress är calendar-notification@google.com. Om de dirigeras via Scribe klarar de inte google.com:s DMARC-policy: påminnelsen avvisas och teammedlemmen får ett studsmeddelande i stället.
Google visar det senaste uttrycket först, så när alla tre har lagts till visar tabellen Sender header, Envelope sender, Full headers i den ordningen, som i skärmbilden nedan.d. I det tredje konfigurationsobjektet ändrar du rutten till den värd du skapade i del 1 av guiden.e. Välj: “Require secure transport (TLS)”f. Klicka på: “Save”
Konfiguration av formuläret för innehållsefterlevnad

Konfiguration av formuläret för innehållsefterlevnad

9

Lägg till uttrycken för efterlevnadsregeln

Varje uttryck läggs till i en egen modal för Compliance rule expression. För det första uttrycket lägger du till informationen som i skärmbilden:Avancerad innehållsmatchning:
  • Location: Full headers
  • Match type: Not contains text
  • Content: X-Scribe-Processed
Modal för uttryck i efterlevnadsregel med kontroll av huvudfältet X-Scribe-Processed

Modal för uttryck i efterlevnadsregel

Lägg till de två andra på samma sätt: Location “Envelope sender” för den ena och “Sender header” för den andra, båda med Match type “Does not match regex” och det reguljära uttrycket .*@google\.com$.
10

Konfigurera DKIM

Konfigurera DKIM för dina avsändardomäner så att e-postmeddelanden inte hamnar i skräpposten och tillgångar som bilder och länkar inte försvinner.Klicka på Configure DKIM i Scribe för att starta konfigurationen.
Knappen Configure DKIM i Scribe

Knappen Configure DKIM i Scribe

11

Installera teamsignaturer

I signaturlistan installerar du alla signaturer på en gång för dina teammedlemmar eller en i taget för en stegvis utrullning.
Scribes signaturlista med knappen Install Signatures

Scribes signaturlista med knappen Install Signatures

Vanliga frågor om IT och säkerhet

Frågor som oftast dyker upp när ett IT-team granskar den här integrationen.
Bara det som regeln för innehållsefterlevnad matchar: utgående och intern utgående e-post från din organisation. Tre undantag byggs in i regeln när du fyller i formuläret Content compliance.
  • Meddelanden vars fullständiga e-posthuvuden redan innehåller INLINE_C
Inkommande e-post från avsändare utanför din organisation skickas aldrig via Scribe.Om din regel skapades innan det tredje undantaget lades till i den här guiden kan teammedlemmar få felmeddelanden om att deras kalenderpåminnelser inte kunde levereras, med texten 550 5.7.26 Unauthenticated email from google.com is not accepted due to domain's DMARC policy. Redigera regeln i Google Admin och lägg till uttrycket för Sender-huvudet för att stoppa dem.
Ja, i båda riktningarna, och konfigurationen kräver det. Efterlevnadsregeln använder Kräv säker transport (TLS) när den skickar e-post till Scribe, och SMTP-relätjänsten använder Kräv TLS-kryptering när Scribe skickar tillbaka den.
För utgående trafik ansluter ditt e-postflöde till Scribes värd på port 25:
För inkommande trafik skickar Scribe tillbaka bearbetad e-post från två fasta IP-adresser. SMTP-relätjänsten är konfigurerad att bara acceptera dessa:
Det påverkar DKIM, och steget Konfigurera DKIM i guiden hanterar det. När en signatur infogas ändras meddelandets innehåll, vilket gör DKIM-signaturen som Google Workspace lade till innan meddelandet skickades ogiltig. Scribe signerar därför meddelandet på nytt innan det skickas vidare.När DKIM har konfigurerats läggs två saker till i varje bearbetat meddelande:
  • En ny DKIM-Signature, signerad med en nyckel som Scribe genererar för din domän och som publiceras som en scribe._domainkey-post. Den omfattar huvudfälten From, To, Cc, Subject och Message-ID samt meddelandets innehåll.
  • En ARC-kedja (RFC 8617): ARC-Authentication-Results, ARC-Message-Signature och ARC-Seal. Dessa registrerar autentiseringsresultaten som följde med meddelandet när Scribe tog emot det, så att en mottagande server kan avgöra att en behörig mellanhand ändrade det i stället för att tolka ändringen som manipulering.
SPF påverkas inte, eftersom Google Workspace fortfarande står för den slutliga leveransen och meddelandet når din mottagare via Googles egen sändningsinfrastruktur.Omsignering sker först när din DKIM-post har validerats, och därför behandlar guiden det steget som obligatoriskt snarare än valfritt. Hoppar du över det får dina mottagare e-post vars ursprungliga signatur inte längre kan verifieras.
Två saker. Scribe märker varje meddelande det hanterar med huvudet X-Scribe-Processed, och regeln för innehållsefterlevnad matchar bara meddelanden vars fullständiga huvuden inte innehåller det. Ett meddelande som kommer tillbaka från Scribe matchar därför inte längre och levereras som vanligt.Som ett andra skydd kontrollerar Scribe om meddelandetexten redan innehåller signaturen innan en signatur infogas. Ett meddelande som når Scribe två gånger skickas ändå med en enda signatur.
Eftersom signaturen läggs till efter att meddelandet har lämnat brevlådan, inte i skrivfönstret. Av samma anledning är kopian som sparas i avsändarens mapp Skickat versionen från innan Scribe bearbetade meddelandet, så inte heller den visar signaturen. Mottagaren får alltid hela signaturen.Om det är viktigt för dina team att se signaturen när de skriver, anslut även den molnbaserade integrationen. När båda är anslutna använder Scribe den molnbaserade integrationen som standard, så att teammedlemmar ser sin signatur medan de skriver, och serversidan fortsätter att täcka de klienter som den molnbaserade integrationen inte når.
Ja, om du publicerar dem. Signaturvarianter fungerar med installation på serversidan, och Scribe väljer en variant när varje meddelande bearbetas:
  • Vid svar, när ämnesraden börjar med ett svars- eller vidarebefordringsprefix som Re:, Fw: eller Fwd:, inklusive lokaliserade motsvarigheter.
  • Intern, när alla mottagare finns på samma domän som avsändaren.
  • Primär i alla andra fall.
Scribe infogar signaturen, signerar om meddelandet och lämnar det direkt tillbaka till Google Workspace. Scribe agerar inte på det dina teammedlemmar skriver: mottagare, ämnesrad, bilagor och brödtext skickas vidare oförändrade.Scribes kontroller kring detta verifieras som en del av SOC 2 Type II-processen. Se Produktsäkerhet och Infrastruktursäkerhet för de detaljer som din säkerhetsgranskning efterfrågar, eller Trust Center för själva certifieringarna.
Inaktivera regeln för innehållsefterlevnad i Google Admin. E-posten lämnar då Google Workspace direkt igen, utan att passera Scribe och utan någon tillagd signatur. Värd- och SMTP-reläposterna kan ligga kvar, oanvända, tills du bestämmer dig för om du vill ta bort dem.

Relaterade artiklar