Entregabilidad del correo: gestión y diagnóstico

La entregabilidad del correo solía tratarse como una instalación básica: añadir un dominio, copiar registros DNS y olvidarse. Ese enfoque resulta insuficiente en 2025 y 2026. Si no llegan las facturas, desaparecen las respuestas de clientes o Microsoft devuelve errores 421 y 550, conviene investigar la operación del correo, no asumir que es solo un problema de marketing.

Para la configuración general, empieza por correo empresarial. Esta guía parte de que ya utilizas tu propio dominio y quieres mantener el funcionamiento del envío. La entregabilidad no se resuelve con una casilla: combina sistemas que cambian, distintos modos de fallo y errores que pueden afectar al negocio. La aceptación SMTP tampoco garantiza llegada a la bandeja de entrada.

La buena noticia es que puedes investigar sus componentes: autenticación, infraestructura, reputación y respuesta a incidencias. Separarlos ayuda a dejar de interpretar cada fallo como algo aleatorio.

Qué cambió después de 2024

La operación requiere seguimiento, no solo una configuración inicial. Gmail y Yahoo reforzaron los requisitos para remitentes en febrero de 2024. Google indica que un dominio que alcance su umbral de remitente masivo puede conservar esa clasificación. Por eso conviene mantener autenticación, control de quejas y supervisión, no revisarlos únicamente al publicar un dominio.

Google describe como remitentes masivos a los dominios que envían cerca de 5,000 mensajes o más a cuentas personales de Gmail en 24 horas, agregados por dominio principal. Así, alerts.example.com, billing.example.com y marketing.example.com se contabilizan conjuntamente. Separar subdominios no evita ese cómputo ni garantiza aislamiento de reputación.

Los equipos pequeños pueden pasar por alto este alcance al pensar que solo afecta a grandes boletines. Los requisitos específicos de envío masivo son más estrictos, pero la autenticación básica y las buenas prácticas también importan en otros envíos. Un dominio nuevo puede sufrir limitaciones por distintas razones antes de alcanzar grandes volúmenes.

Google recomienda mantener la tasa de spam denunciado por usuarios por debajo de 0.1% y evitar 0.3% o más en su métrica aplicable. Comprueba el alcance vigente para tu tráfico: esos umbrales no son una garantía universal de entrega ni una medida de todos los mensajes enviados.

Tres comprobaciones esenciales para la autenticación

SPF, DKIM y DMARC aportan comprobaciones complementarias. SPF evalúa la autorización de la IP para una identidad del sobre SMTP. DKIM verifica una firma y la integridad de los datos firmados; no certifica que el mensaje sea seguro. DMARC exige una vía aprobada y alineada con el From visible. Los resultados influyen en la evaluación del receptor, pero un fallo aislado no determina siempre el tratamiento final.

Muchos equipos conocen las siglas. La dificultad está en reconocer cómo se comportan en rutas reales de envío.

SPF: útil y fácil de configurar mal

SPF publica en DNS una política de autorización para el dominio evaluado, normalmente el del remitente del sobre. Es importante, pero tiene dos límites operativos frecuentes.

Primero, el reenvío puede hacer fallar SPF. El receptor ve la IP del intermediario, no la original. Si se mantiene la identidad del sobre y la nueva IP no está autorizada, la evaluación falla. SPF por sí solo no cubre todas las rutas indirectas ni garantiza entregabilidad.

Segundo, existe un presupuesto de términos que requieren consultas DNS. RFC 7208 fija un límite de 10 durante la evaluación, incluidos los términos relevantes anidados. Superarlo, no simplemente alcanzarlo, puede producir permerror aunque el TXT parezca correcto.

example.com. TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.trekmail.net -all"

Este registro es ilustrativo, no una política lista para publicar. Las dependencias anidadas pueden superar el presupuesto y los valores de los proveedores pueden cambiar. Verifica las autorizaciones actuales y retira servicios obsoletos después de revisar el inventario.

DKIM: una vía que puede sobrevivir al reenvío

DKIM firma datos del mensaje con una clave privada y publica la clave de verificación en DNS. Si SPF falla en un reenvío, una firma DKIM válida y alineada puede permitir que DMARC siga pasando.

Las claves antiguas que no cumplen los requisitos del receptor pueden dar problemas. También pueden hacerlo las modificaciones posteriores a la firma: añadir avisos, pies o reescribir datos firmados puede invalidar la comprobación. El efecto depende de lo firmado y de la canonicalización utilizada.

dkim._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

El registro de clave es un ejemplo incompleto. Al rotar claves, publica el nuevo selector antes de cambiar las firmas, prueba cada ruta y conserva la clave pública anterior mientras haya mensajes firmados en tránsito o en cola. Una rotación parcial puede producir fallos sin avisos claros para el usuario.

