¿Qué debe evaluar un equipo de producto al elegir el servicio de relay SMTP de Google?

Empiece por el encaje con la carga de trabajo y la administración

El servicio de relay SMTP de Google es una vía administrativa de Google Workspace para aplicaciones, dispositivos y servidores de correo que envían a través de smtp-relay.gmail.com. Evalúelo como parte del perímetro de Workspace y de seguridad del correo de la organización, no como un endpoint SMTP anónimo genérico. Identifique al superadministrador responsable de Workspace, los dominios de la cuenta, los sistemas de origen, las IP públicas de salida, las direcciones de remitente, las clases de mensaje, el volumen de destinatarios diario y en picos, el perfil de adjuntos y el contacto para incidentes. Decida si la carga de trabajo es transaccional, operativa interna, redactada por usuarios, masiva con suscripción o generada por dispositivos. Mantenga esas clases separadas, porque sus necesidades de autorización, consentimiento, supresión, auditoría y reputación difieren. Confirme que los entornos inferiores no puedan usar las rutas de producción ni las direcciones de los clientes. Un relay puede transportar un mensaje autorizado; no decide si el evento de negocio es legítimo, si un destinatario dio su consentimiento ni si el estado posterior de la aplicación debe avanzar.

Compare la autorización por IP con la autenticación SMTP

La configuración actual de Google permite a los administradores restringir la entrada al relay a direcciones IP públicas especificadas, exigir autenticación SMTP sobre TLS o combinar opciones de política según la configuración documentada. La autorización por IP estable puede ser adecuada para centros de datos controlados o pasarelas de salida fijas, pero se vuelve frágil detrás de un NAT en la nube cambiante, varias regiones, servicios de conmutación por error o redes de terceros. La autenticación SMTP identifica una cuenta de Workspace y un dominio de envío, pero introduce el ciclo de vida de las credenciales, el estado del usuario, interacciones con la autenticación multifactor y las políticas, y un requisito estricto de TLS. Nunca use una única credencial amplia para varios tenants o aplicaciones no relacionadas. Para cada opción, documente quién puede agregar una IP o una cuenta, cómo se revisan los cambios, cómo se detecta un compromiso, cómo se revoca el acceso y qué hace la conmutación por error. Mantenga los rangos de IP permitidos tan reducidos como sea práctico y verifique la dirección pública de salida desde el entorno de ejecución real en lugar de copiar una dirección interna.

Defina los remitentes permitidos y la identidad del dominio

La configuración del relay en la consola de administración controla qué remitentes están permitidos. Google documenta opciones vinculadas a los usuarios de Apps registrados y a las direcciones de los dominios propios, así como una opción más amplia de cualquier dirección que aumenta la exposición al abuso. Elija la opción más restringida que la carga de trabajo pueda cumplir. Haga un inventario del remitente del sobre SMTP de forma independiente de los campos From y Reply-To visibles. Google señala que, cuando un remitente está fuera de los dominios de la cuenta, SMTP AUTH o un dominio presentado en HELO o EHLO pueden afectar a cómo se identifica o se reescribe el remitente del sobre. No confíe en la reescritura como sustituto de un modelo de remitentes propios. Exija una correspondencia aprobada entre aplicación, tenant, clase de mensaje, remitente del sobre, dominio From visible y return path. Bloquee los encabezados arbitrarios proporcionados por usuarios, la inyección de saltos de línea y las direcciones From de otros tenants antes de conectarse a Google. Pruebe el enrutamiento de rebotes y las respuestas automáticas de ausencia, incluido un remitente del sobre vacío, sin relajar la configuración completa.

Exija la seguridad del transporte de forma deliberada

