Muchos CMS siguen ofreciendo los campos clásicos de servidor, puerto, usuario y contraseña SMTP. Sin embargo, Google dejó de permitir el acceso heredado con la contraseña normal de la cuenta. ¿Cómo puede enviar correos una aplicación moderna? Esta guía explica la configuración real con contraseña de aplicación cuando es compatible, las alternativas OAuth y SMTP Relay y los errores que aparecen en PHP, Laravel y otros sistemas web.

1. Qué cambió en Google: el final de las aplicaciones menos seguras

Durante años, algunas webs y programas se conectaban a Gmail mediante SMTP utilizando el correo y la misma contraseña con la que una persona accede a su cuenta. Ese sistema, denominado autenticación básica o acceso de aplicaciones menos seguras, está obsoleto. Google Workspace completó su retirada en 2025 y ya no ofrece un interruptor para rehabilitarlo. No debe confundirse ese método con una contraseña de aplicación específica ni con OAuth 2.0. El usuario puede seguir accediendo normalmente a Gmail con su contraseña o sus métodos modernos; lo que ha cambiado es el acceso programático heredado.

2. SMTP, OAuth 2.0 y contraseña de aplicación: diferencias reales

Una contraseña de aplicación no equivale a OAuth: sigue siendo un secreto reutilizable hasta que se revoque. Google la considera una alternativa de compatibilidad y recomienda «Iniciar sesión con Google» cuando la aplicación lo ofrezca.

3. Requisitos para generar una contraseña de aplicación

La cuenta debe tener verificación en dos pasos. El acceso suele estar en myaccount.google.com/apppasswords. Es posible que la opción no aparezca si la cuenta es de una organización con restricciones, si utiliza solo llaves físicas como segundo factor o si participa en el Programa de Protección Avanzada de Google. En este último caso, las contraseñas de aplicación están bloqueadas. Para Google Workspace, la disponibilidad también depende de políticas organizativas: no corresponde sugerir que siempre existe un botón universal de activación.

4. Guía práctica: crear y configurar una credencial SMTP

1. Accede a la cuenta Google que realmente enviará el correo y comprueba que tienes permiso para usarla como remitente.
2. En Cuenta de Google → Seguridad, activa y verifica correctamente la autenticación en dos pasos.
3. Abre Contraseñas de aplicaciones. Si la opción no está disponible, consulta las restricciones anteriores y opta por OAuth o por un relay adecuado.
4. Asigna un nombre descriptivo y no confidencial, como «CMS de pruebas», genera la contraseña de 16 caracteres y guárdala únicamente en un gestor de secretos o formulario seguro del servidor. Google solo la muestra una vez.
5. En la administración del CMS, localiza los ajustes de correo saliente. La ruta exacta depende del producto y de su versión.
6. Selecciona SMTP autenticado e introduce los parámetros de la tabla siguiente. Guarda sin exponer la contraseña en logs o pantallas compartidas.
7. Prueba con una dirección controlada, verifica el resultado en el buzón y examina los encabezados, el remitente y las respuestas de error.
8. Revoca la credencial de aplicación si el servicio deja de utilizarse, hay sospecha de exposición o cambian las responsabilidades.

Parámetros habituales de Gmail SMTP

Para el puerto 587 se establece una conexión y se negocia STARTTLS; para 465 el cifrado TLS empieza al conectarse. No basta con elegir un número: el campo «cifrado» del CMS debe corresponder al modo realmente soportado. No desactives la validación de certificados TLS para corregir un fallo.

5. Ejemplo Laravel, PHP y CMS multicliente

En una aplicación Laravel, una configuración de desarrollo puede utilizar un transporte SMTP con MAIL_HOST=smtp.gmail.com, MAIL_PORT=587 y nombre de usuario completo. La contraseña debe entrar mediante una variable de entorno o almacén de secretos gestionado de forma segura. El nombre exacto de la opción TLS depende de la versión del framework y del transporte Symfony Mailer; no copies a ciegas configuraciones de guías antiguas. En un CMS multiinquilino, cada organización debería contar con sus propias credenciales y límites, sin permitir que un administrador de otro espacio vea o exporte secretos.

