¿Una impresora debe usar el SMTP relay o el servidor SMTP de Gmail?

Si solo le escribe a compañeros dentro de la empresa, el servidor SMTP restringido de Gmail es lo más simple porque no pide autenticación. Si le escribe a alguien de afuera, usa el servicio de SMTP relay. El servidor SMTP de Gmail es el que conviene evitar en equipos compartidos, porque se autentica como el buzón de una sola persona y deja de funcionar el día que se elimina esa cuenta.

¿El correo que sale por el SMTP relay pasa DMARC automáticamente?

No. Las opciones del relay deciden si Google acepta el mensaje de tu equipo, no si el mensaje alinea para DMARC. La alineación depende de que tu registro SPF autorice a Google, de que DKIM esté activado para ese dominio en la consola de administración, y de que el dominio del campo De coincida con uno de los dos. La única forma de confirmarlo es enviar un mensaje real por el relay y leer las cabeceras Authentication-Results y DKIM-Signature en la copia que llega.

No sabemos quién configuró la aplicación que manda nuestras facturas. ¿Por dónde empezamos?

Publica un registro DMARC en p=none con una dirección de reportes y dale dos semanas. Los reportes agregados listan cada fuente que envía como tu dominio, que es el inventario que nadie tiene. Después compara esa lista con los remitentes permitidos del relay, la opción de pasarelas de salida por usuario y las contraseñas de aplicación de cada cuenta.

SMTP relay Google Workspace: configuración, límites y DMARC

Imagina una distribuidora de 14 personas que manda tres tipos de correo que nadie en la oficina considera correo. La impresora de bodega envía notas de entrega escaneadas. El sistema de contabilidad envía facturas. El sitio web envía confirmaciones de pedido. Los tres salen con el dominio de la empresa en el campo De, y los tres los configuró hace años alguien que ya no trabaja ahí.

El arreglo funciona hasta que algo lo saca a la luz. Llega un reporte DMARC con fuentes de envío que nadie puede nombrar, o Gmail empieza a rechazar las facturas, o el cuestionario de seguridad de un cliente pregunta qué sistemas están autorizados a enviar como tu dominio y la respuesta honesta es que nadie tiene la lista. Google Workspace ofrece tres maneras distintas de que un equipo o una aplicación envíe correo, más dos opciones a nivel de usuario que pueden mover el envío fuera de tu infraestructura. Se autentican diferente, tienen topes diferentes y fallan con mensajes de rebote diferentes. Así desarmamos esto en la cuenta de un cliente, en el orden en que lo hacemos.

Tres formas en que Google envía por ti, y qué te exige cada una

Google documenta tres opciones para el correo que sale de una impresora, un escáner o una aplicación. Las cifras de abajo salen de la ayuda de administración de Google, revisadas el 5 de octubre de 2026.

El servicio de retransmisión SMTP (SMTP relay), en smtp-relay.gmail.com por el puerto 25, 465 o 587. Lo activa un administrador para toda la organización, y cada usuario puede retransmitir mensajes hasta 10,000 destinatarios por día. Es la opción para cualquier cosa que envíe volumen o que escriba a gente fuera de la empresa.
El servidor SMTP de Gmail, en smtp.gmail.com. Se autentica como el buzón de una sola persona y el límite de envío es de 2,000 mensajes por día. Alcanza para una aplicación que manda unas pocas notificaciones.
El servidor SMTP restringido de Gmail, en aspmx.l.google.com por el puerto 25. No pide autenticación, y a cambio solo entrega a usuarios de Gmail y de Google Workspace. Sirve para un escáner que manda documentos a los compañeros, no sirve para nada que le escriba a clientes.

La opción que se elige por accidente es la segunda, porque no necesita administrador ni conversación. Alguien genera una contraseña de aplicación en su propia cuenta, la pega en el sitio web, y las confirmaciones de pedido salen amarradas a ese buzón. Después esa persona se va, la cuenta se elimina y las confirmaciones dejan de salir sin que nadie encuentre el motivo. El cliente siempre se da cuenta antes que la empresa.

Qué controlan de verdad las opciones del relay

El relay vive en la consola de administración, en Aplicaciones, luego Google Workspace, luego Gmail, luego Enrutamiento. Son tres grupos de opciones y cada uno responde una pregunta distinta.