La guía actual del relay de Google dirige los sistemas locales con TLS habilitado a smtp-relay.gmail.com en el puerto 587 y explica que la autenticación SMTP requiere TLS. La configuración de la consola de administración también puede exigir TLS para las conexiones del servidor de envío. Active TLS obligatorio en producción, salvo que una restricción heredada documentada tenga una excepción limitada en el tiempo. Valide el nombre del servidor, la cadena de certificados, la política de protocolos y cifrados admitidos, la negociación STARTTLS y el comportamiento ante fallos. El cliente debe fallar de forma segura (cerrada) si no puede establecerse el TLS obligatorio; recurrir en silencio a texto sin cifrar anula la política. Proteja las credenciales SMTP en un almacén de secretos gestionado y manténgalas fuera de líneas de comandos, URL, código fuente, registros, analíticas, informes de fallos y tickets. El TLS de transporte protege el salto hasta Google, no todo el ciclo de vida del mensaje ni el buzón. El contenido sensible puede requerir controles a nivel de aplicación, minimización de datos, retención y decisiones separadas de cifrado de extremo a extremo.

Modele las cuotas actuales antes de elegir el relay

La documentación actual de configuración del relay SMTP de Google indica que cada usuario puede enviar hasta 10.000 mensajes y a no más de 10.000 destinatarios únicos en un periodo de 24 horas, con límites posiblemente más bajos durante la prueba. También documenta un límite de 100 destinatarios por transacción SMTP y controles adicionales por cliente, en picos y diarios. Trátelos como límites máximos documentados actualmente, no como un objetivo de capacidad ni un contrato permanente. Vuelva a consultar la página oficial para la cuenta y la carga de trabajo antes del lanzamiento. Calcule los destinatarios, no solo los mensajes, teniendo en cuenta To, Cc, Bcc, los reintentos y la difusión a varios destinatarios. Sitúe los controles de frecuencia, concurrencia, antigüedad de la cola y equidad entre tenants de la aplicación por debajo de los límites de Google. Genere alertas ante aceleraciones y sobre el margen restante. No responda a un límite repartiendo el tráfico entre cuentas no autorizadas, rotando remitentes del sobre ni abriendo conexiones sin control. Una carga de trabajo que se acerca con regularidad a un límite compartido de Workspace puede necesitar la evaluación de un transporte diseñado para ese fin.

Construya un flujo de envío duradero

Coloque el cliente SMTP detrás de un worker de servidor autorizado o de una cola. Guarde una única tarea saliente con una clave estable del evento de negocio, el tenant, la clase de mensaje, la revisión de la plantilla, el remitente y los destinatarios aprobados, la base de consentimiento o necesidad, la decisión de supresión y el historial de intentos. Reclame esa tarea una sola vez, renderice y valide el contenido y luego conéctese al endpoint de Google configurado. Limite los destinatarios por transacción y el tamaño del mensaje según los límites actuales y la política del producto. Registre la respuesta SMTP completa, el código de estado extendido, el host remoto, la marca de tiempo y el identificador del intento sin registrar credenciales ni contenido innecesario. Si el relay acepta la transacción DATA, marque únicamente la etapa de aceptación por el proveedor o el relay. Si el cliente agota el tiempo de espera después de enviar los datos pero antes de observar la respuesta final, mantenga el intento como desconocido y concílielo antes de reenviar. SMTP no ofrece una clave de idempotencia de aplicación, así que el control de duplicados corresponde a la cola y al modelo de eventos del producto.

Clasifique los errores del relay en lugar de reintentarlo todo

La página de errores del relay SMTP de Google documenta situaciones distintas, como relay de correo denegado, credenciales de relay o identificación de dominio no válidas, límite diario superado, aplazamiento temporal por límite de picos y demasiados destinatarios en una sola transacción. Capture la respuesta exacta y asígnela a una clase interna específica. Corrija los errores de configuración, dominio del remitente, credenciales, IP y destinatarios por transacción antes de volver a enviar. Pause o reprograme el trabajo cuando se agote el límite diario. Reintente los errores temporales de picos o de transporte que lo admitan con backoff exponencial, jitter, un máximo de intentos y límites de antigüedad de la cola. Nunca reintente indefinidamente una respuesta permanente. Si un error menciona una IP no registrada, confirme la dirección pública de salida real del entorno de ejecución y la configuración correcta de Workspace en lugar de ampliar la lista de permitidos. Conserve recuentos agregados con datos minimizados por sistema de origen, revisión de la configuración, dominio del remitente, clase de estado y hora. Genere alertas ante respuestas nuevas y picos de autenticación, porque pueden indicar una deriva de las políticas, la revocación de credenciales, un cambio de NAT o un abuso.

