Mejorar la entregabilidad del correo: revisión de 30 minutos

Puedes enviar, recibir 250 OK y no encontrar el mensaje en el destino. La aceptación por tu servidor de envío no confirma la entrega final ni la llegada a la bandeja de entrada. Para mejorar la entregabilidad del correo, empieza por DNS, autenticación y reputación. El manual de correo empresarial explica el modelo general; aquí tienes una guía de diagnóstico.

Cuando el correo acaba en spam, cambiar el asunto no resuelve necesariamente el problema. Un SPF incorrecto, una clave DKIM desactualizada o un fallo de alineación DMARC pueden provocar filtrado antes de la lectura. Las propuestas pueden perderse, los restablecimientos de contraseña retrasarse y las respuestas de soporte no llegar.

Esta guía te ayuda a mejorar la entregabilidad del correo con una primera revisión de unos 30 minutos. Es un tiempo orientativo para diagnosticar, no un plazo garantizado de resolución.

Revisión de 30 minutos para mejorar la entregabilidad

Revisa en orden las listas de bloqueo, las colas, SPF, DKIM, la alineación DMARC, el DNS inverso y las quejas. Así puedes identificar problemas de infraestructura antes de modificar el contenido; la relevancia del mensaje y la calidad de la lista también importan.

1. Comprueba si la IP de envío figura en Spamhaus u otra lista de bloqueo relevante.
2. Confirma si los mensajes salen de tu servidor o proveedor SMTP.
3. Revisa la sintaxis SPF y el límite de 10 términos que generan consultas DNS.
4. Verifica el selector DKIM, la longitud de la clave y el dominio firmante.
5. Comprueba la alineación DMARC, no solo la existencia del registro.
6. Verifica la correspondencia entre DNS directo e inverso y revisa las quejas por spam.

En TrekMail, consulta las pantallas de estado DNS y los registros antes de cambiarlos manualmente. Empieza por los registros DNS necesarios y después por las comprobaciones del estado DNS.

Paso 1: comprueba las listas de bloqueo de nivel 1

Si la IP figura en Spamhaus ZEN, los cambios de contenido o los reintentos pueden no resolver la causa. Contén el envío afectado, conserva las pruebas e investiga la inclusión antes de solicitar la retirada.

Ejemplo: un buzón comprometido envía malware durante 20 minutos, la IP entra en una lista y algunos destinatarios empiezan a rechazar facturas o respuestas legítimas. El alcance depende de las políticas de recepción.

Paso 2: confirma que el correo sale de tu sistema

Una cola puede reflejar un problema interno o un aplazamiento del destinatario, ambos parte del proceso de entrega. Consulta la cola del MTA o el panel SMTP y comprueba cómo define el proveedor estos estados:

• Queued: pendiente por carga, cuota, tiempo de espera o aplazamiento remoto.
• Bounced: fallo de entrega; revisa el motivo y quién lo generó.
• Sent pero ausente: verifica qué aceptación registra el estado antes de investigar el filtrado.

Comprueba DNS y autenticación en orden

SPF evalúa la autorización de la IP para MAIL FROM o HELO cuando corresponde; DKIM verifica las partes firmadas; DMARC exige autenticación alineada con From. El DNS inverso ayuda a identificar el servidor, pero no demuestra por sí solo que sea fiable ni que el mensaje vaya a entrar en la bandeja principal.

1. Revisa el límite de SPF

Dos problemas que conviene comprobar son los registros SPF duplicados y las cadenas excesivas de evaluaciones. El límite de 10 se aplica a los términos que provocan consultas DNS, incluidos los evaluados recursivamente: a, mx, include, exists, ptr y redirect. No cuenta simplemente todos los paquetes DNS ni el número de include visibles. Superarlo puede dar un error permanente.

dig txt example.com +short

Busca lo siguiente:

• Un único registro TXT de SPF para la identidad evaluada que empiece por v=spf1; sus cadenas entrecomilladas se concatenan, y otros TXT de verificación pueden coexistir.
• No uses +all: autoriza cualquier origen.
• Un cierre como ~all o -all, según una política revisada.
• Una cadena de include documentada, con sus dependencias recursivas.