DMARC: la alineación que a menudo se pasa por alto

DMARC publica una política solicitada para mensajes que no obtienen SPF aprobado y alineado ni DKIM válido y alineado. El receptor conserva sus decisiones locales. SPF aprobado sin alineación no basta, y tampoco una firma DKIM válida de un dominio no alineado, salvo que otra vía cumpla las condiciones.

Shopify, Help Scout, herramientas de soporte, CRM, marketing y facturación pueden enviar en tu nombre. La autenticación técnica puede pasar y DMARC fallar si ninguna identidad se alinea con el dominio visible. Comprueba las opciones de autenticación personalizada de cada servicio.

Envías desde billing@yourdomain.com. El proveedor firma con d=vendor.com. SPF aprueba la IP para una identidad del proveedor y DKIM valida su firma. DMARC falla en este ejemplo porque ninguna identidad aprobada se alinea con yourdomain.com.

Si el comportamiento difiere entre herramientas, empieza por revisar las identidades. Una configuración heredada puede reunir 10 o 15 remitentes y tener solo algunos correctamente alineados. El modo relajado admite el mismo dominio organizativo; el estricto exige coincidencia exacta.

Para la parte DNS, consulta añadir un dominio y los registros DNS necesarios de TrekMail. Son una base para configurar y probar las rutas antes de interpretar las señales de reputación.

La reputación también influye en la entregabilidad

No existe una puntuación universal que determine toda la entrega. Cada receptor puede combinar autenticación, reputación de dominios e IP, quejas, rebotes, calidad de listas, constancia y respuesta de usuarios. Estas señales pueden influir en bandeja de entrada, spam, limitación o rechazo.

DNS suele parecer más fácil de comprobar porque sus registros son visibles. La reputación es menos directa, pero merece seguimiento una vez que la autenticación está bien configurada.

Google recomienda a los remitentes masivos mantenerse por debajo de 0.1% de spam denunciado y evitar 0.3% o más. Tres denuncias entre 1,000 mensajes entregados a la bandeja de entrada alcanzarían ese último umbral en el ejemplo; no lo calcules automáticamente sobre todos los envíos.

Si pocos mensajes llegan a la bandeja de entrada, cada denuncia puede representar una proporción mayor en esa métrica. La clasificación y las quejas pueden relacionarse, pero los datos disponibles no permiten siempre demostrar un ciclo causal ni explicar cada mensaje.

El historial de envío también puede influir. Después de semanas de inactividad, retomar todo el volumen de golpe puede provocar nuevas limitaciones. Considera aumentar gradualmente el tráfico consentido y supervisar respuestas, sin asumir un plazo universal de calentamiento.

Incluye en tu procedimiento las reglas de calentamiento del dominio y por qué los correos van a spam. Verifica su alcance actual y adapta las comprobaciones a cada ruta.

Comprobaciones de infraestructura que no conviene olvidar

SPF, DKIM y DMARC correctos no bastan para demostrar entregabilidad. DNS inverso, TLS, baja, reputación del relé y modificaciones de reenvío pueden aportar otras señales. Conviene examinarlas cuando la autenticación parece correcta pero el tratamiento del receptor cambia.

Empieza por la IP que realmente entrega al receptor. Debe disponer de un PTR apropiado hacia un nombre que resuelva de vuelta a esa IP. Normalmente lo gestiona el propietario de la IP o el proveedor SMTP, no el registrador del dominio. Algunos receptores exigen esa coherencia y pueden rechazar conexiones que no la cumplen.

Comprueba también TLS en cada salto SMTP relevante y los requisitos aplicables del receptor. Un relé que no negocia correctamente puede afectar al transporte. SMTP puede utilizar TLS oportunista según la configuración; no equivale a cifrado de extremo a extremo del contenido.

Para el tráfico de marketing sujeto al requisito, revisa la baja con un clic. RFC 8058 define el mecanismo y sus cabeceras:

List-Unsubscribe: <https://example.com/unsub/abc123>, <mailto:unsubscribe@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

El uso de POST importa porque los sistemas de seguridad pueden visitar enlaces automáticamente. Un GET que da de baja de inmediato puede cancelar suscripciones por error. Prueba el mecanismo completo: endpoint HTTPS funcional para POST y firma DKIM válida que cubra ambas cabeceras, no solo su presencia.

El reenvío a Gmail u Outlook también merece pruebas. Si cambia la IP y se mantiene un remitente del sobre no autorizado para el intermediario, SPF puede fallar. SRS puede permitir SPF para una identidad nueva sin alinearla con el From original; DKIM alineado y válido puede conservar DMARC. Consulta reenviar correo del dominio a Gmail y reenvío de correo para estudiar esas rutas.

Diagnóstico inicial de una incidencia en 10 minutos

