Enviar email con Python y Gmail: SMTP, OAuth y adjuntos
La idea es muy facil, el siguiente codigo es una muestra de como funciona en Python el envio de email a traves de la libreria smtplib. Si prefieres un video tutorial visita la siguiente URL: https://www.youtube.com/watch?v=vCFioQizM4w
El codigo completo lo puedes descargar en la siguiente URL https://github.com/al118345/envio_email
El código original es intencionadamente sencillo: gmail_user identifica al remitente y la credencial se lee desde un módulo local de Python. Considera ese módulo un ejemplo histórico y nunca subas una contraseña normal o de aplicación al repositorio. Después se construyen el asunto y el cuerpo antes de abrir la conexión SMTP.
Para finalizar, a partir de la linea 26 establecemos la conexion con el servidor SMTP de Gmail. Un servidor SMTP es un ordenador encargado de llevar a cabo el servicio de envio de correos electronicos y permitiendo su transporte por Internet.
Si no utilizas Gmail, sustituye el host, puerto, cifrado y mecanismo de autenticación por los datos documentados por tu proveedor. Microsoft 365 y las configuraciones actuales de Outlook/Hotmail suelen utilizar smtp.office365.com con STARTTLS en el puerto 587.
Autenticación de Gmail en 2026
Las capturas siguientes muestran el flujo retirado de “aplicaciones menos seguras” y se conservan únicamente como contexto histórico. No intentes activar esa opción: Google ya no admite el acceso con usuario y contraseña normal de la cuenta para este tipo de integración.
Para un script personal pequeño puede funcionar una contraseña de aplicación después de activar la verificación en dos pasos, aunque Google recomienda OAuth siempre que sea posible. Las contraseñas de aplicación no están disponibles en todos los tipos de cuenta y se revocan al cambiar la contraseña de Google.
Para una integración multiusuario o de producción, usa OAuth 2.0/XOAUTH2 o un proveedor de correo transaccional. Los administradores de Google Workspace también pueden configurar SMTP Relay; desde 2025, Workspace no admite el acceso basado únicamente en contraseña desde aplicaciones menos seguras.
Referencias oficiales de autenticación Gmail:App passwords, OAuth 2.0 for Gmail SMTP y Google Workspace SMTP options.
Ejemplo con contraseña de aplicación para una automatización pequeña
El ejemplo original sirve para entender SMTP, pero un proyecto real no debe guardar credenciales en el código fuente. Usa variables de entorno o un gestor de secretos. Para Gmail, prioriza OAuth 2.0 y reserva una contraseña de aplicación para una cuenta compatible y una automatización pequeña que no pueda usar Sign in with Google.
La clase EmailMessage también deja el código más claro porque separa asunto, remitente, destinatario y cuerpo sin construir a mano el mensaje completo.
Enviar un adjunto
Si necesitas enviar facturas, informes o PDFs generados, crea el mensaje con EmailMessage y adjunta el fichero como bytes. El código queda más legible y se evitan muchos errores de codificación.
Configuración SMTP por proveedor
- Gmail: smtp.gmail.com, puerto SSL 465 o STARTTLS 587.
- Outlook o Hotmail: smtp.office365.com, normalmente STARTTLS por el puerto 587.
- Hosting propio: revisa servidor SMTP, puerto y modo de cifrado en el panel del proveedor.
Errores habituales
- Authentication failed: revisa usuario, contraseña de aplicación y verificación en dos pasos.
- Connection timeout: comprueba puerto, firewall y si tu hosting bloquea SMTP.
- Acentos o caracteres especiales rotos: usa EmailMessage y contenido UTF-8.
Checklist para produccion
En una aplicacion real, el envio de emails deberia vivir normalmente en el backend y no en el navegador. El backend puede proteger credenciales SMTP, validar destinatarios, aplicar limites de uso y guardar errores de entrega.
Si el email se dispara desde Angular, expone un endpoint pequeño y deja que Python gestione la conexion SMTP. Esa arquitectura es mas segura que enviar credenciales al frontend.
Entregabilidad y detalles operativos
Enviar un email correctamente desde Python no garantiza que llegue a la bandeja de entrada. En un dominio real conviene configurar SPF, DKIM y DMARC, usar un remitente reconocible y evitar cambiar el From de forma dinamica. Esos registros DNS ayudan a los proveedores de correo a comprobar que el servidor puede enviar en nombre del dominio.
Tambien es util guardar un log de entrega con fecha, destinatario, respuesta del proveedor e identificador interno. No guardes el cuerpo completo del mensaje salvo que el negocio lo necesite. Un log pequeno permite reintentar fallos temporales, detectar cuentas bloqueadas y explicar que ocurrio cuando un usuario dice que no recibio una notificacion.
Arquitectura recomendada con Angular
En una aplicacion Angular, el navegador solo deberia enviar una peticion como “enviar factura” o “notificar usuario”. El backend valida permisos, construye el mensaje, lee plantillas, adjunta ficheros y habla con SMTP. Esta separacion protege credenciales y mantiene las reglas de email en un unico punto testeable.
Plantillas y reintentos
En proyectos mantenibles, las plantillas del mensaje deben estar fuera de la funcion de envio y recibir variables explicitas como nombre de usuario, numero de factura o enlace de confirmacion. Anade reintentos solo para errores temporales del proveedor, nunca para direcciones invalidas o fallos de autenticacion. Asi la automatizacion es predecible y se evitan bucles de spam accidentales.
Lectura relacionada: proteger una API Angular con Nginx y FastAPI. proteger API Angular, Nginx y FastAPI.