término · amazon ses

¿Qué es Amazon SES y cómo afecta al correo de su aplicación?

Amazon Simple Email Service, o Amazon SES, es infraestructura de AWS para enviar correo mediante una API o interfaz SMTP y recibir correo. Para un equipo de aplicaciones, elegir SES implica asumir más que la llamada de envío: identidades verificadas, configuración regional, permisos de IAM, gestión de cuotas, composición de mensajes, ingesta de eventos, respuesta a rebotes y quejas, supresión y monitoreo operativo. La aceptación por parte de SES significa que AWS intentará realizar la entrega; no demuestra la llegada a la bandeja de entrada. Trate SES como una capa de transporte y retroalimentación dentro de un sistema más amplio de correo de aplicaciones.

Entienda los límites del servicio

SES acepta correo de aplicaciones a través de las API de AWS o un endpoint SMTP, y puede crear un mensaje MIME a partir de campos estructurados o aceptar un mensaje creado por el remitente. Eso lo convierte en infraestructura, no en un flujo de trabajo completo de producto. Su aplicación sigue decidiendo quién puede enviar, qué tenant es propietario de un dominio, cómo se manejan las plantillas y los datos de destinatarios, cuándo son seguros los reintentos y qué ven los usuarios después de que una solicitud se completa correctamente. Una arquitectura útil separa tres estados: la aplicación aceptó un trabajo, SES aceptó un mensaje y un servidor de correo receptor aceptó o rechazó el mensaje. Estos estados ocurren en momentos diferentes y requieren identificadores distintos. Almacene su propio ID de trabajo inmutable junto al identificador de mensaje de SES para poder conciliar los reintentos de webhook y las investigaciones de soporte sin deducirlo a partir de líneas de asunto o datos de destinatarios.

Verifique las identidades antes de enviar

AWS define una identidad verificada como un dominio o una dirección de correo que se usa con SES. Antes de enviar, la identidad de From, Source, Sender o Return-Path debe cumplir las reglas de verificación de SES. La verificación de dominios suele ser la opción duradera para una aplicación, porque puede autorizar las direcciones de ese dominio y admite la autenticación a nivel de dominio. La verificación no es una casilla que se marca una vez y se copia a cada despliegue. El estado de la identidad y la configuración de Easy DKIM son regionales, así que un dominio verificado en una región de AWS no queda listo automáticamente en otra. Diseñe la incorporación como una máquina de estados: solicite la identidad, muestre los registros DNS exactos, consulte el estado autoritativo del proveedor y permita el envío en producción solo cuando la región elegida informe el éxito. Conserve las políticas SPF y DMARC existentes cuando el DNS se comparte con otro remitente, y nunca cree un segundo registro SPF por comodidad.

Haga que la región forme parte de la configuración de correo

Los recursos y los límites operativos de SES son regionales. Las identidades verificadas, el estado de sandbox, la cuota diaria, la tasa máxima de envío, la configuración de Easy DKIM, la configuración de supresión y los destinos de retroalimentación pueden variar entre regiones. Una credencial válida en AWS no hace que una identidad sea portable a otro endpoint de SES. Coloque la región junto a la cuenta del proveedor y la identidad en la configuración, en lugar de ocultarla en un valor predeterminado genérico del entorno. Para la conmutación por error, prepare la región secundaria antes de que ocurra un incidente: verifique la identidad, publique sus registros DKIM, obtenga acceso de producción y cuotas adecuadas, configure los destinos de eventos, pruebe los identificadores de mensaje y el procesamiento de webhooks, y confirme que entiende el comportamiento de la supresión. De lo contrario, cambiar solo el endpoint durante una interrupción puede sustituir un incidente por fallos de verificación, throttling o retroalimentación faltante.

Elija entre API y SMTP de forma deliberada

AWS admite el envío en producción mediante la API de SES y la interfaz SMTP. La API se adapta a aplicaciones que ya usan la autenticación y los SDK de AWS, y expone operaciones de mensajes estructurados y sin procesar (raw). SMTP se adapta a software que ya habla SMTP, pero las credenciales SMTP de SES son distintas de las claves de acceso habituales de AWS y siguen siendo regionales. La elección no elimina la necesidad de colas, idempotencia, manejo de tiempos de espera ni reglas de reintento seguras. Si una conexión falla antes de que su aplicación reciba una respuesta, es posible que el proveedor ya haya aceptado el mensaje. Evite reintentar a ciegas una solicitud de cara al usuario con un nuevo identificador de aplicación. Encole una sola vez, conserve la respuesta del proveedor cuando esté disponible y haga que los workers reintenten un trabajo estable. Use una operación de mensaje sin procesar solo cuando necesite un control exacto del MIME, y valide los encabezados y la longitud de las líneas antes de entregar el mensaje a SES.