Ejemplo que conviene revisar:

example.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:spf.trekmail.net ~all"

El registro podría estar dentro del límite o superarlo por las dependencias de los proveedores. Para mejorar la entregabilidad del correo, elimina autorizaciones de servicios realmente retirados. No sustituyas a ciegas sus include por IP fijas: los proveedores pueden cambiar su infraestructura.

Si envías con TrekMail, combina las autorizaciones en un registro y usa los valores actuales del panel, no copies este ejemplo como configuración vigente. La documentación explica el procedimiento. Para preparar el dominio, consulta cómo configurar correo en mi dominio.

2. Verifica el selector y la clave DKIM

La firma debe verificarse criptográficamente con el selector y la clave pública publicados, sobre las partes que cubre. Una clave antigua, un selector ausente o una rotación incompleta pueden impedirlo aunque SPF pase.

dig txt selector._domainkey.example.com +short

Comprobaciones iniciales:

• Existe el registro correcto.
• Si incluye la versión, usa v=DKIM1; su presencia no demuestra la validez de la firma.
• p= contiene una clave pública válida y utilizable, no basta con que parezca una clave.
• El firmante usa el selector correspondiente de las cabeceras, y la verificación de la firma es válida.

Ver pass en una herramienta no completa la revisión. Para usar DKIM en DMARC, el dominio firmante debe alinearse con el From visible. Otra autenticación SPF válida y alineada también puede satisfacer DMARC, incluso con un proveedor externo.

3. Comprueba la alineación DMARC

DMARC vincula SPF o DKIM con el From visible. Publicar el registro no mejora por sí solo la entrega: al menos una comprobación debe pasar y estar alineada con ese dominio.

dig txt _dmarc.example.com +short

Registro de observación ilustrativo:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Un caso a revisar: Return-Path: bounce.provider.com representa de forma abreviada el dominio de la dirección real del sobre SMTP, no una cabecera Return-Path completa válida. El proveedor firma con d=provider.com, pero el From visible es team@example.com. SPF y DKIM pueden pasar y DMARC fallar si ninguno de sus dominios se alinea. La política de observación del ejemplo no anula los demás filtros ni garantiza entrega.

Revisar cada flujo autorizado puede llevar horas si intervienen varios proveedores. En TrekMail puedes comprobar la disponibilidad de Managed SMTP en planes de pago o usar tu motor mediante BYO SMTP. Separar alojamiento y envío permite revisar el proveedor saliente sin cambiar necesariamente todos los buzones; no garantiza reputaciones independientes.

4. Confirma el DNS inverso con verificación directa

FCrDNS comprueba que el PTR de la IP de envío apunta a un nombre cuya resolución directa incluye esa IP. Los destinatarios pueden valorar esta correspondencia, pero no es una prueba de confianza ni de entrega.

dig -x 203.0.113.10 +short
dig A mail.example.com +short

Comprueba que la resolución directa devuelve la IP original; revisa también AAAA si corresponde. El propietario o proveedor de la IP controla normalmente el PTR. Solicita la corrección adecuada y verifica ambos sentidos antes de seguir intentando mejorar la entregabilidad del correo.

Supervisa las quejas por spam

Para mantener la entrega, combina autenticación y correo esperado por sus destinatarios. Google recomienda una tasa de spam inferior a 0.1% y evitar que alcance 0.3% o más. Estos valores corresponden a su métrica de dominio para Gmail personal y sus condiciones de disponibilidad, no a un indicador universal de toda la entregabilidad.

SPF, DKIM y DMARC válidos no compensan las denuncias de los usuarios. Revisa Google Postmaster Tools periódicamente, por ejemplo cada semana, y considera que un volumen insuficiente puede dejar datos sin mostrar. No confundas la ausencia de datos con la ausencia de quejas.

Como orientación para esa métrica:

• Por debajo de 0.1%: dentro del objetivo recomendado, sin confirmar toda la salud del envío.
• 0.1% - 0.3%: investiga el consentimiento, la segmentación y el contenido.
• A partir de 0.3%: pausa campañas no esenciales e investiga la causa antes de reanudarlas.

