Blog

GNU/Linux, Open Source, Cloud Computing, DevOps y más...

Usar GMail gratis con tu propio dominio gracias a Amazon SES + Lambda

6 de junio de 2017

Cuenta de GMail configurada para recibir y enviar correo de nuestro dominio

Una de las principales necesidades que tiene un pequeño negocio o una startup que está empezando es disponer de un sistema de correo fiable con un dominio propio que nos diferencie a nosotros mismos y a nuestro sitio web corporativo en Internet. Aunque hay muchos planes de hosting que ofrecen cuentas de correo gratuitas e incluso podríamos montar nuestro propio servidor de correo, es probable que ya estemos acostumbrados a servicios de correo como GMail y nos gustaría seguir utilizándolo para gestionar el correo de nuestro propio dominio sin tener que recurrir a soluciones de pago como G Suite (antes Google Apps), que aunque son económicas para las prestaciones que ofrecen, suponen un coste adicional que nuestro incipiente proyecto no se puede permitir.

Si es tu caso te alegrará saber que gracias a la capa gratuita que ofrece AWS en algunos de sus servicios como Amazon SES y Lambda , podemos montar sin coste un sistema de correo que se integre perfectamente con nuestra cuenta gratuita de GMail, y que al mismo tiempo permita enviar y recibir correo desde múltiples cuentas de nuestro propio dominio.

El procedimiento que indico a continuación no es exclusivo para cuentas de GMail. Cualquier otro servicio de correo que ofrezca la posibilidad de enviar correo eligiendo el nombre y la dirección que queremos que aparezca en el remitente nos servirá. Para la recepción de correo de nuestro dominio ni siquiera hace falta ninguna característica adicional, por lo que cualquier servicio de correo, ya sea Office 365 Outlook, Yahoo o iCloud Mail servirá.

IMPORTANTE : Consulta los límites de la capa gratuita de AWS y los costes en los que incurrirás si superas éstos, pues aunque son bastante amplios para el propósito que aquí se indica, podrían suponerte un perjuicio económico que no tenías previsto. Recuerda que si llevas a cabo este procedimiento lo haces bajo tu entera responsabilidad.

1. Crear nueva zona DNS para nuestro dominio en Amazon Route 53

El primer paso será crear una zona DNS pública (Public Hosted Zone) para nuestro dominio en Amazon Route 53 si todavía no disponemos de ella. Para ello accederemos a través de la consola de AWS al servicio Route 53 - > Hosted zones -> Create Hosted Zone. Podemos aprovechar este paso para añadir algunas entradas DNS que necesitemos, como registros A que apunten a nuestro sitio web, o en el caso del correo, un registro SPF como medida de seguridad para evitar que usurpen nuestras direcciones de correo o que nuestros destinatarios consideren nuestro correo como spam.

Zona DNS pública básica recién creada en Amazon Route 53

Ejemplo de zona DNS con registro SPF

2. Verificar nuestro dominio en Amazon SES

Abriremos otra pestaña en nuestro navegador y accederemos de nuevo a través de la consola de AWS al servicio Amazon SES. Desde la opción Domains del menú verificaremos nuestro dominio, lo cual provocará que se añadan nuevas entradas DNS en nuestra zona de Route 53 como se puede ver en las siguientes imágenes:

Verificación de dominio en Amazon SES

Resultado tras verificación de dominio en Amazon SES

Nuevos registros DNS añadidos a nuestra zona

IMPORTANTE: Las zonas DNS de Route 53 tienen un coste de 0.50 USD/mes por dominio. Si no quieres incurrir en este gasto puedes, llegados a este punto, replicar todos los registros DNS que aparecen en la última captura de pantalla en el panel de control de zonas DNS de tu proveedor actual con el que registraste el dominio. Si prefieres utilizar el servicio Route 53 tendrás que actualizar los servidores DNS de tu dominio para poner los de Amazon (registros NS de la última captura) y no los de tu proveedor de dominios.

3. Crear función Lambda para redirigir el correo entrante a nuestra cuenta de GMail