Trate el sandbox y las cuotas como restricciones en tiempo de ejecución

Las nuevas combinaciones de cuenta y región de SES pueden estar en el sandbox. AWS documenta actualmente límites del sandbox de 200 entregas a destinatarios por cada 24 horas y un correo por segundo, con el envío restringido a destinatarios verificados excepto para el simulador de buzón. Las cuotas de producción varían según la cuenta, la región y el caso de uso aprobado. Las cuotas cuentan destinatarios, no solicitudes de API, por lo que una solicitud dirigida a diez destinatarios consume diez unidades. Consulte la cuota real de cada región activa y diseñe el backpressure teniendo en cuenta tanto la asignación diaria móvil como la tasa de envío. Una limitación del proveedor debe retrasar un trabajo en cola, no crear envíos duplicados ni presentarse como un éxito sin explicación. Solicite acceso a producción y límites realistas antes del lanzamiento, y luego realice pruebas de carga con destinatarios controlados. No describa el sandbox como un nivel gratuito ni suponga que la aprobación en una región se aplica a otra.

Construya el estado de entrega a partir de los eventos

Una operación de envío correcta en SES significa que la solicitud fue aceptada y que SES intentará la entrega. No significa que el destinatario abrió el mensaje, que lo vio en la bandeja de entrada ni siquiera que el servidor receptor lo aceptó. La publicación de eventos de SES puede informar envíos, entregas, rebotes, quejas, rechazos, fallos de renderizado, retrasos, suscripciones, aperturas y clics a través de destinos de AWS configurados. La distinción operativa importante es que un evento de entrega representa la aceptación por parte del servidor de correo del destinatario, mientras que los eventos de rebote y queja exigen respuestas de política. Ingiera los eventos de forma idempotente, porque los sistemas de entrega pueden reintentar las notificaciones. Conserve el identificador de mensaje del proveedor y la hora del evento, rechace los payloads de webhook malformados y haga que las transiciones de estado sean monótonas siempre que sea posible. Las aperturas y los clics observados son señales de interacción opcionales, con limitaciones de privacidad y de cliente; no deben redefinir si se produjo la entrega a nivel de transporte.

Gestione rebotes, quejas y supresión

Suprimir a los destinatarios que se sabe que son inválidos o que no quieren recibir correo protege tanto a los usuarios como a la cuenta de envío. AWS ofrece supresión global, a nivel de cuenta, a nivel de conjunto de configuración y, más recientemente, a nivel de tenant, pero el alcance exacto depende de la configuración y de la región. Su aplicación sigue necesitando una política clara de destinatarios. Las direcciones con rebote permanente deben dejar de recibir reintentos rutinarios, las quejas deben provocar una supresión inmediata y la eliminación de la supresión debe exigir pruebas de que la dirección es válida y de que el destinatario espera el correo. En un producto multitenant, decida si la supresión abarca toda la cuenta o está aislada antes de incorporar clientes, porque una supresión compartida puede hacer que el resultado de un tenant afecte los envíos de otro. Mantenga las direcciones sin procesar fuera de la analítica y los logs generales. Los sistemas operativos pueden necesitar la dirección para aplicar la supresión, pero los paneles y los experimentos deben usar medidas agregadas o seudónimas.

Aplique el mínimo privilegio y aísle a los tenants

Las políticas de IAM pueden restringir qué operaciones de SES puede invocar una entidad principal y limitar las direcciones From, de destinatario o Return-Path en las acciones de envío. Las políticas de autorización de envío resuelven otro problema: permiten que el propietario de una identidad delegue el uso de una identidad verificada, y se pueden revocar de forma independiente. Para una sola aplicación, prefiera una entidad principal que tenga solo las acciones de envío y monitoreo que la carga de trabajo realmente necesita. No entregue credenciales de AWS a un navegador web. Un producto de correo multitenant también necesita autorización en la capa de aplicación, porque una cuenta de SES compartida no entiende automáticamente su modelo de espacios de trabajo. Compruebe que el tenant autenticado es dueño de un dominio From verificado antes de enviar a SES, limite las claves de API y los registros de mensajes a ese tenant, y haga que los identificadores de otros tenants no devuelvan datos. El IAM del proveedor y la autorización de la aplicación son controles complementarios, no sustitutos.

Use una lista de comprobación para producción