Cuando falla el correo, una secuencia breve ayuda a acotar causas. Comprueba si salió del sistema, lee la respuesta SMTP, examina cabeceras disponibles y separa autenticación, reputación, enrutamiento y filtrado del destinatario. El tiempo de resolución depende de los datos y de los sistemas implicados.

No adivines. Sigue estas comprobaciones:

1. Revisa los registros de salida: ¿se envió, aplazó, suprimió o descartó antes de intentar la entrega?
2. Lee la respuesta completa. Un 550 con explicación de autenticación no es lo mismo que un 421 de limitación; el número aislado no basta.
3. Obtén las cabeceras del mensaje recibido o el .eml original. Revisa Authentication-Results añadido por un servidor receptor de confianza, Return-Path y el dominio DKIM d=.
4. Determina si afecta a una ruta o a varias. Una aplicación SaaS puede tener una configuración distinta del correo normal.
5. Busca cambios recientes: dominio, relé, pie de mensaje, CRM o regla de reenvío. Confirma su relación con el fallo en lugar de asumirla.

Ejemplos de pistas SMTP, cuyo texto depende del proveedor:

550 5.1.1  User unknown
550 5.7.1  Access denied or policy block
421 RP-001 Temporary throttle on new or suspicious sender
550 5.7.515 Authentication failure or alignment problem

Si el mensaje llegó a spam, las cabeceras del receptor pueden aportar evidencia. Este ejemplo muestra resultados de autenticación aprobados, no una garantía de bandeja de entrada:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Resultados como spf=softfail, dkim=neutral o dmarc=fail requieren interpretación conjunta. Un Return-Path distinto del From no demuestra por sí solo un error: importa la alineación configurada y si otra vía pasa. El contenido y las políticas del receptor pueden influir incluso con autenticación correcta.

Enfoque anterior y enfoque actual para gestionar la entregabilidad

Un enfoque anterior trataba el correo como un producto de buzones. Otro trata la entregabilidad como una operación con responsables, alcance de incidentes y controles repetibles. Para varios dominios, esa organización puede facilitar el diagnóstico, aunque no elimina las incidencias.

Según sus funciones actuales, TrekMail ofrece alojamiento multidominio con tarifa fija, almacenamiento compartido, creación de cuentas por invitación y migración IMAP de buzones. La fuente permite SMTP propio en Nano y describe SMTP administrado en planes de pago desde $3.50 al mes. Confirma precios, facturación, límites y disponibilidad actuales. Separar alojamiento y envío puede facilitar la gestión, pero no garantiza separar toda la reputación.

Para muchos dominios, compara este modelo con configuraciones compartidas como las de cPanel. Una ruta común puede propagar problemas entre clientes, pero no todos los despliegues son iguales. El inventario multidominio y las comprobaciones DNS pueden ayudar a localizar errores; siguen haciendo falta controles de cuentas y pruebas de envío.

Para desarrollar procedimientos internos, continúa con alojamiento de correo multidominio y gestión del correo de clientes.

Cómo se ve una operación de correo bien mantenida

El objetivo es predecible: DNS revisado, autenticación alineada, pocas quejas, volumen gradual y herramientas probadas antes de activarse. Los reenvíos se diseñan expresamente. Ante un fallo, registros y cabeceras ayudan a acotar la causa, aunque a veces se necesita información adicional del receptor.

Se trata de un objetivo operativo, no de magia ni de una lista genérica que sustituya las pruebas.

Como base práctica, adopta estos controles:

1. Una política SPF por nombre de dominio, con autorizaciones necesarias.
2. DKIM válido en todas las rutas legítimas de salida.
3. DMARC publicado y supervisado; enforcement después de inventario, pruebas y plan de reversión.
4. Cada servicio SaaS con SPF aprobado y alineado o DKIM válido y alineado.
5. Aumentar gradualmente el tráfico consentido en dominios nuevos o inactivos.
6. Suprimir direcciones inexistentes confirmadas y clasificar otros errores permanentes por su código.
7. Mantener el spam denunciado por debajo de 0.1% en la métrica y el tráfico aplicables.
8. Probar reenvío y baja antes de campañas.

Comprar un buzón más sofisticado no resuelve por sí solo la entregabilidad. Hace falta operar el correo como infraestructura: DNS mantenido, rutas claras y controles. Según el plan, TrekMail puede aportar dominios personalizados, buzones IMAP, catch-all, SMTP propio o administrado, reenvío, migración de buzones y acceso API bajo condiciones sin cargos por usuario. Comprueba recursos y límites vigentes, sin asumir garantías de entrega.

Si cada incidencia exige reconstruir toda la configuración, mejora el proceso o evalúa otra plataforma. En ambos casos, deja de tratar la entregabilidad como una tarea de una sola vez. La supervisión continua ayuda a detectar riesgos, no elimina todas las causas de spam.