TL;DR

• DKIM no evita el spam por sí solo: autentica que un correo fue autorizado por tu dominio.

• SPF y DMARC complementan la autenticación y ayudan a proteger la identidad del remitente.

• La reputación también depende de rebotes, quejas, listas de destinatarios y comportamiento de envío.

• Si tu SaaS envía correos para varios clientes, AWS SES permite aislarlos con tenants y métricas separadas.

• El aislamiento reduce el impacto entre clientes, pero una mala operación global todavía puede afectar tu cuenta de SES.

Que tu código ejecute sendEmail() correctamente no significa que el correo vaya a llegar al inbox. El proveedor receptor evalúa autenticación, reputación, rebotes, quejas y comportamiento de envío antes de decidir si entrega, limita o manda tu mensaje a spam. Por eso la arquitectura de correo importa tanto como el código.

Separar clientes por tenant ayuda a aislar métricas y enforcement de reputación en AWS SES.

DKIM autentica el dominio, no “limpia” tu reputación

DKIM es una firma criptográfica que permite al servidor receptor verificar que el correo fue autorizado por el dominio y que partes relevantes del mensaje no fueron modificadas durante el tránsito. No es un identificador para aislar clientes ni una garantía de llegar a inbox.

En Amazon SES puedes configurar DKIM para tus identidades de dominio. AWS explica que DKIM usa criptografía de clave pública: el mensaje se firma con una clave privada y el servidor receptor valida la firma usando una clave pública publicada en DNS. AWS: autenticación con DKIM.

Piensa en DKIM como una firma digital:

• Tu dominio: “yo autorizo este correo”.

• DKIM: firma el mensaje.

• Gmail, Outlook u otro proveedor: verifica esa firma antes de evaluar el resto de señales.

Eso ayuda a demostrar legitimidad, pero después todavía queda otra pregunta: ¿confío en este remitente?

SPF, DKIM y DMARC resuelven partes diferentes del problema

SPF, DKIM y DMARC trabajan juntos, pero no hacen lo mismo. SPF identifica qué servidores están autorizados para enviar por un dominio; DKIM firma el mensaje; DMARC define cómo validar la alineación de esas señales y qué hacer cuando fallan.

• SPF: autoriza infraestructura de envío.

• DKIM: firma y autentica el mensaje.

• DMARC: verifica alineación y define una política para fallos de autenticación.

Google exige desde 2024 autenticación mínima para quienes envían a Gmail. Para remitentes de más de 5.000 mensajes diarios a cuentas Gmail, exige SPF, DKIM y DMARC, además de otros requisitos como TLS y alineación del dominio. Google: directrices para remitentes.

La conclusión práctica es simple: autenticar es necesario, pero no suficiente para tener buena deliverability.

La reputación decide si un correo termina en inbox o spam

Los proveedores de correo construyen reputación a partir del comportamiento real del remitente. Una configuración DNS correcta no compensa automáticamente una lista mala, demasiados rebotes o usuarios marcando tus mensajes como spam.

Google Postmaster Tools muestra señales como tasa de spam, reputación del dominio y de la IP, autenticación y errores de entrega. Google recomienda mantener la tasa de spam reportada por usuarios por debajo de 0,1% y evitar que alcance 0,3%. Google: FAQ de directrices para remitentes.

Amazon SES también monitoriza métricas como bounces y complaints. Si esas tasas son demasiado altas, AWS puede poner una cuenta bajo revisión o pausar su capacidad de envío. AWS: sender reputation.

Por eso, si estás construyendo un producto real, la pregunta no es solamente “¿se envió?”. También debes observar:

• hard bounces;

• complaints o reportes de spam;

• dominios e IPs de envío;

• autenticación;

• calidad y consentimiento de la lista;

• errores de entrega por proveedor.

Un SaaS multicliente necesita aislar el riesgo de cada cliente

Si varios clientes envían correo desde la misma plataforma, no quieres administrar su reputación como si todos fueran un único remitente. Un cliente con una lista sucia o demasiadas quejas no debería detener el correo de clientes que operan correctamente.

Este fue exactamente el problema que revisamos en una implementación reciente: nuestra plataforma debía enviar correos para distintas instituciones. En pruebas internas vimos mensajes llegando a inbox en Gmail mientras algunos envíos a Hotmail todavía terminaban en spam. Eso no demuestra que un proveedor sea “mejor” que otro; demuestra que cada mailbox provider puede evaluar señales de forma diferente.

La arquitectura que empezamos a usar fue separar cada institución dentro de Amazon SES. Ahí aparece una función especialmente útil: tenants.

Los tenants de AWS SES aíslan métricas y enforcement por cliente