Antes del lanzamiento, registre la cuenta de AWS, la región, el ARN de la identidad, el estado de verificación, el estado de DKIM, el estado de sandbox, la cuota diaria, la tasa máxima de envío, el destino de eventos, el alcance de la supresión y el responsable de las credenciales. Pruebe una entrega normal, un rebote con el simulador de buzones, una prueba de queja donde se admita, una respuesta de throttling, un reintento de evento y un tiempo de espera agotado del proveedor después del envío. Confirme que los workers de la cola no duplican un trabajo estable, que un evento de entrega actualiza el mensaje correcto y que un rebote permanente impide otro envío rutinario. Configure alarmas para solicitudes rechazadas, throttling, fallos en la ingesta de eventos, cambios en rebotes y quejas, y margen de cuota. Revise la configuración cada vez que se incorpore una nueva región, un dominio, un tipo de tenant o una clase de mensaje. Esta lista convierte SES de una dependencia oculta en un subsistema explícito, con responsables y modos de fallo observables.

Decida dónde encaja SendHQ

Los equipos pueden integrar SES directamente cuando quieren un control nativo de AWS y están preparados para construir la capa de aplicación que lo rodea. SendHQ ofrece un contrato de correo más acotado y limitado al espacio de trabajo, con dominios de envío verificados, claves de API con alcance limitado, envíos individuales y por lotes, bandejas de entrada para correo entrante, acceso a eventos de entrega y flujos de supresión. Su API pública exige que el dominio From pertenezca al espacio de trabajo y esté verificado, y registra los mensajes aceptados para su posterior inspección. Esa capa de producto no reemplaza las reglas de identidad, cuotas y reputación de SES ni el filtrado del lado del destinatario. Evalúe las dos capas por separado: el proveedor transporta el correo e informa sobre él, mientras que la capa de aplicación aplica la propiedad por tenant, expone recursos estables y presenta el estado operativo. Ni SES directo ni SendHQ garantizan la llegada a la bandeja de entrada, así que evalúe ambos por sus controles, su observabilidad, la responsabilidad que implican y su adecuación al flujo de trabajo de su aplicación.

Preguntas frecuentes

¿Amazon SES es una API de correo o un servidor SMTP?

Ofrece tanto una API HTTPS como una interfaz SMTP. Elija según las necesidades de autenticación y composición de mensajes de su aplicación, y mantenga las colas, los identificadores de trabajo estables, el procesamiento de eventos y la supresión fuera de la llamada de transporte.

¿Tengo que verificar un dominio para usar Amazon SES?

Debe verificar cada identidad que use como dirección From, Source, Sender o Return-Path. Una identidad de dirección de correo puede servir en casos limitados, mientras que la verificación de dominios suele ser más práctica para direcciones controladas por la aplicación y para DKIM.

¿Una respuesta correcta de SES significa que el correo se entregó?

No. Significa que SES aceptó la solicitud e intentará la entrega. Un evento de entrega posterior significa que el servidor de correo del destinatario aceptó el mensaje, y ninguno de los dos estados demuestra que el mensaje llegó a la carpeta de bandeja de entrada.

¿Las cuotas de Amazon SES se comparten entre regiones?

No. AWS documenta que las cuotas de envío, el estado de sandbox, las identidades verificadas, la configuración de DKIM y la configuración de supresión son regionales. Prepare y pruebe cada región que pueda recibir tráfico de producción, en lugar de cambiar de endpoint durante un incidente.

¿Qué debe guardar una aplicación después de enviar mediante SES?

Guarde un ID de trabajo de aplicación estable, el identificador de mensaje de SES cuando se acepte, el proveedor y la región, el estado actual, las marcas de tiempo y los eventos de entrega normalizados. Mantenga el contenido de los mensajes y los datos de los destinatarios fuera de los logs y la analítica generales.

¿Cuándo conviene usar SendHQ en lugar de SES directo?

Use SES directo cuando el equipo quiera hacerse cargo de la integración con AWS y de todos los controles que la rodean. Considere SendHQ cuando las claves limitadas al espacio de trabajo, las comprobaciones de propiedad del dominio, las bandejas de entrada para correo entrante, los recursos de mensajes, los eventos de entrega y los flujos de supresión sean primitivas útiles para su aplicación.

Fuentes

Siga aprendiendo

Costo de Amazon SES: un modelo de precios para equipos de productoModele el costo de Amazon SES según destinatarios, datos, planes de precios, IP dedicadas, infraestructura de eventos, cuotas y la capa de ingeniería que rodea la entrega.