Wat moet een productteam beoordelen bij de keuze voor de SMTP-relaydienst van Google?

Begin met de workload en de beheerfit

De SMTP-relaydienst van Google is een beheerroute binnen Google Workspace voor applicaties, apparaten en mailservers die via smtp-relay.gmail.com verzenden. Beoordeel hem als onderdeel van de Workspace- en mailbeveiligingsgrens van de organisatie, niet als een algemeen anoniem SMTP-endpoint. Stel vast wie de superbeheerder van Workspace is, welke domeinen in het account zitten, welke bronsystemen, publieke uitgaande IP-adressen, afzenderadressen en berichtklassen er zijn, wat het piek- en dagvolume aan ontvangers is, welk bijlageprofiel er geldt en wie het contactpunt bij incidenten is. Bepaal of de workload transactioneel, intern operationeel, door gebruikers opgesteld, bulkmail op basis van inschrijving of door apparaten gegenereerd is. Houd die klassen gescheiden, want de behoeften rond autorisatie, toestemming, suppressie, audit en reputatie verschillen. Bevestig dat lagere omgevingen geen productieroutes of klantadressen kunnen gebruiken. Een relay kan een geautoriseerd bericht transporteren; hij beslist niet of het bedrijfsevent legitiem is, of een ontvanger toestemming heeft gegeven of dat de applicatiestatus verder moet gaan.

Vergelijk IP-autorisatie met SMTP-authenticatie

Met de huidige configuratie van Google kunnen beheerders de relay beperken tot opgegeven publieke IP-adressen, SMTP-authenticatie via TLS vereisen of beleidskeuzes combineren volgens de gedocumenteerde instelling. Stabiele IP-autorisatie kan passen bij gecontroleerde datacenters of vaste uitgaande gateways, maar wordt kwetsbaar achter veranderende cloud-NAT, meerdere regio's, failoverdiensten of netwerken van derden. SMTP-authenticatie identificeert een Workspace-account en verzenddomein, maar brengt de levenscyclus van credentials, gebruikersstatus, interacties met meervoudige authenticatie en beleid, en een harde eis voor TLS met zich mee. Gebruik nooit één brede credential voor meerdere tenants of niet-gerelateerde applicaties. Documenteer voor elke optie wie een IP-adres of account kan toevoegen, hoe wijzigingen worden beoordeeld, hoe een compromittering wordt gedetecteerd, hoe toegang wordt ingetrokken en wat failover doet. Houd toegestane IP-bereiken zo klein als praktisch mogelijk en verifieer het publieke uitgaande adres vanuit de werkelijke runtime in plaats van een intern adres te kopiëren.

Leg toegestane afzenders en domeinidentiteit vast

De relay-instelling in de Admin-console bepaalt welke afzenders zijn toegestaan. Google documenteert opties die gekoppeld zijn aan geregistreerde Apps-gebruikers en adressen in eigen domeinen, plus een bredere optie voor elk adres die de blootstelling aan misbruik vergroot. Kies de smalste optie waaraan de workload kan voldoen. Inventariseer de SMTP-envelope-afzender los van de zichtbare velden From en Reply-To. Google merkt op dat wanneer een afzender buiten de accountdomeinen valt, SMTP AUTH of een domein dat in HELO of EHLO wordt opgegeven kan beïnvloeden hoe de envelope-afzender wordt geïdentificeerd of herschreven. Vertrouw niet op herschrijven als vervanging voor een model met eigen afzenders. Eis een goedgekeurde koppeling tussen applicatie, tenant, berichtklasse, envelope-afzender, zichtbaar From-domein en return path. Blokkeer willekeurige headers van gebruikers, newline-injectie en From-adressen van andere tenants voordat je verbinding maakt met Google. Test de routering van bounces en afwezigheidsberichten, inclusief een lege envelope-afzender, zonder de hele instelling te verzwakken.

Vereis bewust transportbeveiliging