Remitentes permitidos responde quién puede poner una dirección en el campo De. La opción más estricta es solo usuarios registrados en mis dominios, que exige que el remitente sea un usuario de Workspace en uno de tus dominios. De ahí se abre a cualquier dirección dentro de tus dominios, y luego a cualquier dirección. Esa última es lo primero que revisamos en una cuenta heredada: un relay abierto a cualquier remitente va a enviar en nombre de direcciones que no son tuyas.

Autenticación responde qué máquinas pueden conectarse. Son dos casillas y puedes marcar una o las dos: aceptar correo solo desde las direcciones IP que especifiques, o exigir autenticación SMTP, que identifica el dominio que envía y requiere que la conexión entre por TLS. No marcar ninguna es lo que convierte una configuración floja de remitentes en una peligrosa.

Exigir cifrado TLS responde si la conexión tiene que ser privada. Google es claro con el costo: si tu servidor de correo no soporta TLS y marcas la casilla, los mensajes que no salgan por una conexión TLS cifrada se rechazan. La guía de Google empareja TLS con el puerto 587, y menciona los puertos 25, 465 y 587 cuando no lo usas.

La combinación que dejamos configurada

Para una empresa pequeña con unos pocos equipos que envían, dejamos las cuatro cosas a la vez: remitentes permitidos limitados a tus propios dominios, una lista de IP que nombre la oficina y el servidor, autenticación SMTP obligatoria y TLS obligatorio en el puerto 587. Si un equipo de verdad no puede hacer TLS ni autenticación SMTP, eso va en los hallazgos, no en una regla más floja para todos.

Las dos opciones que mueven el envío fuera de tu dominio

Gmail también permite que un usuario agregue otras direcciones a su cuenta y envíe desde ellas, que es como una sola persona termina enviando también como facturacion@. Por sí sola es una función útil, y el correo sigue saliendo por Google.

La opción que hay que conocer es las pasarelas de salida por usuario, en Aplicaciones, luego Google Workspace, luego Gmail, luego Acceso del usuario final. Al activarla, los usuarios pueden enviar correo a través de un servidor SMTP externo cuando configuran una dirección De alojada fuera de tus dominios de correo. El correo sale entonces por el servidor de alguien más, y Google anota la consecuencia sin rodeos: si esa pasarela modifica los mensajes salientes, es probable que no pasen la autenticación DKIM, lo que vuelve más importante tener un registro SPF exacto, no menos.

Esto es lo que explica el reporte DMARC que nadie logra descifrar. Si un empleado conectó su Gmail al servidor SMTP de un hosting viejo, el correo va con tu dominio, desde una IP que no controlas y sin ninguna firma tuya, y la configuración del relay no te lo va a mostrar porque el relay no está en el camino.

La cabecera resuelve lo que la consola no puede

La consola te dice qué está permitido, no cómo venía un mensaje cuando llegó a Gmail, y lo segundo es lo que define el resultado DMARC. Entonces mandamos un mensaje real por cada camino que encontramos, lo recibimos en una dirección de afuera y leemos dos líneas del código fuente.

La primera es Authentication-Results, que registra qué concluyó el servidor que recibe sobre SPF, DKIM y DMARC. La segunda es el valor d= dentro de DKIM-Signature, el dominio cuya llave firmó el mensaje. Si d= es tu dominio, DKIM está alineado para ese remitente. Si es otra cosa, DKIM no alinea en ese camino y el resultado DMARC queda colgado solo de SPF, que es la mitad frágil. El recorrido completo está en nuestra guía para leer las cabeceras de un correo.

SPF, DKIM y la alineación que decide el resultado

Tres cosas tienen que ser ciertas para que el correo retransmitido se autentique, y lo normal es tener dos de tres. Primero, SPF tiene que autorizar a Google, en un solo registro por dominio:

ejemplo.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

Cada otro sistema que envía como el dominio necesita su propio include o su término ip4 en ese mismo registro, y el conjunto tiene que quedar dentro de las diez consultas DNS que permite el estándar. Ese techo llega más rápido de lo que la gente cree cuando ya están ahí un CRM, una plataforma de boletines y una tienda, y la solución no es un segundo registro SPF: SPF con demasiadas consultas DNS.