Si gestionas varias marcas, separa permisos, flujos y seguimiento. Un dominio o una firma DKIM distinta no garantizan reputación aislada: una IP u otra infraestructura pueden ser compartidas. El alojamiento de correo multidominio ayuda a organizar la gestión, pero requiere evaluar estas dependencias.

Lee el código de error antes de cambiar nada

El código y la respuesta completa del destinatario orientan el diagnóstico. Corrige la causa comprobada en lugar de hacer cambios DNS al azar que puedan añadir otro problema.

Si reenvías entre sistemas, distingue los problemas de autenticación del reenvío de la reputación del remitente. La guía de configuración y diagnóstico del reenvío explica estas rutas.

Qué no cambiar a ciegas

Evita cambios de emergencia que dificulten investigar o creen nuevos riesgos. Cambiar IP sin diagnóstico, excluir todo error temporal o editar DNS a las 2 de la madrugada puede complicar las siguientes 48 horas.

1. No cambies de IP para eludir una lista. Investiga la posible intrusión y planifica cualquier cambio autorizado; una IP nueva no garantiza confianza.
2. No excluyas un destinatario por el primer error temporal. Un 4xx requiere contexto y una política de reintentos limitada.
3. No acumules proveedores SPF: retira los que ya no envían de forma autorizada.
4. No impongas p=reject hasta verificar los flujos autorizados y la alineación que necesitan.
5. No olvides los subdominios ni las dependencias compartidas de reputación.

Dos modelos para gestionar la entregabilidad

El alojamiento y el envío pueden estar ligados o separados. Separarlos puede facilitar cambios salientes sin migrar cada buzón, aunque la compatibilidad, las cuotas y la reputación compartida siguen importando.

Modelo integrado: un proveedor controla los buzones y la infraestructura saliente. Si aparece un problema compartido, revisa las opciones reales antes de decidir una migración.

Modelo con envío separable: TrekMail reúne alojamiento, almacenamiento compartido de la cuenta con cuotas individuales y límites del plan, migración IMAP y gestión multidominio según el plan. Solo el modelo Nano descrito requiere SMTP externo propio mediante BYO SMTP para todos los mensajes salientes y las respuestas. La referencia histórica a planes de pago desde $3.50 al mes incluye Managed SMTP, sujeto a los permisos y a la configuración del cliente compatible. El periodo de prueba de 14 días para planes de pago se describe con tarjeta obligatoria. Verifica las condiciones vigentes; Nano puede servir para probar la recepción sin tarjeta cuando esté disponible, sin prometer permanencia.

Esta separación puede permitirte corregir el envío sin reconstruir el resto del sistema. La migración IMAP necesita acceso autorizado, compatibilidad, copia de seguridad y verificación de carpetas y mensajes, además de DNS y sincronización final. Los contactos y calendarios requieren una revisión aparte.

Compara licencias por usuario, cuotas compartidas y flexibilidad saliente según tus necesidades. Mantener un proveedor propio de envío permite gestionar ese componente, no garantiza una reputación independiente ni evita todos los riesgos compartidos.

Conclusión: empieza por las comprobaciones verificables

Para mejorar la entregabilidad del correo, revisa SPF, las firmas DKIM, la alineación DMARC, el DNS inverso, las quejas y los servicios autorizados. Estas pruebas ayudan a localizar errores; la calidad y el consentimiento de los destinatarios siguen siendo esenciales.

Si quieres mejorar la entregabilidad del correo con un modelo multidominio, compara las cuotas de almacenamiento, las condiciones de migración IMAP y las opciones BYO SMTP o Managed SMTP del plan. La página de precios de TrekMail permite comprobar los términos actuales y posibles cargos.

Consulta las preguntas frecuentes sobre requisitos para remitentes de Google y la especificación SPF en RFC 7208. Si persiste el problema, obtén las cabeceras y los registros pertinentes con autorización y analiza la cadena de errores, sin sustituir las pruebas por suposiciones.