Es preferible cifrar y limitar el acceso a las credenciales, separar entornos de prueba y producción, registrar solo metadatos de los envíos y evitar poner contraseñas en el código fuente, copias de seguridad sin protección o registros de errores. Tras modificar la configuración hay que vaciar la caché de parámetros si el framework lo exige y reiniciar trabajadores de colas que conserven valores antiguos.

6. El remitente no puede falsificarse libremente

Conectar una cuenta ejemplo@gmail.com no convierte en legítima cualquier dirección introducida en el campo From. Gmail puede rechazarla, sustituirla o mostrar la cuenta real como remitente. Para enviar con otra dirección se necesita configurarla y verificarla como alias de envío cuando Google lo permita, o utilizar una cuenta y servicio con el dominio propio correctamente autenticado. El campo Reply-To dirige respuestas, pero no modifica la identidad que firma el envío. Tampoco debe suponerse que el prestigio del proveedor evita automáticamente que un mensaje termine en spam.

7. Límites diarios, volumen y reputación

Google indica para cuentas personales de Gmail un límite aproximado de 500 mensajes diarios, con restricciones por destinatarios y mecanismos de prevención de abusos. Google Workspace maneja límites distintos según plan, modalidad de acceso y configuración. Esos límites no constituyen una garantía de capacidad: pueden existir suspensiones temporales por actividad sospechosa, rebotados o reclamaciones. Para notificaciones masivas, envíos comerciales recurrentes o servicios SaaS multiempresa suele ser más apropiado un proveedor transaccional especializado.

8. Errores habituales y diagnóstico

9. Seguridad y mantenimiento

Genera una contraseña por aplicación y no compartas la misma credencial entre sistemas o usuarios. No envíes esa clave por chat ni correo; el operador debe escribirla directamente en un panel HTTPS seguro. Controla permisos para consultar o cambiar la configuración SMTP. Google revoca las contraseñas de aplicación cuando cambia la contraseña principal, por lo que debes prever ese mantenimiento. Proteger la cuenta con 2FA sigue siendo imprescindible, aunque el SMTP utilice una credencial separada.

10. Cuándo elegir OAuth o SMTP Relay

OAuth 2.0 es preferible si el software lo soporta y necesita gestionar acceso de forma moderna; puede requerir un proyecto Google Cloud, autorización y mantenimiento de tokens en una integración propia. Para organizaciones con Workspace, Google recomienda smtp-relay.gmail.com como opción para aplicaciones y dispositivos en muchos escenarios. Esta ruta exige configuración administrativa, controles de remitentes, autenticación y, en algunas modalidades, IP autorizadas; no es un reemplazo automático de smtp.gmail.com simplemente cambiando el host.

11. Lista de comprobación final

1. ¿La cuenta está autorizada y tiene 2FA?
2. ¿Se permite una contraseña de aplicación o es mejor OAuth?
3. ¿Se utiliza el host y puerto correctos, con TLS activo?
4. ¿El remitente y los alias están autorizados?
5. ¿El secreto está cifrado y oculto a administradores no autorizados?
6. ¿Hay pruebas de entrega, rebotes y límites?
7. ¿Existe un plan de rotación y revocación?
8. ¿El volumen previsto encaja con las políticas de Google?

12. Buenas prácticas para colas, adjuntos y notificaciones

Envía correos fuera de la petición web mediante una cola de trabajos cuando el sistema lo permita. Implementa reintentos limitados y controlados; una excepción SMTP no siempre indica que el receptor no haya procesado el mensaje, por lo que los duplicados son posibles. Controla el tamaño de los adjuntos, evita datos personales innecesarios, usa identificadores de operación y separa los mensajes transaccionales de campañas comerciales. En un CMS multiinquilino, comprueba la salida del remitente desde cada organización sin compartir secretos entre ellas.

WordPress: configuración de Gmail con plugin SMTP