De actuele relaygids van Google verwijst on-premise systemen met TLS naar smtp-relay.gmail.com op poort 587 en legt uit dat SMTP-authenticatie TLS vereist. De beheerinstelling kan ook TLS vereisen voor verbindingen vanaf de verzendende server. Schakel verplichte TLS in voor productie, tenzij een gedocumenteerde legacybeperking een tijdgebonden uitzondering heeft. Valideer de servernaam, de certificaatketen, het ondersteunde protocol- en cipherbeleid, de STARTTLS-onderhandeling en het gedrag bij fouten. De client moet veilig falen als de vereiste TLS niet tot stand kan worden gebracht; stilzwijgend terugvallen op plaintext ondermijnt het beleid. Bescherm SMTP-credentials in een beheerde secret store en houd ze buiten commandoregels, URL's, broncode, logs, analytics, crashrapporten en tickets. Transport-TLS beschermt de hop naar Google, niet de hele levenscyclus van het bericht of de mailbox. Gevoelige inhoud kan maatregelen op applicatieniveau, dataminimalisatie, bewaartermijnen en afzonderlijke beslissingen over end-to-end-versleuteling vereisen.

Modelleer de actuele quota voordat je de relay kiest

Volgens de actuele installatiedocumentatie van de SMTP-relay van Google kan elke gebruiker binnen 24 uur maximaal 10.000 berichten verzenden naar niet meer dan 10.000 unieke ontvangers, met mogelijk lagere limieten tijdens een proefperiode. De documentatie noemt ook een limiet van 100 ontvangers per SMTP-transactie en aanvullende controles per klant, voor pieken en per dag. Behandel deze als actuele gedocumenteerde plafonds, niet als capaciteitsdoel of permanent contract. Controleer vóór de lancering de officiële pagina opnieuw voor het account en de workload. Reken in ontvangers, niet alleen in berichten, over To, Cc, Bcc, retries en fan-out. Stel rate-, gelijktijdigheids-, queueleeftijds- en tenant-fairnesscontroles op applicatieniveau in onder de limieten van Google. Geef meldingen bij versnelling en bij de resterende ruimte. Reageer niet op een limiet door verkeer te verdelen over niet-geautoriseerde accounts, envelope-afzenders te roteren of ongecontroleerde verbindingen te openen. Een workload die regelmatig een gedeelde Workspace-grens nadert, heeft mogelijk een evaluatie van een specifiek daarvoor ontworpen transport nodig.

Bouw een duurzame submissionworkflow

Plaats de SMTP-client achter een geautoriseerde serverworker of queue. Sla één uitgaande job op met een stabiele sleutel voor het bedrijfsevent, tenant, berichtklasse, templaterevisie, goedgekeurde afzender en ontvangers, grondslag van toestemming of noodzaak, suppressiebeslissing en pogingsgeschiedenis. Reserveer die job één keer, render en valideer de inhoud en maak daarna verbinding met het geconfigureerde endpoint van Google. Begrens het aantal ontvangers per transactie en de berichtgrootte volgens de actuele limieten en het productbeleid. Leg het volledige SMTP-antwoord, de enhanced status code, de externe host, het tijdstempel en de identifier van de poging vast zonder credentials of onnodige inhoud te loggen. Als de relay de DATA-transactie accepteert, markeer dan alleen de acceptatiefase bij de provider of relay. Als de client een timeout krijgt na het verzenden van de data maar vóór het ontvangen van het definitieve antwoord, houd de poging dan op onbekend en reconcilieer hem voordat je opnieuw verstuurt. SMTP biedt geen idempotentiesleutel voor applicaties; controle op duplicaten hoort dus thuis in de queue en het eventmodel van het product.

Classificeer relayfouten in plaats van alles opnieuw te proberen

De foutpagina van de SMTP-relay van Google documenteert afzonderlijke situaties, waaronder geweigerde mailrelay, ongeldige relaycredentials of domeinidentificatie, overschreden daglimiet, tijdelijk uitstel door een pieklimiet en te veel ontvangers in één transactie. Leg het exacte antwoord vast en koppel het aan een nauw afgebakende interne categorie. Herstel fouten in configuratie, afzenderdomein, credentials, IP en het aantal ontvangers per transactie voordat je opnieuw afspeelt. Pauzeer of herplan werk nadat de daglimiet is bereikt. Probeer geschikte tijdelijke piek- of transportfouten opnieuw met exponential backoff, jitter, een maximum aantal pogingen en limieten op de queueleeftijd. Probeer een permanente respons nooit eindeloos opnieuw. Als een fout een niet-geregistreerd IP-adres noemt, bevestig dan het werkelijke publieke uitgaande adres van de runtime en de juiste Workspace-instelling in plaats van de allowlist te verruimen. Bewaar privacyvriendelijke geaggregeerde tellingen per bronsysteem, configuratierevisie, afzenderdomein, statusklasse en tijd. Geef meldingen bij nieuwe antwoorden en pieken in authenticatiefouten, want die kunnen wijzen op beleidsdrift, ingetrokken credentials, een NAT-wijziging of misbruik.