Este punto incluye dos pasos. En el primero de ellos crearemos una función Lambda abriendo en una nueva pestaña del navegador la página principal del servicio Lambda de Amazon, y haciendo clic en Create a Lambda function. Seleccionaremos una función en blanco (Blank Function) y nos saltaremos el paso de configurar disparadores (Configure triggers). En las capturas de pantalla de más abajo se pueden ver las opciones que en necesario rellenar en el formulario de creación de la nueva función Lambda.

El código fuente en Node.js de la función Lambda se basa en este repositorio de GitHub: https://github.com/arithmetric/aws-lambda-ses-forwarder. Resumo a continuación los únicos cambios que he realizado en dicho código para ilustrar mi ejemplo y que he probado que funcionan satisfactoriamente:

var defaultConfig = {
 fromEmail: "info@example.com",
 subjectPrefix: "",
 emailBucket: "example-com-mailbox",
 //emailKeyPrefix: "emailsPrefix/",
 emailKeyPrefix: "",
 forwardMapping: {
 "info@example.com": [
 "example@gmail.com"
 ]
 }
};

El segundo paso consiste en modificar las políticas de seguridad asociadas al rol IAM que se genera automáticamente al crear nuestra función Lambda, ya que necesitamos añadirles dos nuevas políticas: una para que se permita acceder al bucket de S3 que crearemos posteriormente para almacenar nuestros mensajes de correo, y otra para poder acceder a los recursos del servicio Amazon SES. Para ello, una vez creada la función Lambda abriremos en una nueva pestaña del navegador el servicio IAM y haremos clic en las siguientes opciones: Roles - > example-com-forwarding -> Policy Name AWSLambdaBasicExecutionRole-99b88501-cad9-4f48-ba03-75b13f98dae0 -> Edit Policy. En esta última página añadiremos el código JSON que aparece señalado en azul en las siguientes capturas de pantalla:

Configuración función Lambda para reenvío de correo

Edición de política IAM

Resumen política IAM

4. Crear nueva regla de recepción de correo en Amazon SES

De nuevo desde la página principal del servicio Amazon SES haremos clic en la opción del menú Rule Sets y a continuación en el botón Create a Receipt Rule , lo cual iniciará un procedimiento de 4 pasos muy simples que culminará con la creación de una nueva regla de recepción de correo para nuestro dominio. El primero de estos pasos será crear uno o varios destinatarios de correo. Aquí podremos introducir una única dirección de correo de nuestro dominio, o directamente el nombre del dominio sin más, lo cual nos permitirá recibir correo para cualquier dirección.

Creación de regla de recepción en Amazon SES - paso 0

Creación de receptores - paso 1

A continuación crearemos 2 acciones que se ejecutarán cada vez que Amazon SES reciba un correo para nuestro dominio: almacenar el correo en un bucket S3 y ejecutar nuestra función Lambda para que sea redirigido a nuestra cuenta de GMail:

Creación de acciones de regla de recepción Amazon SES

Creación de acciones para nuestra regla de recepción

Creación de nuevo bucket S3

Creación de nueva acción basada en nuestra función Lambda

Tras realizar estos pasos la regla de recepción de correo ha quedado completamente configurada, pero quizás no haya sido activada y sea necesario volver hacia atrás y activarla. Por tanto, una vez configurada y activa si enviamos un email a la cuenta o cuentas de nuestro dominio que hayamos creado (en nuestro ejemplo cualquier dirección de nuestro dominio, por ejemplo info@example.com), veremos como se almacena el mensaje en el bucket de S3 que acabamos de crear:

Regla de recepción de Amazon SES configurada

Listado de mensajes de correo electrónico almacenados en S3

5. Verificación de nuestra dirección de GMail y creación de usuario SMTP

Para que Amazon SES acepte correo saliente procedente de nuestra cuenta de GMail es necesario verificarla y además crear un usuario SMTP :

Verificación de direcciones de correo de nuestro dominio

Datos de configuración correo saliente SMTP

Creación de credenciales de usuario SMTP

En un primer momento nuestro recién configurado servicio de Amazon SES será puesto en cuarentena (sandbox) por parte de Amazon como medida de protección ante posibles abusos y envíos de spam. Para sacarlo de la cuarentena y permitir el envío normal de correo es necesario que abramos un ticket de soporte a Amazon para solicitarlo, o si no veremos como nuestros correos enviados rebotan con el siguiente mensaje de error:

554 Message rejected: Email address is not verified. The following identities failed the check in region EU-WEST-1: <a href="mailto:myexample@gmail.com" rel="noopener noreferrer" target="_blank">myexample@gmail.com</a>

A continuación se muestra la página desde la que podemos solicitar que se nos saque de la cuarentena y un ejemplo del mensaje de solicitud. En nuestro ejemplo solicitamos unos límites más altos porque también vamos a utilizar el servicio de Amazon SES para el envío de una newsletter semanal a nuestros suscriptores:

Aviso cuarentena (sandbox) y botón para solicitar aumento del límite de envíos

Ejemplo de mensaje de solicitud de aumento del límite de envíos soporte Amazon

6. Configuración de GMail para envío de correo con la dirección de nuestro dominio

Llegamos a la recta final. Ya sólo queda configurar GMail para enviar correo poniendo la dirección de nuestro dominio como remitente. Para recibir correo no hay que hacer nada, pues de eso se encarga el servicio SES y no precisa de ninguna configuración adicional. Entre las dos capturas de pantalla siguientes hay un paso intermedio que consiste en introducir los datos de configuración SMTP que obtuvimos en el paso 5:

Añadir otra dirección de correo a GMail

Código de verificación nueva dirección

7. Depuración de errores y estadísticas de envío

Por último, si las cosas no han ido bien y no conseguimos que nuestros correos se redirijan correctamente podemos obtener información de depuración de errores y mensajes de log de nuestra función Lambda gracias al servicio CloudWatch. También podemos obtener estadísticas de envío y recepción de correo por parte del servicio SES (ver imagen apartado 5) y estadísticas de funcionamiento de nuestra función Lambda :

Depuración mensajes de log en CloudWatch

Estadísticas de redirección de correos función Lambda

AWS Email GMail Lambda Route 53 SES SMTP

Comparte este artículo

X.com LinkedIn Facebook WhatsApp Email

Sobre el autor

Daniel López Azaña

Emprendedor tecnológico y arquitecto cloud con más de 20 años de experiencia transformando infraestructuras y automatizando procesos.

Especialista en integración de IA/LLM, desarrollo con Rust y Python, y arquitectura AWS & GCP. Mente inquieta, generador de ideas y apasionado por la innovación tecnológica y la IA.

Comentarios

Manuel Asuar 11 de septiembre de 2017

Hola Daniel, He decido hacer una prueba con mi dominio y la cuenta de gmail. Ya está todo verificado y recibo los email en el S3 pero no puedo hacer un test desde la cuenta de gmail , me dice que no reconoce la dirección para esos servidores, y tampoco me funciona el lambda. He usado los servidores de US Virginia, tendría algo que ver? Gracias por tu tiempo. P.D.: Volveré a realizar los pasos, están muy claritos.

Daniel 11 de septiembre de 2017

Hola Manuel, no debería tener nada que ver que la región que hayas elegido sea la de N. Virigina u otra. Si quieres copiame los mensajes de error que te aparezcan en CloudWatch para examinarlos y tratar de ver qué está pasando. ¿O no hay ningún log disponible? Si ese es el caso entonces lo más probable es que la regla de recepción de Amazon SES no tenga bien configurada la acción de ejecutar la función Lambda, sólo la de guardar el mensaje en S3. Asegúrate de que en Amazon SES -> Email Receiving -> Rule Sets -> View Active Rule Set -> Rule Name, en el apartado de Actions aparezca una acción S3 y otra Lambda, que ésta última tenga bien seleccionada en el desplegable la función que hayas creado para el reenvío de correos y que el tipo de invocación sea Event. Con esto al menos se te deberían mostrar mensajes de error en CloudWatch cada vez que llegue un nuevo correo para poder así depurar el problema.

Manuel Asuar 12 de septiembre de 2017

Buenas Daniel, he leido los mensajes de error del CloudWatch y me faltaba permitir enviar el mensaje leido, en el JSON, jeje.. ya funciona, gracias. Ahora el problema lo tengo en eNviar desde la cueta gmail como domio, el error es : 554 Message rejected: Email address is not verified. The following identities failed the check in region US-EAST-1: Un saludo.

Daniel 12 de septiembre de 2017

Me alegro de que ya te funcione. Ese error que comentas y lo que hay que hacer para solucionarlo están explicados en el punto 5.

alejandro 13 de octubre de 2017

Hola Daniel, excelente aporte. Estoy buscando una solucion para superar el limite de envios diarios de gmail. Por lo que veo SES no proporciona una cuenta sino que termina siendo un routeador robusto de los mails o estoy equivocado? Saludos y gracias!

Daniel 13 de octubre de 2017

Hola Alejandro. Efectivamente, aunque sí permite usar distintas cuentas de envío y recepción, no proporciona una cuenta de correo equivalente a una de GMail, sino que está más enfocado al envío masivo de correo tipo newsletter o similar, o a la recepción de correo con el fin de efectuar algún tipo de procesamiento automático basado en reglas sobre el mismo. Si lo que quieres es algo similar a GMail o Google Suite, Amazon también proporciona un servicio equivalente: Amazon WorkMail.

alejandro 13 de octubre de 2017

Genial muchas gracias por tu ayuda.

Hector 16 de octubre de 2017

Hola, gracias por la información tan completa, he realizado todos los pasos pero no logro que los mensajes queden en S3 y mucho menos que haga el reenvio a Gmail, es necesario tener el dominio completamente aparcado en Route53? Lo tengo asociado en un hosting común, dónde lo veo para navegar y subir archivos. Tendría que eliminar todos los registros de ese dns? es la duda que se me presenta con los servicios de Amazon si son compatibles. Gracias

Daniel 19 de octubre de 2017

Hola Héctor. No es imprescindible usar los DNS de Amazon, pero para hacerlo funcionar al principio sí es necesario crear la zona correspondiente a tu dominio en Route53, de modo que se creen los registros requeridos por Amazon SES tal y como explico en el punto 2 de este mismo artículo. Una vez que ya todo funcione puedes replicar manualmente esos mismos registros que aparecen señalados en rojo a tu proveedor de DNS y prescindir de la zona de Route53.

Fernando 2 de enero de 2018

Hola buenos dias daniel ,tengo una duda con aws realmente me sirve nesesito aprox 15 cuentas de correo puedo usarlas solo con una cuenta de gmail que otra herramienta tiene aws para cubrir esa nesesidad que tengo saludos.

Daniel 2 de enero de 2018

Sí, no hay problema en usar este método para gestionar una única dirección de email, 2, 3 ó 15 distintas desde la misma cuenta de GMail. También lo puedes usar para gestionar varias direcciones de email desde varias cuentas de GMail distintas, por ejemplo en el caso de empresas con varios empleados o colaboradores usando el mismo dominio. AWS tiene su propio servicio de correo que se llama WorkMail, pero entonces no podrías usar GMail directamente y tendrías que recurrir a métodos indirectos como este u otros, y entonces no tendría mucho sentido usar WorkMail.

Claudio 3 de febrero de 2018

Hola Daniel primero que nada gracias por tomarte el tiempo de realizar el tutorial, estoy tratando de configurar los mails de mi dominio a travez de los servicios de amazon, pero no tengo muy claro el tema de los dns records, me interesa que siga redireccionado todo a mi hosting salvo la gestion de mail, de ser asi tengo que colocar los NS records de mi hosting y en el hosting los SOA y MX apuntar a amazon? Saludos

Daniel 18 de febrero de 2018

Efectivamente Claudio, si lo único que quieres gestionar con Amazon es el correo, entonces tienes que mantener toda la configuración DNS que te ofrezca tu proveedor de hosting, incluidos los registros de tipo NS y SOA, y tan sólo sustituir los registros MX por otros que apunten a Amazon.

César González 10 de marzo de 2018

Hola Daniel. Tengo una cuenta en aws y tengo un servidor EC2 con windows server funcionando. Este servidor lo uso como una de mis capas de servicio (Modelo DataSnap), este tiene una REST para enviar correos de recuperación de claves y cambio de ellas, las cuales quiero enviar desde mi correo corporativo el cual ya tengo (info@midominio.com), la inquietud es que no he sabido como configurar mi hosting para que pueda recibir el registro txt que me pide esta aplicacion (SES), Uso Mydomain.com como gestor de dominio.

Daniel 12 de marzo de 2018

Hola César, los registros TXT no se reciben, se añaden al dominio como otro registro cualquiera de tipo A, CNAME, MX. En el panel de control del gestor de tu dominio debería haber un apartado "Zonas DNS" o similar que te permita gestionar las zonas DNS de tu dominio, que normalmente sólo será una y en la que estarán todos los registros DNS que tenga configurados ya por defecto tu dominio. Debería haber un botón de añadir o crear un nuevo registro DNS que te permita seleccionar su tipo (A, CNAME, MX, TXT, NS, SOA...) y un par clave/valor donde la clave sería el nombre que queremos asignar a esa entrada DNS y el valor suele ser una dirección IP u otro nombre DNS, y en el caso de los registros TXT una cadena de texto que puede ir o no entrecomillada.

Porfirio Ángel Díaz Sánchez 12 de marzo de 2018

Qué tal Daniel, configuré el Simple Email Service para recibir correos en Gmail, pero tengo algunos problemas para enviar y recibir archivos con adjuntos. Hice algunas pruebas y puedo enviar adjuntos de hasta aproximadamente 7 megabytes, no sé si este límite se pueda incrementar, al menos a que sea igual al de gmail (25 megas) Y al recibir mensajes con adjuntos en ocasiones no puedo verlos en la interfaz de gmail, pero en el bucket del s3 sí se reciben. Ojalá puedas echarme la mano

Daniel 12 de marzo de 2018

Es cierto, yo también me he encontrado con esa limitación. Se produce un error Javascript (recordemos que la función Lambda que procesa los mensajes para su reenvío está escrita para NodeJS) cuando el tamaño del mensaje es superior a 10 MB. Como los adjuntos del email se codifican en Base64, esto equivale aproximadamente a un tamaño de adjunto de unos 6,8 MB aproximadamente. Cuando el mensaje supera ese tamaño la función Lambda no puede procesarlo y deja un error en el log de Amazon CloudWatch y el mensaje no se reenvía. Lo lamento, pero no he encontrado aún una solución para este problema. He visto algún código similar en Python que parece no tener esa limitación, y también algún otro enfoque que se basa en sustituir el fichero o ficheros adjuntos codificados en Base64 por un link en el cuerpo del mensaje hacia los ficheros adjuntos almacenados en el bucket de S3, pero no he conseguido aún una forma definitiva de salvar la mencionada limitación. Por tanto, de momento conviene tener la precaución de no enviar ficheros adjuntos muy grandes.

Porfirio Ángel Díaz Sánchez 12 de marzo de 2018

De momento estoy haciendo eso, tratar de no enviar adjuntos tan grandes. Sobre mi otro problema, cuando desde algún correo por ejemplo de hotmail envío algún adjunto al email que tengo asociado al amazon web services, y dicho correo tiene adjuntos, el correo no me llega a Gmail (y al bucket de s3 sí me llega), pero si no lleva adjuntos sí lo recibo.

Wilson 17 de abril de 2018

Hola Daniel, excelente articulo, al principio me dio algunos problemas la configuracion pero ya logre que me funcionara, tengo un problema que no he podido resolver, como puede bajar o transferir los correos que recibo en S3 bucket a mi cuenta gmail u a los usuarios de las cuentas.

Jorge García 29 de noviembre de 2018

Tengo exactamente la misma duda.

Daniel 29 de noviembre de 2018

Wilson, Jorge, el reenvío de correos desde el bucket de S3 al buzón de GMail se hace a través de la función Lambda tal y como se explica en los puntos 3 y 4. Saludos.

Javier Doas 4 de enero de 2019

Hola Daniel, Gracias por el tutorial, Funciona bastante bien, envía y recibe, sólo un detalle.Cuando se responde un correo, me respondo a mi mismo y no al correo que me envío el email supuestamente, entiendo que es un reenvío, pero como puedo arreglar eso. Todo bien aquí info@empresa.com > envía a >juancho@hotmail.com Juancho@hotmail.com > responde a > info@empresa.com El problema aqui Juancho@hotmail.com > envía a > info@empresa.com info@empresa.com > responde a > info@empresa.com ¿Cómo puedo solucionar esto? ¿Alguna idea? Gracias de antemano.

Daniel 8 de enero de 2019

Hola Javier, efectivamente tras un tiempo usando esta solución he encontrado 3 limitaciones. Una es esta que comentas, aunque no es un problema para mí, ya que sé que los correos procedentes de una dirección determinada (puedes usar una dirección inexistente de tu dominio, por ejemplo, forwarded@example.com) son correos reenviados y sólo tengo que pulsar el botón "Responder" para saber la dirección del verdadero remitente, no su nombre, que no sufre ninguna alteración. Desde el punto de vista del remitente, nada cambia y es completamente transparente tanto al escribirnos como al recibir nuestro correo, por lo que creo que es una buena solución dado el coste, aunque es cierto que es algo molesto y sería mejor que no ocurriera. La segunda limitación está relacionada con esta primera: en el histórico de los correos también aparece la dirección de reenvío de tu dominio en lugar de la del remitente (su nombre sí aparece bien), por lo que hay que acordarse de cambiarla si para nosotros es importante que aparezca bien. Esto puede ser algo molesto, aunque como sí aparece bien el nombre para mi no es un problema. La tercera limitación es el tamaño de los ficheros adjuntos. Pongo más detalles sobre esto en un comentario anterior que aparece más arriba de estas líneas. Entiendo que estos defectos puedan causar molestias, no es un método perfecto, pero dado su bajo coste puede servir de ayuda a mucha gente, y si se trata de limitaciones importantes en tu caso entonces te recomiendo que vayas a soluciones de pago más sofisticadas como Google Suite o Amazon Workmail.

alberto 11 de enero de 2019

Tengo un servidor para un par de dominios con un catch-all, es decir un unico correo que recibe todos los correos a cualquier direccion de esos dominios. Luego hace un forward a mi cuenta de correo en un tercer dominio, no almacena nada, solo necesito recibirlos, luego al contestar se puede usar mi correo real. Ves factible el usar lo que describas mas arriba para sustituir los servidores y el catchall por el que me cobran un dineral?

Daniel 14 de enero de 2019

Efectivamente, un sistema como el que propongo captura todos los correos que llegan a cualquier dirección del dominio y luego los reenvía a la dirección de GMail que corresponda, que puede ser única, por lo que puede funcionar como catch-all. Esto es así debido a que en el punto 4, paso 1, ponemos el nombre del dominio para que englobe a todos los posibles destinatarios.

Omar 21 de abril de 2019

Hola He realizado las configuraciones y verificaciones que comentas en cada paso, sin embargo, no consigo que la lambda redireccione a mi cuenta de gmail. no veo registro alguno en cloudwatch pero si observo que los correos se almacenan correctamete en s3. ¿Hay algún modo de debbuguear la que la lambda se este jecutando correctamente?

Daniel 28 de mayo de 2019

Sí, las Lambda dejan sus propios logs. Pueden ser consultados desde la pestaña Monitorización de cada Lambda o directamente desde CloudWatch.

Carlos Erick 7 de octubre de 2019

Hola Daniel gracias por el articulo. queria consultarte lo siguiente. He realizado la configuracion: https://aws.amazon.com/es/getting-started/projects/setup-email-receiving-pipeline/ Actualmente estoy recibiendo los correos en el Buceked S3 de Amazon, lo que necesito es que me lleguen a mi servidor (exchange) Al hacerlo como lo explicas me llegara desde un correo que yo indique ? es decir fordwarder@midominio.com.bo si es así, como puedo hacer para leer los correos desde el bucket S3 ? Saludos,

Damian Lluch 26 de octubre de 2019

hola!! gracias por la data, estuve una tarde con tu tutorial, y todo salio bien. Me queda generarle el ticket para que me deje enviar a otros correos

Javier Nieve 17 de octubre de 2020

Hola Daniel, seguí tu guía y recibo los correos pero no me deja conectar la cuenta de gmail con el smtp de AWS. El paso de configurar las credenciales en la cuenta de gmail me tira el siguiente error. No ha sido posible conectar con el servidor. Revisa el servidor y el número del puerto.

Enviar comentario

Volver al blog

Daniel López Azaña