Cosa dovrebbe valutare un team di prodotto nella scelta del servizio di relay SMTP di Google?

Parti dall'adeguatezza al carico di lavoro e al modello amministrativo

Il servizio di relay SMTP di Google è un percorso amministrativo di Google Workspace per applicazioni, dispositivi e server di posta che inviano tramite smtp-relay.gmail.com. Valutalo come parte del perimetro di Workspace e di sicurezza della posta dell'organizzazione, non come un generico endpoint SMTP anonimo. Individua il super amministratore di Workspace responsabile, i domini dell'account, i sistemi di origine, gli IP pubblici di uscita, gli indirizzi dei mittenti, le classi di messaggi, il volume di destinatari di picco e giornaliero, il profilo degli allegati e il contatto per gli incidenti. Stabilisci se il carico di lavoro è transazionale, operativo interno, composto dagli utenti, inviato in massa a iscritti o generato da dispositivi. Tieni separate queste classi, perché le esigenze di autorizzazione, consenso, soppressione, audit e reputazione sono diverse. Conferma che gli ambienti non di produzione non possano usare i percorsi di produzione o gli indirizzi dei clienti. Un relay può trasportare un messaggio autorizzato; non decide se l'evento di business sia legittimo, se un destinatario abbia dato il consenso o se lo stato dell'applicazione a valle debba avanzare.

Confronta l'autorizzazione per IP con l'autenticazione SMTP

La configurazione attuale di Google consente agli amministratori di limitare l'accesso al relay a indirizzi IP pubblici specifici, richiedere l'autenticazione SMTP su TLS o combinare le opzioni di policy secondo l'impostazione documentata. L'autorizzazione con IP stabili può andare bene per data center controllati o gateway di uscita fissi, ma diventa fragile con NAT cloud variabili, più regioni, servizi di failover o reti di terze parti. L'autenticazione SMTP identifica un account Workspace e un dominio di invio, ma introduce il ciclo di vita delle credenziali, lo stato dell'utente, interazioni con l'autenticazione a più fattori e le policy, e un requisito rigido di TLS. Non usare mai un'unica credenziale ampia per più tenant o per applicazioni non correlate. Per ogni opzione, documenta chi può aggiungere un IP o un account, come vengono revisionate le modifiche, come viene rilevata una compromissione, come viene revocato l'accesso e cosa succede in caso di failover. Mantieni gli intervalli di IP consentiti il più ristretti possibile e verifica l'indirizzo pubblico di uscita dal runtime effettivo invece di copiare un indirizzo interno.

Definisci i mittenti consentiti e l'identità del dominio

L'impostazione del relay nella Console di amministrazione controlla quali mittenti sono consentiti. Google documenta opzioni legate agli utenti Apps registrati e agli indirizzi nei domini di proprietà, oltre a un'opzione più ampia per qualsiasi indirizzo, che aumenta l'esposizione agli abusi. Scegli l'opzione più ristretta che il carico di lavoro può rispettare. Censisci il mittente della busta SMTP indipendentemente dai campi From e Reply-To visibili. Google segnala che, quando un mittente è esterno ai domini dell'account, SMTP AUTH o un dominio presentato in HELO o EHLO possono influire sul modo in cui il mittente della busta viene identificato o riscritto. Non affidarti alla riscrittura come sostituto di un modello di mittenti di proprietà. Pretendi una mappatura approvata tra applicazione, tenant, classe di messaggi, mittente della busta, dominio From visibile e return path. Blocca intestazioni arbitrarie fornite dagli utenti, l'iniezione di caratteri di nuova riga e indirizzi From di altri tenant prima di collegarti a Google. Testa l'instradamento dei bounce e i messaggi di risposta automatica per assenza, incluso un mittente di busta vuoto, senza indebolire l'intera impostazione.

Richiedi la sicurezza del trasporto in modo deliberato