Un tenant de Amazon SES es un contenedor lógico para separar recursos y reputación entre clientes o unidades de negocio. Puede agrupar identidades, configuration sets, templates y métricas de reputación de una entidad específica.

AWS diseñó tenant management precisamente para plataformas que envían correo en nombre de múltiples clientes. SES puede detectar problemas de reputación y pausar al tenant problemático sin detener automáticamente a los demás. AWS: SES Tenants.

Una arquitectura simplificada puede verse así:

Tu app → identidad autenticada → Tenant A → SES → Gmail / Outlook → Inbox o Spam

Tu app → identidad autenticada → Tenant B → SES → Gmail / Outlook → Inbox o Spam

Si Tenant A empieza a generar muchos rebotes o complaints, puedes identificarlo, pausarlo y corregirlo sin administrar Tenant B como si fuera el mismo cliente.

DKIM autentica quién envía. El tenant ayuda a aislar quién puede afectar a quién dentro de SES.

Un tenant no es un escudo mágico para toda tu cuenta

El aislamiento tiene un límite importante: AWS aclara que la actividad combinada de todos los tenants todavía influye en la reputación general de la cuenta. Separar clientes mejora el control y permite enforcement más granular, pero no convierte una operación de correo mala en una operación saludable.

Además, por defecto los tenants comparten la suppression list de la cuenta. Si necesitas aislar también bounces y complaints a nivel de destinatario, SES permite habilitar tenant-level suppression lists. AWS: tenant-level suppression.

Entonces, en una plataforma multicliente yo separaría el problema en tres capas:

1. Autenticación: SPF, DKIM y DMARC.

2. Aislamiento: tenant, identidad y configuration set por cliente cuando tenga sentido.

3. Operación: monitorizar rebotes, complaints, listas y errores de entrega.

Qué implementaría antes de enviar correos en producción

La mejor defensa contra el spam no es una sola configuración: es un sistema observable. Antes de escalar los envíos, necesitas saber qué cliente envió, con qué identidad, qué ocurrió y qué proveedor rechazó o clasificó el correo.

1. Verifica tu dominio y configura SPF, DKIM y DMARC.

2. Separa clientes si tu aplicación envía correo en nombre de varias organizaciones.

3. Captura bounces y complaints por cliente.

4. Activa alertas antes de que una tasa de error se vuelva crítica.

5. Usa Google Postmaster Tools cuando tengas suficiente volumen para observar reputación y autenticación. Google: Postmaster Tools.

6. No sigas enviando a direcciones que rebotan.

7. Permite unsubscribe cuando corresponda, especialmente en mensajes promocionales.

El error típico es esperar a que aparezca el problema. La deliverability debería diseñarse desde el momento en que tu producto empieza a enviar correos reales.

FAQ

¿DKIM evita que mis correos lleguen a spam?

No. DKIM autentica que el mensaje fue autorizado por el dominio y ayuda a los proveedores a confiar en su origen. La entrega a inbox también depende de reputación, complaints, rebotes, contenido, listas y otras señales.

¿Qué diferencia hay entre SPF, DKIM y DMARC?

SPF autoriza servidores de envío; DKIM firma los mensajes; DMARC valida la alineación entre el dominio visible y SPF o DKIM, y permite definir una política frente a fallos de autenticación.

¿Qué es un tenant en AWS SES?

Es un contenedor lógico que permite agrupar recursos y monitorizar reputación por cliente o unidad de negocio. SES puede aplicar enforcement a un tenant problemático sin pausar automáticamente a los demás.

¿Un tenant evita que un cliente afecte completamente a los demás?

Aísla métricas y enforcement de forma importante, pero no es aislamiento absoluto de la cuenta. AWS advierte que la actividad combinada de todos los tenants sigue influyendo en la reputación general de tu cuenta de SES.

¿Por qué un correo puede llegar a Gmail y caer en spam en Outlook?

Porque cada proveedor aplica sus propios modelos y señales para clasificar correo. Una prueba en un proveedor no garantiza el mismo resultado en otro; por eso conviene monitorizar entregabilidad por ISP.

¿Qué métrica debería vigilar primero?

Empieza por bounces y complaints. Si envías a Gmail, Postmaster Tools también permite observar tasa de spam, reputación de dominio/IP, autenticación y errores de entrega.

El siguiente paso

Si tu aplicación manda correos, deja de pensar en email como una simple función de backend. Diseña autenticación, reputación, aislamiento y observabilidad desde el inicio. El objetivo no es solo que el correo salga: es que llegue, puedas medirlo y sepas exactamente qué cliente está afectando tu sistema cuando algo falla.