Autentique al remitente más allá del acceso al relay

Tener permiso para usar el relay de Google no equivale a autenticar al remitente ante los destinatarios. Publique una política SPF que autorice la ruta de envío real para la identidad del sobre, configure la firma DKIM con un dominio que controle la organización y que esté alineado con DMARC, y publique una política DMARC revisada para el dominio From visible. Verifique el mensaje recibido sin procesar desde buzones externos controlados. Registre el resultado y el dominio de SPF, el resultado de DKIM, el dominio d= y el selector, el dominio From visible, la alineación y el resultado DMARC. Una firma de proveedor o de Workspace técnicamente válida puede seguir sin estar alineada con un dominio From personalizado. El reenvío también puede cambiar la evidencia SPF. No agregue un segundo registro SPF ni relaje DMARC en toda la organización solo para que una prueba apruebe. Coordine a los administradores de DNS y de correo, conserve los registros anteriores, pruebe las respuestas autoritativas y recursivas, y despliegue los cambios de identidad de uno en uno.

Exija observabilidad y una vía de salida probada

Use la búsqueda de registros de correo de la consola de administración de Google y los registros del relay cuando estén disponibles, pero mantenga el registro de envíos salientes propio del producto como sistema de referencia para la toma de decisiones. Monitoree la antigüedad de la cola, la aceptación, las respuestas temporales y permanentes, el uso de los límites, las señales de rebotes y quejas, la autenticación y la latencia por clase de mensaje y dominio del remitente. Restrinja el acceso y evite incluir direcciones completas o contenido en las métricas habituales. Pruebe los cambios de IP de origen, la rotación de credenciales, los fallos de TLS, la desactivación de la configuración en la consola de administración, la suspensión de usuarios, el agotamiento de límites, la difusión a varios destinatarios, los cambios de DNS y las caídas del proveedor. Defina una reversión que pueda pausar la cohorte afectada sin descartar las tareas duraderas. Para la migración, aísle los campos SMTP específicos del proveedor en un único adaptador y conserve las claves de eventos de negocio, el estado de supresión, la autorización de remitentes y el historial de intentos. Un segundo relay no debe convertirse en una vía automática para eludir rechazos permanentes de política o de destinatarios. La compatibilidad exige pruebas a nivel de campos y de errores, no simplemente cambiar un nombre de host.

Cómo encaja SendHQ

SendHQ es una API de correo electrónico con alcance por espacio de trabajo para comunicaciones de producto esperadas, con envío desde dominios verificados, correo entrante, plantillas alojadas, eventos de entrega, supresiones y un panel web. Compárela con SMTP relay de Google Workspace mediante su documentación actual y pruebas controladas de límites de cuenta y tenant, credenciales y rotación, aplicación de remitentes permitidos, identidades de sobre y visibles, fallos de TLS, límites de destinatarios, respuestas temporales y permanentes, resultados ambiguos, supresiones, consulta de eventos y migración.

Preguntas frecuentes

Fuentes

• Enrutar los mensajes salientes del relay SMTP a través de Google — Google Workspace
• Mensajes de error del servicio de relay SMTP — Google Workspace
• RFC 3207: extensión del servicio SMTP para SMTP seguro sobre TLS — RFC Editor
• RFC 7208: marco de políticas del remitente (SPF) — RFC Editor
• RFC 6376: firmas DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 7489: autenticación, informes y conformidad de mensajes basados en dominios (DMARC) — RFC Editor
• RFC 5321: protocolo simple de transferencia de correo (SMTP) — RFC Editor