Authenticeer de afzender verder dan alleen relaytoegang

Toestemming om de relay van Google te gebruiken is niet hetzelfde als afzenderauthenticatie richting ontvangers. Publiceer een SPF-beleid dat het werkelijke verzendpad voor de envelope-identiteit autoriseert, configureer DKIM-ondertekening met een domein dat de organisatie beheert en dat uitgelijnd is voor DMARC, en publiceer een beoordeeld DMARC-beleid voor het zichtbare From-domein. Verifieer het ruwe ontvangen bericht vanuit gecontroleerde externe mailboxen. Leg het SPF-resultaat en -domein, het DKIM-resultaat, het d=-domein en de selector, het zichtbare From-domein, de alignment en het DMARC-resultaat vast. Een technisch geldige handtekening van een provider of Workspace kan niet-uitgelijnd blijven met een aangepast From-domein. Doorsturen kan het SPF-bewijs ook veranderen. Voeg geen tweede SPF-record toe en verzwak DMARC niet voor de hele organisatie alleen om één test te laten slagen. Stem af tussen DNS- en mailbeheerders, bewaar eerdere records, test gezaghebbende en recursieve antwoorden en rol per keer één identiteitswijziging uit.

Eis observability en een getest exitpad

Gebruik het zoeken in e-maillogs in Google Admin en logs aan de relaykant waar beschikbaar, maar houd het uitgaande register van het product zelf als beslissysteem. Monitor queueleeftijd, acceptatie, tijdelijke en permanente responses, limietgebruik, bounce- en klachtsignalen, authenticatie en latentie per berichtklasse en afzenderdomein. Beperk de toegang en vermijd volledige adressen of inhoud in routinematige statistieken. Test wijzigingen van het bron-IP, rotatie van credentials, TLS-fouten, uitschakeling van de beheerinstelling, opschorting van gebruikers, het bereiken van limieten, fan-out naar ontvangers, DNS-wijzigingen en een storing bij de provider. Definieer een terugdraaiprocedure die de betreffende groep kan pauzeren zonder duurzame jobs te verliezen. Isoleer bij een migratie providerspecifieke SMTP-velden in één adapter en behoud sleutels van bedrijfsevents, suppressiestatus, afzenderautorisatie en pogingsgeschiedenis. Een tweede relay mag geen automatische omweg worden voor permanente afwijzingen door beleid of ontvangers. Compatibiliteit vereist tests op het niveau van velden en fouten, niet alleen het wijzigen van een hostnaam.

Hoe SendHQ past

SendHQ is een e-mail-API per workspace voor verwachte productcommunicatie, met verzending vanaf geverifieerde domeinen, inkomende e-mail, gehoste templates, bezorgevents, suppressies en een webdashboard. Vergelijk SendHQ met Google Workspace SMTP relay aan de hand van de actuele documentatie en gecontroleerde tests voor account- en tenantgrenzen, credentials en rotatie, handhaving van toegestane afzenders, envelope- en zichtbare identiteiten, TLS-fouten, ontvangerlimieten, tijdelijke en permanente antwoorden, dubbelzinnige uitkomsten, suppressies, het teruglezen van events en migratie.

Veelgestelde vragen

Bronnen

• Route outgoing SMTP relay messages through Google — Google Workspace
• SMTP relay service error messages — Google Workspace
• RFC 3207: SMTP Service Extension for Secure SMTP over TLS — RFC Editor
• RFC 7208: Sender Policy Framework — RFC Editor
• RFC 6376: DomainKeys Identified Mail Signatures — RFC Editor
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor