Amazon SES desde cero: configurar un dominio, DKIM, DNS y enviar correos de prueba
Configurar el envío de correos desde una aplicación no consiste solo en introducir una dirección de remitente. Hay que demostrar el control del dominio, publicar correctamente los registros DNS, comprender qué hace cada protocolo de autenticación y distinguir el sandbox de la autorización para enviar a usuarios reales. Esta guía práctica explica el proceso de Amazon SES con ejemplos neutros, sin describir sistemas privados.
¿Qué es Amazon SES y cuándo tiene sentido?
Amazon Simple Email Service (SES) es un servicio de AWS para enviar correos transaccionales, notificaciones y campañas autorizadas mediante API o SMTP, y también ofrece ciertas funciones para recibir y procesar correo. Puede utilizarse con aplicaciones PHP, Laravel, Node.js, Python, Java, WordPress o servicios propios, sin que la aplicación tenga que estar alojada en AWS. No es una bandeja de entrada de usuario como Gmail: es infraestructura de mensajería.
Ejemplos útiles son confirmaciones de compra, avisos de cita, recuperación de acceso, facturas o notificaciones de una aplicación. Para newsletters es necesario gestionar consentimiento, bajas y reputación. Ningún servicio garantiza que todos los mensajes terminen en la bandeja principal.
Los conceptos que hay que dominar: DNS, MX, SPF, DKIM y DMARC
| Elemento | Qué hace | Qué debes saber |
|---|---|---|
| DNS | Publica registros que otros servidores consultan | Los cambios se realizan en el proveedor DNS autoritativo, no necesariamente donde se compró el dominio |
| MX | Indica qué sistema recibe los correos destinados al dominio | No hace falta modificar el MX principal para empezar a enviar mediante SES |
| SPF (TXT) | Autoriza servidores para el dominio del remitente de sobre o MAIL FROM | No publiques dos SPF diferentes en el mismo nombre DNS |
| DKIM | Firma criptográficamente el mensaje para validar el dominio firmante | SES Easy DKIM facilita tres CNAME propios, compatibles con otros selectores DKIM |
| DMARC | Comprueba alineación de SPF o DKIM con el From visible y aplica una política | Una firma DKIM válida y alineada puede permitir DMARC incluso si SPF no está alineado |
Es perfectamente posible conservar el proveedor que recibe correo y varios servicios que envían con el mismo dominio, siempre que estén bien autenticados. El peligro no es utilizar varios proveedores: es borrar un registro existente, publicar una política contradictoria o confundir autenticación con entregabilidad.
Guía paso a paso: verificar un dominio con SES
- Abre SES → Identidades verificadas en Europa (Irlanda), o selecciona la región que realmente utilizará tu aplicación. Las identidades de SES se verifican por región.
- Elige Crear identidad → Dominio y escribe un dominio que controles; en esta guía se usa
example.com, reservado para documentación, y no un dominio operativo. - Selecciona Easy DKIM, normalmente RSA de 2048 bits. No necesitas BYODKIM si AWS puede gestionar las claves.
- Si Route 53 no gestiona tus DNS autoritativos, no elijas crear automáticamente los registros allí. SES mostrará normalmente tres registros CNAME; copia exactamente nombre y destino.
- En el proveedor DNS que tenga los nameservers autoritativos del dominio, añade los tres CNAME sin borrar MX, SPF, DKIM anteriores ni DMARC.
- Comprueba si el panel DNS completa automáticamente el sufijo del dominio: si escribes el FQDN entero donde el panel espera solo el selector, puedes crear un nombre duplicado.
- En Cloudflare, los registros CNAME utilizados para DKIM deben publicarse como Solo DNS cuando proceda, no como un proxy HTTP.
- Regresa a SES y comprueba que la identidad y DKIM alcanzan los estados de verificación correctos. La propagación puede llevar tiempo, incluso hasta 72 horas según AWS.
Ejemplo ilustrativo de CNAME
| Tipo | Nombre | Destino |
|---|---|---|
| CNAME | selectorA._domainkey.example.com | selectorA.dkim.amazonses.com |
| CNAME | selectorB._domainkey.example.com | selectorB.dkim.amazonses.com |
| CNAME | selectorC._domainkey.example.com | selectorC.dkim.amazonses.com |
Son valores completamente ficticios: no funcionarán al copiarlos. Es obligatorio utilizar los registros de la identidad real generados por AWS, cuyos destinos pueden incluir sufijos específicos de región.
¿Debo tocar el SPF existente o cambiar el MX?
Con Easy DKIM, para verificar un dominio remitente no hace falta sustituir el MX utilizado por el proveedor de correo entrante ni añadir un segundo SPF en el dominio raíz. SES usa por defecto un MAIL FROM de amazonses.com con SPF propio. La alineación DMARC puede alcanzarse por DKIM si la firma coincide con el dominio visible del remitente.
Si se desea un MAIL FROM personalizado, la situación cambia: SES exige configurar un subdominio dedicado, un MX específico para ese subdominio y un TXT SPF en él. No debe confundirse ese MX con el MX principal de recepción. Revisa la documentación oficial de MAIL FROM personalizado. Múltiples mecanismos de envío pueden coexistir, pero conviene auditar SPF y DMARC antes de modificar políticas.
Sandbox: por qué SES no deja enviar a cualquier persona al principio
Una cuenta nueva puede comenzar en el sandbox de SES. Mientras permanece allí, el envío a destinatarios ordinarios está restringido a direcciones o dominios de destino verificados; también se puede usar el simulador de buzones de SES. Verificar el dominio remitente no elimina automáticamente esa restricción. El estado y los límites se consultan en el panel de cuenta de SES.
Para probar de forma segura: verifica una dirección de destino que controles, abre una identidad de envío verificada y utiliza Enviar correo electrónico de prueba. Puedes probar entrega aceptada o rebote con el simulador, aunque sus correos pueden facturarse. Cuando hayas probado el recorrido, solicita acceso a producción y explica el uso legítimo, volumen estimado y gestión de bajas o rebotes. AWS decidirá la aprobación y las cuotas.
Prueba de consola frente a prueba de aplicación
Que la consola permita enviar un email confirma una parte de la integración: la identidad y el servicio de envío. No demuestra que el software pueda utilizar las credenciales, invocar la API, manejar errores o registrar el resultado.
Una arquitectura conceptual podría ser:
Aplicación → Backend autenticado
|
Cola de trabajos (opcional)
|
Servicio de notificaciones
|
Amazon SES API
|
Servidor receptor
|
Eventos entrega / rebote
Si se utiliza Lambda, no se necesita para el primer correo de prueba: es un componente opcional que puede procesar trabajos. Para producción conviene revisar permisos IAM de envío, políticas por identidad, colas, límites de volumen, identificadores de mensaje y eventos de entrega, rechazo y denuncia. Un mensaje aceptado por la API no garantiza entrega final.
Seguridad, privacidad y entregabilidad
Utiliza roles o identidades de carga de trabajo cuando sea viable y evita claves permanentes incrustadas en aplicaciones o repositorios. Concede únicamente los permisos necesarios de SES a los recursos autorizados. Protege los formularios contra abuso y controla el envío masivo accidental. Configura supresiones, métricas, avisos de rebote y reclamaciones, y revisa la calidad de las listas de destinatarios.
Si el correo contiene datos personales, evita incluir información innecesaria, aplica las obligaciones de privacidad correspondientes y conserva registros limitados. Diseña también una estrategia para errores y reintentos que no duplique notificaciones sensibles.
Precios orientativos de Amazon SES en octubre de 2026
AWS presenta planes Essentials, Pro y Enterprise y una alternativa de precios a la carta. En el primer tramo de hasta diez millones de correos al mes, Essentials cuesta 0,16 USD por cada 1.000 correos, Pro 0,22 USD por 1.000 con una tarifa adicional de 105 USD por cuenta y región al mes y Enterprise 0,23 USD por 1.000 más 500 USD por cuenta y región al mes. El modo a la carta publica 0,10 USD por 1.000 correos salientes. Las nuevas cuentas o combinaciones cuenta/región sin actividad previa suelen comenzar con Essentials desde julio de 2026; revisa qué plan tiene asignado tu entorno.
| Envíos al mes | Essentials (0,16 USD / 1.000) | A la carta (0,10 USD / 1.000) |
|---|---|---|
| 1.000 | 0,16 USD | 0,10 USD |
| 10.000 | 1,60 USD | 1,00 USD |
| 100.000 | 16,00 USD | 10,00 USD |
| 1.000.000 | 160,00 USD | 100,00 USD |
Son cálculos ilustrativos exclusivamente del tramo de envío, sin impuestos, adjuntos, funciones adicionales, uso de otros servicios o créditos promocionales. Los correos pueden cobrarse por destinatario; añade costes de datos, validaciones, IP dedicadas o funciones avanzadas según lo utilizado. La página oficial y la consola prevalecen sobre cualquier cifra de este artículo.
También existen distintas modalidades de nivel gratuito o créditos según fecha de alta y elegibilidad. No presupongas 3.000 correos gratis al mes para una cuenta recién creada: AWS modificó su política en julio de 2026. Consulta el plan de facturación y la página de tarifas antes de estimar costes.
Errores frecuentes y cómo reconocerlos
Un estado pendiente suele indicar que SES no encuentra los CNAME, que el panel DNS ha duplicado el dominio o que se está mirando otra región. Un error de dirección no verificada puede proceder del remitente o, en sandbox, del destinatario. Si el correo llega a spam, revisa autenticación, alineación, reputación y contenido, no solo DKIM. Si el proveedor anterior deja de recibir correo, comprueba si accidentalmente se han modificado los MX principales.
Conclusión
SES puede añadirse como un canal de salida más sin sustituir los demás sistemas. Primero verifica identidad y DKIM, después prueba en sandbox y por último conecta la aplicación y solicita producción. Revisa límites, métricas y costes antes de escalar.
Una empresa que necesite asistencia profesional puede acudir a proveedores especializados, como Screen Art, además de consultar la documentación de AWS.
Acceso a producción de SES: qué información puede pedir AWS
Salir del sandbox no es simplemente pulsar un botón. Tras solicitar acceso a producción en la región elegida, AWS puede evaluar el caso y pedir información adicional para determinar si el uso previsto respeta sus políticas. Una solicitud de aclaraciones no equivale a una denegación ni garantiza que el acceso vaya a aprobarse. El remitente debe disponer de una identidad (dirección o dominio) verificada en la misma región para la que solicita producción.
Una revisión puede pedir, incluso si ya se indicó antes, los siguientes datos:
| Información | Qué conviene explicar |
|---|---|
| Web o aplicación | URL pública del servicio que originará los envíos y su finalidad legítima. |
| Tipo de mensajes | Si son transaccionales (confirmaciones, avisos de servicio, recuperación de cuentas) o marketing (boletines y promociones). |
| Volumen previsto | Estimación realista por día o mes y evolución esperada. No existe una cifra universal recomendada. |
| Origen de destinatarios | Cómo se obtienen las direcciones y qué relación, permiso o base legítima justifica los envíos. No utilizar listas compradas o extraídas indiscriminadamente. |
| Rebotes y reclamaciones | Qué mecanismos están activos para detectar errores, suprimir direcciones problemáticas, investigar quejas y dejar de enviar cuando corresponda. |
| Ejemplo de correo | Una muestra representativa sin datos personales reales, con asunto, contenido y contexto de envío. |
Ejemplo genérico de uso transaccional
Una plataforma de reservas podría explicar que enviará confirmaciones solicitadas por sus usuarios, con un volumen inicial reducido que aumentará si se incorporan más negocios. Los destinatarios habrían facilitado su dirección al solicitar la reserva. El ejemplo de mensaje podría ser:
Asunto: Confirmación de tu reserva
Hola: tu reserva para la fecha y hora indicadas ha quedado registrada. Si necesitas modificarla, utiliza el canal de atención indicado por el establecimiento.
Este correo se envía en relación con una solicitud realizada por ti.
El ejemplo no presupone consentimiento para campañas publicitarias. Los correos transaccionales y los comerciales pueden tener requisitos distintos, incluidos los de baja y normativa aplicable.
Rebotes, reclamaciones y listas de supresión
Un rebote indica que un mensaje no ha podido entregarse; puede ser permanente o temporal. Una reclamación puede indicar que alguien lo ha marcado como correo no deseado. SES permite configurar métricas, supresión y publicación de eventos mediante destinos adecuados, por ejemplo SNS, EventBridge o Firehose según las funcionalidades utilizadas. Pero hay que distinguir entre capacidades disponibles y mecanismos ya configurados.
Si la automatización de rebotes aún no está desplegada, debe explicarse con transparencia qué supervisión manual existe y qué medidas se adoptarán antes de aumentar los envíos. No se debe afirmar que llegan alertas, que se tramitan supresiones automáticas o que hay un sistema de reintentos si todavía no se ha probado. AWS puede solicitar más evidencias o mantener el sandbox hasta completar su evaluación.
Cómo contestar a una solicitud de datos adicionales
- Abre el caso correspondiente en AWS Support Center desde la cuenta correcta.
- Reúne los seis apartados y responde de forma concreta y coherente, preferiblemente en un solo mensaje.
- Confirma que la identidad remitente está verificada en la región solicitada.
- Declara las medidas operativas existentes y separa las que siguen en preparación.
- Conserva la respuesta y comprueba las comunicaciones posteriores: AWS determina la aprobación y las cuotas.
No respondas a una dirección automática no-reply cuando la notificación indique que las respuestas deben enviarse desde el centro de soporte. Tampoco publiques el identificador de un caso, contactos personales, accesos privados ni información técnica sensible en una guía pública.
Antes y después de la aprobación
Una vez concedido el acceso a producción, revisa las cuotas de la región, los límites diarios y de velocidad, la autenticación DNS, el control de gastos y las políticas contra abuso. La aprobación no garantiza que cada correo llegue a la bandeja de entrada: la reputación de envío, los rebotes y la experiencia de los destinatarios siguen siendo importantes. El control de listas de destinatarios y los eventos de entrega debe formar parte del mantenimiento.
AWS: documentación oficial para solicitar acceso a producción.
Comments (0)
No comments yet.
Leave a Comment