Segundo, DKIM tiene que estar activado para el dominio en la consola de administración y el registro google._domainkey publicado en el DNS. Hasta que lo esté, la firma de tu correo saliente no lleva tu dominio y la verificación de alineación no tiene nada tuyo con qué comparar. Las guías para remitentes de Gmail piden una llave de al menos 1024 bits y recomiendan 2048 donde el proveedor de DNS lo permita. Las formas en que esto falla del lado de Workspace son suficientemente específicas para tener su propio artículo: DKIM falla en Google Workspace.

Tercero, y esta es la parte que se salta, las dos tienen que alinear. En el correo enviado de forma directa, el dominio organizacional del encabezado De tiene que coincidir con el dominio de SPF o con el de DKIM. Solo uno de los dos necesita alinear para que DMARC pase, y por eso un dominio puede verse sano mientras la mitad de sus caminos de envío está a una edición de DNS de fallar. Vale conocer un umbral: quien envía más de 5,000 mensajes por día a cuentas personales de Gmail cuenta como remitente masivo y necesita SPF, DKIM y DMARC, no uno de los tres.

Los rebotes, traducidos

Cuando un camino del relay se rompe, el equipo se suele tragar el error y la empresa lo escucha de un cliente. Si puedes llegar al registro, la redacción de Google apunta directo a la causa.

550 5.7.1 Invalid credentials for relay. La IP registrada no coincide con el dominio de la cuenta desde la que se envía el mensaje, o el remitente del sobre viene vacío o en un dominio no registrado. La solución de Google: configurar el servidor para usar autenticación SMTP e identificar el dominio que envía, o presentar uno de tus nombres de dominio en el comando HELO o EHLO.
Mail relay denied. El correo viene de un dominio o una IP que no está registrada en las opciones del relay. Casi siempre es una oficina que cambió de proveedor de internet, o un servidor que se movió.
550 5.4.5 Daily SMTP relay limit exceeded for user. Un buzón se acabó su cupo, normalmente porque todos los equipos apuntan a la misma cuenta.
550 5.7.1 Daily SMTP relay sending limit exceeded for this customer. La organización completa llegó a su techo, lo que en una cuenta pequeña suele significar un bucle.

Un límite por usuario solo ayuda cuando los usuarios son distintos, y por eso cada sistema que envía recibe su propia cuenta.

Qué revisamos en la cuenta de un cliente, en orden

Todo sistema que envía como el dominio, por escrito. Dos semanas de reportes agregados de DMARC en p=none dan el inventario real, incluidos los sistemas que nadie mencionó.
La regla del relay. Remitentes permitidos, la lista de IP, autenticación SMTP y TLS, apretados en ese orden, porque la exposición está en los remitentes permitidos.
Pasarelas de salida por usuario y direcciones de "Enviar como". Quién las tiene, hacia dónde apuntan y si alguien todavía las necesita.
Contraseñas de aplicación. Qué cuentas las tienen, a qué están conectadas y si alguna es de alguien que ya se fue.
SPF, DKIM y alineación en cada camino. Un mensaje de prueba por camino, cabecera leída, resultado anotado junto a su origen.
La política, al final. Solo cuando cada camino legítimo alinea es seguro subir DMARC, y ese orden de despliegue es trabajo aparte: pasar DMARC de p=none a p=reject.

El paso cuatro es el que encuentra las peores sorpresas. Una contraseña de aplicación sobrevive a la conversación que la creó y sigue funcionando hasta que la cuenta se suspende. Si nunca las has auditado, asume que hay más de las que crees: están enviando correo como mi dominio.

Cómo ayuda Guanacos Tech

Casi todo este trabajo es inventario, no configuración. El relay se deja bien en veinte minutos y comprobar que nada más está enviando como el dominio toma mucho más, así que tratamos las dos cosas como un solo trabajo. Lo hacemos para empresas pequeñas y medianas de Norteamérica y Latinoamérica, en inglés y en español, dentro de nuestra consultoría de Google Workspace. Con una llamada de 30 minutos alcanza para leer tu regla del relay, tus registros SPF y DKIM y un juego de cabeceras, y decirte qué caminos de envío sobrevivirían una política DMARC estricta.

SMTP relay y Enviar como en Google Workspace: los remitentes de tu dominio que nadie puede explicar