WordPress usa normalmente wp_mail(); para configurar su transporte puedes instalar un plugin mantenido como WP Mail SMTP. Si la integración de Google mediante OAuth está disponible, suele ser preferible. Para SMTP genérico, introduce smtp.gmail.com, puerto 587 con STARTTLS (o 465 con TLS implícito), autenticación activada, la dirección Gmail completa y una contraseña de aplicación válida si la cuenta es compatible. Configura como remitente la cuenta autenticada o un alias autorizado y prueba los formularios, avisos y recuperación de contraseñas. Los nombres exactos de menús dependen del plugin y su versión.

Instalar un plugin no aumenta el cupo de Gmail. Las cuentas personales tienen un límite orientativo de 500 mensajes salientes al día, además de restricciones por destinatarios y medidas contra abusos; Workspace tiene límites diferentes según su configuración. Límites oficiales de Gmail.

CMS con SMTP integrado: sin instalar plugins

Algunos gestores incorporan el correo saliente en sus ajustes de administración. El nuevo MuseDock CMS, actualmente en desarrollo, contempla esta configuración integrada sin requerir un plugin SMTP externo. Las opciones y pantallas deben verificarse en la versión disponible; no se presupone que todas las instalaciones tengan idénticas funciones. El procedimiento conceptual es configurar host, puerto, TLS, cuenta autorizada, secreto protegido y remitente, guardar y probar. En CMS multiempresa deben separarse las credenciales y permisos de cada espacio. No se deben compartir contraseñas de aplicación por chat, registros o capturas.

Documentación oficial

• Google: contraseñas de aplicaciones
• Google Workspace: transición desde aplicaciones menos seguras
• Google Developers: SMTP, IMAP, OAuth y TLS
• Google Workspace: enviar desde aplicaciones y dispositivos
• Gmail: límites de envío
• Google: Protección Avanzada

Ruta de administración de ejemplo y configuración completa

En un CMS con correo integrado, la configuración puede encontrarse en una dirección como https://example.com/admin/settings/email. Esta ruta es ilustrativa: no pertenece a un proyecto real ni está garantizada en todas las versiones de un CMS. Abre la página con una identidad administradora autorizada y comprueba la documentación de tu instalación.

Si existe una opción «Usar servidor global», desactívala únicamente cuando desees configurar un servidor SMTP propio para ese sitio o espacio de trabajo. Si se mantiene activada, los campos particulares podrían ignorarse. No cambies el servidor global de otros sitios inadvertidamente.

Activar la cuenta de Google

1. Abre Seguridad de tu cuenta Google y activa la verificación en dos pasos.
2. Accede a Contraseñas de aplicaciones; asigna un nombre genérico como «CMS web».
3. Si Google te permite crearla, copia la contraseña de aplicación y pégala directamente en el formulario seguro. No uses la contraseña normal ni compartas el secreto por chat.
4. Guarda los cambios y ejecuta la prueba de envío del CMS, si existe. Confirma recepción, remitente, cabeceras y funcionamiento de formularios y avisos.
5. Si falla, revisa conectividad saliente al puerto 587, negociación STARTTLS, restricciones de Google, estado de la credencial y logs sin datos sensibles.

No hace falta crear un proyecto de Google Cloud para usar SMTP con contraseña de aplicación. Sí puede hacer falta para una integración OAuth propia. Si no aparece la opción de contraseñas de aplicaciones, no presupongas que basta con activar un interruptor de Workspace: revisa la cuenta, su política de organización, la verificación en dos pasos, la Protección Avanzada y las opciones OAuth o SMTP Relay disponibles. En Gmail personal el límite de envío ronda los 500 mensajes diarios, sujeto a las reglas actualizadas de Google; ese cupo no se multiplica por utilizar más de un CMS o módulo.

Compatibilidad con otros CMS y módulos SMTP

La secuencia es aplicable a WordPress mediante un plugin SMTP, a gestores con transporte integrado y a aplicaciones de desarrollo propio: identidad autorizada → método de autenticación → host y puerto → TLS → remitente → prueba de envío. Cambian el nombre de los campos y las rutas del panel, pero no los principios de seguridad. MuseDock CMS es un ejemplo de plataforma cuyo nuevo sistema en desarrollo contempla el correo integrado, sin un plugin independiente. Comprueba siempre las funciones concretas de la versión instalada.