L'attuale guida al relay di Google indirizza i sistemi on-premise con TLS abilitato verso smtp-relay.gmail.com sulla porta 587 e spiega che l'autenticazione SMTP richiede TLS. L'impostazione della Console di amministrazione può anche richiedere TLS per le connessioni dal server di invio. Abilita TLS obbligatorio in produzione, a meno che un vincolo legacy documentato non preveda un'eccezione limitata nel tempo. Convalida il nome del server, la catena di certificati, la policy di protocolli e cifrari supportati, la negoziazione STARTTLS e il comportamento in caso di errore. Il client deve bloccare la connessione se non è possibile stabilire il TLS richiesto; ripiegare silenziosamente sul testo in chiaro vanifica la policy. Proteggi le credenziali SMTP in un secret store gestito e tienile fuori da righe di comando, URL, codice sorgente, log, analytics, crash report e ticket. Il TLS di trasporto protegge il passaggio verso Google, non l'intero ciclo di vita del messaggio o la casella. I contenuti sensibili possono richiedere controlli a livello di applicazione, minimizzazione dei dati, regole di conservazione e decisioni separate sulla crittografia end-to-end.

Modella le quote attuali prima di scegliere il relay

L'attuale documentazione di configurazione del relay SMTP di Google indica che ogni utente può inviare fino a 10.000 messaggi e a non più di 10.000 destinatari univoci in un periodo di 24 ore, con limiti potenzialmente più bassi durante la prova. Documenta anche un limite di 100 destinatari per transazione SMTP e ulteriori controlli per cliente, di picco e giornalieri. Considera questi valori come tetti attualmente documentati, non come un obiettivo di capacità o un impegno contrattuale permanente. Ricontrolla la pagina ufficiale per l'account e il carico di lavoro prima del lancio. Calcola i destinatari, non solo i messaggi, considerando To, Cc, Bcc, nuovi tentativi e fan-out. Imposta controlli a livello di applicazione su frequenza, concorrenza, età della coda ed equità tra tenant al di sotto dei limiti di Google. Imposta avvisi sull'accelerazione e sul margine residuo. Non reagire a un limite distribuendo il traffico su account non autorizzati, ruotando i mittenti di busta o aprendo connessioni incontrollate. Un carico di lavoro che si avvicina regolarmente a un limite condiviso di Workspace potrebbe richiedere la valutazione di un trasporto dedicato.

Costruisci un flusso di submission affidabile

Metti il client SMTP dietro un worker server autorizzato o una coda. Salva un unico job in uscita con una chiave stabile dell'evento di business, tenant, classe del messaggio, revisione del template, mittente e destinatari approvati, base di consenso o necessità, decisione di soppressione e cronologia dei tentativi. Prendi in carico quel job una sola volta, renderizza e valida il contenuto, poi collegati all'endpoint Google configurato. Limita i destinatari per transazione e la dimensione del messaggio in base ai limiti attuali e alla policy del prodotto. Registra la risposta SMTP completa, il codice di stato esteso, l'host remoto, il timestamp e l'identificatore del tentativo, senza registrare credenziali o contenuti non necessari. Se il relay accetta la transazione DATA, segna solo la fase di accettazione da parte del provider o del relay. Se il client va in timeout dopo aver inviato i dati ma prima di ricevere la risposta finale, mantieni il tentativo come sconosciuto e riconcilialo prima di inviare di nuovo. SMTP non fornisce una chiave di idempotenza applicativa, quindi il controllo dei duplicati spetta alla coda e al modello degli eventi del prodotto.

Classifica gli errori del relay invece di ritentare tutto

La pagina degli errori del relay SMTP di Google documenta condizioni distinte, tra cui relay della posta negato, credenziali o identificazione del dominio non valide per il relay, limite giornaliero superato, rinvio temporaneo per limite di picco e troppi destinatari in una sola transazione. Registra la risposta esatta e associala a una classe interna specifica. Correggi gli errori di configurazione, dominio mittente, credenziali, IP e destinatari per transazione prima di ripetere l'invio. Sospendi o riprogramma il lavoro dopo l'esaurimento del limite giornaliero. Ritenta gli errori temporanei di picco o di trasporto idonei con backoff esponenziale, jitter, un tetto ai tentativi e limiti all'età della coda. Non ritentare mai all'infinito una risposta permanente. Se un errore indica un IP non registrato, conferma il reale indirizzo pubblico di uscita del runtime e l'impostazione Workspace corretta invece di ampliare l'allowlist. Conserva conteggi aggregati, ridotti al minimo per la privacy, per sistema di origine, revisione della configurazione, dominio mittente, classe di stato e periodo. Imposta avvisi su risposte nuove e picchi di autenticazione, perché possono indicare una deriva delle policy, una revoca delle credenziali, un cambio di NAT o un abuso.

Autentica il mittente oltre l'accesso al relay

Il permesso di usare il relay di Google non equivale all'autenticazione del mittente verso i destinatari. Pubblica una policy SPF che autorizzi il percorso di invio effettivo per l'identità della busta, configura la firma DKIM con un dominio controllato dall'organizzazione e allineato a DMARC e pubblica una policy DMARC revisionata per il dominio From visibile. Verifica il messaggio grezzo ricevuto da caselle esterne controllate. Registra risultato e dominio SPF, risultato DKIM, dominio d= e selettore, dominio From visibile, allineamento e risultato DMARC. Una firma del provider o di Workspace tecnicamente valida può restare non allineata con un dominio From personalizzato. Anche l'inoltro può modificare le prove SPF. Non aggiungere un secondo record SPF e non indebolire DMARC per tutta l'organizzazione solo per far superare un test. Coordina gli amministratori DNS e di posta, conserva i record precedenti, testa le risposte autoritative e ricorsive e introduci una modifica di identità alla volta.

Pretendi osservabilità e un percorso di uscita testato

Usa la ricerca nei log email della Console di amministrazione di Google e i log lato relay dove disponibili, ma mantieni il registro degli invii gestito dal prodotto come sistema di riferimento per le decisioni. Monitora età della coda, accettazioni, risposte temporanee e permanenti, utilizzo dei limiti, segnali di bounce e segnalazioni di spam, autenticazione e latenza per classe di messaggi e dominio mittente. Limita gli accessi ed evita indirizzi completi o contenuti nelle metriche di routine. Testa cambi di IP di origine, rotazione delle credenziali, errori TLS, disattivazione dell'impostazione nella Console di amministrazione, sospensione degli utenti, esaurimento dei limiti, fan-out dei destinatari, modifiche DNS e interruzioni del provider. Definisci un rollback che possa sospendere il gruppo interessato senza perdere i job persistenti. Per la migrazione, isola i campi SMTP specifici del provider in un unico adapter e conserva chiavi degli eventi di business, stato delle soppressioni, autorizzazione dei mittenti e cronologia dei tentativi. Un secondo relay non deve diventare un modo automatico per aggirare rifiuti permanenti dovuti a policy o destinatari. La compatibilità richiede test a livello di campi e di errori, non solo il cambio di un hostname.

Come si inserisce SendHQ

SendHQ è un'API email con ambito limitato al workspace per comunicazioni di prodotto previste, con invio da domini verificati, email in entrata, template ospitati, eventi di consegna, soppressioni e dashboard web. Confrontala con il relay SMTP di Google Workspace tramite la documentazione corrente e test controllati per confini di account e tenant, credenziali e rotazione, applicazione dei mittenti consentiti, busta e identità visibili, errori TLS, limiti dei destinatari, risposte temporanee e permanenti, esiti ambigui, soppressioni, lettura degli eventi e migrazione.

Domande frequenti

Fonti

• Instradare i messaggi in uscita tramite il relay SMTP di Google — Google Workspace
• Messaggi di errore del servizio di relay SMTP — Google Workspace
• RFC 3207: estensione del servizio SMTP per SMTP sicuro su TLS — RFC Editor
• RFC 7208: Sender Policy Framework (SPF) — RFC Editor
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — RFC Editor
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor
• RFC 5321: Simple Mail Transfer Protocol (SMTP) — RFC Editor