Cómo configurar Gmail SMTP en una web: contraseñas de aplicación, puertos y seguridad

En una web corporativa, un gestor de reservas o un CMS, el correo automático suele encargarse de enviar avisos, confirmaciones o mensajes de contacto. Si se utiliza una cuenta Gmail, en 2026 ya no es correcto introducir la contraseña normal y activar un supuesto ajuste de «aplicaciones menos seguras». Explicamos paso a paso qué opciones están disponibles hoy, cómo configurar SMTP sin debilitar la cuenta y cuándo conviene pasar a un servicio de correo empresarial.

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. Consejos adicionales para pequeñas empresas

Utilizar Gmail para unos pocos avisos puede ser razonable si el uso es legítimo y encaja con las políticas y límites del servicio. No conviertas una cuenta personal en una plataforma masiva de campañas sin controles de consentimiento o gestión de errores. Una identidad de correo corporativa con dominio propio ofrece ventajas de marca y administración; para grandes volúmenes conviene evaluar servicios de envío transaccional. La mejor solución depende de la escala y del nivel de mantenimiento que pueda asumir la organización.

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